Important Metrics for Running Higher Concurrent Users

The most important metrics to consider when trying to run a higher number of concurrent users are:

  • Hits per second (hits/s) and
  • Response time.

The above two KPIs are directly related.

In the above screenshot: Max Users refers to the maximum concurrent (simultaneous) users running during the test. For example, if you successfully run a 100-user test, then see a value of 50 for Max Users, that means 50 of the 100 users ran simultaneously. This is therefore an important metric to watch when trying to increase the number of users executing at the same time.

Hits per second (hits/s) measures throughput in terms of how many hits all of your users can get within one second. The higher this number, the more concurrent users you can have running simultaneously. (More concurrent users = more hits/s).

The most important thing to understand is that hits/s is entirely dependent on your server's response time. The faster your application server can respond to BlazeMeter (the lower the response time), the higher hits/s you can achieve, and thus the more users you can get running simultaneously.

The converse is also true: the slower your application responds (the higher the response time), the lower hits/s will be, and thus the fewer users you can have running at once.

If you find your throughput to be lower than desired, then we recommend investigating your application server and network to see what may be responsible for the slower response times when your server tries to respond to requests sent to it from BlazeMeter cloud engines.

Note: BlazeMeter only reports these metrics as observed by the engine from the location/provider you selected. BlazeMeter does not in any way impact or interfere with these metrics; it only reports them. For example, BlazeMeter has no control over response time. In other words, BlazeMeter only observes how long it took for the engine to receive a response from your application server; BlazeMeter cannot interpret why the response time was the value reported, because that is information that can only be determined by investigating on your application server's or internal network's end.