In the last chapter you created a basic Thread Group with 10 users, a ramp-up, and a loop count. That is the "Hello World" version. In real projects, you will need much finer control over how users arrive, how long they stay, and how they behave. Think of a Thread Group as the casting director of your performance test -- it decides who shows up, when, and how many times they perform their scene.
The default Thread Group has three knobs: Number of Threads, Ramp-Up Period, and Loop Count. But there is a fourth option most beginners ignore: the "Duration" and "Startup delay" checkboxes at the bottom. When you check "Duration", the test runs for a fixed time regardless of loop count. This is how real load tests work -- you say "run for 30 minutes" instead of "run 100 loops".
| Setting | What It Controls | Real-World Example |
|---|---|---|
| Number of Threads | Total virtual users | 100 users for a load test, 500 for stress |
| Ramp-Up Period | Time to start ALL users | 100 users over 60 seconds = ~1.7 users/sec |
| Loop Count | How many times each user repeats | 10 loops = each user runs the scenario 10 times |
| Duration (seconds) | Total test runtime (overrides loops) | 1800 = 30 minute test |
| Startup Delay | Wait before starting this group | 60 seconds -- let another group warm up first |
| Same user on each iteration | Reuse cookies/sessions across loops | Checked = one login, many actions. Unchecked = fresh login each loop |
| Delay Thread creation | Create threads only when needed | Saves memory in long ramp-ups |
The ramp-up period is deceptively simple. It is just one number -- but getting it wrong changes your test type entirely. Here is the thing most beginners miss: ramp-up = 0 is not a load test, it is a spike test. All users hit at once. Ramp-up = total_threads is the "gentle" approach -- one user per second.
# Formula: users_per_second = threads / ramp_up_seconds
# Gentle ramp (load test):
100 threads / 100 seconds = 1 user/sec
# Moderate ramp:
100 threads / 20 seconds = 5 users/sec
# Aggressive ramp (stress test):
100 threads / 5 seconds = 20 users/sec
# Spike test:
100 threads / 0 seconds = ALL AT ONCE
# Recommendation for load tests:
# ramp-up = 10-20% of total test duration
# For a 30-minute test with 100 users: ramp-up = 180-360 seconds (3-6 minutes)The default Thread Group ramps up linearly -- that is, all users arrive at a constant rate. But real traffic does not work like that. The Stepping Thread Group (available via the JMeter Plugins Manager) gives you staircase patterns. Think of it like adding people to a conference call: 10 join, wait 30 seconds to see if things are stable, then 10 more join.
This is incredibly useful for finding the breaking point. You can see exactly at which user count the response times start degrading. With a linear ramp-up, everything blurs together.
The Ultimate Thread Group (also from the Plugins Manager) gives you complete control. You define rows, and each row specifies: start N threads, after M seconds delay, ramp up over X seconds, hold for Y seconds, then shut down over Z seconds. You can create any traffic shape -- morning spike, lunch peak, gradual evening decline.
# Row format: [Start Threads] [Initial Delay] [Ramp-Up] [Hold] [Shutdown]
# Morning spike:
Row 1: 50 threads, 0s delay, 60s ramp-up, 300s hold, 30s shutdown
Row 2: 30 threads, 120s delay, 30s ramp-up, 240s hold, 30s shutdown
# Result: 50 users start ramping immediately over 60s, hold for 5 min.
# After 2 minutes, 30 more users start ramping over 30s.
# Peak = 80 concurrent users.
# Then both groups shut down gradually.Here is where it gets interesting. The regular Thread Group defines concurrent users. But what if you want to define arrivals per second instead? The Arrivals Thread Group (also from Plugins) says "I want 10 new users to START the scenario every second" regardless of how long each scenario takes. This is closer to how real web traffic works -- people arrive at a rate, they do not coordinate with each other.
The Arrivals Thread Group can overwhelm your machine. If you set 10 arrivals/sec but each scenario takes 30 seconds, JMeter needs 300 concurrent threads. Monitor your machine resources -- CPU, memory, and network -- when using arrivals-based models.
Download the Plugins Manager JAR from https://jmeter-plugins.org/install/Install/
Place the JAR in your JMeter lib/ext/ directory.
Restart JMeter.
Go to Options → Plugins Manager.
Search for "Custom Thread Groups" and install.
Restart JMeter. You will now see Stepping, Ultimate, Arrivals, and other thread groups under Add → Threads.
Q: What types of Thread Groups have you used in JMeter, and when would you use each?
A: I use the regular Thread Group for simple load tests and CI pipeline smoke tests -- set 50 users, 60-second ramp-up, run for 10 minutes. For finding breaking points, I use the Stepping Thread Group: start with 20 users, add 20 more every 60 seconds, and watch where response times degrade. For realistic production simulations, I use the Ultimate Thread Group because it lets me model traffic patterns -- morning ramp, peak hours, afternoon decline. When the SLA is defined in requests per second rather than concurrent users, I use the Arrivals Thread Group. The key difference is that concurrent thread models tie throughput to response time, while arrivals models maintain a constant request rate regardless of server speed.
Key Point: The default Thread Group is fine for basics. For real projects, use Stepping (find breaking points), Ultimate (model traffic patterns), or Arrivals (constant request rate). Install them via the Plugins Manager.
Key Point: Thread Group types: Regular (basic), Stepping (staircase), Ultimate (custom shapes), Arrivals (request rate). Ramp-up controls your test type.