Load test your NGINX optimizations

Use wrk to test NGINX

You can skip this section if you already have a performance test method for your NGINX deployment.

One method for testing NGINX is with wrk. Use this method as a starting point if you don’t already have an established load test strategy.

To understand the impact of tuning on your deployment, use a workload that reflects your request pattern, response size, TLS behavior, concurrency, and upstream service behavior.

About wrk

wrk is an HTTP load test tool that lets you configure the number of threads, open connections, and test duration. It reports throughput and latency statistics. Another option is h2load , which is useful when you want to test HTTP/2 behavior or prefer the nghttp2 toolchain.

Install wrk

You can install wrk by cloning the source and using make.

Install the required build dependencies:

    

        
        
sudo apt-get update
sudo apt-get install -y build-essential libssl-dev git zlib1g-dev

    

Build wrk

Use the following commands to build wrk:

    

        
        
git clone https://github.com/wg/wrk
cd wrk
make

    

Example load test setup

The following diagram shows a typical multi-node test setup. The load generator runs wrk. The instance under test runs the reverse proxy or API gateway. The file servers act as upstream servers for the reverse proxy or API gateway.

You can also run wrk directly against NGINX file servers, or run wrk on the same node as NGINX. Choose a setup that reflects your deployment and avoids making the load generator the bottleneck.

Example NGINX load test setup

Run a wrk test

The NGINX file servers need files to serve. If you’re using the configuration files discussed in Tune a static file server or Tune a reverse proxy or API gateway , run the following commands on each file server to create sample files:

    

        
        
# Create 1 KB file in the reverse proxy use case directory
sudo dd if=/dev/urandom of=/usr/share/nginx/html/1kb bs=1024 count=1

# Create 5 KB file in the reverse proxy use case directory
sudo dd if=/dev/urandom of=/usr/share/nginx/html/5kb bs=1024 count=5

# Create 10 KB file in the reverse proxy use case directory
sudo dd if=/dev/urandom of=/usr/share/nginx/html/10kb bs=1024 count=10

# Copy files into the API gateway use case directory
sudo mkdir -p /usr/share/nginx/html/api_new
sudo cp /usr/share/nginx/html/1kb /usr/share/nginx/html/api_new
sudo cp /usr/share/nginx/html/5kb /usr/share/nginx/html/api_new
sudo cp /usr/share/nginx/html/10kb /usr/share/nginx/html/api_new

    

You don’t need to create these files on reverse proxy or API gateway nodes because they don’t serve files directly.

Run the sample commands from the wrk build directory, or use the full path to the wrk binary.

The following sample command tests a file server or reverse proxy:

    

        
        
./wrk -t64 -c200 -d60s --latency https://<nginx_ip_or_dns>/1kb

    

Choose thread and connection values that load the NGINX server without causing connection, read, or write errors in wrk or NGINX. Because wrk does not use a fixed request-rate option, adjust -t, -c, and -d to scale load and keep the same values when comparing configurations.

The following sample command tests an API gateway path:

    

        
        
./wrk -t64 -c200 -d60s --latency https://<nginx_ip_or_dns>/api_old/1kb

    

The API gateway shown in Tune a reverse proxy or API gateway rewrites api_old to api_new. This is why the sample files are copied into /usr/share/nginx/html/api_new as well as the document root on the file servers.

What you’ve accomplished

You’ve now built wrk, created sample files, and run repeatable load tests against an NGINX workload.

You can use the guidance in this Learning Path to optimize and compare the performance of your NGINX workloads on Arm-based platforms.