what is the maximum number of threads in JMeter from a single machine? I know there is a dependency for hardware configuration. I'm using this hardware configuration:

Command: #lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                24
On-line CPU(s) list:   0-23
Thread(s) per core:    2
Core(s) per socket:    6
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 44
Stepping:              2
CPU MHz:               1600.000
BogoMIPS:              5333.19
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              12288K

Can anyone suggest me what will be the maximum number of threads for this hardware configuration?


3 Answers 3


This does not only depend on the CPU of the computer, but also the operating system, memory and maybe disk IO speeds.

There is only one way to find out and that is to try and ramp up until either the tests are failing or the computer crashes. Be assure to use a simple site that you know it can handle more than you expect your single JMeter instance can.

There have been numerous similar question on the Stack Exchange network, I suggest you read them:

This blog also has some good suggestion of the limits and how to handle them.


How many threads you will get depends on the resources consumed by each thread, both on the JMeter host and on the system under test. This is turn is dependent on the content of your test plan and the nature of your samplers and the target application.

Considering only the JMeter resource consumption, if you find that the JMeter host can't handle the number of threads you want the resolution is the same as for running out of memory: more of the resource, simpler test plan, less threads, or JMeter server. (Some test plan elements are known to be resource consumptive - see the User Manual.) we can generate 5000 or more threads through multiple system with jmeter on a server this is lie in distributed testing and plot a single graph.

Either you can simply used 100 threads with loop count 2-3 or 4....etc. it means the total no. of executed threads are multiplied by loop count. Having said that, 2000 or more threads is a pretty large number, so I'm not entirely surprised that there are memory problems. Some OSes have limits to the number of open sockets, even if memory is not a problem.

That number of threads is also potentially a huge load on whatever server is under test - do you really need to run with 7000 threads? as a work-round:

  • use non-GUI mode
  • remove all but one listener
  • use CSV output
  • minimise assertions
  • use multiple independent jobs, and combine the results.

Number of threads in thread group can be up to java.lang.Integer.MAX_VALUE which is 2,147,483,647 but in fact it depends on multiple factors:

  • Amount of your total physical RAM
  • Number of Pre/Post Processors and Assertions (they all have cost)
  • Throughput (50 threads active 100% of time can produce the same load as 500 threads active 10% of time)
  • Specific of the application under test (response time, response size, protocol, etc.)

Follow recommendations from 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article to get the most of single JMeter instance. And don't forget that JMeter can be run in distributed mode (if one machine is not capable of generating enough virtual users you can make a "cluster" of several JMeter machines)

  • third point (50 threads vs 500 threads) is not correct. You have to calculate with context switching, which is relatively expensive. Prefer 1 thread (working like in Quake 3 for example :) over 50 threads, which are busy switching and scheduling between them.
    – Lubo
    Apr 6, 2020 at 7:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.