Symptom:
My average response time for a test is higher than what was expected or desired.
Examples:
- A BlazeMeter test has a higher average response time than the same test run locally.
- Two different BlazeMeter tests show different average response times.
- Two runs of the same BlazeMeter test show different average response times.
- Tests run from different locations or engine providers show different average response times.
Reason:
The last section of this article will touch on each of the above scenarios, but first, let's explore an overall explanation of where BlazeMeter fits into the picture.
BlazeMeter is Merely the Messenger
BlazeMeter only reports these metrics as observed by the engine from the location or provider you selected. BlazeMeter does not in any way impact or interfere with these metrics; it only reports them. BlazeMeter has no control over response time, nor does BlazeMeter affect actual response times. (Mock Services can Simulate Irregular Response Latencies in addition to the response time.)
Waiting for a Call Back
When you run a test from BlazeMeter, the system can only know how long it took your application server to respond; it doesn't know why it took as long as it did.
Solution:
To find out why your application server took as long to respond to the test engines as it did, investigate your own server and network internally with the appropriate teams that can help you troubleshoot. Here are some pointers to help you get started.
(1) A BlazeMeter test has a higher average response time than the same test run locally:
BlazeMeter's engines are in different geographical locations and on different networks than your local machine, so response times are not comparable between the two. If your local machine is on the same network as your application server, data has less distance to travel. There will always be a difference between the routes from each engine to your server compared to from your local machine to your server.
To test locally, set up a Private Location: your own BlazeMeter engine which you install within your own network.
(2) Two different BlazeMeter tests show different average response times:
There are many reasons why response times may differ between two different tests. For example, expect a multi-test to experience higher response times than a single test. A more complex script puts a heavier strain on your application server or your network, resulting in bottlenecks that affect response time. Keep in mind that no two test scripts are alike, so some differences are inevitable.
(3) Two runs of the same BlazeMeter test show different average response times:
It's not uncommon for two runs of the same test to have considerably different average response times. If this happens, work with your application server and network teams to investigate what conditions differed between the time frames of the two runs. It's possible an internal server or network issue caused a momentary delay in getting responses out to BlazeMeter's engines.
(4) Tests run from different locations or engine providers show different average response times:
Variances in response times are to be expected, because (a) data sent to engines in two different geographic locations travels different routes and (b) different providers (Google, AWS, Azure) provide different machines, and though they are comparable, they are not exactly the same.
In case of the former, if the difference in response times is severe, you may need to work with your network team internally to identify bottlenecks in sending data to some locations versus other locations.
