DEV Community

Yilia for Apache APISIX

Posted on • Originally published at api7.ai

Apache APISIX vs NGINX

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 APISIX_VS_NGINX_1_SS APISIX_VS_NGINX_2_SS
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

APISIX_VS_NGINX_1

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.

APISIX_VS_NGINX_2

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.

APISIX_VS_NGINX_3

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.

APISIX_VS_NGINX_4

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)