How to Load Test Asynchronous HTTP Requests with JMeter

In this article we will cover the main issues that developers face when they need to load test asynchronous HTTP requests with Apache JMeter™ and learn to overcome them. You will also learn how to create a JMeter async request. 

What is a JMeter Async request? 

An asynchronous (async) HTTP request is a request that is executed in the application or page background without interrupting or preventing user engagement. 

The asynchronous HTTP request does not wait for an immediate response from the server. You send the request, and your application continues to work. 

Users can enter data into forms, press other buttons, and even leave the form. There is no load spinner or a rotating sandglass, and there are no large freezes of the application until an answer is received. When the processing of your request on the Server is completed, it will let the requestor know about it.

For instance, data in a table will be updated. As a result, we have an application that is sensitive, interactive and fast. On the web, asynchronous requests are most often associated with AJAX and XHR technologies.

To create a JMeter async request,  we need to solve two tasks:

1. Perform other actions while waiting for a response to an asynchronous HTTP request.
2. Get the response to our request.

1. Performing Actions While Waiting for the Response

The Solution: Running Parallel Requests

We can solve the first task by using the Parallel Controller. You can install it via JMeter Plugins. All elements inside the Parallel Controller will be executed parallel to each other. This way, you will have one main flow and other flows with JMeter async requests, which will be executed in a parallel way.

The scenario will be the following:

async request 1 and async request 2 will run in parallel to samplers that are in the “[Simple Controller] Main Flow” controller.

2. Getting the Server Response

The mechanism of asynchronous data exchange between the client and the server can have different behaviors. The left part of the picture below shows one of implementations: the client sends a request and receives a response only when the data is updated on the server, and then sends a request again. The next implementation, on the right side of the picture, works as an event subscription: The client sends only one message and after it the server sends requests when the data is updated.

Now we will consider the technologies by which you can implement these types of data exchanges in JMeter.

Solution 1: Long-Polling

In long-polling, the client initializes a HTTP connection and does not close it until an event occurs. Upon the occurrence of an event, the client receives data and re-opens the connection. This technology is suitable for implementing the first type of client-server interaction.

In JMeter, for long-polling request simulation, we can use HTTP Request Sampler. This sampler has Response Timeout field. This field causes the server to not break the connection ahead of time and we can use it to wait for a server event. However, this solution is lacking because it configures a fixed maximum of response time waiting, and the response might take longer than the time set (thus marking the request as unsuccessful).

Solution 2: SSE (Server-Sent Events)

SSE can be used to implement the second type of data exchange: the client establishes a  HTTP connection to the server and receives data from it, which is updated periodicity. Unfortunately at the moment, there is no good solution for working with SSE in JMeter. Maybe someone should think about extension developing. In the meantime, you can use Gatling, which supports working with SSE.

Solution 3: WebSockets

WebSockets are suitable for both types of data exchange. This technology allows you to create an interactive connection between the client and the server for real-time messaging. That is, we can send a message that will give us a subscription to receive any data, or send a message and wait for a response as long as necessary. Here the situation is much better than with SSE. JMeter has 2 Plugins for testing WebSocket connections: JMeter WebSocket Sampler by Maciej Zaleski and JMeter WebSocket Samplers by Peter Doornbosch, and you can read about how to use them from the blog posts.

Solution 4: HTTP Server in Client Application

And the last option in this article, which is suitable for both types of exchanging too, is using an HTTP server on the client side (a rarely used option). This option can be used in a case where we ask the server to perform an operation that takes a very long time. This prevents a situation when we ask the server for a status of the operation every 5 minutes. For example, the client asks to build a large report and when it is built, send it to a specific address (http server on the client).

That is, the client sends a request to the server being tested and receives a response that the server has started to perform some work. Accordingly, we have no open connections and we do not check the progress on the server every minute. When the server finishes the work, it sends the request with information about it to its HTTP server.

As an example, you can review this plugin. It is not in the Plugin Manager, because it is developed for a certain implementation of tested server and it will have to be changed for your needs. It deploys a small http server, when the sampler starts and waits for a response from the server.

The plugin works as follows (A is our client, B is a tested server):

• A :  NotificationReceiverCreation sampler starts and notifies NanoHTTPD that it is waiting for an answer from B
• A : Any sampler sends a request to B for initialization of action
• A : NotificationReceiverWait sampler starts and waits for the response
• B : B sends the answer to A (to our NanoHTTPD)
• A : NanoHTTPD notifies NotificationReceiverWait sampler that the answer has arrived
• A : NotificationReceiverWait Sample is closed, the time is recorded

Accordingly, our task is to process the flow described above. We wrote a little demo server to demonstrate the working of the plugin. It uses NanoHTTPD too and you can download it from GitHub. It works as follows:

A client sends a GET request to localhost:8085/build address with a reportId parameter. This parameter must equal the Functional Identifier in NotificationReceiverCreation and NotificationReceiverWait. Using this parameter, we will be able to track the chain of requests and understand that the message with the report is the answer to our request and not to some other one.

• Server sends response with information that it has started building the report.
• Server waits 3 seconds.
• Server sends request to our NanoHTTPD Server in JMeter.

Now we can proceed with the demonstration:

1. Compile the source code of the plugin and put it in the /lib/ext folder

2. You also need to download nanohttpd lib and put it in /lib folder.

3. The structure of script for this case is shown in the screenshot below:

4. A GIF that demonstrates the work is presented below.

Notes for Your JMeter Asynchronous HTTP Requests

1. nanoHTTPD is deployed immediately when you select a sampler, and not when you run the test.

2. There will be only one server. These samplers will simply add messages to the waiting queue, but will not create a big amount of http servers.

3. If you see the following error, it means that you have something located on your 8080 port. The nano server tries to use this port and fails, so you either need to kill what's located on the specified port or change the line that is responsible for the port selecting in the HttpServer.java file (line 35). 

Bottom Line

That’s it! You now know how to deal with JMeter asynchronous HTTP requests. To learn more advanced JMeter usage, check out our free BlazeMeter University.

You can also scale your JMeter tests and JMeter async requests through BlazeMeter, and enjoy running your tests from multiple locations, security and advanced reporting.

START TESTING NOW