NGINX stress testing scheme

NGINX Sizing Guide: How to Test

A topology and hardware

1.1 Topology

All tests were done using three separate machines connected via dual 40 GbE links in a simple, flat Layer 2 network. (The software version of the figure below has been updated)

To generate traffic from the client machine, we used wrk - Similar toab(ApacheBench) performance testing tool. All traffic is directed to the NGINX reverse proxy server, which forwards the connection to the web server backend.

1.2 Hardware

Machine	CPU	Network	Memory
Client	16 Real Cores	Omit	16GB
Reverse proxy server	16 Real Cores	Omit	16GB
Application Server	16 Real Cores	Omit	16GB

II Software used

• wrk Traffic that generates NGINX proxies running version 4.0.0 on client computers. We follow theseillustrateIt is installed.

III Test methodology

The performance of NGINX as a reverse proxy server with different CPU numbers was tested. An NGINX worker Processes consume one CPU, so to measure the performance of different numbers of CPUs, we changed NGINX worker The number of processes, with two, four, eight, etc worker Process repeats the test.

ℹ️note：

To set NGINX manually workerNumber of processes, please use worker_processes Directives. The default value is auto。

IV. Performance indicators

The following performance metrics are measured:

• Requests per second (RPS) - Measure the ability to handle HTTP requests. In the test, each client sent a request for a 1 KB file size over the keepalive connection. The reverse proxy server processes each request and forwards it to the web server through another keepalive connection.
• SSL/TLS transactions per second (TPS) - Measure the ability to handle new SSL/TLS connections. In testing, each client sends a series of HTTPS requests, each on a new connection. The reverse proxy server resolves the requests and forwards them to the web server through the established keepalive connection. The web server sends back a 0-byte response for each request.
• throughput - Measure the throughput that NGINX can sustain when serving 1 MB files over HTTP.

📑cite：

NGINX Key Performance Indicators

5. Run the test

To generate all client traffic, we use wrk The following options for the tool:

• -c The option specifies the number of TCP connections to create. For our tests, we set it to 50 connections.
• -d The option specifies when the traffic is generated. We run the tests for 3 minutes at a time.
• -t Option specifies the number of threads to create. We specify a thread.

Pass taskset Instructions, to make full use of each CPU, can be individual wrk The process is pinned to the CPU. with an increase wrk This approach produces more consistent results compared to the number of threads.

5.1 Requests Per Second

To measure requests per second (RPS), run the following script:

for i in `seq 1 number-of-CPUs`; do
    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1kb.bin
done

The test produced per CPU wrk of a copy. Each replica creates 50 TCP connections and requests for 1 KB files continuously for 3 minutes (180 seconds).

5.2 SSL/TLS transactions per second

To measure SSL/TLS transactions per second (TLS), we ran the following script:

for i in `seq 1 number-of-CPUs`; do
    taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Connection: close' https://Reverse-Proxy-Server-IP-address/0kb.bin
done

This test uses the same as the previous test -c，-d and -tvalue, but there are two significant differences, as this focus is on the handling of SSL/TLS connections:

• The client opens and closes connections for each request (-H Option settings Connection: close HTTP headers).
• The requested file is 0 bytes instead of 1 KB in size.

5.3 Throughput

To measure throughput, we ran the following script:

for i in `seq 1 number-of-CPUs`; do
    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1mb.bin
done

The only difference from the first test is that the file is larger, with a size of 1 MB. We found that using a larger file size of 10 MB did not improve overall throughput.

Install wrk on Linux

wrk requires openssl dev package and gcc/dev Stack.

Below is a brief explanation on how to install wrk on Linux.

CentOS/RedHat/Fedora

sudo yum groupinstall 'Development Tools'
sudo yum install -y openssl-devel git 
git clone https://github.com/wg/wrk.git wrk
cd wrk
make
＃将可执行文件移动到 PATH 中的某个位置 
sudo cp wrk /somewhere/in/your/PATH

Install build tools, openssl dev libs (including header files), and git. Then use git to download wrk and build.