One of the most practical questions you will face in real projects is: "How many machines do I need for this test?" And the answer, like most things in testing, is "it depends." But I can give you a framework to figure it out systematically instead of guessing.
The number of virtual users a single machine can handle depends on your test script complexity. A simple HTTP GET test with no assertions is very different from a scripted e-commerce checkout flow with SSL, JSON extraction, assertions, timers, and CSV parameterization.
| Test Complexity | Description | Users per Machine (4-core, 8GB) | Users per Machine (8-core, 16GB) |
|---|---|---|---|
| Light | Simple GET/POST, no SSL, no assertions, no timers | 1,500-2,000 | 3,000-4,000 |
| Medium | SSL/TLS, basic assertions, JSON extraction, 3-5 requests per flow | 800-1,200 | 1,500-2,500 |
| Heavy | Full browser-like flow with correlation, CSV data, multiple extractors, assertions, think times | 300-600 | 800-1,200 |
| Very Heavy | WebSocket, large file uploads/downloads, heavy scripting (Groovy/BeanShell) | 100-300 | 300-600 |
Step 1: Determine target concurrent users
Target = 10,000 concurrent users
Step 2: Run a baseline test on a single machine
- Start with 100 users and increase by 100 every 2 minutes
- Monitor: CPU, RAM, JMeter response times vs actual response times
- The ceiling is when CPU > 80% or JMeter times diverge from actual
- Baseline result: 800 users per machine (before degradation)
Step 3: Apply a safety margin (20-30%)
Safe capacity = 800 x 0.75 = 600 users per machine
Step 4: Calculate number of workers
Workers needed = Target / Safe capacity = 10,000 / 600 = 16.7
Round up = 17 workers
Step 5: Add contingency (1-2 spare machines)
Final count = 17 + 2 = 19 workers + 1 master = 20 machines total
Step 6: Verify
19 workers x 600 users = 11,400 user capacity
Thread count in JMX = 10,000 / 19 = 527 threads per worker
Well within the 600 safe capacity -- good to go!Set up ONE worker machine with your exact test plan (all the correlation, parameterization, and assertions you plan to use)
Configure a Thread Group with 100 threads and a Stepping Thread Group or use a simple ramp-up
Run the test while monitoring the WORKER machine (not the target): CPU, RAM, JMeter heap
Increase thread count in increments of 100 and re-run, observing when CPU crosses 80%
Compare JMeter-reported response times with actual response times (curl from another machine)
When JMeter times are 20%+ higher than actual, you have hit the worker capacity ceiling
Record this number as your raw capacity. Apply 25% safety margin for production tests.
This is your users-per-machine number. Divide target users by this to get worker count.
The master machine does not generate load, but it has its own resource demands: collecting results from all workers, writing to the JTL file, and managing RMI connections. For most tests, a machine similar to the workers works fine. For very large tests (10+ workers, 50,000+ total users), give the master extra RAM for result aggregation.
| Number of Workers | Master CPU | Master RAM | Master Disk |
|---|---|---|---|
| 2-5 | 4 cores | 8 GB | SSD, 50 GB free |
| 5-10 | 4 cores | 16 GB | SSD, 100 GB free |
| 10-20 | 8 cores | 16-32 GB | SSD, 200 GB free |
| 20+ | 8+ cores | 32 GB | SSD, 500 GB free (result files get large) |
Always run the baseline capacity test with SSL enabled and your full test script (including assertions and extractors). A simplified script gives artificially high capacity numbers that fall apart in the real test. Test as you fly, fly as you test.
Q: How would you plan the infrastructure for a performance test requiring 20,000 concurrent users?
A: I would follow a systematic capacity planning process. First, I would run a baseline test on a single worker with the actual test script (not simplified) to determine per-machine capacity. Assuming the script is medium complexity with SSL, I would expect around 1,000-1,200 users per machine (8-core, 16GB). Applying a 25% safety margin gives ~800 users per worker. 20,000 / 800 = 25 workers. I would provision 27 workers (2 spares) plus a beefed-up master (8 cores, 32GB RAM, SSD). That is 28 machines total. Each worker would get at least 16GB RAM with 4GB allocated to JMeter JVM heap. I would also calculate bandwidth: if the test generates 3 requests/sec at 30KB average response, each worker needs 800 x 3 x 30KB = 72 MB/s -- within 1 Gbps NIC capacity. For cloud-based infrastructure, I would use EC2 c5.2xlarge instances (8 vCPU, 16GB), costing roughly $0.34/hr each. A 1-hour test run would cost about $10 in compute -- far cheaper than the alternative of maintaining physical hardware.
Key Point: Run a baseline test on one machine to find your per-worker capacity. Apply 25% safety margin. Divide target users by safe capacity to get worker count. Add 1-2 spare machines.
Key Point: Run a single-machine baseline, apply 25% safety margin, divide target users by safe capacity. Always test with your actual script, not a simplified version.