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
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.