Recientemente hemos probado la escalabilidad de NGINX para equilibrar la carga de conexiones WebSocket . Incluso con 50.000 conexiones WebSocket activas, NGINX necesitó menos de 1 GB de memoria y menos de 1 núcleo de CPU. Además, al someterlo a conexiones con una actividad muy intensa, el uso de memoria se mantuvo estable y aumentó más lentamente que el tamaño de los mensajes. El rendimiento en su entorno dependerá de la naturaleza de su aplicación, pero los resultados de estas pruebas pueden ofrecerle una idea de la cantidad de recursos que puede esperar que utilice NGINX.
Entorno de pruebas
Para estas pruebas se utilizaron los siguientes equipos:
- Generador de carga – thor en un Xeon EX5645 de 6 núcleos a 2,40 GHz, 48 GB de RAM
- NGINX – Versión 1.7.0, x86_64 con 6 procesos de trabajo en un Xeon E5645 de 6 núcleos a 2,40 GHz, 48 GB de RAM
- Backend de WebSocket – servidor de eco Node.js en un Xeon E5-2660 0 de 4 núcleos a 2,20 GHz, 8 GB de RAM
Pruebas
Realizamos dos series de pruebas.
El primer conjunto de pruebas simuló conexiones de larga duración y mayormente inactivas. El número de conexiones varió entre 1.000 y 50.000, el tamaño de los mensajes entre 10 y 4096 bytes, y el intervalo entre mensajes entre 0,1 y 10 segundos (una frecuencia que consideramos baja).
Los resultados muestran que la memoria total necesaria para las conexiones WebSocket depende del número de conexiones y que la memoria utilizada por conexión se mantiene constante. El uso de memoria no se ve afectado por el tamaño ni por la frecuencia de los mensajes. El uso de la CPU sigue, en líneas generales, la evolución del número de conexiones y, ni siquiera con 50.000 conexiones, llegó a utilizar un núcleo completo. El uso de la CPU que se muestra aquí se ha normalizado respecto a un único núcleo sumando el uso de la CPU de todos los núcleos. Los siguientes gráficos muestran los resultados de este conjunto de pruebas:
El segundo conjunto de pruebas simuló conexiones de corta duración, pero con una actividad muy intensa. El número de conexiones simultáneas se mantuvo constante en 500, con 50 mensajes por conexión y sin demora entre mensajes. El tamaño de los mensajes osciló entre 1 y 4096 bytes.
Los resultados muestran que, con un número fijo de conexiones simultáneas, el uso total de memoria depende del tamaño de los mensajes, al igual que la memoria utilizada por conexión. Sin embargo, en ambos casos, la cantidad de memoria varía poco y lo hace de forma sublineal, con un aumento inferior al 15 %.
Resumen
Durante estas pruebas, NGINX ofreció un rendimiento predecible y escalable al actuar como proxy de servidores WebSocket. Se trataba de pruebas sintéticas que no eran necesariamente representativas de una aplicación real, por lo que los resultados de las pruebas realizadas en otros sistemas pueden variar. Para obtener más información, consulte:
- NGINX como proxy de WebSocket
- Proxy de WebSocket (nginx.org)
- Comparación de funcionalidades de NGINX y NGINX Plus
- Especificaciones técnicas de NGINX Plus
Sobre el autor
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.