The scheduler is a small panel in the thread group that gives a test a start time and a length.

JMeter is a free, open-source tool from the Apache Software Foundation that pretends to be many users at the same time so you can see how a system behaves under pressure. In JMeter, the people you pretend to be are called virtual users, and each one is run by a Java thread. A thread group is the element that holds a crowd of these threads and tells them what to do.

Every thread group has settings for the number of threads, the ramp-up period, and the loop count. Under those you will find the scheduler. Depending on your JMeter version, it is shown as a checkbox labelled “Scheduler” or “Specify Thread lifetime”. When you tick it, two extra boxes become available:

A timer for the whole group, not for one request

It is easy to confuse the scheduler with the timers that add pauses between requests. They are completely different. A timer adds a short pause before a single request, to imitate a person who is thinking. The scheduler controls the lifetime of the whole thread group: when it begins and when it ends. One works in seconds and fractions of seconds between actions; the other works in minutes and hours across a whole test.

Counting loops is easy. Counting minutes is what real performance questions need.

By default, a thread group runs until each thread has repeated its steps a fixed number of times. This number is the loop count. A test with one hundred threads and a loop count of ten sends roughly one thousand journeys through the system, then stops. When the system is fast, this happens in seconds. When it is slow, the same test takes much longer. In other words, the length of the test depends on the very thing you are trying to measure.

That is a problem. Real questions about performance are almost always phrased in time: “Can the system handle the expected crowd for thirty minutes?”, “Does memory slowly leak over eight hours?”, “What happens during the first five minutes after a sale starts?” To answer questions like these, you need the test to run for a chosen length of time, whatever the speed of the system. The scheduler provides exactly that.

Predictability helps everyone

Time-based tests are easier to schedule with other people. You can tell the operations team, “We will hit the system between ten and ten thirty, and the monitoring dashboards should be watched during that period.” You can plan a pipeline stage that must finish within a limit. You can compare two runs fairly because they ran for the same length of time at the same load. And you can calculate the number of samples you expect to collect, which tells you whether your statistics are strong enough to trust.

Every scheduled thread group moves through the same stages. Learn the stages once and every setting makes sense.

When you press the start button, the test does not simply explode into action. A scheduled thread group walks through a predictable sequence of stages, and each setting controls one of them.

flowchart LR
    S["Test started"] --> D["Startup Delay: group waits"]
    D --> R["Ramp-Up: threads join gradually"]
    R --> ST["Steady State: all threads working"]
    ST --> E["Duration ends: threads stop"]
    E --> F["Test finishes or next group continues"]

A picture in numbers

Suppose a group has one hundred threads, a startup delay of 60 seconds, a ramp-up of 100 seconds, and a duration of 1800 seconds. For the first minute, nothing happens. Then, over the next hundred seconds, one new virtual user joins every second. After that, all one hundred users work together until the duration is finished. The steady state lasts the rest of the time, which is the bulk of the test.

Duration is the total length of life you give to a thread group.

The Duration field answers one question: for how many seconds should this group be allowed to run? When the scheduler is active and a duration is set, JMeter calculates an end time from it and tells the threads to stop when that moment arrives.

What the duration includes

The duration includes the ramp-up. It is a single clock that starts when the group begins and covers the time the threads are still joining as well as the time all of them are working. This surprises many beginners. If your duration is 600 seconds and your ramp-up is 300 seconds, then half of your duration is spent while the crowd is still growing, and only the remaining half is true steady state.

How a duration is chosen

There is no single correct duration. It depends on the question. A quick sanity check after a code change may run for five minutes. A normal load test often runs for thirty to sixty minutes. A soak test, which looks for slow problems such as memory leaks, may run for many hours. We will return to the choice later in a dedicated chapter, but for now remember that the duration should be long enough to collect many measurements during a stable period.

What happens when the duration is empty

If the scheduler is on and the duration is left blank or zero, JMeter has no end time from this field. The group then relies on the loop count to decide when to stop. If the loop count is also infinite, the test would run until someone stops it by hand. That is a classic cause of tests that never finish, so always check both fields together.

The duration and finite loops

If you set both a duration and a finite loop count, the group ends as soon as either one is reached first. A group of fifty threads with a loop count of five and a duration of one hour will probably finish in a few minutes, long before the hour, because the threads run out of loops. If your goal is “run for exactly one hour”, set the loop count to infinite so that the duration alone controls the end.

Startup delay is a polite pause before a thread group begins its work.

The Startup Delay field says how many seconds a thread group should wait after the test is started before it begins. During the wait, the group does nothing at all and sends no traffic. After the wait, it begins its ramp-up and starts its threads.

Why would anyone wait?

If you only have one thread group, a startup delay is rarely needed. Its real power appears when a test has several groups. By giving each group a different delay, you decide who arrives first, who arrives later, and who overlaps with whom.

Delay is relative, not a clock time

The startup delay is a relative number. It means “wait this many seconds after the group is told to start”, not “start at three o’clock”. This is helpful because the test behaves the same whether you start it at nine in the morning or midnight. It also works well when the same plan is shared by many machines, since each machine counts the delay from its own start moment.

The two settings are partners. Together they place a thread group on the timeline of the whole test.

To know exactly when a group is active, add the startup delay to the duration. A group with a startup delay of 300 seconds and a duration of 1200 seconds begins working after five minutes and finishes twenty minutes after that, so it is active until the 1500-second mark of the test. Remember to confirm this in your own JMeter version by watching a chart of active threads over time during your first run, because small differences between versions do exist.

This plan builds the load gradually. Browsers arrive first and form the background. Searchers join five minutes later. Buyers join five minutes after that, when the system is already busy. The test is therefore heaviest in the middle, and it winds down as groups finish at different moments, which is an excellent way to see how the system behaves as load rises and falls.

A rule of thumb for planning

• Decide the length of the whole test from the question you are answering.
• Decide when each crowd should arrive, and write that as its startup delay.
• Decide how long each crowd should stay, and write that as its duration.
• Check that for every group, the ramp-up is clearly shorter than its duration.
• Check that the longest delay plus its duration does not exceed the length of the test you planned.

Numbers become clear when you do the arithmetic yourself. Here are three schedules, worked from start to finish.

Example one: a thirty-minute load test

The team wants about 200 virtual users, a gentle ramp, and a steady period of roughly twenty-one minutes. They choose 200 threads, a ramp-up of 200 seconds, a duration of 1500 seconds, an infinite loop count, and no startup delay. The arrival speed is 200 threads divided by 200 seconds, which is one new user per second. The ramp-up covers the first 200 seconds, so the steady state lasts the remaining 1300 seconds, a little over twenty-one minutes.

Now estimate the work done. If each journey takes about twenty seconds including think time, a thread completes about 65 journeys during the steady state, because 1300 divided by 20 is 65. Multiplied by 200 threads, that is about 13,000 journeys. If a journey contains five requests, the test sends about 65,000 requests in the steady window. That is enough for stable percentiles in most cases.

Example two: a four-hour soak test

A second team wants to look for slow memory growth. They choose 50 threads, a ramp-up of 300 seconds, a duration of 14400 seconds, an infinite loop count, and a startup delay of 120 seconds so monitoring can record a quiet baseline first. The group begins working at the 120-second mark, reaches full strength at 420 seconds, and ends at 14520 seconds. The steady state lasts 14100 seconds, almost four hours. The load is small on purpose; the point is the length, not the weight.

Example three: a spike on top of a background crowd

A third team wants to see how a system copes with a sudden burst. The first group is the background: 100 threads, a ramp-up of 100 seconds, a duration of 1800 seconds, and no delay. The second group is the spike: 400 threads, a ramp-up of 10 seconds, a startup delay of 900 seconds, and a duration of 300 seconds. The spike group arrives at forty new users per second, which is very fast, between the 900-second and 910-second marks. For about 290 seconds the system serves 500 users, then the spike group stops and the system returns to its background load of 100. The team watches how long it takes response times to recover.

The scheduler is not magic. It is a few simple rules applied by every thread in the group.

When you start a test, JMeter reads the plan, creates the engine, and starts each thread group. For a scheduled group, JMeter converts your two numbers into actual moments in time. It calculates a start moment by adding the startup delay to the current time. It calculates an end moment by adding the duration to that start moment. Each thread in the group is given these moments, and each thread then checks them as it works.

flowchart TD
    A["Test starts"] --> B["Read scheduler settings"]
    B --> C["Compute start time from startup delay"]
    C --> D["Compute end time from duration"]
    D --> E["Each thread waits for its turn during ramp-up"]
    E --> F["Thread runs samplers in order"]
    F --> G{"End time reached?"}
    G -- "No" --> F
    G -- "Yes" --> H["Thread stops and reports"]
    H --> I["Group ends when all threads stop"]

Threads check the clock between actions

A thread is busy sending a request, waiting for a reply, running extractors, and pausing in timers. JMeter does not slam on the brakes in the middle of ordinary work. Instead, the thread looks at the clock at natural points in its work, such as between samplers. When it sees that the end moment has passed, it stops running its normal steps. A scheduled background task also watches the clock and asks any thread that is still working to stop at the end time.

Because of this, the very end of a scheduled test is a little untidy. A request that is in flight when the clock runs out may be cut short, and a thread that is in the middle of a long think-time pause may take a moment to react. The last few samples of each user can therefore look unusual, with slightly different timings or an error. This is normal, and the proper response is to ignore the tail of the test when you read results.

Why the delay is handled per thread

Each thread knows its own start moment and end moment. This design keeps the engine simple: there is no central referee shouting instructions to every thread. Instead, every thread knows the rules and follows them. This makes it dependable even with thousands of threads, because the only shared fact is the same pair of times.

The data flow and lifecycle

A thread passes through four clear states: waiting, running, stopping, and finished. During the startup delay and its own ramp-up slot, it is waiting. Once its slot arrives, it is running and executes its samplers in order, round after round. When the end moment passes, it moves to stopping, where it finishes or abandons the current work. Finally, it is finished, and the group notes that one more thread has ended. When all threads in the group are finished, the group is complete, and if every group is complete, the whole test ends.

Delaying thread creation

The thread group has a related checkbox that says to delay the creation of threads until they are needed. By default, JMeter creates all of the threads at the start, even though many of them will wait through a long ramp-up. With the option on, each thread is created only when its slot arrives. For very large groups, this saves memory early in the test and lets a long startup delay cost almost nothing while it waits.

Both settings can end a thread. Knowing who wins avoids a whole family of surprises.

A thread can stop for two different reasons: it has finished its loops, or the duration has run out. The thread stops at whichever happens first. Because beginners usually think about only one of them at a time, the combination causes many confusing results.

The recommended pairing

For nearly every time-based test, the recommended pairing is scheduler on, a positive duration, and an infinite loop count. With this, the only thing that ends the test is the clock, which is exactly what you want when the goal is “run for this long”. Each thread simply repeats its journey, one iteration after another, until time is up.

The cost of looping for a long time

With an infinite loop and a long duration, every thread repeats its journey many times. This has side effects worth planning for. Data files may run out and need to be recycled, otherwise threads may stop early. Created records, such as orders or accounts, may pile up in the system under test. Sessions that last hours may expire. These are not problems with the scheduler, but they are consequences of running for a long time, and the scheduler is what makes a long test easy to start by accident.

Ramp-up decides how fast the crowd arrives. Duration decides how long the whole party lasts. They share the same clock.

The ramp-up period is the number of seconds over which JMeter starts all of the threads. With one hundred threads and a ramp-up of one hundred seconds, one new thread starts about every second. The first thread begins right away and the last thread begins at the end of the ramp-up. The speed of arrival is the number of threads divided by the ramp-up in seconds.

Choosing a sensible ramp-up

A sensible ramp-up gives the system time to warm its caches and open its connection pools naturally. For a few hundred threads, one to five minutes is common. For thousands, longer is often better. A rule many teams use is to keep the ramp-up under about a quarter of the duration, so most of the test sits in the steady stretch. When you want to see how the system copes with a sudden crowd, deliberately shorten the ramp-up and call it what it is: a spike test.

Separating warm-up from measurement

The first minutes of a test behave differently from the rest. Caches are cold, connection pools are small, and just-in-time compilers in the server are still deciding what to optimize. Measurements taken during this time are usually slower and noisier. A well-designed schedule treats the delay and ramp-up as warm-up and bases its conclusions on the steady stretch only. When you later read the results, you will cut the first part away, so you must make sure that a steady stretch exists in the first place.

The scheduler lives in a crowded panel. Its neighbours change how it behaves.

A thread group has several settings in the same panel as the scheduler. Each of them interacts with duration and startup delay, so it is worth understanding the whole neighbourhood.

Same user or new user?

In a long timed test, each thread runs its journey many times. If every round must look like a new visitor arriving, the thread should not carry old cookies, caches, and connections into the next round. If every round is the same person continuing to browse, carrying that state is correct. Because the scheduler makes rounds repeat for a long time, this choice has a much bigger effect than in a short test: a wrongly shared state can make the whole run look unrealistically fast, since a visitor who already has everything cached is quick.

Errors and the schedule

The error action interacts with the duration in a quiet but important way. If the action is “stop thread” and the system begins to fail, threads stop one by one long before the duration ends. The active-threads chart then shows a falling staircase in the middle of what should have been a steady plateau. If the action is “stop test”, a single failure can end the whole run early. Make a conscious choice for each test. For a stress test where failures are exactly what you want to observe, continuing is usually better than stopping.

Label differences between versions

Depending on your version of JMeter, the checkbox that unlocks duration and startup delay is called “Scheduler” or “Specify Thread lifetime”. The two fields underneath behave the same way. Do not be alarmed if your screen shows a slightly different label from a tutorial. Look for the two fields measured in seconds, and read the help text of your version if in doubt.

Real traffic is a mixture of crowds. The scheduler lets each crowd have its own timetable.

A test plan may contain several thread groups, each representing a different kind of user or a different system activity. By default, JMeter starts all the groups at the same time. Giving each group its own startup delay and duration turns the plan into a timetable.

flowchart TD
    T["Test starts at 0 s"] --> G1["Group A Browsers: delay 0 s, duration 1800 s"]
    T --> G2["Group B Searchers: delay 300 s, duration 1200 s"]
    T --> G3["Group C Buyers: delay 600 s, duration 600 s"]
    G1 --> E1["Ends near 1800 s"]
    G2 --> E2["Ends near 1500 s"]
    G3 --> E3["Ends near 1200 s"]
    E1 --> END["Test completes when the last group ends"]
    E2 --> END
    E3 --> END

Running groups one after another

The test plan itself has a checkbox that says to run thread groups consecutively. When it is ticked, JMeter runs the first group completely, then the second, and so on, rather than all at once. This is a different way to make groups follow each other. Use it when groups depend on each other, such as a setup group that must finish before the main test. Use startup delays when groups should overlap in time. Do not mix the two without understanding exactly what you want, because the delays then count from each group’s own start.

A special pair: setUp and tearDown

JMeter offers special groups that run before and after the main test. A setUp group is meant for preparation, such as creating test data. A tearDown group is meant for cleanup. These run in their own phases, so you rarely need startup delays to order them. Their scheduler settings can still be used to limit how long they may run, which is a useful safety measure if preparation might hang.

Designing the mix

Different questions need different timelines. The scheduler is how each test type is written down.

Smoke test: prove the script first

Always begin with a tiny test. A smoke test uses one or two threads, a short duration, and no startup delay. It exists to prove that the script logs in, extracts its values, passes its checks, and ends cleanly. Skipping this step and starting a one-hour test with a broken script wastes time and may also disturb the system for no reason.

Load test: the main event

A load test applies the traffic you expect on a busy day. It uses a ramp long enough to be gentle, a steady period long enough to gather plenty of samples, and a short cool-down. The duration is usually thirty to sixty minutes. This is the test whose numbers go into the report.

Spike and stress: the extremes

A spike test shortens the ramp to almost nothing. All the users arrive in seconds, as they might after a link goes viral. A stress test keeps raising the load beyond the expected level until the system shows weakness. The built-in scheduler gives a single steady level, so many teams build stress tests with several thread groups, each joining later with its own startup delay, to create steps. Community plugins offer dedicated groups that draw more complicated shapes, and we discuss them in a later chapter.

Soak test: the marathon

Some problems only appear after hours: slow memory leaks, growing log files, connection leaks, and database tables that become gradually slower. A soak test runs a moderate load for a long time to expose them. Here the scheduler is the main tool, since the whole point is a long and exact duration. Because the test is long, it needs extra care around data, results files, and monitoring, which we cover in the chapters on performance and safety.

The number you type in the box should come from a reason, not from habit.

Many tests use whatever number the first tutorial used, often 600 or 3600. A better approach is to choose the duration from what you need to learn. Several factors guide the choice.

Enough samples to trust the numbers

Statistics need data. A percentile calculated from fifty samples is shaky, while one calculated from fifty thousand is steady. Estimate the number of samples you will collect by multiplying the expected requests per second by the length of the steady period. If a journey is made of six requests and your target is twenty journeys per second, you will send about one hundred and twenty requests per second. Over a thirty-minute steady period, which is 1800 seconds, that is about two hundred thousand samples, which is plenty. A slower, rarer action, such as a monthly report with only one request per minute, would need a much longer test to collect enough samples.

Long enough for slow effects

Some behaviour needs time to show. A cache that expires every ten minutes needs a test long enough to include several expiry cycles. A scheduled backup job at the server may run every hour. A memory leak of one megabyte per minute is invisible in ten minutes and obvious in ten hours. Ask yourself what is the slowest event you care about, and make the steady period several times longer than that event.

Short enough to afford

Tests cost money and attention. Cloud machines are billed by time, test environments are shared, and long tests make it harder to repeat the test. A good rule is to run the shortest test that gives a trustworthy answer and to repeat it two or three times, rather than running one very long test once. Repeating shows whether your result is stable.

A simple recipe

A few simple formulas connect the schedule to the load your system actually feels.

The scheduler tells JMeter how long to run, but it does not directly say how much traffic will be produced. The traffic is a result of the number of threads, the time each journey takes, and the pauses between actions. A handful of formulas let you predict it.

An example with numbers

Take 600 threads with a journey time of 30 seconds and eight requests in each journey. The crowd starts 600 divided by 30, which is 20 journeys per second. That is 160 requests per second. Over a 1800-second steady period, the test collects about 288,000 samples. If the target for peak hour is 200 requests per second, this test is a little under the target and you would raise the threads or reduce the think time.

Why the journey time changes under stress

Think time stays constant, but response time grows when the system is stressed. A longer response time means a longer journey, which means fewer journeys per second from the same crowd. In other words, a thread group with a fixed number of threads automatically sends fewer requests when the system slows down. This is helpful because it avoids burying a struggling system, but it also means that “the load” you applied dropped exactly when the system suffered. If you need a constant request rate regardless of response time, add a rate-controlling timer or a plugin made for that purpose, and make sure there are enough threads to reach the rate.

A startup delay should always tell a story. If you cannot explain why it is there, remove it.

Where duration is chosen from the question, a startup delay is chosen from the story of the day you are imitating. Real days have a shape: quiet mornings, a lunchtime burst, an evening peak, a sudden email campaign. Startup delays are how you place those events on a timeline. Here are the most useful stories.

Avoid pointless delays

A common mistake is to add a delay of a few seconds to every group “just in case”. It adds nothing, makes the timeline harder to read, and often confuses a later reader who wonders what was supposed to happen in those seconds. Use a delay only when it expresses something about the traffic you are imitating or something you need from the environment.

Use a delay for safety in unattended runs

If a test is started by a pipeline or a scheduled job, a short startup delay can give the environment time to finish a deployment or restart before traffic arrives. This is a pragmatic use, but it is best paired with a proper readiness check in the pipeline, because a fixed delay is only a guess about how long a restart will take. If the guess is wrong, your first minutes of data will be garbage.

Hard-coded numbers force you to edit the plan for every run. Properties let one plan serve many runs.

Typing 1800 into the Duration box works, but it ties the plan to one length. The moment someone wants a five-minute smoke test or a four-hour soak test, they must open the plan, edit it, and save it, which invites mistakes. A better way is to read the number from a property, a named setting handed to JMeter when the test starts.

JMeter provides a function for this called the property function. You write it directly in the field, for example ${__P(duration,1800)}. It means: “use the property called duration if it was supplied, otherwise use 1800”. The same idea works for the startup delay, the number of threads, and the ramp-up. When you start the test from the command line, you pass values for these properties, and the same plan becomes a smoke test, a load test, or a soak test without any editing.

Always give a default

The second value in the function is the default, used when nobody supplies the property. Choose a small, safe default, such as a short duration, so a run started by accident cannot hammer a system for hours. The default should be the value you would be comfortable with if the person starting the test forgot to set anything.

Making runs reproducible

When settings come from properties, the exact values used for a run can be recorded next to its results, for example in the name of the results folder or in the pipeline log. Months later you can see that a result came from a thirty-minute run with two hundred threads, and you can repeat it exactly. With values hidden inside an edited plan, that history is lost.

Debug by printing

While building a plan, it helps to see the values JMeter actually used. A Debug Sampler can show the current properties, and the log records the settings at the start of each group. A thirty-second look at these saves hours of confusion later.

When one machine is not enough, many machines share the work. The schedule travels with the plan.

In distributed testing, one machine called the controller sends the test plan to several remote machines called engines. Each engine runs the plan on its own and the controller gathers the results. The scheduler works naturally here because the settings are relative: every engine receives the same duration and the same startup delay and counts them from its own start moment.

flowchart TD
    C["Controller: sends plan and start command"] --> E1["Engine 1: delay, ramp-up, duration"]
    C --> E2["Engine 2: delay, ramp-up, duration"]
    C --> E3["Engine 3: delay, ramp-up, duration"]
    E1 --> R["Results collected"]
    E2 --> R
    E3 --> R
    R --> C

Important points to remember

• Thread counts multiply. If the plan says one hundred threads and you have five engines, you generate five hundred virtual users. Duration and delay do not multiply; they stay the same on every engine.
• Starts are almost, but not exactly, simultaneous. The controller tells the engines to start one after another, so there may be a small gap of a second or more between them. For tests lasting many minutes this does not matter, but for very sharp spikes it can blur the picture.
• Use the same clock. If you compare JMeter results with server monitoring, make sure all machines agree on the time. A network time service keeps them in step.
• Properties must reach the engines. A setting supplied only on the controller may not be known to the engines. JMeter has a separate way to send properties to the engines, and forgetting it leads to engines using their defaults.

A schedule is a promise about time, and time on computers is not as simple as it looks.

The duration and the startup delay are relative: they count seconds from a starting moment. Under the hood, JMeter turns them into absolute moments by reading the computer’s clock. This has a few consequences that are worth knowing before you plan a long or important test.

Relative settings are stable

Because the settings are relative, a test behaves the same whether it starts in the morning or at midnight, in one time zone or another. Daylight saving changes do not matter for the settings themselves, because thirty minutes is always one thousand eight hundred seconds. This is another reason to prefer the built-in fields over writing your own start-time logic.

Timestamps in the results file

Each sample in the results file carries a timestamp. By default it is a number of milliseconds since a fixed starting date, which does not depend on any time zone. That is good, because the numbers from machines in different countries can be compared. When you turn timestamps into readable dates for a report, be careful about which time zone the tool uses, and write the zone next to the times you show to people. A chart that says “peak at ten o’clock” is confusing if the reader lives somewhere else.

Clock jumps

Since JMeter reads the machine’s clock to decide when the end moment has arrived, a sudden jump in the clock during the test can shift the schedule. A time service on the machine might correct a clock that has drifted, and a manual change would do the same. For short tests this is rare. For overnight tests, keep the clocks of all test and server machines synchronised with a trusted time service, and avoid changing them by hand while a test runs.

The built-in scheduler draws a simple shape. Plugins can draw richer ones.

With duration and startup delay, the standard thread group gives a simple shape: wait, ramp up to a fixed level, hold, stop. That is enough for many tests. When you need a shape with several steps, peaks, and valleys, there are two common approaches.

Approach one: several standard groups

You can build steps with several thread groups, each with its own startup delay and duration. It needs no extra software, and every part is visible in the plan. The disadvantage is that the plan becomes long and the thread counts of different groups must be adjusted separately. A staircase with ten steps is ten thread groups.

Approach two: plugin thread groups

The community maintains a collection of plugins, usually installed through a helper called the Plugins Manager. Several of them are made for shaping load over time.

A schedule is only useful if your report respects it. Cut away the warm-up and the tail before you trust any number.

When a scheduled test ends, you have a results file with a row for every sample, including the quiet ramp-up and the untidy tail. If you calculate averages over the whole file, those edges pull the numbers away from the truth. The slow, cold start inflates response times, and the last few cut-off requests add errors.

Find the steady window

The first chart to open is the one showing active threads over time. It should look like a plateau: a rise during ramp-up, a flat top, and a drop at the end. The flat top is your steady window. The HTML dashboard report that JMeter can generate includes this chart, along with response times, throughput, and errors over time. Compare their shapes. Response times that stay flat while threads are flat show a healthy system. Response times that climb during a flat top show something degrading under constant load.

How to trim

Recent versions of JMeter allow the report generator to be limited to a time window through report properties, so the dashboard covers only the steady period. If your version does not, you can filter the results file by the timestamp column with a spreadsheet or a small script before analysing. Either way, record the exact window you used in the report, so a reader knows which part of the test the numbers describe.

Compare with the plan

Check that what happened matches what you scheduled. Did the group start when it should? Did all threads join? Did the duration end when expected? A group that started late, or a crowd that never reached its full size, tells you that the test did not follow your plan, and any conclusion drawn from it is suspect. The active-threads chart is a lie detector for your schedule.

When the clock and the chart disagree, work through the usual suspects in order.

Most scheduler problems have simple causes. The trick is to look at the symptom, match it to a likely cause, and check that cause first. The table below lists the symptoms beginners meet most often.

A method for any puzzle

A long test is a long watch. Decide in advance what you will watch and who will watch it.

Time-based tests, especially long ones, produce a lot of information. Without a plan for watching it, the problems appear only when the test is over and fixing them means repeating the whole thing. Three kinds of information matter: what JMeter sees, what the system under test shows, and the health of the test machine.

flowchart LR
    J["JMeter schedule runs"] --> R["Results file and Backend Listener"]
    J --> L["JMeter log"]
    SYS["System under test"] --> M["Server monitoring"]
    GEN["Load generator machine"] --> M
    R --> D["Live dashboard"]
    M --> D
    L --> D
    D --> H["Human watcher with a stop plan"]

What to watch in JMeter

• Active threads over time. It should follow the shape you scheduled. A different shape means something went wrong.
• Throughput. Requests per second should rise with the ramp and settle on the plateau.
• Error rate. A sudden rise during the steady period is a strong signal worth investigating at once.
• Response time percentiles. Watch the ninety-fifth and ninety-ninth, not only the average.

What to watch around JMeter

Watch the processor, memory, disk, and network of the servers under test, because they explain why response times move. Also watch the load generator. If its processor is saturated or its memory is nearly full, your results describe the generator, not the system. The JMeter log should be checked for repeated warnings, which often mean a missing data file or a script that fails after some time.

Live dashboards for long tests

For tests of an hour or more, stream the metrics to a live dashboard using the Backend Listener, which sends data to an external monitoring system while the test is running. A team can then watch the same chart in a meeting room, compare it with server metrics, and decide in time whether to stop. Waiting for a report at the end of an eight-hour soak test only to learn it broke in the first ten minutes is a painful way to learn.

The longer a test runs, the more the test machine itself has to carry.

A short test can get away with sloppy settings. A long one cannot. Over hours, small inefficiencies add up to full disks, slow garbage collection, and memory pressure. Because the scheduler makes it so easy to run for a long time, you must plan for the cost.

Results file size

Every sample becomes a row in the results file. Suppose your test sends one thousand requests per second for eight hours. That is about twenty-nine million samples. If each row takes about two hundred bytes, the file grows to nearly six gigabytes. Saving response bodies or extra columns makes it much bigger. Plan disk space, choose the columns you need, and consider writing results to a fast disk that is not shared with the operating system.

Memory over time

A listener that keeps results in memory, such as the results tree, grows steadily and will eventually exhaust the memory of the machine. For any long run, use non-GUI mode, remove heavy listeners, and write results straight to a file. Watch the memory and garbage collection of the load generator during the first long test, so you know how it behaves before you trust it overnight.

Data that runs out

With infinite loops and a long duration, a data file that was enough for a five-minute test is used up quickly. Decide what should happen when the data ends: recycle the rows, stop the thread, or stop the test. For tests that create records, think about whether the same row can be used again without breaking the system, for example whether an order number must be unique.

Sessions and tokens

Logins that last a short time will expire during a long test. If the plan logs in only once per thread, the threads will start failing after the token lifetime. Either refresh the token on a schedule or design each iteration to log in again if needed. A soak test that silently becomes an hour of error pages is worse than no test at all, so always keep assertions in place.

The scheduler fits naturally into automated delivery pipelines, because a pipeline needs tests with a known length.

A delivery pipeline is a chain of automatic steps that builds, tests, and releases software. Each step must have a clear start and a predictable end, otherwise the pipeline stalls. A JMeter test with a duration is a good citizen in such a chain: you know before it begins how long it will take, so you can reserve the right amount of time and set a sensible time limit on the step.

flowchart LR
    B["Build and deploy"] --> H["Health check: system is ready"]
    H --> S["Short smoke run: duration 120 s"]
    S --> Q{"Smoke passed?"}
    Q -- "Yes" --> L["Load run: duration from property"]
    Q -- "No" --> X["Stop pipeline and report"]
    L --> G["Quality gate: error rate and percentile limits"]
    G --> P["Publish report"]

Two tiers of tests

A common design uses two tiers. On every change, the pipeline runs a short test, perhaps two to five minutes. It catches broken scripts and obvious slowdowns. On a nightly or weekly basis, a longer test of thirty to sixty minutes runs against a more stable environment. Occasionally, before a big event, the team runs a long soak test. All three use the same plan; only the duration and the number of threads change, supplied through properties.

Quality gates

A quality gate is a rule that decides whether the pipeline may continue. After the run, a small script reads the results of the steady window and compares them with agreed limits, such as an error rate below one percent and a ninety-fifth percentile response time under two seconds. If the limits are broken, the step fails and the team is told at once. Since a scheduled test always ends at a known time, the gate can run right after it.

Wait for readiness, not for time

A fixed startup delay is a poor way to wait for a deployment. Deployments take different amounts of time on different days. Instead, let the pipeline poll a health address until the system says it is ready, and then start the test. Use the startup delay only for what it is good at: arranging crowds inside the test timeline.

Shared build machines

Machines that run many jobs are noisy. Another job may use the processor during your test and distort results. For dependable numbers, run the load generator on a machine reserved for the purpose, or at least check the generator’s own metrics during each run so you can discard measurements affected by a busy neighbour.

A test that runs for hours while nobody watches deserves extra guardrails.

The scheduler makes it simple to start a test that runs for a very long time. That convenience carries responsibility. A load test is real traffic with real credentials, and a mistake that would be small in a five-minute test can become serious in an eight-hour one.

Permission and notice

Run tests only against systems you own or have written approval to test. Agree on the time window with every team that operates the target, the network, and any shared service. A long test that begins at a surprise hour looks like an attack, wakes people up, and may trigger automatic defences that block your generators. Tell people the start time, the end time, and the contact number for stopping it.

Know the stop plan

Before starting, decide how the test will be stopped in an emergency and who is allowed to do it. JMeter can be stopped gracefully, where threads finish current work, or immediately. Operations staff should know that the test is time-limited and when it should end naturally, so a test that continues past its expected end is a clear sign that something is wrong.

Protect secrets for long runs

Keep passwords and tokens out of the saved plan. Provide them at run time as properties or from a protected file. For long tests, results files may contain tokens inside headers or response bodies, so store them securely and delete them when they are no longer needed. Use dedicated test accounts with the smallest rights needed.

Avoid real side effects

A long loop that sends emails, text messages, or payments can create enormous numbers of real events. Always use test data and test endpoints, and confirm that outgoing messages go to a safe place. Think about what the test will leave behind, such as thousands of orders or accounts, and plan the cleanup, perhaps through a tearDown group.

Cost control in the cloud

Cloud machines are billed by time. A test with an unexpectedly long duration, or one that never ends because the loop count and duration were misconfigured, can run up a large bill. Put a limit on the running time of the machines, set alerts on spending, and tear machines down automatically at the end.

The built-in scheduler is simple on purpose. Simplicity brings strengths and limits.

Time-based versus work-based

The main trade-off is between measuring over a fixed time and measuring a fixed amount of work. A time-based test gives you a predictable calendar. A work-based test, using loop counts, gives you the same number of operations whatever the speed. Time-based tests are better for judging load behaviour. Work-based tests are better when you want to compare the exact same work across two versions of a system. Neither is better in every case, so choose the one that matches your question.

Simplicity versus control

Using only duration and delay keeps a plan easy to read and easy to hand over to a colleague. Plugin thread groups add control but also add things that can break and things people must learn. A good policy is to use the simplest tool that expresses the load you need.

Patterns are habits that keep a schedule healthy. Anti-patterns are habits that quietly spoil results.

Helpful patterns

Anti-patterns to avoid

A short checklist to carry into your next test.

Common mistakes in one list

• Typing minutes into a field that expects seconds
• Ticking the scheduler box but leaving the duration blank
• Leaving a finite loop count and expecting the full duration
• Choosing a ramp-up as long as the duration
• Forgetting that the startup delay counts from the test start, not from the end of the previous group
• Adding delays that nobody can explain
• Reading the whole file instead of the steady window
• Running a long test without a stop plan, monitoring, or approval

Four typical situations, described in general terms so you can adapt them.

One plan, many shapes

These four scenarios use the very same thread group elements and samplers. Only the numbers in the scheduler fields, and the way several groups are arranged, change. That is the real value of understanding duration and startup delay: they let a single well-built test plan act as a smoke check, a load test, a spike, a stress staircase, or a soak marathon.

A one-page summary you can keep next to your test plan.

When you are in a hurry, start from this table and adjust. It lists sensible starting values for each goal. They are starting points, not rules, so always check them against your own question, your system, and the number of samples you need.

The five questions to ask before pressing start

• Is the scheduler box ticked, and is there a positive number in the duration field?
• Is the loop count infinite, so that the clock decides the end?
• Is the ramp-up clearly shorter than the duration?
• Can I explain every startup delay in one sentence about real traffic?
• Do I know where I will watch the active threads, the error rate, and the response time percentiles?

Quick answers to the questions beginners ask most often.

The JMeter scheduler gives a thread group a place on the timeline of a test. Startup delay says when the group begins, and duration says how long it lives. Together with the ramp-up and the loop count, these settings turn a plain crowd of virtual users into a planned performance experiment with a start, a steady middle, and an end. If you remember one idea, let it be that every number in the thread group works together, and a trustworthy test is one where you can explain every second of its timeline.