How to Performance Test Web Services Using JMeter

It's important to performance test web services — whether you have SOAP or REST APIs. In this blog, we break down how to performance test web services with JMeter.

What Is Web Service Performance Testing?

Web service performance testing involves testing the scalability of your web services with varying user load. This type of performance testing simulates real-life user load for the targeted web services (SOAP or REST). 

Web services are now virtually everywhere. Almost every website uses them for communicating with the backend, serving as one of the transports between components in microservices-based applications. Mobile applications use them widely similar to websites, financial applications get data on quotes rates, weather applications get actual updates, and so on. 

Of course, if the web service is subject to use by hundreds, thousands, or even millions of concurrent users (or threads of the upstream/downstream systems), it needs to be tested appropriately prior to being deployed into production. 

By doing performance testing for web services, teams can check whether the API endpoints are capable of handling the anticipated load and providing acceptable response times, as well as determine what could be the possible problems if the number of users suddenly increases. 

For example, the BlazeMeter website heavily relies on the BlazeMeter REST API. Therefore, a slow API response will impact page loading time, real-time results, and so on. 

How to Performance Test Web Services

In this blog, we will build a simple web service test plan against the BlazeMeter REST API with a few requests that will:

1. Create a Shared Folder.
2. Delete the Shared Folder.

To make a successful API request we will need two mandatory parameters: the API key and the Workspace ID.

API Key

The first one is the API key and secret because BlazeMeter API calls require authentication. You can create a key pair under your account settings. Click the gear icon at the upper right corner of BlazeMeter GUI and then choose the “API Keys” section on the left:

Workspace ID

The second one is Workspace ID, it can be obtained from the same page under the “Workspace” section.

Now that we have these two parameters, we can create a Shared Folder using the BlazeMeter REST API from the JMeter Test Plan. 

Let’s get started. 

Create Shared Folder Request With JMeter

As per the BlazeMeter REST API documentation, we need to send a POST request to the 
https://a.blazemeter.com/api/v4/folders endpoint. The payload should look like the following:

{
   "name": "New_folder",
   "workspaceId": 123456
}

We will need to:

• Replace 123456 with our own workspace ID.
• Make the folder name unique as duplicate shared folder names are not allowed. 

For that we’ll use a couple of useful JMeter Functions like

•  ${__time(,)} to add the current timestamp.
• ${__threadNum} to add current virtual user’s number and.
• ${__groovy(vars.getIteration(),)} to add the current loop number of the Thread Group.

So the modified request will look like:

{
   "name": "folder${__time(,)}user${__threadNum}iteration${__groovy(vars.getIteration(),)}",
   "workspaceId": 32841
}

Now let us send it using JMeter. We will need:

• A Thread Group to define how many users and iterations we want to run. Since we are only creating and debugging the test let’s keep it with default settings of one user and one iteration.

• The HTTP Authorization Manager to provide our BlazeMeter API Key. Otherwise, the API requests will fail due to missing authentication details.

• The HTTP Header Manager to send the relevant Content-Type header. Otherwise, the BlazeMeter REST API will not process our requests.

An HTTP Request sampler. This will send the HTTP POST request to create the Shared Folder.

That’s it! We can now add a View Results Tree listener, which allows us to inspect request and response details and run our test. 

As we can see the request was successful and the folder with the name of “folder1667984143412user1iteration1” with the ID “636b6b10ef03b02c0b2274c6” has been successfully created.

Delete Shared Folder Request With JMeter

A well-behaved test leaves the system in its initial state, so let us delete the folder we have just created. According to the BlazeMeter API documentation, we need to send an HTTP DELETE request to the following endpoint: https://a.blazemeter.com/api/v4/folders/5b96c41fad67294528f03df8.

In this case, we need to use our own folder ID instead of the example one from the documentation. Therefore, in order to successfully execute the request which will delete the folder we need to:

1. Extract the created folder’s ID and store it into a JMeter Variable.
2. Use the variable from the previous step in the Path of the next request. 

JMeter provides several Post-Processors to deal with different response content types, such as:

• CSS Selector Extractor for HTML.
• XPath Extractor and XPath2 Extractor for XML and XHTML (can be used for HTML as well).
• JSON Extractor and JSON JMESPath Extractor for JSON.
• Regular Expression Extractor and Boundary Extractor for anything else.

Since we are getting a JSON object as the response, it makes sense to consider using the JSON JMESPath extractor to extract the ID. The relevant JMESPath query would be as simple as result.id, and we can check how it works using the JSON JMESPath Tester mode of the View Results Tree listener.

Since the above image shows that the JMESPath expression works, now we can add the JSON JMESPath Extractor to our test plan and perform the appropriate configuration:

Now let’s add another HTTP Request sampler to delete the folder we’ve just created.

Mention that we’re now using DELETE as the HTTP Request method and add the ${folderId} JMeter Variable to the request path. Note that the variable comes from the JSON JMESPath Extractor.

Let us run the test once again:

As we can see, the ${folderId} JMeter Variable placeholder has been substituted with the value of the variable extracted from the previous response and the request is successful. 

Add a Delay Between Requests

Let us add another small but important detail: a delay between requests. 

Imagine that a real user creates a folder and realizes that the folder was created in the wrong workspace or just by accident. Real users need some time to find the relevant way to delete the folder, move the mouse pointer, hover the folder name, wait for the icon to appear, click the icon, confirm, and so on. Since this process takes time, we should also put a realistic delay between the requests (e.g. five seconds). 

JMeter Timers allow for introducing delays based on various algorithms. For this example, we will just put a five-second delay between folder creation and deletion. To do this, we need to add a Constant Timer as a child of the second request and configure it to “sleep” for 5000 milliseconds. 

We should also disable the View Results Tree listener because we do not need it anymore. 

Performance Test Web Services With BlazeMeter

Now it’s time to run our test, which we will do in BlazeMeter.

Execute Web Services Performance Test

Let us create a new Performance Test.

And upload our JMeter script there:

We are going to kick off 100 virtual users for 10 minutes with five minutes of ramp-up time, which means that each minute another 20 users will be added and the load will increase gradually. No matter what we have defined in the Thread Group, BlazeMeter will override the values with the ones we define under the test configuration page. 

Of course if you want to use the original Thread Group settings this is also possible. Just disable the “Load Configuration” parameters and your Thread Group setup would revert back to the original. 

Analyze Test Results

Let us analyze the test results using BlazeMeter. You can find the overall metrics on the Summary Report page.

Looking at the charts we can see that:

1. Response time remains nearly the same during the whole duration of the test and even goes down as the time passes.
2. Number of hits per second grows proportionally to the number of active threads (virtual users).
3. Average response time is below 400 milliseconds and 90% percentile is below 500 milliseconds, which means 90% of users are capable of getting the response from the API in less than a half of a second.
4. There are no errors.
5. On average 100 users generated 23.75 requests per second. You can calculate this by dividing the test duration by the total number of requests executed.

So BlazeMeter’s REST API endpoints for creating and deleting the shared folders are working more than fine, assuming 100 concurrent users are constantly doing these actions. 

BlazeMeter provides more comprehensive Timeline Reports where you can see multiple metrics of your choice in a single chart. This feature makes metrics and KPIs correlation much easier:

Bottom Line

In this blog, we learned how to do web services performance testing using JMeter, and how to view how those tests performed using BlazeMeter.

In addition to the BlazeMeter Timeline Report, BlazeMeter offers many reporting options such as inspecting load generator health, sharing reports, generating management-friendly summary, comparing different test executions against baseline and each other, and more.

Experience how JMeter and BlazeMeter work together in action. Start your free trial of BlazeMeter today.
 

START TESTING NOW

Related Resources: 

• Web Testing with JMeter: How To Properly Handle Embedded Resources in HTML Responses
• How to Set Your JMeter Load Test to Use Client Side Certificates