One field, one number, and a lot of hidden meaning.

The simple definition

A thread in JMeter is one independent worker that runs your test plan from top to bottom. When you type 100 in the Number of Threads field of a Thread Group, JMeter starts 100 such workers. Each worker takes the list of steps you designed, such as open the home page, log in, search for a product, add it to the cart, and pay, and performs those steps again and again. Because JMeter calls each worker a “user”, the field is labelled “Number of Threads (users)”.

Each worker is separate from the others. It keeps its own variables, its own cookies, its own login session, and its own position in the test plan. If one worker is waiting for a slow response, the others carry on. This independence is exactly what makes the test look like many different people using the system at the same moment.

Why this one number matters so much

The thread count is the main control for concurrency, which means how many activities are in progress at the same moment. Too few threads and your test is too gentle: the application looks healthy, and you ship a problem into production. Too many threads and you may overload your own test machine, so the slowness you measure belongs to JMeter, not to the application. In both cases the report looks professional, but the conclusion is wrong.

What the thread count does not control

The thread count does not directly set the speed of the test, the total number of requests, or the duration. Those are decided by the Ramp-up Period, the Loop Count, the scheduler, timers, and the response time of the system under test. The thread count only sets the maximum number of workers that can be active together. Understanding this separation is the first step toward designing correct tests.

Four words that people use as if they mean the same thing, but they do not.

Performance conversations become confusing because teams mix up words. A business owner says “we expect 5,000 users”. A tester configures 5,000 threads. The application then receives a load that has little to do with the business expectation. Before choosing a number, you need a shared vocabulary.

Why the difference is important

A real person reads, thinks, scrolls, and drinks tea between clicks. A JMeter thread, unless you tell it otherwise, never pauses. It sends the next request the instant the previous response arrives. A single thread without any pause can create as much load as ten or twenty real people, depending on how fast the application responds. So “5,000 users” and “5,000 threads” are not the same thing unless you add realistic pauses between steps.

The bridge between business numbers and thread numbers

The bridge is a pair of ideas: think time and throughput. If you reproduce realistic think time, then the number of active sessions maps to the number of threads fairly closely. If you remove think time, you should instead target a request rate and calculate how many threads are needed to reach it. Both approaches are valid, but you must pick one on purpose. Chapters 7, 8 and 10 explain both approaches in detail.

The Number of Threads field lives inside a Thread Group, and its neighbours change its meaning.

A Thread Group is the container that holds your test steps and tells JMeter how to run them. Every test plan needs at least one. The Number of Threads field is only one of several settings, and the settings work as a team. Changing one often changes the effect of the others.

The action after a sampler error

Beside these fields there is a choice that tells each thread what to do when a request fails. The thread can continue with the next step, start the next loop, stop itself, stop the whole test gracefully, or stop the whole test immediately. This choice quietly affects your thread count in practice. If failing threads stop themselves, then during a failure storm your 500 threads may shrink to 200 without any warning, and your test no longer applies the load you planned. For capacity tests, most teams choose to continue or start the next loop, so the load stays constant and the failures show up clearly in the report.

More than one Thread Group

A test plan may contain several Thread Groups, each with its own thread count. This is useful when different user types behave differently. For example, 800 threads may browse the catalogue, 150 may search, and 50 may check out. The total concurrency is the sum of all groups. When people say “the test used 1,000 users”, they usually mean this sum. Remember to report the number per group as well, because a mix of behaviours is more important than the total.

A look under the hood explains why thread counts have real physical limits.

JMeter is a Java program. Each JMeter thread is a real Java thread running inside one Java Virtual Machine, usually called the JVM. When the test starts, the engine reads your test plan, makes a private copy of the plan elements for every thread, and starts the threads according to the ramp-up schedule. This copy is the reason each thread can hold different variables and different cookies without interfering with the others.

flowchart TD
    A["Test starts"] --> B["Engine reads the Thread Group settings"]
    B --> C["Engine makes a private copy of the plan for each thread"]
    C --> D["Threads start one by one during the ramp-up"]
    D --> E["Each thread runs samplers in order"]
    E --> F["Timers add pauses between steps"]
    F --> G{"More loops or time left?"}
    G -->|"Yes"| E
    G -->|"No"| H["Thread ends and frees its memory"]
    H --> I["Test ends when all threads finish"]
        

The thread life cycle

Blocking behaviour: why one thread equals one request at a time

A JMeter thread is synchronous. This means that while it waits for a response, it does nothing else. It cannot send a second request in the meantime. So a single thread can have at most one request in flight at any moment. This simple fact is the foundation for the maths in the next chapters: the maximum number of requests in progress at the same time is never larger than the number of threads.

What each thread costs your test machine

A thread consumes memory for its stack and for the variables, response data and sampler results it holds. It also uses CPU time for building requests, encrypting and decrypting secure traffic, parsing responses, and running scripts. A plain page request is cheap. A request that uses heavy scripting, large response bodies, or many regular expressions is expensive. Two test plans with the same thread count can therefore need very different hardware. This is why Chapter 13 is devoted to sizing the machine that generates the load.

The thread count says how many. The ramp-up says how quickly.

The Ramp-up Period is the number of seconds JMeter takes to start all of the threads. The start times are spread evenly. If you have 100 threads and a ramp-up of 50 seconds, JMeter starts one new thread every half second. If you set a ramp-up of zero, all 100 threads start almost together, and your application receives a sudden wall of traffic.

flowchart LR
    A["Ramp-up phase: threads start gradually"] --> B["Steady state: all threads active, measure here"]
    B --> C["Ramp-down phase: threads finish and exit"]
        

Why a gradual start is healthier

Real traffic rarely appears in one second. Even a marketing email arrives across several minutes. A slow ramp-up lets the application warm up: caches fill, connection pools open their connections, the runtime compiles hot code paths, and auto-scaling has time to react. If you slam the system with all users at once, you test a “cold start shock”, which is a valid scenario, but it is a different test, usually called a spike test. Mixing the two ideas gives results that nobody can interpret.

The measurement window

Results collected during the ramp-up are not stable, because the load is changing every second. For honest numbers, you want a steady state: a period where all threads are active and the load is flat. A good test plan has a ramp-up, then a hold period long enough to take measurements, then a ramp-down. Many teams exclude the ramp phases when they calculate averages and percentiles.

A subtle detail: the first iteration

Threads that start early are already on their second or third loop while the last threads are still starting. That is normal. But it means that during the ramp-up the mix of requests is skewed toward the early part of your scenario, because new threads begin at the first step while old threads are further along. Over a long steady state, this skew disappears.

Threads need a reason to stop. These settings decide when.

A thread keeps working until something tells it to stop. There are two main ways to define that moment. The first is a count of loops: each thread repeats the scenario a fixed number of times and then leaves. The second is a time limit: the thread keeps looping until the clock runs out. These two styles lead to very different tests, even with the same thread count.

Loop-based tests

In a loop-based test, the total work is predictable. With 100 threads and 10 loops, the test sends the scenario 1,000 times in total. The duration, however, is not predictable. If the application is fast, the test ends quickly. If it is slow, the test takes longer, and the load on the system gradually decreases as fast threads finish early and slow threads continue alone. This is a useful style for functional performance checks and for tests where you need an exact number of transactions, such as creating exactly 5,000 orders.

Time-based tests

In a time-based test, you enable the thread lifetime option, set a duration, and set the loop count to run forever. Now the duration is predictable, and the number of transactions is not. Every thread stays busy until the end, so the concurrency stays flat during the hold period. This is the preferred style for load, stress and endurance tests, because the shape of the load is easy to explain: “500 users for 30 minutes”.

Startup delay

The startup delay setting postpones the start of a Thread Group. It is helpful when you have several groups that should begin at different moments. For example, a background batch job may start five minutes before the user traffic so that the system is already warm and busy when the users arrive. It is also a simple way to stack different groups in time without extra plugins.

Why this matters for the thread count

The effective number of active threads at any second equals the threads that have started and not yet finished. In loop-based tests this number falls toward the end. In time-based tests it holds steady. If your report says “500 users” but the average active thread count was 380, then your claim is off by almost a quarter. Always confirm the active thread count from the live graphs or from a listener that records it, not just from the number typed into the field.

The one formula every performance engineer should know by heart.

Two words come up again and again in performance work. Concurrency is how many things are happening at once. Throughput is how many things are completed per unit of time, such as requests per second. They are connected by a beautiful and simple rule named after the mathematician John Little. It says that, in a stable system, the average number of items inside the system equals the arrival rate multiplied by the average time each item spends inside.

Applying the rule to JMeter

For a JMeter test where every thread sends one request at a time, the number of threads in action equals the throughput multiplied by the time each cycle takes. A cycle is the response time of a request plus any pause the thread takes before the next one. Written in words: threads needed equals the target requests per second multiplied by the sum of response time and think time, measured in seconds.

Worked examples

Look at the first two rows. The target rate is the same, but when the response time becomes four times slower, you need four times more threads to keep that rate. This is the reason a degrading application can fool you. If you keep the thread count fixed while the server slows down, the throughput drops, because each thread now finishes fewer cycles per second. The graph then shows a falling request rate, and some people mistakenly read this as “the application handled less traffic” when in fact the application caused the drop.

The reverse direction: predicting throughput from threads

You can also turn the rule around. Throughput equals the number of threads divided by the cycle time. With 200 threads and a cycle of 4 seconds, the system sees about 50 requests per second. If the response time grows from 1 second to 3 seconds while think time stays at 3 seconds, the cycle grows from 4 to 6 seconds and the throughput falls from 50 to about 33 per second. The load generator is the same, the threads are the same, but the pressure on the server changed because the server itself became slower.

flowchart LR
    A["Target throughput"] --> D["Threads needed"]
    B["Response time"] --> D
    C["Think time and pacing"] --> D
    D --> E["Concurrency on the server"]
        

Without pauses, a thread is a machine. With pauses, it becomes a believable user.

What think time is

Think time is the pause between two steps of a user journey: the time a person takes to read a page, choose an option, or type a form. In JMeter you create this pause with timers. A fixed timer waits for the same duration each time. A uniform random timer waits for a random duration between a minimum and a maximum. A Gaussian random timer produces most waits near an average, with a few shorter and a few longer waits, which looks natural. Random timers are usually better because real people are not robots with a stopwatch.

Think time versus pacing

These two ideas are often confused. Think time is the pause between steps inside one journey. Pacing is the pause between full iterations of the journey, designed so that each thread starts a new iteration at a regular interval. Pacing is especially useful when you want each user to perform a fixed number of journeys per hour. For example, if each user should complete one order every two minutes, pacing makes the thread wait until the two minutes are over, whether the order took 20 seconds or 60 seconds.

The effect on the thread count

Think time reduces the load that each thread creates. If one thread creates ten requests per second without pauses, it creates less than one request per second with a five-second pause between steps. This means that to produce the same load, you need many more threads. Teams that forget this either under-test their systems, because they keep a small thread count and add big pauses, or over-test them, because they keep a big thread count and no pauses.

Honest choice of think time

Choose think time from evidence, not from guesses. Look at your web analytics or application logs. Measure the real gaps between consecutive actions for the same session. Use the average as the centre and the spread as the random range. If you do not have data, document your assumption clearly in the test report so that readers can judge the result for themselves.

An advanced idea that explains why thread-based tests can flatter your system.

The closed model

The classic JMeter Thread Group follows the closed workload model. There is a fixed population of users. A user can send a new request only after the previous one is finished. If the server slows down, users wait longer, and so the number of new requests per second automatically falls. The system, in a sense, protects itself because the test slows down together with the application.

The open model

Real public websites behave according to the open workload model. New visitors arrive from the outside world at a certain rate, whether the server is fast or slow. If the server is struggling, visitors do not politely wait for earlier visitors to finish. They keep arriving, queues build up, and the system can collapse. The arrival rate is independent of how well the server is doing.

flowchart LR
    subgraph Closed["Closed model: fixed number of threads"]
        direction LR
        C1["Thread sends request"] --> C2["Server responds"]
        C2 --> C3["Thread thinks"]
        C3 --> C1
    end
    subgraph Open["Open model: arrivals at a fixed rate"]
        direction LR
        O1["New visitors arrive at a set rate"] --> O2["Server queue"]
        O2 --> O3["Server responds"]
    end
        

Why this changes how you interpret thread counts

In a closed model test with a fixed number of threads, a slow server reduces the arrival rate. The server then gets a little relief, and the test may not show the full collapse that a real crowd would cause. This effect is sometimes called coordinated omission: the measuring tool, by waiting for slow responses, quietly leaves out the requests that should have been sent during the slow period, and it therefore records fewer slow samples than reality would produce. The measured percentiles look better than what real users would experience.

Tools JMeter gives you for open-style tests

Recent JMeter versions include an Open Model Thread Group, where you describe a schedule of arrival rates such as “rise from zero to twenty arrivals per second over ten minutes, then hold for thirty minutes”. JMeter then creates as many threads as required to honour the schedule, up to a limit you choose. Alternatively, in the classic approach, teams combine a large enough thread count with a throughput timer, so that threads are always available and the timer decides the pace. Both methods aim to keep arrivals independent of server speed.

A step-by-step method that replaces guesswork with arithmetic.

The question “how many threads should I use?” has no universal answer. It depends on your goal, your traffic and your system. But there is a reliable method that works for most projects. It moves from business facts, to throughput, to concurrency, to the final thread count.

A full worked example

An online store expects 36,000 visits in its busiest hour next year. Each visit performs on average 12 requests. So the site must serve 432,000 requests in that hour, which is 120 requests per second. A pilot test shows an average response time of 0.8 seconds, and the team decides on an average think time of 6 seconds per request, because shoppers read and compare. The cycle time is 6.8 seconds. Threads needed are 120 multiplied by 6.8, which gives 816. Adding a fifteen percent margin brings the number to about 940, so the team plans for roughly 950 threads.

The concurrent-users shortcut

When you know the visits per hour and the average visit length, there is a shorter route. Concurrent users equal visits per hour multiplied by the average visit length expressed in hours. If 36,000 visits happen in an hour and each lasts 10 minutes, which is one sixth of an hour, then about 6,000 sessions are open at the same time. That is a different number from 950, because the shortcut counts every open session, including people who are only reading, while the threads in the earlier example send a request every few seconds. Both numbers are valid, but they answer different questions. Always state which one you use.

The same scenario needs a different thread pattern depending on the question you are asking.

A performance test is not one thing. Teams run several kinds of tests, and each kind uses the thread count in its own way. Naming the test type clearly in your plan tells everybody what the thread number is supposed to prove.

The standard Thread Group has one shape. Real tests often need many shapes.

The standard Thread Group ramps up once and then holds. That is fine for simple tests, but serious work often needs more control: steps, plateaus, bursts, and dips. JMeter offers several options for this, and some of them come from the well-known plugin collection that most performance teams install.

Fixed threads versus fixed rate

A key idea in this chapter is the difference between telling JMeter “use 500 threads” and telling it “deliver 100 requests per second”. With the first instruction you control concurrency, and the request rate follows the server speed. With the second you control the rate, and the number of active threads follows the server speed. Rate control with a pool of spare threads is the closest match to open-style traffic. It also keeps your test steady when the application slows down.

flowchart TD
    A{"What do you want to control?"} -->|"Number of users"| B["Standard or Concurrency Thread Group"]
    A -->|"Complex shape with spikes"| C["Ultimate Thread Group"]
    A -->|"Requests per second"| D["Throughput Shaping Timer with a spare thread pool"]
    A -->|"Arrivals of new visitors"| E["Open Model Thread Group"]
    B --> F["Closed model behaviour"]
    C --> F
    D --> G["Rate driven behaviour"]
    E --> G
        

Why spare threads are your friend

When you use a rate-driven setup, you must give JMeter enough threads to reach the rate in the worst case. If the response time doubles during the test, the threads needed also double. If you provide only the minimum, the rate will fall short exactly when the system is struggling, which is the moment you most want accurate pressure. Provide a margin, and then confirm from the active threads graph that the pool never ran empty.

Installing and governing plugins

Advanced thread groups usually come from plugins, which means extra software on every load generator machine. Treat them like any other dependency. Keep the same plugin versions on the controller and on all workers, record the versions in the test report, and keep a copy of the files in your own storage in case the public source is not reachable on test day. A version mismatch between machines can produce silent errors that look like application problems.

If your test machine is the weakest link, your results measure the machine, not the application.

Every thread you add costs the load generator something. If the generator runs out of CPU, memory or network capacity, requests are delayed inside JMeter itself. The recorded response time then includes time the application never caused. This is one of the most common reasons for misleading performance reports, and it is entirely avoidable with a little planning.

The heap setting

JMeter starts with a modest default heap size, which is fine for development but too small for large tests. Increase the maximum heap in the startup configuration to a value that fits the machine, usually no more than about half to three quarters of the available memory, so the operating system still has room. Setting the minimum and maximum heap to the same value avoids resizing pauses during the run.

Practices that let one machine carry more threads

How to prove your generator is healthy

Run a calibration test. First, point the same test plan at a very simple, very fast endpoint, such as a static page on a healthy server. If response times at your target thread count are still tiny and stable, the generator is coping. If response times already show spikes there, the generator is the problem. This quick check separates tool limits from application limits, and it takes only a few minutes.

When one machine is not enough, use several, and remember that the thread count multiplies.

JMeter can control several machines from one place. One machine, the controller, sends the test plan to many workers, sometimes called remote engines. Each worker runs the plan on its own, generates load against the application and sends summary results back to the controller. This way you can reach very high loads that no single machine could produce.

flowchart TD
    C["Controller: starts and stops the test, collects results"] --> W1["Worker 1: runs its own threads"]
    C --> W2["Worker 2: runs its own threads"]
    C --> W3["Worker 3: runs its own threads"]
    W1 --> T["Application under test"]
    W2 --> T
    W3 --> T
    W1 -.->|"results"| C
    W2 -.->|"results"| C
    W3 -.->|"results"| C
        

The multiplication rule

The most important fact about distributed testing is simple: every worker runs the whole Thread Group with the thread count you typed. If the Thread Group says 200 threads and you use five workers, the application receives 1,000 threads of load, not 200. Many teams are surprised by this and accidentally run ten times more load than planned. The same rule applies to loop counts and to every other setting inside the plan.

Practical points for healthy distributed runs

Containers and cloud generators

Many organisations run workers inside containers or on cloud machines that are created for the test and deleted afterwards. This gives flexible capacity and a clean state for every run. The same rules still apply: the machines must be close to the target in network terms, have stable resources, and be sized by a calibration test. Cloud machines that share hardware with other customers can have uneven CPU performance, so check the generator’s CPU during the run rather than trusting the label of the machine type.

Every extra thread travels through a chain of limited resources on the server side.

When your threads send requests, each request passes through a chain: a load balancer, a web server, an application server, perhaps a cache, and a database. Every stage has a limit, such as a maximum number of worker threads or database connections. As you raise the JMeter thread count, you push the chain until the weakest stage becomes full. Understanding the chain helps you read your results correctly.

flowchart LR
    A["JMeter threads"] --> B["Load balancer"]
    B --> C["Web server worker pool"]
    C --> D["Application thread pool"]
    D --> E["Database connection pool"]
    E --> F["Database"]
        

The knee of the curve

As you increase the thread count, the system passes through three zones. In the first zone, response time stays flat and throughput rises almost in proportion to threads. In the second zone, the system approaches its limit: throughput rises more slowly and response time begins to climb. This turning point is often called the knee. In the third zone, the system is saturated: more threads add no extra throughput, because the extra requests only wait in queues, and response time grows steeply. Errors and timeouts often appear here.

Reading the capacity from the knee

The best working capacity of a system is usually found just before the knee, not at the point of total failure. If a system can technically serve 800 users before collapsing, but response times become unacceptable at 600, then the real capacity for the business is 600. Run a stepped test, plot response time and throughput against the number of active threads, and mark the knee. That mark is a much more useful result than a single pass or fail.

Queues hide in many places

When threads wait, they are waiting somewhere: in an operating system queue, in a web server queue, in an application pool queue, or for a database connection. A high response time with low CPU usage on the server is a classic sign that requests are waiting in a queue for a limited resource, such as a small connection pool. Raising JMeter threads further would make the wait longer without raising throughput. The cure is to find and widen the right pool or to speed up the slow dependency, not to add more load.

Connections and keep-alive

Each JMeter thread normally keeps its own connection to the server and reuses it between requests when keep-alive is enabled. So the thread count is roughly the connection count seen by the server and its load balancer. A load balancer with a limit of a few thousand connections may refuse new ones long before your application is stressed. Likewise, a firewall with connection tracking limits can drop connections. If errors begin suddenly at a round thread count, suspect such a limit in the network path.

A number without a graph beside it is only half a result.

Your thread count is an input. To judge the test, you must watch the outputs and the health of everything in between. A good performance report always connects the number of active threads to the behaviour of the system at the same moment.

The core metrics to track

Averages lie, percentiles tell the truth

Suppose 95 requests finish in 1 second and 5 requests take 20 seconds. The average is almost 2 seconds, which sounds acceptable, yet one in twenty users waited twenty seconds. Percentiles expose this. When you compare tests with different thread counts, compare the same percentile each time, and look at how the high percentiles grow as threads grow. The tail often begins to climb long before the average moves.

flowchart LR
    A["Test plan with planned threads"] --> B["JMeter results file"]
    A --> C["Generator health metrics"]
    D["Server and database metrics"] --> E["One combined timeline"]
    B --> E
    C --> E
    E --> F["Conclusion linked to thread count"]
        

Live dashboards and backend listeners

JMeter can send metrics, while the test is running, to an external time-series database and a dashboard tool. This lets you watch active threads, throughput and percentiles beside server graphs in real time. It also lets you stop a test quickly if something goes wrong. For after-the-run analysis, JMeter can generate an HTML dashboard report from the saved results file, which is a convenient way to share findings with people who do not use JMeter.

Security and data hygiene during load tests

Performance testing touches real systems and real data, so some safety rules apply. Never run high-thread tests against a production system without written approval and a clear schedule, because a successful test may look exactly like an attack to security tools and to other users. Use synthetic test accounts and fake data, never real customer details. Keep passwords and tokens out of shared test plan files, and pass them as protected parameters. Store result files carefully, because they can contain addresses, tokens and other sensitive values from requests and responses.

Learn from the errors that experienced engineers have already paid for.

A practical checklist and four stories that show the ideas at work.

Best-practice checklist

Real-world stories

Quick answers to questions that come up in almost every project.

Only if you add realistic think time and use realistic data. Without pauses, one thread can produce the load of many real people, so the claim “one thread equals one user” can be badly wrong.

There is no fixed number. It depends on the script weight, response sizes, secure traffic, heap size and CPU. Light scripts may carry thousands of threads, while heavy scripts may struggle with a few hundred. Find your own limit with a calibration test and live monitoring of the generator.

Long enough for the system to warm up and for the load to build smoothly, and shorter than the hold period. Many teams use a ramp-up of ten to twenty-five percent of the total test time, and then adjust after watching the first run.

Because the thread count was fixed. Each thread completes fewer cycles per second when responses slow down, so throughput falls. This is how closed-model tests behave. Use a rate-driven setup with spare threads if you need a steady request rate.

No. More threads mean more load, but not necessarily more value. Beyond the knee, extra threads only create queues and errors. The right number is the one that matches your goal, whether that is the expected peak, a stress step or a breakpoint search.

Concurrent users count people active together, including those who are thinking. Requests per second count the work the server completes each second. They are linked through response time and think time, using Little’s Law.

No. Each thread should have its own session so it behaves like a separate person. Sharing sessions makes the load unrealistic and may trigger caching or locking behaviour that real users would not cause.

Watch its CPU, memory, network and garbage collection during the run, and run a calibration test against a very fast endpoint. If timings are poor there, or CPU stays very high, the generator is limiting the test.

When your real traffic is open, meaning visitors arrive at a certain rate whether or not the server is keeping up. It lets you describe arrival rates directly and avoids the self-protecting effect of a fixed thread population.

The standard Thread Group does not support it. Advanced thread groups from plugins let you shape the thread count over time with steps, plateaus and spikes, and some can adjust the active count through a schedule defined in advance.

Every worker runs the full thread count typed in the plan, so the total is the thread count multiplied by the number of workers. Divide your target by the number of workers before you start.

Long enough to gather a large number of samples at steady state, often thirty to sixty minutes for a load test. Soak tests run for many hours, because slow problems need time to appear.

Many threads running the same plan need careful handling of data and state.

When one thread runs a test, mistakes in data handling are easy to miss. When hundreds of threads run the same plan at the same moment, small design errors become loud failures. Good test plans follow a few simple patterns that keep every thread independent, so that failures you see belong to the application and not to a clash between your own threads.

Pattern 1: one data row per thread

Give each thread its own account, order number or search term from a data file. Configure the data reader so that every thread takes the next unused row, and decide in advance what happens when the file runs out. The reader can stop the thread, start again from the top, or stop the whole test. For a test with 500 threads running for an hour, a file with only 500 rows may be used up quickly if each loop consumes a row, so size the file with the loop rate in mind.

Pattern 2: correlate dynamic values per thread

Modern applications send values that change on every request, such as session identifiers, security tokens and form keys. Each thread must capture these values from the previous response and send them back in the next request. Captured values are stored in variables that belong to the thread, so threads do not mix their tokens. Never store such values in shared properties that all threads can read, because one thread could overwrite another thread’s token and cause strange, random failures that disappear when the thread count is low.

Pattern 3: separate shared and private state

Some things should be shared, such as a read-only list of product names, and some must be private, such as a shopping cart. Keep a clear boundary. Shared items should only be read during the run, never changed. Anything a thread changes belongs in its own variables. If you must share a counter, for example to generate unique order references, use a counter element that is designed for this and be aware that it can become a small point of contention under very high thread counts.

Pattern 4: realistic transaction grouping

Group the requests of one user action, such as a page and its images and scripts, under a named transaction. This lets you report the time of the whole action, which is what the user feels, instead of dozens of separate request times. When you compare tests with different thread counts, the transaction view is much easier to read and to explain to managers.

Pattern 5: controlled randomness in the user mix

Real users do not all follow the same path. Use controllers that pick a path at random with a defined probability, so that, for example, seventy percent of the iterations browse, twenty percent search and ten percent buy. This keeps one Thread Group realistic without needing many groups. Check afterwards, from the results, that the achieved mix is close to the intended mix, because a short test may drift from the plan by chance.

Anti-pattern: global locks and synchronised sections

Some teams add scripts that lock a shared resource, for example to write to a common file or to wait for each other. Under high thread counts, such locks force threads to queue inside JMeter itself. The measured time then includes time spent waiting for a lock, not time spent waiting for the application. If you see throughput flatten at a surprisingly low value while server CPU is idle, search your plan for shared locks, shared file writes and long scripts.

Warm-up and cache behaviour

Applications behave differently on a cold start and on a warm run. The first requests after a restart fill caches, compile code paths and open connections. A fair test either includes a short warm-up that is excluded from the results, or deliberately tests the cold state as its own scenario. Likewise, if all threads request the same product again and again, the cache will answer almost every time, and your test will show speed that real users with a varied catalogue will never see. Use varied data so that the cache hit rate in the test is close to the rate seen in production.

When the numbers look strange, start from the symptom and work toward the cause.

Thread-related problems tend to repeat across projects. The table below links the most common symptoms to their likely causes and the first thing to check. It will not replace careful analysis, but it saves time at the start of an investigation.

A calm way to investigate

The Number of Threads field looks tiny, but it carries the weight of your whole performance test. A thread is one independent worker that repeats your scripted journey. It is not a person, and it is not a request rate. How well it stands in for real users depends on think time, data, ramp-up, loop settings and the workload model. The right number comes from arithmetic, not from habit: peak throughput multiplied by the time of each cycle, with a margin for safety. Once chosen, the number must be supported by a healthy generator, confirmed by live monitoring, and interpreted together with server metrics and percentiles.