JMeter Concurrent Users Count Practice
I have a web application which is working in production and there are 2000+ users of my application. Now I have to perform performance testing on the system so is there any idea how many concurrent users will be sending requests at a single time? It is presumed that not all the 2000+ users hit the server at the same time. I am going to use JMeter for load testing of my system so how many concurrent users should I assume must be hitting the server at the same time? Is there any practice being followed in the world or it varies application-to-application? Any help is welcomed.
As far as I can tell, you are trying to answer the question "How do I take the information I have from usage of my current system - number of concurrent users and hits per second - and convert that into how many concurrent threads in JMeter?". I'll answer the best I can, if that is not your question, please correct me. Tools like JMeter don't allow you to simply tell it "Hit this page X times in Y seconds", instead they execute tests as quickly as they can and you throttle the total number of hits per second by increasing and decreasing the number of threads. You can have a number of goals for your stress testing, one of them may be "ensure we can continue to support the current production load". For this case, you generally need to experiment a bit with how many threads until you hit a number that will generate approximately the same amount of load you would see in your production environment. It is not guaranteed that if you run the tests for any amount of time that the requests per second will stay consistent. For example, if there is a slow memory leak in your application, the number of requests per second from your tests may decrease over time as it begins taking longer and longer to get responses back. I have experimented with writing tests that will send only 1 request per X seconds so that I can "throttle" the requests to an exact number. You can do this by starting a timer, sending a request, getting a response and then sleeping until the timer hits X seconds. Then, you can pretty easily calculate how many threads you would need to execute in order to get an exact number of requests per second. I will say that after experimenting with this approach I stopped using it because it really didn't add much value. I could usually meet all of my stress testing goals without using this trick.