Apache APISIX vs NGINX

Según las estadísticas de W3Techs hasta junio de 2022, NGINX es el servidor web más utilizado a nivel mundial, con una participación de mercado significativa del 33.6%. Su amplia adopción y su rendimiento destacable han establecido un alto nivel de confianza entre los usuarios, convirtiéndolo en un punto de referencia frecuente para comparaciones.

Resultados de las Pruebas de Rendimiento

En pruebas prácticas, comparamos el rendimiento de APISIX y NGINX en un escenario simple, con los siguientes resultados:

• APISIX demuestra un rendimiento de QPS de 58,080 en un solo núcleo de CPU, superando el rendimiento de NGINX de 37,154 en el mismo hardware.

• El rendimiento de APISIX supera al de NGINX en un impresionante 56%.

Configuración de la Prueba y Resultados de la Prueba de Estrés

	APISIX	NGINX
QPS de un solo núcleo	58080	37151
Prueba de Estrés
Configuraciones Principales	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
Tasa de Uso de CPU	100%	100%

Entorno de Prueba:

• Host: M1 Macbook Pro

• Sistema Operativo: Debian

Si estás interesado en esto, vale la pena intentar replicar la prueba tú mismo, cuyos resultados son relativamente fáciles de reproducir.

Perspectivas Técnicas

Según el diagrama de arquitectura de software lanzado oficialmente por APISIX, la expectativa razonable es que el rendimiento de APISIX debería ser inferior al de NGINX. Sin embargo, "las ocurrencias inusuales a menudo indican problemas subyacentes". Exploremos algunos escenarios anómalos que pueden surgir durante las pruebas de estrés de NGINX.

Vayamos al grano: Los resultados de rendimiento de APISIX son los esperados, y lo mismo ocurre con NGINX. Sin embargo, es importante reconocer que el escenario de prueba para APISIX se centra en el rendimiento de QPS bajo conexiones de larga duración, mientras que para NGINX, son conexiones de corta duración. Por lo tanto, la diferencia en el rendimiento de QPS es razonable.

Las conexiones de larga duración se emplean típicamente en escenarios que requieren comunicación continua, como chats en tiempo real o transmisión continua de datos. Por otro lado, las conexiones de corta duración son adecuadas para necesidades de comunicación temporales, como el acceso a páginas web ordinarias en el modo de solicitud-respuesta HTTP.

A continuación se muestra un ejemplo de configuración razonable para NGINX. Con esta configuración, encontrarás una mejora significativa en el rendimiento de un solo núcleo de NGINX, típicamente duplicándose como mínimo.

¿Por qué NGINX usa conexiones de corta duración por defecto?

Nacido en 2004, NGINX es un veterano en proyectos de código abierto, acercándose a sus dos décadas de existencia. Para garantizar una iteración continua de usuarios y una experiencia consistente, la evolución de las características de NGINX tiende a favorecer la compatibilidad hacia adelante. Esto lo convierte en uno de los pocos servicios de proxy web que utiliza por defecto el protocolo HTTP 1.0. Esta configuración por defecto ha perdurado durante más de una década, y se especula que es poco probable que NGINX la cambie en el futuro.

En la era de los microservicios, las soluciones nativas de la nube y la explosión de la información de IA, los ingenieros buscan software confiable y sin complicaciones que les permita comenzar a trabajar sin problemas. También aprecian configuraciones por defecto que se alinean con las mejores prácticas de producción. En consecuencia, el software de código abierto moderno tiende a deshacerse del bagaje histórico y a centrarse en resolver problemas de manera eficiente, con sus ventajas y desventajas.