The Loop Count is the number of times each virtual user repeats the full set of steps placed under a Thread Group.

The Simple Definition

In Apache JMeter, a Thread Group creates virtual users, and each virtual user is called a thread. Every thread follows the same list of steps, such as opening the home page, searching for an item, and logging out. The Loop Count is a field on the Thread Group that says how many times a thread should go through that whole list before it stops.

If the Loop Count is one, each user does the journey once and leaves. If it is ten, each user does the journey ten times in a row. If you tick the Infinite box next to it, the user keeps going without a fixed count, and something else must decide when to stop.

One Word You Must Know: Iteration

An iteration is one complete pass through the steps. People often say “loop” and “iteration” to mean the same thing. If a user logs in, views a product, adds it to a basket, and logs out, that is one iteration. A Loop Count of five means five iterations for each thread.

To see why we need this setting, imagine a load test without it.

The Problem

A single trip through a website is over in seconds. If every virtual user did just one trip and left, your test would be finished almost at once, and you would learn very little. Servers behave differently when they have been working for a while. Caches fill up. Connection pools warm up. Memory slowly grows. Slow problems only show themselves after many repeated requests.

You need a way to keep users busy for long enough to see the true behaviour. You also need a way to control exactly how much work each user does, so that two test runs can be compared fairly. The Loop Count solves both problems with one number.

What It Gives You

A few words appear again and again. Learn them once and the rest becomes easy.

Test Plan and Thread Group

The Test Plan is the whole saved test, stored in a file with the extension .jmx. A Thread Group sits directly under it and controls the crowd of virtual users: how many there are, how fast they start, and how many times they repeat.

Sampler

A sampler is one action that sends a request to the system being tested and measures the answer. The most common is the HTTP Request sampler. A single iteration usually contains several samplers.

Logic Controller

A logic controller decides the order and conditions of the steps. Some controllers repeat their children. The most important one for this topic is the Loop Controller, which has its own loop count that works inside the larger loop of the Thread Group.

Think Time

Real people pause between actions. This pause is called think time, and JMeter creates it with timers. Think time decides how long one iteration takes, and that decides how many iterations fit into a given amount of time.

Infinite Loop

When the Infinite box is ticked, the Loop Count has no limit. The thread will keep repeating until another rule stops it, such as a time limit on the Thread Group, a stop action after an error, or a manual stop by the tester.

A JMeter test is a tree. The Loop Count lives on the branch that decides how often everything beneath it runs.

The Test Plan is the root of the tree. The Thread Group is a branch below it, and the Loop Count is a setting on that branch. Everything placed under the Thread Group is part of one iteration. When a thread finishes the last step, JMeter checks the Loop Count. If more loops remain, the thread jumps back to the first step. If not, the thread ends.

flowchart TD
    TP["Test Plan"] --> TG["Thread Group: Loop Count = 5"]
    TG --> ONCE["Once Only Controller: Login"]
    TG --> LC["Loop Controller: Loop Count = 3"]
    LC --> S1["Sampler: View Product"]
    LC --> TM["Timer: Think Time"]
    TG --> S2["Sampler: Add To Basket"]
    TG --> S3["Sampler: Logout"]
    TG --> LS["Listener: Summary Report"]
    

Reading the Diagram

In the picture, the Thread Group repeats five times. Inside each of those five iterations, the Loop Controller repeats its own steps three times, so the product page is viewed three times per iteration and fifteen times per thread. The login is placed under a Once Only Controller, so it runs only on the first iteration. The basket step and the logout run once per iteration.

Analogy: A Washing Machine

The panel looks tiny, but every field beside the Loop Count changes how it behaves.

The Loop Count Field

You type a whole number. One means a single pass. Ten means ten passes. Zero is a trap: a Thread Group with a Loop Count of zero does no iterations, so threads start and immediately end, and your report will be empty. If your report is empty and you cannot see why, check this field first.

The Infinite Checkbox

When you tick Infinite, JMeter ignores the number in the field. The thread repeats until something else ends it. Infinite loops are popular for timed tests, where you want the load to stay steady for, say, thirty minutes no matter how fast or slow each iteration is.

Neighbouring Settings That Change the Meaning

Several other fields sit beside the Loop Count, and each one interacts with it.

• Number of Threads says how many users repeat the loops.
• Ramp-up period says how far apart the thread starts are. It does not change how many loops each thread performs.
• Same user on each iteration decides whether a thread keeps its cookies and session between loops.
• Specify Thread lifetime adds a duration and a startup delay.
• Action after a sampler error can end the loops early if you choose a stop option.

A good tester always knows how many requests a test will send before pressing start.

The Basic Formula

The total number of requests equals the number of threads, multiplied by the Loop Count, multiplied by the number of samplers that run in one iteration. If a Loop Controller or an If Controller changes how many samplers run, use the real number for each pass.

Worked Example One

You have 50 threads, a Loop Count of 10, and each iteration contains 4 samplers. The total is 50 times 10 times 4, which equals 2,000 requests. If the server answers each request in about half a second, and users pause two seconds between steps, one iteration takes roughly ten seconds, so each thread needs about a hundred seconds, plus the ramp-up time.

Worked Example Two

You have 200 threads, a Loop Count of 20, and an iteration with 8 samplers. The total is 200 times 20 times 8, which equals 32,000 requests. If your test data file supplies one account per iteration, you need 200 times 20, which is 4,000 accounts, or you must allow the file to be reused.

Why This Matters

Systems under test often have limits that matter beyond load, such as daily message quotas, rate limits, or the cost of every call to a paid service. A few seconds with a calculator can stop you from sending a million messages by accident.

There are two ways to end a thread: by counting laps or by watching a clock. Understanding how they combine is essential.

Counting Laps

With a fixed Loop Count, each thread stops after its last iteration. A fast server finishes the test sooner, and a slow one makes it last longer. The amount of work stays the same, but the length of the test changes.

Watching a Clock

With Infinite loops and a duration, each thread keeps going until time runs out. The length of the test stays the same, but the amount of work changes. A fast server completes more iterations in the same time, and a slow one completes fewer.

When Both Are Set

If you set a finite Loop Count and also set a duration, each thread stops at whichever limit comes first. A thread that finishes its loops early ends early, and a thread still running when the clock runs out is stopped by the clock.

flowchart TD
    Q1{"What is your goal?"} --> A["Fixed amount of work, like 10000 orders"]
    Q1 --> B["Steady load for a fixed time, like 30 minutes"]
    Q1 --> C["Quick check that a script works"]
    A --> A1["Use a finite Loop Count and calculate threads times loops"]
    B --> B1["Use Infinite loops with a Duration"]
    C --> C1["Use 1 thread and Loop Count of 1"]
    

Two things share the name “loop count,” and mixing them up is one of the most common beginner errors.

The Thread Group Loop Count

This setting repeats the entire set of steps under the Thread Group, for each thread. It is the outer loop. The whole journey, from first sampler to last, is run again each time.

The Loop Controller

The Loop Controller is a separate element that you add under a Thread Group. It repeats only its own children. It has its own Loop Count field and its own Infinite checkbox. It is the inner loop, used to repeat part of the journey, such as viewing several products or paging through several result pages.

An Example That Shows the Difference

You want each user to log in once, view ten products, and log out. The right design is a Thread Group with a Loop Count of one, and a Loop Controller of ten around the product view. The wrong design is a Thread Group with a Loop Count of ten containing login, product view, and logout. That version logs in ten times and logs out ten times, which puts ten times more load on the login service than you intended, and it distorts every result about login.

Understanding the engine room helps you predict what your test will do and why it sometimes surprises you.

Every Thread Keeps Its Own Counter

When you start a test, JMeter reads the Test Plan and makes a private copy of the Thread Group’s contents for every virtual user. Each thread is a real Java thread running inside the JMeter process. Each one also keeps its own loop counter. Thread number seven has no idea what thread number eight has done. This is why a Loop Count of ten gives each thread its own ten loops, rather than ten loops shared among all of them.

The Decision at the End of Each Pass

At the end of every iteration, the thread asks a simple question: “Do I have loops left?” JMeter also asks other questions at the same moment: “Has my duration run out?” and “Did someone ask the test to stop?” If every answer says to continue, the thread goes back to the first step and begins the next iteration. If any answer says to stop, the thread ends and its results remain in the report.

sequenceDiagram
    participant E as JMeter Engine
    participant T as Virtual User Thread
    participant C as Loop Counter
    participant S as Server Under Test
    E->>T: Start thread at ramp-up time
    T->>C: Set counter to Loop Count
    loop Until counter reaches zero or time ends
        T->>S: Run samplers of one iteration
        S-->>T: Return responses
        T->>E: Report sample results
        T->>C: Reduce counter by one
    end
    T->>E: Thread finished
    

What Resets and What Does Not

At the start of a new iteration, some things are renewed and some are kept. The position in the script goes back to the beginning. Controllers that keep per-iteration state, such as the inner Loop Controller, begin their counting again. Thread variables, cookies, and caches are kept or cleared depending on the “Same user on each iteration” setting, which we cover in a later chapter.

Why Counters Are Per Thread

Keeping a counter per thread makes the engine fast and simple. No thread has to wait for another to update a shared number. The price is that JMeter cannot easily say, “Run exactly one thousand iterations in total, split among whatever threads are free.” For that kind of goal, you need a special tool such as the Throughput Controller in its total-executions mode, which we discuss later.

Follow one virtual user through its loops and the whole mechanism becomes clear.

flowchart TD
    A["Thread starts after its ramp-up delay"] --> B["Loops remaining?"]
    B -- "No" --> Z["Thread ends"]
    B -- "Yes" --> C["Read next row of test data"]
    C --> D["Run samplers in order"]
    D --> E["Wait for think time between steps"]
    E --> F["Check responses with assertions"]
    F --> G{"Error happened?"}
    G -- "Yes, stop action chosen" --> Z
    G -- "No or continue chosen" --> H{"Duration finished?"}
    H -- "Yes" --> Z
    H -- "No" --> I["Reduce loop counter"]
    I --> B
    Z --> L["Results collected by listeners"]
    

Where the Time Goes

The length of one iteration equals the sum of all response times plus all think times plus a small amount of processing inside JMeter. Multiply that by the Loop Count to estimate the working life of a thread. Add the ramp-up delay to estimate when the last thread will finish.

Some steps should happen only on a user’s first lap. The Once Only Controller makes that easy.

The Problem It Solves

Real users log in once and then do many things. If you place a login step directly under a Thread Group with a Loop Count of twenty, each thread logs in twenty times. That is not how people behave, and it distorts your results by hammering the login service far more than reality.

How the Once Only Controller Works

The Once Only Controller runs its children during the first iteration of each thread and skips them in every later iteration. So you place the login under this controller, and the rest of the journey beside it. Thread one logs in on its first loop, and from the second loop onwards, it goes straight to the real work.

An Alternative Design

Another approach is a setUp Thread Group that logs in and stores a token, or a Thread Group with a Loop Count of one that contains an inner Loop Controller around the repeating steps. The right choice depends on whether each virtual user needs its own login. If every user needs a personal session, the Once Only Controller inside the main group is simplest. If all users share one token, a setUp group is cleaner.

This small checkbox decides whether a thread behaves like one person returning or a new stranger each time.

What the Checkbox Does

When “Same user on each iteration” is checked, the thread keeps its state between loops. Cookies, cached items, and authorization details stay in place. The thread behaves like one real person who keeps using the application.

When it is unchecked, JMeter clears this state at the start of every new loop. The thread behaves like a brand-new visitor each time. Cookies are gone, so the server treats the thread as a new session.

Which One Should You Choose?

An Example With Numbers

You have 100 threads and a Loop Count of 10. With the box checked, the server sees about 100 long sessions, each doing ten rounds of work. With the box unchecked, the server sees about 1,000 short sessions. The total number of requests may be equal, but the pressure on session memory, login code, and cache behaviour is very different.

Every extra loop wants fresh data. If your data runs out, your test may stop, repeat, or fail in surprising ways.

How Many Rows Do You Need?

The CSV Data Set Config element feeds each iteration with a row from a file, such as a username and password. If every iteration consumes one row and all threads share the file, you need one row for each iteration in the whole test. That equals the number of threads multiplied by the Loop Count.

What Happens When Data Runs Out

The CSV Data Set Config has two settings for the end of the file. Recycle on EOF sends the reader back to the first row, so data is reused. Stop thread on EOF ends the thread when the data finishes. If you set neither, reaching the end of the file gives threads a placeholder value of “EOF,” and your requests quietly use the wrong data. This is a very common cause of strange failures near the end of a test.

Sharing Mode and Loops

The sharing mode decides who shares the file pointer. In “All threads” mode, every thread takes the next unused row, so each row is used once until recycling. In “Current thread group” mode, each Thread Group has its own pointer. In “Current thread” mode, every thread reads the file from the beginning. With many loops, the wrong sharing mode can make two users log in with the same account at the same moment, and servers that block repeated logins will reject them.

Often you want to know which loop you are in, to create unique names or change behaviour over time.

The Counter Config Element

JMeter offers a Counter config element that produces a growing number. You choose a starting value, an increase for each use, and a variable name. This number can be placed into requests, for example to build unique order references or names.

Two options matter most. Track counter independently for each user gives each thread its own count, which then matches the loop number. If unchecked, all threads share one count, and the number rises across the whole test. Reset counter on each Thread Group iteration sends the count back to its start at the beginning of every loop, which is rarely what you want for unique names.

Iteration Index From Controllers

Newer JMeter versions record an index variable for loop-style controllers, named after the controller. This lets you read which pass of an inner loop you are on, starting from zero. Names and details can vary between versions, so check the documentation for your version before relying on it.

Using the Iteration Number Wisely

• Build unique names so repeated loops do not clash, for example a new basket name per iteration.
• Vary search words or page numbers, so every loop does slightly different work, which is closer to real behaviour.
• Switch behaviour after a warm-up number of loops, for example ignoring early loops in your analysis.

Loop Count tells you how many laps. Think time and pacing tell you how fast each lap goes.

Iteration Time

The time of one iteration is the sum of every response time plus every pause. If a journey has four requests that each take half a second, and three pauses of three seconds, then one iteration lasts about eleven seconds. A Loop Count of ten makes each thread live for about 110 seconds.

The Request Rate Each Thread Produces

A thread making four requests every eleven seconds produces about 0.36 requests per second. One hundred such threads produce about 36 requests per second. If you remove all think time, the same iteration might last only two seconds, and each thread would produce two requests per second. The Loop Count did not change, but the pressure on the server is five times higher.

Pacing: Keeping Each Lap the Same Length

Pacing means starting each iteration at a fixed interval, no matter how long the work took. For example, “begin a new iteration every thirty seconds.” If the server is fast, the thread waits for the rest of the interval. If the server is slow, the next iteration begins as soon as the last one ends. Pacing holds the rate steady, so a slower server does not accidentally reduce the load it receives. In JMeter you can achieve a similar effect with a throughput-oriented timer, or with a timer that adds a pause at the end of each iteration.

Sometimes the goal is a fixed total, such as one thousand orders, no matter how many threads share the job.

Why the Loop Count Alone Does Not Do It

Each thread repeats the same number of times. If you want exactly 1,000 orders and you have 40 threads, you can set a Loop Count of 25. That works only when 1,000 divides evenly by the number of threads. With 30 threads, 1,000 does not divide evenly, and you must accept a small difference, or find another approach.

Throughput Controller in Total Executions Mode

The Throughput Controller can run its children a fixed number of times across all threads. In its “Total Executions” mode, with the “Per User” box unchecked, it counts executions for the whole test. Once the total is reached, it stops running its children. Threads keep looping with an infinite Loop Count but they skip the controller, so the work stops at exactly the number you chose.

Combine this with a stop action or a short duration, so that threads do not keep spinning idly after the work is done.

Other Ways to Reach a Fixed Total

• Choose threads and loops that multiply to the total. For 1,000 orders, use 50 threads and 20 loops, or 100 threads and 10 loops.
• Use a data file with exactly that many rows and set threads to stop at the end of the file. The data decides the total.
• Use a Throughput Controller with a percentage mode to run a step only for a share of iterations, such as five percent of users buying.

Sometimes a loop should end before its count is finished. JMeter offers several safe ways to do that.

Error Actions on the Thread Group

The Thread Group has a setting called “Action to be taken after a Sampler error.” Its choices decide how failures affect your loops.

• Continue ignores the error and carries on with the next step.
• Start Next Thread Loop abandons the rest of this iteration and begins the next one, which is useful when a failed login makes later steps pointless.
• Stop Thread ends this one user and all its remaining loops.
• Stop Test and Stop Test Now end the whole test, either gently or immediately.

While Controller

The While Controller repeats its children as long as a condition is true. It is the right tool for “keep checking until the order status says complete,” a pattern called polling. Always give it a limit or a sleep, so that a condition that never becomes false does not trap the thread forever.

Flow Control Action

The Flow Control Action sampler lets you stop or redirect in the middle of a journey. Its options include going to the next iteration of the current loop, breaking out of the current loop, starting the next thread loop, stopping the thread, or stopping the test. You place it inside an If Controller so that it only acts when a certain condition happens, such as a missing token.

Choosing the Right Exit

Infinite loops are powerful for timed tests, and dangerous when nothing is set to end them.

Why People Use Infinite Loops

A steady-state test usually says, “Hold this load for thirty minutes.” The most natural way to build that is Infinite loops with a duration of thirty minutes. Each thread keeps working no matter how fast the server is, so the load is steady for the whole period. A fixed Loop Count would let fast threads end early and leave the system with less load near the end of the test.

The Ways an Infinite Test Can End

• Duration. The Thread Group’s own time limit stops each thread when the clock runs out. This is the cleanest option.
• Error action. A stop setting after an error can end a thread or the whole test.
• Manual stop. The tester presses stop in the window, or sends a shutdown command to a non-GUI run. A gentle shutdown lets running requests finish, while an immediate stop interrupts them.
• Data end. A data file set to stop threads at its end can finish the test when data is exhausted.
• Controllers. A Throughput Controller that has reached its total, combined with a Flow Control Action, can end threads.

A Safe Checklist Before You Start an Infinite Test

When you add more machines, every setting, including the Loop Count, is applied on each of them.

Every Worker Runs the Whole Plan

In JMeter’s distributed mode, a controller machine sends the Test Plan to several worker machines. Each worker runs the full plan exactly as written. If a Thread Group has 100 threads and a Loop Count of 10, each worker runs 100 threads for 10 loops. With three workers, the server sees 300 threads and 3,000 iterations.

Planning the Totals

To hit a target total, divide the threads or the Loop Count by the number of workers before you set the fields. Most surprises in distributed tests come from forgetting this step.

Data Files Across Workers

Each worker reads its own copy of the data file, and each copy begins from the first row. That means two workers can use the same account at the same moment. To avoid it, give each worker a different slice of data, for example separate files named for each machine. Counters also run separately on each worker, so values that must be unique across the whole test should include something that identifies the worker.

More loops do not just mean longer tests. They change what your test machine and your target system experience.

Effects on the Test Machine

• Memory growth. Every completed sample may be stored by listeners. With many loops, the number of samples grows quickly. Heavy listeners can fill memory long before the test ends.
• Processor use. Parsing responses and running scripts happens on every iteration. Cheap scripts become expensive when repeated millions of times.
• Result file size. A test that sends millions of requests produces a large results file. Plan disk space, and consider saving only the fields you need.
• Network connections. If each iteration opens new connections, the machine can run out of network ports. Reusing connections helps.

Effects on the System Under Test

• Warm caches. Early loops hit cold caches. Later loops hit warm ones. Averages that include early loops can look worse than steady behaviour.
• Slow leaks. A system that leaks memory or connections may look healthy for ten loops and fail after ten thousand.
• Data growth. Loops that create orders or records make databases bigger, which can slow later loops.
• Garbage collection and compaction. Many platforms run clean-up work periodically. Longer tests reveal these pauses that short tests miss.

Warm-Up Loops

A common tactic is to run a small warm-up first. You can create a separate Thread Group for warm-up, run it before the main group using the option to run Thread Groups one after another, and exclude its results from your analysis by giving its samplers a different name or using a separate results file. Another way is to run the main test and study only the steady part afterwards.

A repeated test creates a long story. Good metrics let you read it.

Numbers to Watch

Compare Early Loops and Late Loops

One of the most valuable habits is to compare the first tenth of a test with the last tenth. If response times double, something is accumulating on the server. If errors start only near the end, data may have run out, sessions may have expired, or a disk may have filled up.

Server Side Monitoring

JMeter measures what users see. To find causes, also collect server numbers such as processor use, memory, disk, database connections, and queue lengths over the same period. Line up both views on one timeline, and the cause of a slow rise during later loops is usually easy to spot.

Logging Your Settings

Always record the thread count, Loop Count, duration, and ramp-up for every run, next to the results. Numbers without settings cannot be compared later. A tiny text file saved with each results file is enough.

Loops multiply every action. Anything harmful done once becomes much worse when done ten thousand times.

Only Test What You Are Allowed To Test

Sending a flood of requests to a system you do not own, or have no written permission to test, may be illegal and can be treated as an attack. Even inside your own company, tell the operations team and anyone sharing the environment before you start a long, looping test.

Side Effects Multiply

• A loop that creates an order creates thousands of orders. Use a test environment with test payment settings, and clean up afterwards.
• A loop that sends an email or text message can message real people many times. Point it at test addresses or a mail sink.
• A loop that registers accounts can fill databases with junk. Plan clean-up in a tearDown Thread Group.
• A loop that calls a paid service can run up a large bill.

Account Lockouts and Defences

Security systems watch for repeated logins and suspicious behaviour. A loop that logs in again and again with the same account can lock it, or trigger rate limiters and firewalls. Plan with the security team, use enough different test accounts, and be clear in your report about whether defences were active during the test.

Protect Credentials and Data

Test data files often contain usernames and passwords. Do not use real customer data. Keep files out of public places, and do not share results files that contain sensitive responses.

Every approach has strengths and weaknesses. Knowing both helps you choose well.

Key Trade-Offs

Experienced testers keep returning to a few shapes that work and a few traps that fail.

Patterns That Work

Traps to Avoid

Habits that save time and protect the trustworthiness of your results.

Best Practices

Common Mistakes at a Glance

These scenarios show how loop settings change with the goal. They describe how teams at well-known kinds of companies commonly think, and they are illustrations, not claims about any company’s private tools.

Reading is helpful, but building makes it stick. Follow these steps in order.

Let us design the loop settings for a realistic test, from business goal to final numbers.

Step 1: State the Goal

An online store wants to prove that its checkout service can run at 20 completed checkouts per minute for 30 minutes, with 95 percent of requests answering within two seconds. That means a total of 600 checkouts over the test.

Step 2: Estimate the Iteration Time

One checkout journey has five requests: view the basket, enter the address, choose shipping, pay, and confirm. Each takes about 0.6 seconds on average, which gives 3 seconds of server time. The journey includes four pauses of 5 seconds each for reading and typing, which gives 20 seconds of think time. One iteration lasts about 23 seconds.

Step 3: Use Little’s Law for Threads

The target rate is 20 checkouts per minute, which is one checkout every three seconds, or about 0.33 per second. Using the idea that users in the system equal the arrival rate multiplied by the time spent, we need about 0.33 multiplied by 23, which is roughly 7.7. Round up to 8 threads, and add a small margin, so 10 threads will do.

Step 4: Choose Fixed Loops or a Duration

The goal talks about “30 minutes,” so the natural choice is Infinite loops with a duration of 30 minutes plus the ramp-up. If instead the goal were “exactly 600 checkouts,” a fixed count would fit: 10 threads times 60 loops is 600 iterations.

Step 5: Check the Rate Matches the Goal

Option A produces about 780 checkouts in 30 minutes, which is 26 per minute, higher than the 20 per minute target. To match the target exactly, add pacing so each thread starts a new iteration every 30 seconds, which gives 10 threads times 2 iterations per minute, equal to 20 per minute. This shows why thread count and loop count alone do not control rate. Pacing or a throughput timer does.

When loops misbehave, the cause is nearly always one of a small set of familiar suspects.

A Simple Debugging Routine

Shrink the problem. Use one thread, a Loop Count of three, and a debugging listener. Count how many times each sampler appears. The numbers will quickly show you whether a controller is repeating something or skipping something. Fix the structure first, then scale.

Many wrong results come from mixing up two things that sound alike.

Loop Count and Ramp-Up

Loop Count says how many times each thread repeats. Ramp-up says how far apart threads begin. A long ramp-up does not make the work slower, and a larger Loop Count does not make threads start later.

Loop Count and Duration

Loop Count limits repetitions. Duration limits time. When both are set, whichever is reached first stops the thread. Using a small finite Loop Count together with a long duration often leads to tests that end long before the duration, which confuses people who expected a steady load for the whole time.

Thread Group Loop and Loop Controller

The Thread Group Loop Count repeats the whole journey. The Loop Controller repeats only the steps inside it. Nested together, they multiply.

Iteration, Sample, and Request

An iteration is a full pass through all the steps. A sample is one measured action. A request is usually the same as a sample in a web test. One iteration contains many samples. Reporting “ten thousand iterations” and “ten thousand requests” are two very different statements.

Same User and Once Only

Once Only decides which steps run during the first iteration only. “Same user on each iteration” decides whether cookies and caches survive from one loop to the next. They are independent, but they work together: a Once Only login helps only if the session is kept by the “same user” setting.

This story is a composite of problems that engineering teams commonly meet. It shows how a small loop choice can produce a big wrong conclusion.

The Situation

A team wants to prove their order service can hold a steady load of 200 users for forty minutes. A junior engineer sets 200 threads, a ramp-up of 300 seconds, a Loop Count of 5, and a duration of 2,400 seconds. Each iteration takes about forty seconds.

What the Report Said

The report showed healthy response times and no errors. The engineer declared success. Later, a senior colleague noticed that the whole test had lasted only about eight minutes and that the load graph looked like a hill, not a plateau.

What Was Really Happening

How the Team Fixed the Test

They ticked Infinite, kept the duration at forty minutes, and shortened the ramp-up to five minutes. Active threads now rose to 200 and stayed there. The new report showed that response times drifted upward after twenty-five minutes, because a cache on the server slowly filled and slowed lookups. This was a real finding that the first, misleading test had completely hidden.

Keep this page handy. Every word here appears somewhere in the guide.

Modern teams run performance tests again and again, not only once before a launch. Fixed numbers typed into a panel make that hard.

Why Parameterise

Imagine one test file that must serve three purposes: a two-minute smoke check after every code change, a twenty-minute check every night, and a two-hour soak before a big release. If the Loop Count and duration are typed into the Thread Group, you need three copies of the file, and they will slowly drift apart as people edit one but not the others. A better approach is to let the numbers come from named properties.

How It Works in Plain Words

JMeter lets you start a test from the command line and pass in named properties, such as the number of threads, the Loop Count, and the duration. Inside the Thread Group fields, you use a property function that reads the named property and falls back to a sensible default if none was supplied. When you open the test by hand, the defaults make it behave as a tiny smoke test. When the pipeline starts it, the real numbers arrive from outside.

A Typical Pipeline Flow

The standard Thread Group is not the only way to shape load. Other groups treat repetition differently.

The Standard Thread Group

This group has the Loop Count field and the Infinite checkbox we have studied. Each thread repeats its steps on its own until the count, the duration, or a stop rule ends it. It follows what is called a closed model: the number of users is fixed, and each user starts a new trip only after finishing the last one.

setUp and tearDown Groups

These special groups also have loop settings, but they are normally kept at one. A setUp group prepares things before the main test, such as creating test data or fetching a token. A tearDown group cleans up afterwards. Both usually run once, because you want preparation and clean-up to happen exactly one time.

Plug-In Groups With Schedules

Plug-in groups, such as the Ultimate Thread Group and the Concurrency Thread Group, replace the Loop Count with a schedule. You describe how many users there should be, and for how long, and the group keeps threads busy repeating their steps for as long as the schedule demands. In effect, these groups use infinite loops with a clock. Their shape is controlled by time, not by a loop number.

The Open Model Thread Group

The Open Model Thread Group, found in newer versions, goes one step further. You do not say how many users loop. You say how fast users arrive, for example ten per second for five minutes, and each arriving user performs the steps once. The “loop” is replaced by the arrival rate. This is a strong fit for public websites, where visitors arrive whether or not the server is busy.

Repetition creates a lot of data. How you summarise it decides whether your report is trusted.

Do Not Blend Warm-Up With Steady State

The first loops of a test run against cold caches and half-open connection pools. They are often slower than the loops that follow. If you average everything together, the early slow loops drag your numbers around. Where possible, report the steady part separately, and mention the warm-up in a note.

Use Transactions for Readable Reports

One iteration may contain many requests, and a report that lists each one has hundreds of lines. A Transaction Controller groups requests into one named business step, such as “Checkout.” Your report then shows one line per step, with one response time that matches what a person would feel. Remember to say whether numbers refer to samples or to transactions.

Report the Settings Next to the Numbers

• Threads, Loop Count or duration, and ramp-up.
• Expected and actual total samples.
• Number of workers, if distributed.
• Whether think time and pacing were used.
• Whether the environment had security defences active.

Show the Trend, Not Only the Average

A single average hides what loops reveal. Include a chart of response time across the whole run, and one of active threads. The first shows drift, and the second proves that the load you describe is the load you really produced.

Be Honest About Limits

If the test ended early, say so. If data was recycled, say so. If some loops hit errors from the test machine rather than the server, say so. Honest reports build trust, and trust is what makes performance results useful when real decisions depend on them.

When you are in a hurry, use this page to pick the right loop settings for the job in front of you.

Five Questions to Ask Before Every Run

Quick answers to the questions beginners ask most.

The whole guide in a few lines.