Nous avons récemment testé l’évolutivité de NGINX pour l’équilibrage de charge des connexions WebSocket. Même avec 50 000 connexions WebSocket actives, NGINX a nécessité moins de 1 Go de mémoire et moins d’un cœur de processeur. Lorsqu’il était soumis à des connexions très sollicitées, l’utilisation de la mémoire restait stable et augmentait moins rapidement que la taille des messages. Les performances dans votre environnement dépendront de la nature de votre application, mais les résultats de ces tests peuvent donner une indication de la quantité de ressources que NGINX est susceptible d’utiliser.
Environnement de test
Les machines suivantes ont été utilisées pour ces tests :
- Générateur de charge – thor sur un Xeon EX5645 à 6 cœurs cadencé à 2,40 GHz, avec 48 Go de RAM
- NGINX – Version 1.7.0, x86_64 avec 6 workers sur un Xeon E5645 à 6 cœurs cadencé à 2,40 GHz, 48 Go de RAM
- Backend WebSocket – serveur d’écho Node.js sur un Xeon E5-2660 0 à 4 cœurs cadencé à 2,20 GHz, 8 Go de RAM
Tests
Nous avons effectué deux séries de tests.
La première série de tests simulait des connexions de longue durée et généralement inactives. Le nombre de connexions variait de 1 000 à 50 000, la taille des messages de 10 à 4 096 octets et l’intervalle entre les messages de 0,1 à 10 secondes (ce que nous considérions comme une faible fréquence).
Les résultats montrent que la quantité totale de mémoire nécessaire aux connexions WebSocket dépend du nombre de connexions et que la mémoire utilisée par connexion reste constante. L’utilisation de la mémoire n’est pas affectée par la taille ni par la fréquence des messages. L’utilisation du processeur évolue globalement en fonction du nombre de connexions et, même avec 50 000 connexions, elle n’a pas mobilisé un cœur complet. L’utilisation du processeur présentée ici est normalisée par rapport à un seul cœur en additionnant l’utilisation du processeur sur l’ensemble des cœurs. Les graphiques suivants présentent les résultats de cette série de tests :
La deuxième série de tests simulait des connexions de courte durée, mais très actives. Le nombre de connexions simultanées était maintenu à 500, avec 50 messages par connexion et aucun délai entre les messages. La taille des messages variait de 1 à 4 096 octets.
Les résultats montrent qu’avec un nombre fixe de connexions simultanées, l’utilisation totale de la mémoire dépend de la taille des messages, tout comme la mémoire utilisée par connexion. Toutefois, dans les deux cas, la quantité de mémoire varie peu et de manière sous-linéaire, avec une augmentation inférieure à 15 %.
Résumé
Lors de ces tests, NGINX a fourni des performances prévisibles et évolutives en tant que proxy pour des serveurs WebSocket. Il s’agissait de tests synthétiques, qui ne sont pas nécessairement représentatifs d’une application réelle. Les résultats de tests effectués sur d’autres systèmes peuvent donc différer. Pour plus d’informations, consultez :
- NGINX en tant que proxy WebSocket
- Proxy WebSocket (nginx.org)
- Comparaison des fonctionnalités de NGINX et NGINX Plus
- Spécifications techniques de NGINX Plus
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.