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).
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.
Für den Test haben wir folgende Hardware verwendet.
Maschine | CPU | Netzwerk | Erinnerung |
---|---|---|---|
Kunde | 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2,30 GHz, 36 echte (oder 72 HT) Kerne | 2x Intel XL710 40GbE QSFP+ (Rev. 01) | 16 GB |
Reverse-Proxy | 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2,30 GHz, 36 echte (oder 72 HT) Kerne | 4x Intel XL710 40GbE QSFP+ (Rev. 01) | 16 GB |
Webserver | 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2,30 GHz, 36 echte (oder 72 HT) Kerne | 2x Intel XL710 40GbE QSFP+ (Rev. 01) | 16 GB |
Für die Tests haben wir folgende Software verwendet:
wrk
hat den von NGINX weitergeleiteten Datenverkehr generiert. Wir haben es gemäß dieser Anleitung installiert.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.
Wir haben die folgenden Kennzahlen gemessen:
Um den gesamten Client-Verkehr zu generieren, haben wir wrk
mit den folgenden Optionen verwendet:
-c
gibt die Anzahl der zu erstellenden TCP-Verbindungen an. Für unsere Tests haben wir dies auf 50 Verbindungen eingestellt.-d
gibt an, wie lange Datenverkehr generiert werden soll. Wir haben unsere Tests jeweils 3 Minuten lang ausgeführt.-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.
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.
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:
-H
legt den HTTP-Header „ Connection:
close
“ fest).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.
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
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 .
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.
Servermodell | Technische Daten | Preis |
---|---|---|
Dell PowerEdge R230 | CPU: 2 Kerne Intel Core I3 6100 3,7 GHz, 2C/4T RAM: 4 GB Festplatte: 500 GB Netzwerkkarte: Intel X710 2×10 Gbe |
1.200 US-Dollar |
CPU: Intel® Xeon® E3‑1220 v5 3,0 GHz, 4 Kerne/8 Threads RAM: 4 GB Festplatte: 500 GB Netzwerkkarte: Intel XL710 2×40 Gbe |
1.400 US-Dollar | |
Dell PowerEdge R430 | CPU: Intel® Xeon® E5-2630 v3 2,4 GHz, 8C/16T RAM: 4 GB Festplatte: 500 GB Netzwerkkarte: Intel XL710 2×40 Gbe |
2.200 $ |
CPU: 2x Intel® Xeon® E5‑2630 v3 2,4GHz, 8C/16T RAM: 8 GB Festplatte: 500 GB Netzwerkkarte: Intel XL710 2×40 Gbe |
3.000 US-Dollar | |
Dell PowerEdge R630 | CPU: 2x Intel® Xeon® E5-2697A v4 2,6 GHz, 16C/32T RAM: 8 GB Festplatte: 500 GB Netzwerkkarte: Intel XL710 2×40 Gbe |
8.000 US-Dollar |
CPU: 2x Intel® Xeon® E5‑2699 v3 2,3GHz, 18C/36T RAM: 8 GB Festplatte: 500 GB Netzwerkkarte: Intel XL710 2×40 Gbe |
11.000 US-Dollar |
Die folgende Konfiguration wurde auf dem NGINX Plus Reverse Proxy verwendet. Beachten Sie die beiden Sätze von Anweisungen „keepalive_timeout“
und „keepalive_requests“
:
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; } } } }
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 .
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."