What Is the HTTP Request Sampler?
The HTTP Request sampler is the most commonly used element in JMeter because most modern applications are tested over HTTP or HTTPS. It generates one HTTP call per execution, defined by a protocol, server name or IP, port, method (GET, POST, PUT, DELETE, and so on), and path. Every sampler placed under a Thread Group runs once per loop iteration for each virtual user, so a Thread Group with 50 threads and 10 loops executes the sampler 500 times.
Cricket analogy: Just as a bowler's over is the basic repeatable unit that gets executed ball after ball across a match, the HTTP Request sampler is the basic repeatable unit JMeter fires request after request, and a 50-thread, 10-loop plan is like 50 bowlers each sending down 10 overs.
Configuring Request Fields
The sampler's core fields are Protocol (http or https), Server Name or IP, Port Number, and Path, combined into a full URL at request time. The Method dropdown selects GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, or TRACE. For GET requests, query parameters are usually entered in the Parameters table as name/value pairs, which JMeter automatically URL-encodes and appends to the path unless the 'Encode?' checkbox is manually unchecked for a value that is already encoded. 'Follow Redirects' controls whether JMeter transparently follows 3xx responses, and 'Use KeepAlive' keeps the underlying TCP connection open across requests, mirroring how a real browser or HTTP client behaves.
Cricket analogy: Choosing GET versus POST is like choosing between a defensive block and an aggressive drive off the same delivery, same ball (URL) but a completely different shot (method) determines the outcome.
Sending Body Data for POST and PUT
<HTTPSamplerProxy guiclass="HttpTestSampleGui" testname="Create Order">
<stringProp name="HTTPSampler.domain">api.example.com</stringProp>
<stringProp name="HTTPSampler.port">443</stringProp>
<stringProp name="HTTPSampler.protocol">https</stringProp>
<stringProp name="HTTPSampler.path">/v1/orders</stringProp>
<stringProp name="HTTPSampler.method">POST</stringProp>
<boolProp name="HTTPSampler.postBodyRaw">true</boolProp>
<elementProp name="HTTPsampler.Arguments" elementType="Arguments">
<collectionProp name="Arguments.arguments">
<elementProp name="" elementType="HTTPArgument">
<stringProp name="Argument.value">{"sku":"SKU-1042","qty":2}</stringProp>
</elementProp>
</collectionProp>
</elementProp>
</HTTPSamplerProxy>For POST or PUT requests, the sampler offers two mutually distinct approaches. Checking 'Body Data' switches the sampler into raw mode, where whatever text is typed, JSON, XML, or plain text, is sent verbatim as the request body, which is the correct choice for JSON REST APIs. Leaving it unchecked keeps the sampler in Parameters mode, where name/value pairs are form-encoded as application/x-www-form-urlencoded, suited to classic HTML form submissions. A separate Files Upload tab handles multipart/form-data submissions, letting you attach a file path, parameter name, and MIME type for testing upload endpoints.
Cricket analogy: Choosing Body Data versus Parameters mode is like choosing to bowl a scripted yorker exactly as planned versus letting the field placement (encoding) dictate a generic delivery, raw mode gives you exact control over what's delivered.
For JSON APIs, always check 'Body Data' and paste raw JSON rather than trying to build it through the Parameters table, since Parameters mode form-encodes values and will corrupt JSON structure.
Implementation and Advanced Settings
Under the 'Advanced' tab, the Implementation dropdown chooses the underlying HTTP client engine, typically HttpClient4 (the modern default) versus the older Java implementation, which affects connection pooling behavior and proxy support. Connect Timeout and Response Timeout (in milliseconds) bound how long JMeter waits before marking a sampler as failed, which is essential for catching hung backends under load rather than letting threads block indefinitely. 'Retrieve All Embedded Resources' tells JMeter to parse the HTML response and automatically fetch images, CSS, and JavaScript, simulating full browser page-load behavior, and it can optionally use a configurable thread pool for parallel downloads.
Cricket analogy: Setting a Response Timeout is like a captain giving a bowler a strict over-rate deadline, if the delivery isn't bowled in time, the umpire calls it dead, just as JMeter marks a slow sampler as failed.
Enabling 'Retrieve All Embedded Resources' during a load test dramatically increases the number of actual HTTP calls per sampler iteration; always pair it with an HTTP Cache Manager and Cookie Manager, and verify your intended requests-per-second math accounts for the embedded resource fan-out.
- The HTTP Request sampler is JMeter's core element for issuing HTTP/HTTPS calls and runs once per thread per loop iteration.
- Protocol, Server Name/IP, Port, Path, and Method together define the target URL and verb.
- GET requests typically use the Parameters table; POST/PUT REST calls should use raw 'Body Data' mode for JSON payloads.
- The Files Upload tab handles multipart/form-data for testing file upload endpoints.
- Connect Timeout and Response Timeout prevent hung backends from blocking threads indefinitely under load.
- HttpClient4 is the modern recommended implementation over the legacy Java HTTP implementation.
- 'Retrieve All Embedded Resources' simulates full browser page loads but must be used deliberately since it multiplies actual request volume.
Practice what you learned
1. Which setting must be enabled to send a raw JSON payload in a POST request without JMeter form-encoding it?
2. What is the effect of enabling 'Retrieve All Embedded Resources'?
3. Which tab is used to test a multipart/form-data file upload endpoint?
4. What does the Response Timeout field control?
5. Which HTTP Request Implementation is the modern recommended default in current JMeter versions?
Was this page helpful?
You May Also Like
Configuring Headers and Cookies
Use the HTTP Header Manager and HTTP Cookie Manager to simulate realistic browser and API-client behavior, including auth headers and session cookies.
Parameterizing Requests with CSV Data
Use the CSV Data Set Config element to drive requests with varied, realistic test data instead of hardcoded values, avoiding caching and duplicate-key artifacts.
Correlation: Extracting Values with Extractors
Capture dynamic values like session tokens, CSRF tokens, and IDs from server responses and replay them in later requests using JMeter's extractor elements.