It is the JMeter element that sends one HTTP or HTTPS request to a server and records exactly what came back and how long it took.

First, a few words you will see everywhere

JMeter is a free, open-source tool from the Apache Software Foundation, written in Java, that measures how well a system behaves when many users use it at once. This is called load testing or performance testing. A JMeter test is arranged as a tree called a Test Plan. The smaller pieces inside the tree are called test elements.

A Sampler is a test element that does real work against the system under test. “Sampling” means taking one measurement. Each time a sampler sends one request and gets one answer, JMeter calls it one sample. There are samplers for databases, mail servers, message queues and more, but the HTTP Request Sampler is the one used for websites, web services and APIs.

HTTP stands for HyperText Transfer Protocol. A protocol is simply an agreed set of rules for how two computers talk. HTTPS is the same conversation, but wrapped in encryption so nobody in the middle can read it. When you type a web address in your browser or when an app loads your account balance, HTTP or HTTPS is what carries that conversation.

What the sampler really does

The HTTP Request Sampler does four things. It builds a request from the values you type into its fields. It sends that request over the network to a server. It waits for the response and reads it. And it packages everything into a sample result, which holds the response code, the response body, the timings, the size and a pass or fail flag, so that assertions and Listeners can use it.

Why it matters so much

Every other element in a web test exists to support the sampler. Config elements give it default settings. Timers pause before it. Extractors pull values out of its responses. Assertions check its answers. Listeners record its results. If the sampler is built wrongly, nothing else can rescue the test, because you would be measuring the wrong thing. A test that sends the wrong data, forgets a header, or skips a login step may still show a happy green report while telling you nothing true about your system.

Before filling in sampler fields, you need a clear picture of what an HTTP request is made of. It is simpler than it sounds.

The parts of a request

Every HTTP request has the same ingredients. Once you know them, the sampler screen stops looking like a form full of mysteries and starts looking like a checklist.

The common methods

The method tells the server your intention. The five you will meet most often are easy to remember with a library comparison.

There are others. HEAD asks for the headers of a response without the body, which is handy for a cheap availability check. OPTIONS asks the server what is allowed. The sampler supports these and more through its method list.

The response and its status code

The server answers with a status code, a three-digit number that gives the outcome at a glance. The first digit tells the family.

A sampler never works alone. Its position in the tree decides which helpers can affect it.

A typical tree

A normal web test is built from a few layers. At the top is the Test Plan. Beneath it sits a Thread Group, which controls how many virtual users run, how quickly they start, and how long or how many times they repeat. Inside the Thread Group live the helper elements and the samplers. Each virtual user is a thread, a small worker that independently walks through the samplers in order.

flowchart TD
    A[Test Plan] --> B[Thread Group]
    B --> C[HTTP Request Defaults]
    B --> D[HTTP Header Manager]
    B --> E[HTTP Cookie Manager]
    B --> F[Transaction Controller Login]
    F --> G[HTTP Request Open Login Page]
    F --> H[HTTP Request Submit Login]
    H --> I[JSON Extractor]
    H --> J[Response Assertion]
    B --> K[Listener]

The order JMeter runs things

For each sample JMeter follows a fixed order, regardless of where elements sit visually. Config elements apply first, then pre-processors, then timers, then the sampler sends the request. After the response arrives, post-processors such as extractors run, then assertions, and finally Listeners receive the result. This is why a header added by a Header Manager already exists when the sampler sends, and why an extractor can read the response before the next sampler starts.

Scope in one idea

An element affects its own level and everything beneath it, like a notice pinned on a floor of a building: everyone on that floor sees it, other floors do not. A Header Manager placed directly under the Thread Group applies to every sampler in that group. The same Header Manager placed under one sampler applies only to that request. Choosing the level is a design decision, and we will return to it when we discuss patterns.

Open the sampler and you meet one screen with a few tabs. The Basic tab holds the fields that decide where the request goes and what it asks for.

The essential fields

The option checkboxes

Below the main fields sit several tick boxes. Each one changes how the sampler behaves, so it is worth understanding all of them.

The Path and the full address

You can build the address in two ways. The cleaner way is to put the host in the HTTP Request Defaults element once, and let each sampler hold only its path. The other way is to give every sampler its own server and port. The first method means that moving a test from the testing environment to a staging environment takes one edit instead of fifty. You may also paste a full address into the Path field, and JMeter will understand it, but this is best avoided in finished tests because it makes switching environments painful.

Most real requests carry data. The sampler gives you three separate tabs to send it, and picking the right one is half the battle.

Parameters tab

The Parameters tab holds a simple table of names and values, like a form with labelled boxes. For each row you give a name, a value, and a few switches. The URL Encode switch converts special characters, such as spaces and symbols, into a safe form that travels well in an address. The Content-Type column is relevant for multipart sending, and the Include Equals switch controls whether the equals sign is written even when a value is empty.

Where do these parameters go? It depends on the method. For GET, DELETE and similar methods, they are appended to the address after a question mark, which is called the query string. For POST and PUT, they are normally placed in the request body in the same name and value style that a browser form uses.

Body Data tab

Modern web services usually do not use simple forms. They expect a block of structured text, most often JSON or XML, inside the request body. The Body Data tab is a text area where you paste exactly that block. JMeter sends it as it is, after replacing any variables you wrote in it.

Files Upload tab

To simulate uploading a photo or a document, use the Files Upload tab. For each file you give its path on the machine running JMeter, the parameter name the server expects, and the MIME type, which is a label like image/jpeg that describes the kind of file. When files are involved, the sampler uses the multipart format automatically or when you tick the multipart option.

Choosing the right tab

Using variables for realistic data

Real users do not all log in with the same name. JMeter lets you write a variable name inside any field using a dollar sign and curly brackets, and it replaces the variable with a real value at run time. Where do values come from? Most often from a CSV Data Set Config element, which reads rows from a file so each virtual user can have its own username and password, or from functions that make random numbers, unique identifiers and timestamps. This is how a hundred threads send a hundred different logins instead of a hundred copies of one login that the server might block.

The Advanced tab holds the settings that decide how patient the sampler is, whether it behaves like a browser that downloads page extras, and which software engine sends the request.

Timeouts

A timeout is the longest the sampler is willing to wait. There are two. The connect timeout limits the time allowed to open the network connection to the server. The response timeout limits how long to wait for the server’s answer once the request has been sent. Both are written in milliseconds, where one thousand milliseconds make one second.

If you leave these empty, a sampler may wait for a very long time on a stuck server. During a load test that is dangerous, because stuck threads pile up, the test seems to freeze, and the numbers become meaningless. Setting explicit timeouts that match what a real user would tolerate, such as several seconds for a page, keeps the test honest and lets failures show up as clear errors instead of silent hangs.

Embedded resources

A web page is rarely a single file. When your browser opens a page, it also downloads the pictures, the style sheets and the scripts mentioned inside it. These are called embedded resources. The option Retrieve All Embedded Resources tells the sampler to read the HTML it receives, find these extras and download them too, imitating a browser.

flowchart TD
    A[Sampler requests page] --> B[Server returns HTML]
    B --> C[Sampler reads HTML for resources]
    C --> D[Download style sheets]
    C --> E[Download scripts]
    C --> F[Download images]
    D --> G[Page sample result with sub results]
    E --> G
    F --> G

With this option you can also enable parallel downloads, with a number that sets how many resources load at the same time, similar to a browser’s own limit, and you can write regular expressions to include or exclude certain addresses, for example to skip third-party advertising or analytics servers that you do not own and should not load test. An expression here means a short pattern that describes which text to match.

Implementation

The Implementation setting picks which software library does the sending. The common choice, and the default in current JMeter versions, is HttpClient4, which relies on the Apache HttpClient library and supports the widest range of features, such as connection reuse, proxies and detailed timing. The other choice is the plain Java implementation that uses the built-in networking of the Java platform, which is simpler but has fewer features. For nearly all work you leave this on HttpClient4.

Proxy, source address and other settings

A bare sampler behaves like a robot. A handful of companion elements turn it into something close to a real browser or app.

HTTP Request Defaults

This is a config element that stores the settings every sampler shares, such as protocol, host, port and a common path prefix. Each sampler can then leave those boxes empty and inherit them. When the application moves to a new address, you change one place. It also prevents typing mistakes, because fifty samplers with fifty slightly different typed hostnames is a classic source of puzzling failures.

HTTP Header Manager

Headers are the small labelled notes sent with each request. The HTTP Header Manager lets you define them once, such as the content type, the accepted response format, a browser identity, and a security token. Headers placed at Thread Group level apply to every sampler beneath. Headers added at several levels are merged, and a lower level overrides the same header set higher up.

HTTP Cookie Manager

A cookie is a small piece of text that a server gives to a client and expects back on later requests, often to remember who is logged in. Browsers handle cookies automatically. JMeter does not, until you add an HTTP Cookie Manager. With it, each virtual user keeps its own cookie jar. Without it, a login would succeed but the very next request would arrive as an anonymous stranger and be rejected.

HTTP Cache Manager

Real browsers store files they have already downloaded, so they do not download them again every time. The HTTP Cache Manager imitates this behavior, so repeated requests for unchanged static files are skipped or answered with a quick “not modified” response. Adding it makes load patterns closer to reality, especially when embedded resources are on.

HTTP Authorization Manager

For older styles of protection like Basic or Digest authentication, where the browser pops up a login box, the HTTP Authorization Manager stores the credentials and the addresses they apply to. Modern token-based protection is usually handled instead with a header that carries a token you captured earlier.

What actually happens between the moment a virtual user reaches a sampler and the moment a result appears in your report?

Step by step

sequenceDiagram
    participant T as Virtual User Thread
    participant S as HTTP Request Sampler
    participant D as DNS Resolver
    participant W as Web Server
    participant P as Post Processors and Assertions
    T->>S: Start next sample
    S->>S: Replace variables and build the request
    S->>D: Look up the server name
    D-->>S: Server address
    S->>W: Open connection and secure handshake
    S->>W: Send request
    W-->>S: Status code headers and body
    S->>P: Pass sample result
    P-->>T: Result ready for Listeners

Connections and KeepAlive

Opening a fresh network connection is surprisingly costly, particularly for HTTPS because of the handshake. With KeepAlive on, the connection from the first request stays open and the next request from the same virtual user reuses it, as a browser would. Each thread normally has its own connections. This matters for load: if every request opens a fresh secure connection, you stress the server’s encryption work far more than a real user population would, and your test shows slower numbers than reality. If connections are reused too aggressively, you may understate that cost. Mirroring real client behavior is the goal.

Name lookup and caching

Turning a name like a website address into a numeric network address is called a DNS lookup. The Java platform may remember lookups for some time, which means that a large number of virtual users could all talk to the same address even if the real site spreads users across many servers. When testing a system fronted by several machines behind a name, the DNS Cache Manager config element lets you control or simulate how names resolve. Without that care, the load might not be spread the way real users would spread it.

Real applications hand out values on the fly, like session numbers and security tokens. Your test must catch them from one response and send them in the next request.

What is correlation?

Imagine a cinema that gives each buyer a ticket with a unique code, and the code must be shown at the screen door. If you copied last week’s code onto your ticket, you would be turned away. Web applications do something similar. After login, the server returns a session identifier, an access token, or a hidden value inside a form, and it expects that exact value back on later requests. If the test replays the value that was recorded yesterday, the server rejects it. The technique of capturing a fresh value and reusing it is called correlation.

flowchart LR
    A[Login request] --> B[Server response contains token]
    B --> C[Extractor reads the token]
    C --> D[Token stored in a variable]
    D --> E[Next request sends the token in a header]
    E --> F[Server accepts the request]

The tools of correlation

Using the captured value

An extractor is attached under the sampler whose response holds the value. You give it a variable name. In later samplers you write that variable name in the Parameters, the Body Data, the Path or a header, wrapped in the dollar sign and curly bracket style. JMeter swaps in the captured value for each user separately, so a hundred users hold a hundred different tokens at the same time without clashing.

Making data unique and varied

Besides captured values, tests need generated data. JMeter has built-in functions for random numbers, random strings, unique identifiers, the current time and counters. These help when each order needs a unique reference, when a signup form needs a fresh email address, or when search words should vary. Combine them with the CSV Data Set Config for credentials and product lists, and your virtual users start behaving like different people instead of identical clones.

These four topics decide whether your virtual users behave like real, logged-in people or like a crowd of strangers knocking on a closed door.

How redirects appear in results

After a successful login, many sites answer with a redirect code like 302 and a new address, and the browser jumps there automatically. With Follow Redirects ticked, JMeter does the jump and records the first answer and the final answer as a parent sample with child samples, so you can see each hop. With Redirect Automatically, the intermediate answer is hidden from JMeter and you see only the end result.

flowchart LR
    A[POST login] --> B[Server replies 302 with new address]
    B --> C[Sampler follows redirect]
    C --> D[GET home page]
    D --> E[Server replies 200]

Sessions and cookies

A session is the server’s memory of one user across many requests. It is held together by a cookie or by a token. The Cookie Manager takes care of cookies for every virtual user. The thread group offers an option to clear cookies on each iteration of the loop, which makes each loop behave like a brand new visitor. If you leave that off, a user keeps the same session across loops, which may mean they are already logged in on loop two. Choose according to the real behavior you want to model.

Token-based authentication

Many modern applications do not use cookies. Instead the login request returns a token, and every later request carries it in a header. To handle this you place an extractor under the login sampler to capture the token, then use a header manager or a header on each sampler to send it, written with the variable name. Tokens often expire after a period. A long test may need a refresh step that gets a new token when the old one is close to its end. The well-known standard behind many of these flows is OAuth, and tests for it follow the same capture and reuse pattern.

Basic and certificate-based authentication

Older systems use Basic or Digest authentication, handled by the Authorization Manager. Some corporate systems require the client to present a digital certificate. JMeter can do this by pointing it at a keystore file, which is a protected file that holds the certificate, through its configuration properties. This setup is done once per run and is outside the sampler itself.

Every sample leaves behind a small bundle of facts. Knowing what each fact means turns a pile of numbers into a diagnosis.

The three timing numbers

What counts as success

The sampler decides success from the response code. Codes in the 2xx and 3xx families are treated as passing, and codes in the 4xx and 5xx families as failing. That is only a starting point. Assertions can overturn the verdict, for example by checking that a page contains the expected words or that a JSON response has the right field. The final success flag you see in Listeners is the combination of the sampler’s view and every assertion in scope.

Sub-results and parent samples

When a request involves redirects or embedded resources, the result has a main parent and several children. The parent’s time covers the whole chain, while each child reports its own piece. In reports, this can inflate the number of samples and mix different kinds of timing. Many teams therefore wrap a user step in a Transaction Controller and look at the total for the business step, such as “Place Order”, as well as the pieces.

The size of what moved

Each result also records how many bytes were sent and received. This helps estimate bandwidth needs. A response that is much larger than expected may reveal a missing compression setting or an endpoint that returns far more data than the screen actually needs.

Instead of building each sampler by hand, you can let JMeter watch a real browser session and create the samplers for you.

How recording works

JMeter includes a tool called the HTTP(S) Test Script Recorder. It acts as a proxy, which is a middleman placed between your browser and the website. You point your browser at it, click through a real user journey, and the recorder notes every request that passes through and turns each one into an HTTP Request Sampler with the right method, path, parameters and headers. For secure sites the recorder needs you to trust a temporary certificate that JMeter generates, so it can read the otherwise encrypted traffic during recording.

What recording gives you, and what it does not

Cleaning up a recording

Your load generator is a computer with limits. If it struggles, your results describe its struggle, not your server’s behavior.

What limits a single load generator

Things that make samplers heavy

Scaling out

When one machine is not enough, JMeter can run in distributed mode, in which one controller directs several load generator machines, each running the same plan with its own set of virtual users. The numbers of users then add up across machines. Teams also run generators inside the same cloud network as the system under test, because a long internet path adds delay and noise that has nothing to do with the application. As a rule, measure the generator machine itself, and keep its processor use comfortably below the point where it could skew timings.

Think time and arrival patterns

Real people read, think and scroll before the next click. If your sampler fires the next request instantly, one virtual user behaves like a very fast robot and creates far more load than a real person would. Timers, such as the Constant Timer or the Uniform Random Timer, add pauses between samplers. Choosing think times that match real behavior lets you reason about how many real users a given number of threads represents.

A load test is powerful enough to cause real damage and sensitive enough to leak real secrets. Treat both risks seriously.

Only test systems you are allowed to test

Sending a large flood of requests to a website you do not own, or have no written permission to test, can disrupt that service and may be illegal in many places. Always test systems you own or where the owner has explicitly agreed, preferably in a separate testing environment that mirrors production. When using embedded resources, exclude third-party addresses such as advertising networks and analytics services, because stressing them is stressing someone else’s system.

Protect secrets in test plans

A Test Plan file stores everything typed into it in plain text, including usernames, passwords and tokens. If it is committed to a shared code repository, those secrets travel with it. Better habits include loading credentials from a separate protected data file, passing sensitive values at run time through properties, and using dedicated test accounts that have no power over real data.

Testing the security of the system under load

Load tests can also reveal security behaviors, though they are not a replacement for a proper security review. Examples include whether rate limiting kicks in at a reasonable level, whether error pages leak internal details when the system is stressed, and whether sessions are properly separated between users. Treat any such finding as a prompt to involve the security team.

When a request does not behave, you need to see exactly what was sent and what came back. JMeter gives you several windows into this.

The debugging toolkit

A reliable debugging routine

Monitoring the system during the run

A sampler only measures what the client sees. To understand why a request was slow, watch the server side too: processor use, memory, database activity, queue lengths and error logs. Line these up with the time of the slow samples. Good teams run application monitoring tools next to JMeter, so every slow response in the report can be traced to a cause in the system.

Experienced engineers build HTTP samplers following a few reliable shapes, and avoid a handful of tempting shortcuts that cause trouble later.

Patterns that work

Anti-patterns to avoid

These are the habits that experienced performance engineers repeat on every project, and the slips that beginners make again and again.

Best practices checklist

Common mistakes

• Leaving the cookie manager out, so every request after login is anonymous.
• Forgetting the Content-Type header when sending a JSON body, then chasing strange 400 and 415 errors.
• Using both the Parameters table and Body Data in one sampler.
• Typing the protocol into the Server Name field instead of the Protocol field.
• Pasting a recorded token or session id and wondering why it works once and then fails.
• Reading a low average response time that actually comes from fast error pages.
• Testing from a laptop on Wi-Fi and blaming the server for network noise.
• Changing the plan between runs and then comparing the numbers as if nothing changed.

Here is how teams use the HTTP Request Sampler across different kinds of systems. These are illustrative patterns that show the kind of scale and care involved, not descriptions of any company’s private tooling.

What these examples share

In every case, the sampler is only a small part of a bigger design. The value comes from the whole arrangement: shared defaults, realistic data, captured tokens, meaningful assertions, human pacing and honest measurement.

The HTTP Request Sampler is excellent at what it does, and it has clear edges. Knowing them helps you choose the right tool and read results honestly.

Protocol-level testing versus browser-level testing

This is the single most important limit. The sampler measures how long the server side takes to answer requests, plus the network. It does not measure how long a browser takes to run scripts, paint the screen and make the page usable. A page that downloads in half a second might still feel slow if the browser spends three seconds running scripts. For full user experience numbers, teams add browser-based testing tools beside JMeter. The two approaches complement each other. JMeter answers “how much load can the system take”, and browser tools answer “how does the page feel”.

Open model versus closed model

A normal thread group is a closed model. A fixed number of users each wait for a response before sending the next request. If the server slows down, those users send fewer requests, which can hide how bad things get. Real internet traffic is closer to an open model, where new users keep arriving at a certain rate regardless of how slow the server is. To explore this, teams use throughput-controlling elements or special thread group plugins that fix the arrival rate. Understanding which model you are using helps you interpret the numbers correctly.

Choosing other samplers when needed

If the thing you test is not a web service, use the sampler built for it, such as the JDBC Request for databases, the JMS samplers for message queues, the FTP Request for file servers, the SMTP sampler for mail, or the TCP Sampler for raw network messages. Many real tests mix several kinds, for example HTTP calls plus a database check afterwards.

Short, direct answers to the questions people ask most often about the HTTP Request Sampler.

The HTTP Request Sampler is the voice of your virtual users. Everything else in a web test exists to help it speak honestly and to make sense of its answers.