NGINX Key Performance Indicators

RPS

RPS (Requests Per Second) for HTTP Requests

The following table and graph show the number of HTTP requests with different CPU numbers and different request sizes, in kilobytes (KB).

CPUs	0 KB	1 KB	10 KB	100 KB
1	145,551	74,091	54,684	33,125
2	249,293	131,466	102,069	62,554
4	543,061	261,269	207,848	88,691
8	1,048,421	524,745	392,151	91,640
16	2,001,846	972,382	663,921	91,623
32	3,019,182	1,316,362	774,567	91,640
36	3,298,511	1,309,358	764,744	91,655

RPS for HTTPS Requests

HTTPS RPS is lower than HTTP RPS for the same configured bare metal hardware because the data encryption and decryption required to protect data transmitted between machines is computationally expensive.

Still, continued evolution of Intel architecture—resulting in servers with faster processors and better memory management—means that software performance for CPU-bound cryptographic tasks continues to improve compared to dedicated hardware cryptographic devices.

CPUs	0 KB	1 KB	10 KB	100 KB
1	71,561	40,207	23,308	4,830
2	151,325	85,139	48,654	9,871
4	324,654	178,395	96,808	19,355
8	647,213	359,576	198,818	38,900
16	1,262,999	690,329	383,860	77,427
32	2,197,336	1,207,959	692,804	90,430
36	2,175,945	1,239,624	733,745	89,842

Connections per Second

Connections per second (CPS) measures NGINX’s ability to create a new TCP connection to a client that has made a request. The client sends a series of HTTP or HTTPS requests, each of which is established on a new connection. NGINX parses the requests and sends back a 0-byte response for each request. Once the request is satisfied, the connection is closed.

ℹ️Remark:

The HTTPS variant of this test is often referred to as SSL transactions per second (SSLTPS).

CPS for HTTP Requests

The table and graph show the CPS for HTTP requests across different CPUs.

CPUs	CPS
1	34,344
2	54,368
4	123,164
8	194,967
16	255,032
32	261,033
36	257,277

CPS for HTTPS Requests

Tables and graphs show CPS for HTTPS requests.

CPUs	CPS
1	428
2	869
4	1,735
8	3,399
16	6,676
24	10,274
36	10,067

Throughput

These tests measure NGINX’s ability to sustain a throughput of 180 seconds of HTTP requests in Gbps.

CPUs	100 KB	1 MB	10 MB
1	13	48	68
2	20	69	71
4	45	67	71
8	50	68	72
16	48	66	71
32	48	66	71
36	48	66	71

Throughput is proportional to the size of HTTP requests made by client computers. NGINX will get higher throughput when the file size is larger because a given request results in more data being transferred. However, performance peaks at about 8 CPUs; For tasks with higher throughput, there is not necessarily more benefit.

Miscellanies

• Hyperthreading is available on the CPU we tested, which means that other NGINX worker processes can be run to use the full capacity of the hyperthreaded CPU. We didn’t enable hyperthreading for the tests reported here, but we do see that using hyperthreading in separate tests can improve performance. Most notably, hyperthreading boosted SSL TPS by about 50%.
• The numbers shown here are related to OpenSSL 1.0.1. We also tested OpenSSL 1.0.2 and found a 2x performance improvement. OpenSSL 1.0.1 is still widely used, but we recommend OpenSSL 1.0.2 for better security and performance.
• We also tested Elliptic Curve Cryptography (ECC), but the results shown here use RSA. For encryption, RSA is still more widely used than ECC, although ECC is typically deployed on mobile devices that require efficiency. We have seen a 2 to 3x improvement in the performance of ECC compared to standard RSA certificates, and we recommend that you consider implementing ECC.

The combination of moving to OpenSSL 1.0.2 and moving to ECC could result in very powerful performance improvements. Furthermore, our results show that using 16 CPUs or even 32 CPUs for SSL can lead to a really significant improvement if you are currently using a 4-CPU or 8-CPU server.