What is the max number of concurrent users a JMeter can handle?

JMeter has no built-in maximum number of concurrent users. Each virtual user is one Java thread, and the ceiling on one machine is set by its CPU, the JMeter heap (1 GB by default), the network and how heavy each thread’s work is. A laptop that struggles at a few hundred busy threads in the GUI can usually run many more in CLI mode with think times. The only reliable number is the one you measure on your own load generator, and this post shows how.

Key takeaways

• There is no fixed JMeter thread limit. Any number you read online, including the ones in this post, is a rule of thumb for one kind of test on one kind of machine.
• Think time changes everything: a thread that waits 5 seconds between requests costs a fraction of one that fires requests back to back.
• Run in CLI mode, disable listeners, raise the heap and save CSV results. That is what lets one machine run its real maximum.
• Calibrate: step the thread count up while watching the generator’s CPU and memory, stop below saturation, and spread anything larger over several machines.

How many threads can JMeter run on one machine?

As many as the hardware and the test plan allow. The JMeter manual says your hardware and your test plan design both decide how many threads you can effectively run, and that a faster server makes JMeter work harder, because responses come back sooner. There is no setting that caps the count; you hit CPU, memory or operating system limits first.

For orientation only, as rough rules of thumb rather than measurements:

The 2013 version of this post gave 200 to 300 threads as the ceiling. That was never a JMeter limit, and it does not describe JMeter 5.6.3 on current hardware with a current Java. Treat the table above the same way: it tells you where to start measuring, not where to stop.

What limits the number of concurrent users in JMeter

Four resources run out, and the test plan decides which one goes first. CPU goes first on plans with no think time, heavy extractors or scripting. Heap goes first on plans that keep results in listeners or handle large responses. Operating system limits on threads and open sockets appear on very large runs. Network bandwidth goes first when responses are big.

• CPU. Every request means building it, parsing the response, running extractors and assertions, and writing a result line. Once the generator’s CPU is saturated, JMeter’s own measurements slow down, and response times in your report include time spent waiting inside JMeter.
• Heap memory. JMeter starts with -Xms1g -Xmx1g unless you change it. View Results Tree, large response bodies and big CSV data sets all live in the heap. Long garbage collection pauses distort timings well before an OutOfMemoryError stops the test. See how to increase the heap size in JMeter.
• Threads and sockets. Each thread is a real operating system thread, and each keep-alive connection holds a socket. On Linux and macOS, ulimit -u (processes and threads) and ulimit -n (open files) can stop a large run with an OutOfMemoryError saying JMeter is unable to create a native thread, even when the heap has room.
• Network. A 1 Gbit/s link moves at most about 125 MB per second. A test that downloads 500 KB pages hits that limit at roughly 250 page loads per second, however many threads you add.

Why think time decides how many users one machine can simulate

A JMeter thread without timers sends its next request the moment the last one finishes, so it behaves like many real users at once. Add a realistic pause and the same thread mostly sleeps, which costs almost nothing. That is why the thread count alone tells you little about the load a machine can generate.

Little’s Law links the three numbers: threads = requests per second x (response time + think time). For 100 requests per second with 0.5 seconds of response time and 4.5 seconds of think time, you need 100 x 5 = 500 threads, and the generator handles 100 requests per second. Take the timers out and those 500 threads would try to send 500 / 0.5 = 1,000 requests per second, ten times the work, for the same “500 users”. The guide to calculating concurrent users walks through the same arithmetic from analytics data.

How to find the maximum threads for your own machine

Calibrate once per test plan and machine type. Run the real plan in CLI mode against a target that can take the load, step the thread count up, and watch the load generator rather than the application. The highest step at which the generator stays comfortably below saturation, and its numbers still agree with the server’s own metrics, is your per-machine ceiling.

1. Run in CLI mode with listeners disabled: jmeter -n -t plan.jmx -l results.csv. The manual is blunt about it: do not run load tests in GUI mode. See how to start JMeter in non-GUI mode.
2. Give JMeter more heap, for example HEAP="-Xms4g -Xmx4g -XX:MaxMetaspaceSize=256m" jmeter -n -t plan.jmx -l results.csv on macOS or Linux. Leave memory for the operating system.
3. Step the load: run, say, 250, 500, 1,000 and 2,000 threads, each with a gradual ramp-up period, and record the generator’s CPU, memory and network for every step (top, Activity Monitor or your cloud provider’s metrics).
4. Stop below saturation. A common rule of thumb is to keep the generator’s CPU under about 75 to 80%. Above that, compare JMeter’s response times with the server’s: if JMeter reports slower responses than the server measured, the generator is the bottleneck.
5. Plan with a margin. Use roughly three quarters of the measured ceiling per machine in the real test, and add machines for the rest.

The manual also mentions the Java Request sampler’s JavaTest class, which needs no network, as a way to see the most a given machine can push. The Thread Group’s Delay Thread creation until needed option helps when a plan has many threads that start late in the test, because threads are only created when they are about to run.

How to raise the per-machine ceiling

The JMeter best-practices page lists what reduces the cost of each thread. In practice these make the biggest difference:

• Remove or disable View Results Tree and View Results in Table during load tests. Keep them for debugging.
• Save results as CSV with only the fields you need, through -l, rather than through several listeners writing files.
• Use as few assertions and regular expression extractors as the test allows.
• Write scripts in JSR223 elements with Groovy and Cache compiled script if available ticked, rather than BeanShell.
• Prepare test data in files read by a CSV Data Set Config instead of generating it at run time.
• Use a current Java release supported by JMeter. JMeter 5.6.3 needs Java 8 or later; the manual advises the latest version JMeter supports.

When to distribute the load across several machines

Once the calibrated per-machine number is below your target, add machines rather than tuning one box further. The JMeter manual suggests running several CLI instances on several machines, either in JMeter’s distributed mode, where a controller starts the test on remote servers with -r or -R and collects the results, or as independent instances whose result files you merge afterwards. Distributed mode needs the same JMeter and Java versions on every node and an open network path back to the controller, which is the part most setups struggle with. More in running a JMeter distributed test in the cloud.

Running JMeter tests past one machine with LoadFocus

LoadFocus JMeter load testing takes your existing .jmx file and CSV data files, spreads the threads across cloud load generators in up to 25 regions, and shuts them down when the test ends, so there is no controller or remote server setup to maintain. Results stream back while the test runs and break response times, throughput and errors down by location. The Free plan runs 10 virtual users for 60 seconds, and paid plans go from 250 to 20,000 concurrent users per test (pricing, October 2026). On paid plans you also choose what share of the users each region sends.

Frequently Asked Questions

What is the maximum number of threads in JMeter?

There is no hard-coded maximum. The limit comes from the machine: CPU, heap, operating system thread and file limits, and network bandwidth. On a modern multi-core machine in CLI mode with realistic think times, a few thousand threads is often possible; a heavy plan with no think time may saturate the same machine at a few hundred.

Is a JMeter thread the same as a concurrent user?

A JMeter thread is one virtual user that runs the Thread Group’s samplers in a loop. It matches one real concurrent user only when the plan includes realistic think time. Without timers, one thread sends requests far faster than a person would, so 100 threads can generate the traffic of many more real users.

How much memory does JMeter need per thread?

There is no fixed figure, because memory depends on response sizes, extractors, data sets and listeners rather than on the thread count alone. Start from the 1 GB default, run a calibration step, and watch heap usage and garbage collection pauses. Raise the heap when usage stays high, leaving room for the operating system.

Can JMeter simulate 10,000 users?

Yes, but usually not from one machine. Measure what one load generator sustains for your plan, then spread the rest over several machines with JMeter’s distributed mode, independent CLI instances or a cloud service that runs your .jmx file. Running all 10,000 threads on one box mostly measures the box.

Why does JMeter say it is unable to create a native thread?

The operating system refused to create another thread. On Linux and macOS this usually means the per-user process or thread limit (ulimit -u) is too low, or the machine is short of memory for thread stacks. Raise the limit, lower the thread count per machine, or distribute the test.

Sources

• Apache JMeter user manual, Best Practices (hardware and plan decide the thread count, faster servers load JMeter more, reducing resource usage, distributed and independent instances, JavaTest sampler, delayed thread creation), read 23 October 2026.
• Apache JMeter user manual, Getting Started (1 GB default heap, HEAP variable, CLI mode, Java 8 or later, -r and -R), read 23 October 2026.
• Apache JMeter user manual, Remote Testing (same JMeter and Java versions on every node, RMI ports and firewalls), read 23 October 2026.
• Apache JMeter, bin/jmeter in the 5.6.3 source (default -Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m), read 23 October 2026.
• Apache JMeter, download page (5.6.3, “Requires Java 8+”), read 23 October 2026.
• LoadFocus, JMeter Load Testing and Pricing, read 23 October 2026.

Related reading

• Measuring Latency for Different Regions of the World
• How To Use Apache JMeter To Load Test a Web Server
• Run JMeter Distributed Test in the Cloud
• Calculate concurrent users for load tests

Run this JMX in the cloud, from 25+ regions

Upload your JMeter script to LoadFocus and run it with thousands of virtual users from 25+ cloud locations, with no load generators to manage. Results show p95/p99 response times, throughput and errors per request, and a free tier is included.

JMeter Cloud Load Testing

Free API Load Test