Wir haben kürzlich die Skalierbarkeit von NGINX beim Load-Balancing von WebSocket-Verbindungen getestet. Selbst bei 50.000 aktiven WebSocket-Verbindungen benötigte NGINX weniger als 1 GB Arbeitsspeicher und weniger als einen CPU-Kern. Auch unter hoher Last durch sehr aktive Verbindungen blieb die Speicherauslastung stabil und stieg langsamer als die Nachrichtengröße. Die Leistung in Ihrer Umgebung hängt von der Art Ihrer Anwendung ab, doch die Ergebnisse dieser Tests geben einen Anhaltspunkt dafür, mit welchem Ressourcenbedarf von NGINX Sie rechnen können.
Testumgebung
Für diese Tests wurden die folgenden Rechner verwendet:
- Lastgenerator – thor auf einem 6-Kern-Xeon EX5645 mit 2,40 GHz und 48 GB RAM
- NGINX – Version 1.7.0, x86_64 mit 6 Workern auf einem 6-Kern-Xeon E5645 mit 2,40 GHz und 48 GB RAM
- WebSocket-Backend – Node.js-Echo-Server auf einem 4-Kern-Xeon E5-2660 0 mit 2,20 GHz und 8 GB RAM
Tests
Wir haben zwei Testreihen durchgeführt.
Die erste Testreihe simulierte langlebige und größtenteils inaktive Verbindungen. Die Anzahl der Verbindungen variierte zwischen 1.000 und 50.000, die Nachrichtengröße zwischen 10 und 4096 Byte und das Nachrichtenintervall zwischen 0,1 und 10 Sekunden (was wir als niedrig erachteten).
Die Ergebnisse zeigen, dass der Gesamtspeicherbedarf für WebSocket-Verbindungen von der Anzahl der Verbindungen abhängt und der Speicherverbrauch pro Verbindung konstant bleibt. Die Speicherauslastung wird weder von der Nachrichtengröße noch von der Nachrichtenfrequenz beeinflusst. Die CPU-Auslastung steigt im Wesentlichen mit der Anzahl der Verbindungen und beanspruchte selbst bei 50.000 Verbindungen keinen vollständigen CPU-Kern. Die hier dargestellte CPU-Auslastung ist auf einen einzelnen Kern normiert, indem die CPU-Auslastung aller Kerne addiert wird. Die folgenden Diagramme zeigen die Ergebnisse dieser Testreihe:
Die zweite Testreihe simulierte kurzlebige, aber hochaktive Verbindungen. Die Anzahl der gleichzeitigen Verbindungen wurde konstant bei 500 gehalten, mit 50 Nachrichten pro Verbindung und ohne Verzögerung zwischen den Nachrichten. Die Nachrichtengröße lag zwischen 1 und 4096 Byte.
Die Ergebnisse zeigen, dass bei einer festen Anzahl gleichzeitiger Verbindungen sowohl die gesamte Speicherauslastung als auch der Speicherverbrauch pro Verbindung von der Nachrichtengröße abhängen. In beiden Fällen verändert sich der Speicherbedarf jedoch nur geringfügig und steigt unterlinear um weniger als 15 %.
Zusammenfassung
Bei diesen Tests lieferte NGINX beim Proxying von WebSocket-Servern eine vorhersehbare und skalierbare Leistung. Da es sich um synthetische Tests handelte, die nicht unbedingt eine reale Anwendung widerspiegeln, können die Ergebnisse von Tests auf anderen Systemen abweichen. Weitere Informationen finden Sie unter:
- NGINX als WebSocket-Proxy
- WebSocket-Proxying (nginx.org)
- Funktionsvergleich von NGINX und NGINX Plus
- Technische Spezifikationen für NGINX Plus
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.