Größenleitfaden für NGINX Plus: So haben wir getestet

Anfang des Jahres haben wir die Leistung von NGINX Plus getestet und einen Größenleitfaden für die Bereitstellung auf Bare-Metal-Servern erstellt. NGINX Open Source und NGINX Plus werden häufig für den Layer 7-Lastausgleich verwendet , der auch als Anwendungslastausgleich bezeichnet wird .

[ Herausgeber – Wir aktualisieren den Größenleitfaden regelmäßig, um Änderungen sowohl der NGINX Plus-Funktionen als auch der Hardwarekosten und -leistung zu berücksichtigen. Der Link oben führt immer zum neuesten Leitfaden.

Informationen zur Leistung von NGINX und NGINX Plus als Webserver finden Sie unter Testen der Leistung von NGINX- und NGINX Plus-Webservern .]

Der Größenleitfaden beschreibt die Leistung, die Sie mit NGINX Plus auf verschiedenen Servergrößen erwarten können, sowie die geschätzten Kosten für die Hardware. Mithilfe des Größenleitfadens können Sie NGINX Plus-Bereitstellungen angemessen spezifizieren und eine Überbereitstellung – die Sie sofort Geld kostet – oder eine Unterbereitstellung – die zu Leistungsproblemen führen und Sie auf lange Sicht Geld kosten kann – so weit wie möglich vermeiden.

Wir haben von Kunden und anderen Personen, die unsere Ergebnisse reproduzieren möchten, großes Interesse an der Größentabelle sowie Fragen zu unserer verwendeten Methodik erhalten. Dieser Blogbeitrag bietet einen Überblick über die Tests, die wir durchgeführt haben, um die in der Größentabelle dargestellten Ergebnisse zu erzielen. Es behandelt die von uns verwendete Topologie, die von uns durchgeführten Tests und wie wir auf die in der Größenanleitung aufgeführten Preise gestoßen sind.

Notiz : Obwohl wir den Größenleitfaden speziell für NGINX Plus entwickelt haben, haben wir zum Testen NGINX Open Source verwendet, sodass jeder unsere Tests ohne ein NGINX Plus-Abonnement reproduzieren kann. Bei den Tests werden keine der erweiterten Funktionen von NGINX Plus genutzt, daher sind die Ergebnisse für NGINX Open Source und NGINX Plus identisch. NGINX Open Source Version 1.9.7 entspricht in etwa NGINX Plus Release 7.

Um den Reverseproxy in der Testtopologie jedoch besser vom Back-End-Webserver unterscheiden zu können, verweisen wir für ersteren auf NGINX Plus und für letzteren auf NGINX (Open Source).

Topologie

Alle Tests wurden mit drei separaten Maschinen durchgeführt, die über duale 40-GbE-Verbindungen in einem einfachen, flachen Layer-2-Netzwerk miteinander verbunden waren.

Um Datenverkehr vom Client-Computer zu generieren, haben wir wrk verwendet, ein Leistungstesttool ähnlich wie ab (ApacheBench). Wie im Diagramm gezeigt, wurde der gesamte Datenverkehr an den NGINX Plus Reverse Proxy geleitet, der die Verbindungen an das Backend des NGINX Open Source Web Servers weiterleitete.

Verwendete Hardware

Für den Test haben wir folgende Hardware verwendet.

Verwendete Software

Für die Tests haben wir folgende Software verwendet:

• Die auf dem Client-Rechner ausgeführte Version 4.0.0 von wrk hat den von NGINX weitergeleiteten Datenverkehr generiert. Wir haben es gemäß dieser Anleitung installiert.
• Version 1.9.7 von NGINX Open Source lief auf den Reverse-Proxy- und Webserver- Maschinen. Wir haben es gemäß diesen Anweisungen aus dem offiziellen Repository unter nginx.org installiert.
• Auf allen drei Maschinen lief Ubuntu Linux 14.04.1 .

Testmethodik

Wir haben die Leistung des NGINX Plus Reverse-Proxy-Servers mit unterschiedlichen CPU-Zahlen getestet. Ein NGINX Plus- Arbeitsprozess verbraucht eine einzelne CPU. Um die Leistung unterschiedlicher CPU-Zahlen zu messen, haben wir die Anzahl der Arbeitsprozesse variiert und die Tests mit zwei, vier, acht usw. Arbeitsprozessen wiederholt. Einen Überblick über die NGINX-Architektur finden Sie in unserem Blog .

Notiz : Um die Anzahl der Arbeitsprozesse manuell festzulegen, verwenden Sie die Direktive worker_processes . Der Standardwert ist „auto“ , wodurch NGINX Plus angewiesen wird, die Anzahl der CPUs zu erkennen und einen Arbeitsprozess pro CPU auszuführen.

Leistungsmetriken

Wir haben die folgenden Kennzahlen gemessen:

• Anfragen pro Sekunde (RPS) – Misst die Fähigkeit, HTTP-Anfragen zu verarbeiten. In unseren Tests sendet jeder Client Anfragen für eine 1 KB große Datei über eine Keepalive-Verbindung. Der Reverse Proxy verarbeitet jede Anfrage und leitet sie über eine weitere Keepalive-Verbindung an den Webserver weiter.
• SSL/TLS-Transaktionen pro Sekunde (TPS) – Misst die Fähigkeit, neue SSL/TLS-Verbindungen zu verarbeiten. In unseren Tests sendet jeder Client eine Reihe von HTTPS-Anfragen, jeweils über eine neue Verbindung. Der Reverse Proxy analysiert die Anfragen und leitet sie über eine hergestellte Keepalive-Verbindung an den Webserver weiter. Der Webserver sendet für jede Anfrage eine 0-Byte-Antwort zurück.
• Durchsatz – Misst den Durchsatz, den NGINX Plus beim Bereitstellen von 1-MB-Dateien über HTTP aufrechterhalten kann.

Ausführen von Tests

Um den gesamten Client-Verkehr zu generieren, haben wir wrk mit den folgenden Optionen verwendet:

• Die Option -c gibt die Anzahl der zu erstellenden TCP-Verbindungen an. Für unsere Tests haben wir dies auf 50 Verbindungen eingestellt.
• Die Option -d gibt an, wie lange Datenverkehr generiert werden soll. Wir haben unsere Tests jeweils 3 Minuten lang ausgeführt.
• Die Option -t gibt die Anzahl der zu erstellenden Threads an. Wir haben einen einzelnen Thread angegeben.

Um jede CPU vollständig auszulasten, haben wir ein Taskset verwendet, mit dem ein einzelner Arbeitsprozess an eine CPU gebunden werden kann. Diese Methode führt zu konsistenteren Ergebnissen als die Erhöhung der Anzahl der Wrk- Threads.

Anfragen pro Sekunde

Um die Anfragen pro Sekunde (RPS) zu messen, haben wir das folgende Skript ausgeführt:

für i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; mache taskset -c $i wrk -t 1 -c 50 -d 180s http:// Reverse-Proxy-Server-IP-Adresse /1kb.bin & fertig

Dieser Test erzeugte eine Kopie von wrk pro CPU, insgesamt 36 für unseren Client-Computer. Jede Kopie erstellte 50 TCP-Verbindungen und forderte darüber 3 Minuten (180 Sekunden) lang kontinuierlich eine 1-KB-Datei an.

SSL/TLS-Transaktionen pro Sekunde

Um SSL/TLS-Transaktionen pro Sekunde (TPS) zu messen, haben wir das folgende Skript ausgeführt:

für i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Verbindung: schließen' https:// Reverse-Proxy-Server-IP-Adresse /0kb.bin & fertig

Dieser Test verwendet die gleichen Werte für -c , -d und -t wie der vorherige Test, unterscheidet sich jedoch in zwei wichtigen Punkten, da der Schwerpunkt auf der Verarbeitung von SSL/TLS-Verbindungen liegt:

• Der Client öffnet und schließt für jede Anforderung eine Verbindung (die Option -H legt den HTTP-Header „ Connection: close “ fest).
• Die angeforderte Datei ist 0 (null) Byte statt 1 KB groß.

Durchsatz

Um den Durchsatz zu messen, haben wir das folgende Skript ausgeführt:

für i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; mache taskset -c $i wrk -t 1 -c 50 -d 180s http:// Reverse-Proxy-Server-IP-Adresse /1mb.bin & fertig

Der einzige Unterschied zum ersten Test ist die größere Dateigröße von 1 MB. Wir haben festgestellt, dass die Verwendung einer noch größeren Dateigröße (10 MB) den Gesamtdurchsatz nicht erhöht.

Mehrere Netzwerkkarten

Bei unseren Tests haben wir mehrere Netzwerkkarten verwendet. Das folgende, leicht modifizierte Skript stellte sicher, dass der Datenverkehr gleichmäßig zwischen den beiden Karten verteilt wurde:

für i in `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; mache n=`echo $(($i+ Anzahl-der-CPUs/2 ))`; Taskset -c $i ./wrk -t 1 -c 50 -d 180s http:// Reverse-Proxy-Server-IP-Adresse-1 /1kb.bin & Taskset -c $n ./wrk -t 1 -c 50 -d 180s http:// Reverse-Proxy-Server-IP-Adresse-2 /1kb.bin & fertig

Preise

Der letzte Schritt, nachdem wir Leistungszahlen mit unterschiedlichen Kernzahlen hatten, bestand darin, die Kosten für Server mit den entsprechenden Spezifikationen zu ermitteln. Wir haben Preise für Dell PowerEdge-Server mit ähnlichen Spezifikationen wie die Intel-Hardware verwendet, die wir in unseren Tests verwendet haben. Der folgende Anhang enthält eine vollständige Stückliste für jeden Server sowie die vollständige NGINX-Konfiguration sowohl für den Reverse Proxy als auch für den Webserver .

Anhang

Dell-Hardwarekonfigurationen

Die Preise in der Größentabelle gelten für die folgenden Dell-Hardwarekonfigurationen.

Notiz : Servermodelle mit den angegebenen Spezifikationen und Preisen waren zum Zeitpunkt unserer Tests verfügbar, können sich jedoch in Zukunft ändern.

NGINX Plus Reverse-Proxy-Konfiguration

Die folgende Konfiguration wurde auf dem NGINX Plus Reverse Proxy verwendet. Beachten Sie die beiden Sätze von Anweisungen „keepalive_timeout“ und „keepalive_requests“ :

• Für SSL/TLS-TPS-Tests haben wir die Werte für beide Anweisungen so festgelegt, dass die Verbindungen nur für eine Anfrage offen bleiben, da das Ziel dieses Tests darin besteht, zu ermitteln, wie viele SSL/TLS-Verbindungen pro Sekunde NGINX Plus verarbeiten kann. Das SSL/TLS-Sitzungscache wurde ebenfalls deaktiviert.
• Für die RPS-Tests wurden die Anweisungen so angepasst, dass die Verbindungen möglichst lange aufrechterhalten wurden.

Ansonsten handelt es sich bei der Konfiguration um eine ziemlich standardmäßige Reverse-Proxy-Server-Konfiguration, wobei NGINX Plus unter Verwendung der Direktive „proxy_pass“ einen Proxy zu einem Webserver sendet.

Benutzer nginx; Worker_Prozesse automatisch; Worker_rlimit_nofile 10240; PID /var/run/nginx.pid; Ereignisse { Worker_Connections 10240; Accept_Mutex aus; Multi_Accept aus; } http { Access_Log aus; Include /etc/nginx/mime.types; Standardtyp Anwendung/Oktett-Stream; Log_Format Haupt '$Remote_Addr - $Remote_User [$Time_Local] "$Request" ' '$Status $Body_Bytes_sent "$http_Referer" ' '"$http_User_Agent" "$http_x_forwarded_for" "$Ssl_Cipher" ' '"$Ssl_Protocol" '; Sendfile ein; # RPS testet Keepalive_Timeout 300 s; Keepalive_Requests 1000000; # SSL/TLS TPS-Tests #keepalive_timeout 0; #keepalive_requests 1; Upstream-Webserver { Server Web-Server-IP-Adresse ; } Server { abhören 80; abhören 443 SSL-Rückstand=102400 Wiederverwendungsport; SSL-Zertifikat /etc/nginx/ssl/rsa-cert.crt; SSL-Zertifikatsschlüssel /etc/nginx/ssl/rsa-key.key; SSL-Session-Tickets aus; SSL-Session-Cache aus; Root /var/www/html; Standort / { Proxy-Passwort http://Webserver; } } } }

NGINX-Webserverkonfiguration

Die folgende Konfiguration wurde auf dem NGINX- Webserver verwendet. Es stellt statische Dateien aus /var/www/html/ bereit, wie durch die Root- Direktive konfiguriert. Die statischen Dateien wurden mit dd generiert. Dieses Beispiel erstellt eine 1 KB große Datei mit Nullen:

dd wenn=/dev/zero von=1kb.bin bs=1KB Anzahl=1

Die Konfiguration:

Benutzer nginx;
Arbeitsprozesse automatisch;
worker_rlimit_nofile 10240;
pid /var/run/nginx.pid;

Ereignisse {
Arbeitsverbindungen 10240;
accept_mutex aus;
multi_accept aus;
}

http {
access_log aus;
include /etc/nginx/mime.types;

Standardtyp application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
'"$ssl_protocol" ';

sendfile ein;

keepalive_timeout 300s; 
keepalive_requests 1000000;

Server {
abhören 80;
root /var/www/html;
}
}

Um NGINX Plus selbst auszuprobieren, starten Sie noch heute eine kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .