According to W3Techs' statistics up to June 2022, NGINX is the most extensively used web server globally, commanding a substantial 33.6% market share. Its widespread adoption and commendable performance have established a high level of trust among users, making it a frequent benchmark for comparison.
Performance Test Results
In practical testing, we compared the performance of APISIX and NGINX in a simple scenario, with the following results:
APISIX demonstrates a QPS performance of 58,080 on a single CPU core, surpassing NGINX's performance of 37,154 on the same hardware.
APISIX's performance outpaces NGINX by an impressive 56%.
Test Configuration & Stress Test Results
| APISIX | NGINX | |
|---|---|---|
| Single-Core QPS | 58080 | 37151 |
| Stress Testing |  |
 |
| Primary Configurations | routes: - uri: /hello upstream: nodes: "127.0.0.1:1980": 1 #END |
http { access_log off; server { listen 1990; location / { proxy_pass http://127.0.0.1:1980; } } } |
| Hardware | CPU 1 CORE, 4GB RAM | CPU 1 CORE, 4GB RAM |
| CPU Usage Rate | 100% | 100% |
Test Environment:
Host: M1 Macbook Pro
Operating System: Debian
If you are interested in this, it's worth trying to replicate the test yourself, the results of which are relatively easy to reproduce.
Technical Insights
According to the software architecture diagram officially released by APISIX, the reasonable expectation is that the performance of APISIX should be lower than that of NGINX. However, "unusual occurrences often indicate underlying issues." Let's explore some abnormal scenarios that may arise during NGINX stress testing.
Let's get straight to the point: The performance results of APISIX are as expected, and the same holds for NGINX. However, it's important to recognize that the testing scenario for APISIX focuses on QPS performance under long-lived connections, while for NGINX, it's short-lived connections. Therefore, the difference in QPS performance is reasonable.
Long-lived connections are typically employed in scenarios requiring continuous communication, such as real-time chatting or continuous data transmission. Short-lived connections, on the other hand, are suitable for temporary communication needs, like ordinary web page access in the HTTP request-response mode.
Below is a reasonable configuration example for NGINX. With this configuration, you will find a significant improvement in NGINX's single-core performance, typically doubling at a minimum.
Why Does NGINX Use Short-Lived Connections by Default?
Born in 2004, NGINX stands as an elder in open-source projects, approaching its two-decade mark. To ensure continuous user iteration and a consistent experience, NGINX's feature evolution tends to favor forward compatibility. This makes it one of the few Web proxy services defaulting to the use of the HTTP 1.0 protocol. This default setting has endured for over a decade, and it's speculated that NGINX is unlikely to alter it in the future.
In the age of microservices, cloud-native solutions, and the explosion of AI information, engineers seek software that is reliable and hassle-free, allowing them to start working seamlessly. They also appreciate default configurations that align with production best practices. Consequently, modern open-source software tends to shed historical baggage and focus on efficiently solving problems, with both merits and drawbacks.
Top comments (0)