How Can I Achieve a Higher Count of Concurrent Users?

The most important metrics to consider when trying to achieve a higher number of concurrent users is:

• hits per second (hits/s) and
• response time.

The above two KPIs are directly related.

First, a note about the Max Users measurement, as seen in the above screenshot: Max Users refers to the maximum concurrent (simultaneous) users achieved during the test.  For example, if you successfully run a 100-user test, then see a value of 50 for Max Users, that means of the your 100 users that ran, 50 of them 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 in 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 responses times when your server tries to respond to requests sent to it from Blazemeter cloud engines. 

Note: Please be aware that 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 know why response time was the value reported, as that is information that can only be determined by investigating on your application server's or internal network's end.