Processor in JMeter: PreProcessor & PostProcessor

A processor in Apache JMeter is a test plan element that modifies the Samplers inside its scope. It runs automatically, either just before a request leaves JMeter or immediately after a response arrives, which makes it the main mechanism for handling dynamic data during a performance test.

There are 2 Types of processors:

1. Pre-processor
2. Post-processor

Scope decides how far a processor reaches. A processor placed directly under a Test Plan or a Thread Group applies to every Sampler below it, while a processor nested inside a single Sampler affects only that request. Understanding this rule prevents the configuration mistakes covered in the troubleshooting section of this page.

Pre-processor

Pre-processor executes some action before making Sampler Request.

Consider a simple example: let’s say you wanted JMeter to “spider” through the website under test, parse link(check all links on the page) and return the HTML. You would add some action such as “HTML link parser” to your controller before creating an HTTP request.

The diagram above shows the Pre-processor sitting between the controller and the outgoing request. Because it runs first, it is the correct place to build request data: generating a timestamp, reading a value from a CSV column, rewriting a session identifier into the URL, or assigning different credentials to each virtual user.

Post-processor

Post-processor executes some action after making a Sampler Request.

Consider a simple example: JMeter sends an HTTP request to the web server under test (etc www.google.com) and get the response. You want JMeter to stop the test if the server response is an error. You can use the post-processor to do above task as follows:

As the second diagram illustrates, the Post-processor reads the response after the Sampler completes. This is also the standard answer to correlation. When a server returns a token, a session ID, or an order number that changes on every run, a Post-processor captures that value into a JMeter variable so the next Sampler can reuse it.

Types of PreProcessors in JMeter

Apache JMeter ships with a compact set of PreProcessors. Each one prepares a Sampler in a different way, so selecting the right element keeps a test plan readable and easy to maintain.

• Sample Timeout: Defines a maximum duration for a request. Any Sampler that runs longer than the configured value is marked as failed.
• User Parameters: Assigns specific values to variables per virtual user, so each thread sends its own data set.
• HTML Link Parser: Spiders the page under test, parses the links it finds, and feeds them into the following HTTP Request.
• HTTP URL Re-writing Modifier: Injects a session identifier into the URL for applications that track sessions without cookies.
• RegEx User Parameters: Populates request parameters using values captured by a regular expression from an earlier response.
• JDBC PreProcessor: Runs a SQL statement before the Sampler, which is useful for seeding or resetting database records.
• JSR223 PreProcessor: Executes a Groovy or Java script for any custom preparation logic. It supersedes the older BeanShell PreProcessor and performs significantly better under load.

Types of PostProcessors in JMeter

PostProcessors fall into two groups: extractors that pull values out of a response, and handlers that react to the result of a Sampler. The table below maps each element to the response format it suits best.

PostProcessor	Best Suited For	Typical Use
Regular Expression Extractor	Any text response	Capturing tokens or IDs from HTML and plain text
Boundary Extractor	Any text response	Capturing a value using a left and right boundary instead of a full regular expression
JSON Extractor	JSON responses	Reading fields from REST payloads during API testing
CSS/jQuery Extractor	HTML responses	Selecting an element by CSS selector
XPath Extractor	XML and XHTML responses	Navigating a structured document tree
JDBC PostProcessor	Database results	Verifying or cleaning up rows after a request
JSR223 PostProcessor	Any response	Custom scripted parsing and assertions
Result Status Action Handler	Any response	Stopping a thread or the whole test when a Sampler fails

The Boundary Extractor arrived in JMeter 4.0 and is often the fastest option to write, because it only asks for the text immediately to the left and right of the value. The Regular Expression Extractor remains the more flexible choice when the surrounding markup varies between responses.

Difference Between PreProcessor and PostProcessor

Both elements share the same scope rules, yet they solve opposite problems. The comparison below summarizes the distinction before the worked example.

Parameter	PreProcessor	PostProcessor
Execution time	Runs before the Sampler sends its request	Runs after the Sampler receives its response
Primary purpose	Prepares and modifies request data	Reads response data and reacts to it
Typical elements	User Parameters, HTML Link Parser, JSR223 PreProcessor	Regular Expression Extractor, JSON Extractor, Result Status Action Handler
Effect on flow	Cannot stop the test, only shapes the request	Can stop a thread or the entire test run
Common goal	Parameterization	Correlation and error handling

In practice the two work as a pair. A PostProcessor captures a session token from a login response, and a PreProcessor on the next request injects that token before the call is sent. The example that follows demonstrates the PostProcessor half of that pattern.

Post Processor Example

This tutorial will show you step-by-step instructions on how to use Post-processor in JMeter. Let start with the simple test script.

1. JMeter sends an HTTP request to the web server under test www.google.com.
2. JMeter gets a response from the Google server.
3. If server response is an error, JMeter will stop the test.
4. If server response OK (no error), JMeter will continue the test.

Here is the roadmap of this example:

Pre-condition:

We re-use the Step 1 and Step 2 in article JMeter Performance Testing. If JMeter is not installed yet, follow the JMeter installation guide first.

Step 1) Add Thread Group

Right click on the Test Plan and add a new thread group: Add -> Threads (Users) -> Thread Group

But in Thread Group control panel, enter Thread Properties as follows:

This setting lets JMeter create 10 user request to http://www.google.com 10 times.

Step 2) Add JMeter elements

• Add HTTP request default
• Add HTTP request

We still make JMeter send request http://www.google.com to Google server.

Step 3) Add Post-Processor Element

Right Click Thread Group -> Add -> Post Processor -> Result Status Action Handler

Result Status Action Handler allows the user to stop the thread or the whole test if the user request failed.

In Result Status Action Handle Pane, choose Stop Test Now. This selection will stop the test if JMeter get the error from server response.

Step 4) Config the HTTP Request

Open the HTTP Request Panel. Enter “abc” to the Path field.

When you enter “abc” to the path, JMeter will create a URL request to Google server: http://www.google.com/abc. This URL doesn’t exist on Google server. It is wrong URL request so Google server will return an error.

Step 5) Add View Result Tree

Right Click Thread Group -> Add -> Listener -> View Result Tree

Step 6) Run Test

Select View Result Tree, press Run button on Menu bar. You will see the error response from Google server and the test will stop with out completing 100 threads.

Now return to step 4, open the HTTP Request pane, enter “calendar” to the pane. It makes JMeter create URL request https://calendar.google.com/calendar/u/0/r to the Google server. This is correct URL request so Google server will return OK (no error).

Select View Result Tree, press Run button on Menu bar. You will see the OK response from Google server and the test will continue until all 100 threads are complete.

Adding an assertion alongside the Result Status Action Handler makes the check stricter, because an assertion can fail a Sampler that returned HTTP 200 but delivered the wrong content.

Troubleshooting

If you face the issue while running the above scenario … do the following:

1. Check whether you are connecting to the internet via a proxy. If yes, remove the proxy.
2. Open a new instance of Jmeter
3. Open the ProcessorTestPlan.jmx in Jmeter
4. Double-click on Thread Group -> View Results Tree
5. Run the Test

If a Post-processor appears to do nothing, check its position first. A Post-processor placed outside the scope of the Sampler it targets never runs, which is the single most frequent cause of an empty extracted variable. Related elements such as controllers and distributed testing follow the same scope logic.

FAQs