Hey Amit, let's break down your questions step by step—this thread group behavior is super common to get confused about when moving beyond the basic Normal Thread Group.

Why do Concurrent/Ultimate Thread Groups show inconsistent sampler counts vs. Normal? #

First, let's clarify how each thread group operates:

• Normal Thread Group: It strictly follows your user count (200) and ramp-up time (60s) to start threads. Each thread runs through all your samplers repeatedly (unless you set a fixed loop count or duration). That’s why every sampler ends up with exactly 200 samples—each user runs every sampler the same number of times.
• Concurrent Thread Group (now rebranded as Stepping Thread Group) & Ultimate Thread Group: These are "advanced" thread groups focused on controlling dynamic concurrency levels, not just fixed user counts. When you set 200 users over 60s ramp-up, they’ll gradually scale to 200 concurrent threads, but thread lifecycles and loop logic work differently. For example, if a sampler runs fast, a thread might finish early and exit before running all samplers again. Or if you haven’t configured a fixed duration/loop count, threads might terminate once they complete their initial pass. These groups prioritize "concurrent load" over "fixed user iterations," so sampler counts won’t always match your user number.

Which thread group should I use for high-user load testing? #

For real-world high-volume load testing (simulating gradual user traffic, sustained concurrency, or realistic traffic spikes):

• Prioritize the Concurrent/Stepping Thread Group. It lets you model realistic traffic patterns (ramp up, steady load, ramp down) which matches how real users interact with systems (they don’t all log in at the exact same time). It’s also more resource-efficient for large user counts (thousands+) because it avoids the sudden thread spike that can crash JMeter itself with the Normal Thread Group.

If your test requires exactly N users to run a fixed set of samplers once (like a batch of users completing a single workflow), the Normal Thread Group works—but for high volumes, make sure your ramp-up time is long enough to avoid overwhelming JMeter.

The Ultimate Thread Group is only necessary for complex multi-phase scenarios (e.g., 100 users for 10 mins, add 100 more for 20 mins, then ramp down gradually). For most standard high-load tests, Concurrent Thread Group is simpler and sufficient.

Recommended Learning Resources #

• JMeter: The Complete Guide: Covers everything from basics to advanced load testing, with deep dives into thread group use cases and best practices.
• Performance Testing with JMeter 3: Focuses on practical, real-world testing—including tuning JMeter for high user counts and optimizing thread group configurations.
• JMeter’s official documentation: Search for "Thread Groups" in the official docs; it has detailed explanations and configuration examples for every thread group type.

Key Performance Benchmark Metrics (What Indicates a Problem?) #

Here are the core metrics to monitor—if these fall outside acceptable thresholds, your system has a performance bottleneck:

• Response Times:
  • Average response time: Exceeds your business’s acceptable limit (e.g., <2s for general web apps, <1s for critical transactions).
  • 95th/99th percentile response time: If these are drastically higher than the average, it means a large portion of users are experiencing slow performance, indicating poor system stability.
• Throughput:
  • Transactions Per Second (TPS): Falls below your expected peak business demand—this means the system can’t handle the required volume of work.
  • Requests Per Second (RPS): Can’t keep up with concurrent user requests.
• Error Rate:
  • Sampler error rate exceeds 1% (adjust based on business needs; critical transactions should have 0% errors). High error rates mean the system breaks under load.
• Server Resource Utilization:
  • CPU: Sustained usage over 80% indicates CPU is a bottleneck.
  • Memory: Sustained usage over 85% (with no garbage collection relief for Java apps) points to memory leaks or unoptimized resource handling.
  • Disk I/O: IOPS exceed the disk’s rated capacity, or disk queue length stays above 2—disk is slowing down the system.
  • Network Bandwidth: Sustained usage near the network limit means network is constraining performance.
• Thread/Connection Pools:
  • Application server thread pools or database connection pools are fully utilized, with long wait queues—this means the system can’t handle more concurrent requests.

内容的提问来源于stack exchange，提问作者AMIT GUPTA