JMETER | Max Virtual Users Capacity

Question

Can some be kind enough to let me know how many Virtual User loads maximum can JMeter machine can handle?

If we consider a machine with unlimited PROCESSOR, RAM.

Answer 1

It would be something like 2,147,483,647 (maximum value of a 32-bit signed integer) for a single instance.

If you go for Distributed Testing - you will be able to have that many for each JMeter Slave engine.

Answer 2

There is no "unlimited PROCESSOR , RAM" but even if there was , there would be at least 3 additional factors:

• Disk
• Network
• Potential issue at that scale

Theorically, since number of thread is an Integer, the possible max value is Integer.MAX_VALUE, but this is absurd.

It's impossible to answer your question since number of threads depend on many factors, see this answer:

• What is the highest number of threads that is reasonable to simultaneously run in Jmeter?

You should always calibrate on 1 machine to see how much threads your plan can handle by watching CPU, swap ...

Then you can increase number of Machines by using a Cloud solution or Distributed testing.

If you'd like to learn more about load testing, this book can help you.

Answer 3

Agreed, there are really too many variables here in play to provide an answer. As each virtual user in play takes up some amount of resource from the finite resource pool of CPU, DISK, MEMORY and NETWORK, how your virtual user is constructed makes a significant difference.

Your underlying hardware has an impact as well. For instance, for ethernet, if you are in a collision domain vs switched, you may find that once you exceed 35% of your resource pool for network that your error and busy rates increase, dropping your throughput where you may have other resources available.

Other examples, you will typically experience some level of queuing on the CPU once you hit 85% CPU. Will it be noticeable? Perhaps if is a busy host, then causing your virtual users to slow. Heck, I have even observed a poorly constructed disk interface for fiber channel pin all interrupt service to processor zero on a 8 way box. Once zero was saturated, all other scalability was done.

In general practice, maxing the box is a bad idea because of the problem of delays imposed on virtual users as the resource pool shrinks, with the OS then having to broker higher access to the limited remaining pool. This is true for all of the finite items. As a general rule of thumb, I never run a test with fewer than three hosts: Two for primary load and one for a control set of a single virtual user of each type. This helps me to understand within a test execution cycle if my hosts are causing delays in my virtual users, as both the control group and the non-control hosts should degrade at the same rate. If they do not, then there is a host problem that needs to be addressed.

Another rule of thumb I try to adhere to is no more than 50% of the available resource pool in use on the load generator hosts during the execution of the test. I am more conservative than my peers in this case, who will often push to 75-80%. I want tests that are consistent, repeatable and highly defensible when I find an issue. Developers are like parents - When you find a problem with their code it becomes natural for them to blame the test. They can pick my tests apart all day long and they will find nicely documented control factors, repeatability, documented initial conditions, checking for expected data results (not just HTTP 200). The test doesn't need glasses, your code (child) is ugly.

Answer 4

Let's check it in practice:

1. For the simplest empty Test Plan add Debug Sampler.

2. Set Number of Threads to 2147483648 (Integer.MAX + 1) and run the test. JMeter shows log:

   INFO o.a.j.e.StandardJMeterEngine: Starting 0 threads for group Thread Group.

3. Set Number of Threads to 2147483647 (Integer maximum value). Test run successfully

   INFO o.a.j.e.StandardJMeterEngine: Starting 2147483647 threads for group Thread Group.

So, 2147483647 — that is how many threads JMeter can start at one machine.

But what if we run Remote testing, considering you may scale your JMeter test in the cloud services:

Note: The same test plan is run by all the servers. JMeter does not distribute the load between servers, each runs the full test plan. So if you set 1000 Threads and have 6 JMeter server, you end up injecting 6000 Threads.