How to Use JMeter to Performance Test a REST API

Use JMeter to Performance Test a REST API

Performance testing a REST API reveals its runtime behaviour under stress and can be an early indicator of QoS violations in production. Apache JMeter offers a GUI mode where such load tests can be created and their results be analyzed easily.

In this tutorial, I will show you how to test the performance of the FizzBuzz-API written in Rust presented in one of my previous articles. Let’s get started.

Install JMeter

Installing JMeter is very simple once you have Java installed on your machine (there are numerous tutorials to install Java, so I won’t go into detail here).

Once you can run the following command, you can continue with JMeter:

java -version

Download JMeter from this link (select the ZIP archive) and unpack it. In the extracted folder, go to bin/ and execute jmeter.sh (on Linux) or jmeter.bat (on Windows). You should be greeted by the following GUI:

Create a Simple Load Test

We’ll add a Thread Group which represents a group of artificial users interacting with your API. In the left panel, right click on “Test Plan” and select “Add -> Threads (Users) -> Thread Group”:

Enter the following parameters on the right panel under “Thread Properties”:

The number of threads determines how many simulated users should connect to your REST API simultaneously. The ramp-up period defines how long JMeter waits before the next request is started.

For example, if we have 64 users and a ramp-up period of 100 seconds, JMeter would add a delay of 100 / 64 seconds between each user’s first request.

Define the Invoked Action

You now have to instruct JMeter on which action should be performed by the simulated users. First, we define the base URL. Right click on the Thread Group and select “Add -> Config Element -> HTTP Request Defaults”.

For my Rust application, I use the following settings:

The default protocol is HTTP and I use localhost:8000 since this is the default port for a Rocket web application.

Next, define which specific endpoint should be used by adding an HTTP Request via “Add -> Sampler -> HTTP Request”:

And enter the following settings:

Notice that protocol and server name / port are left blank because they were set by the HTTP defaults earlier.

In my example, I’m using a GET request on the endpoint /<count> which controls how many FizzBuzz iterations are computed. By changing this number, the computational load per request can be modified. For example, /5000 means that FizzBuzz is computed for the numbers 1 to 5000.

Generating a Response Time Graph

Since we want to monitor how our API performs, the response time graph is an illustrative way of showing the average response time per request. Add it by right clicking the Thread Group and selecting “Add -> Listener -> Response Time Graph”.

The resulting graph will display how long on average it takes for an API call to produce a result.

Run the Test

Although the GUI is not a reliable way to execute tests and the command-line interface should be used instead, you can quickly verify that your test is working correctly by selecting the play button ().

Before starting the test, make sure your API is running and accepting HTTP requests. For Rust and Rocket, you can either run the application with cargo run or compile it and run the resulting binary with cargo build --release and ./target/release/fizzbuzz.exe.

After pressing the play button to start your test, you can track how many connections have been opened on the upper right corner of the interface (14 of 64 users in this example):

While the test is running, the Rust console window is showing a large number of incoming connections when using cargo run:

Interpreting the Response Time Graph

During and after the test, you can have a look at the response time graph by selecting “Response Time Graph” in the panel on the left and “Display graph” in the panel on the right.

In this example, you can easily see that the average response time for 64 parallel users is about 1.3 seconds on my absolutely non-competitive hardware (after the ramp-up period where increasingly more users are added).

Keep in mind that there are many factors contributing to the fact that this number won’t match your real response time in production, including:

  • the fact that both JMeter and the API run on the same hardware and have almost no network latency
  • the execution of JMeter itself consumes a certain part of the hardware resources
  • in a production environment, a web server such as nginx would be used in front of the API
  • performance optimizations such as caching would be applied

However, a quick measurement such as this can be more than enough when you just want to verify that you can support a given order of magnitude of parallel requests in production.

A REST API in Rust and Rocket in 5 Minutes

Learn How to Create a FizzBuzz Implementation in Rust

FizzBuzz is a classical software developer interview question with the simple goal of writing an application that outputs “Fizz” for numbers divisible by 3, “Buzz” for numbers divisible by 5 and “FizzBuzz” for numbers matching both cases.

In this article, I will show you how to implement FizzBuzz using the Rust programming language and the Rocket framework.

Start by using Rust nightly and setting up a new Rust project using cargo:

rustup default nightly
cargo new fizzbuzz --bin
cd fizzbuzz
rustup update && cargo update

Edit Caro.toml and add the following dependency for Rocket:

[dependencies]
rocket = "0.4.1"

Continue reading