Update: This article uses benchmark figures produced in July 2014. More recent benchmarks (NGINX Sizing Guide, September 2016) use more recent hardware and OpenSSL implementations to provide more representative performance measurements.
In particular, in the more recent benchmarks NGINX and NGINX Plus sustained over 2,000 SSL transactions per second per core, up to 16 cores (33k SSL TPS), using high‑strength 256‑bit ECC certificates and the secure, PFS‑enabled ECDHE‑ECDSA‑AES256‑GCM‑SHA384 cipher.
NGINX and NGINX Plus use OpenSSL to terminate encrypted SSL and TLS connections. In this article, we take a high‑level view of SSL performance, and try to establish a correlation between difficult‑to‑measure SSL performance and easier‑to‑measure OpenSSL performance.
NGINX and NGINX Plus are commonly used to terminate encrypted SSL and TLS connections on behalf of upstream web and application servers. SSL termination at the edge of an application reduces the load on internal servers, simplifies certificate management, and reduces certificate costs. However, because it is extremely CPU‑intensive, it can create a scalability bottleneck that may limit growth.
Our new NGINX SSL Performance whitepaper investigates the performance of NGINX’s SSL termination under a range of traffic types and ciphers. It seeks to establish a correlation between OpenSSL benchmarks and NGINX performance, to enable users to rapidly estimate the capacity of selected hardware or virtual machines.
Summary of Results
You can use the
rsa command to measure how many RSA 2048‑bit signs a single core can sustain per second. As a rough estimate, the number of full SSL handshakes (using ECDHE‑RSA) that a single core can sustain is between 45% and 60% of that value.
For example, in the tests conducted, a single virtualized Intel core could perform approximately 600 RSA 2048‑bit signs per second, and 350 full 2048‑bit SSL handshake operations per second. This equates to several hundred new users of your service per second per core.
NGINX’s SSL performance scales with the number of cores available on the host server, until other limits (typically bandwidth) are met, so an 8‑core virtual machine could accept traffic from well over 1,000 new users per second and still have resources to spare.