The main problem is that JMeter doesn't have a built-in feature to identify how Response Time changes with amount of parallel threads. But what if we need to measure this metric in scope of performance testing? There is a nice Response Times vs Threads plugin for JMeter. However this plugin works only with the version of JMeter starting from 2.4 and it is hard to integrate it with Continuous Integration servers. And what if we have the bunch of scripts already implemented for the older 2.3.4 version or just looking for alternative solution that is easier to integrate with our Continuous Integration server? Chronos plugin for Maven would be a good match. Integration of Maven and Chronos with JMeter had been already described in this post
This what I suggest to change in your JMeter script:
- In "Thread group" properties set the "Number of Threads" value to 300.
- Set "Stop Test Now" behavior in case of Sample error. This will help to avoid excessive requests when your application cannot handle the simulated number of parallel threads anymore.
- Set the "Ramp-Up Period" value to 300.
- Set "Loop Count" to "Forever" this will simulate constant load produced by parallel users, the number of parallel users will grow +1 each second, until it reaches 300, this will be in 5 minutes.
- In "Scheduler" the end time must be 5 minutes after the start time, this will guarantee that the test will end in 5 minutes.
Chronos report will include response time over time graph and the graph that shows the number of active threads. If we compare both graphs we can see what response time corresponds to what number of parallel users. This approach helps us to find the peak number of parallel users that leads to performance degradation where the response time is becoming lower than the acceptable level for our web application. This level can be different for different pages depending on their functionality. This is a simple strategy for JMeter to find the maximum number of parallel users supported by web application. You can play with the configuration a bit, for example you could try to increase ramp-up period, decrease or increase number of threads, this will help you to match the configuration with your test environment.