NGINX Plus-Dimensionierungsleitfaden: So haben wir getestet

NGINX | 29. November 2016

Anfang dieses Jahres haben wir die Leistung von NGINX Plus einem Benchmark unterzogen und einen Leitfaden zur Dimensionierung für die Bereitstellung auf Bare-Metal-Servern erstellt. NGINX Open Source und NGINX Plus werden häufig für Layer-7-Lastverteilung, auch bekannt als Anwendungslastverteilung, eingesetzt.

[Redaktion – Wir aktualisieren den Leitfaden zur Dimensionierung regelmäßig, um Änderungen sowohl bei den Funktionen von NGINX Plus als auch bei den Hardwarekosten und der Hardwareleistung zu berücksichtigen. Der obige Link verweist stets auf die neueste Version des Leitfadens.

Informationen zur Leistung von NGINX und NGINX Plus als Webserver finden Sie unter „Leistungstests für NGINX- und NGINX Plus-Webserver“.]

Der Leitfaden zur Dimensionierung beschreibt die Leistung, die Sie mit NGINX Plus auf Servern unterschiedlicher Größe voraussichtlich erzielen können, sowie die geschätzten Hardwarekosten. Mithilfe des Leitfadens können Sie NGINX Plus-Bereitstellungen angemessen dimensionieren und eine Überdimensionierung – die unmittelbar unnötige Kosten verursacht – oder eine Unterdimensionierung – die zu Leistungsproblemen und langfristig zu zusätzlichen Kosten führen kann – so weit wie möglich vermeiden.

Unser Leitfaden zur Dimensionierung ist auf großes Interesse gestoßen. Gleichzeitig haben uns Kunden und andere Personen, die unsere Ergebnisse reproduzieren möchten, Fragen zu unserer Methodik gestellt. Dieser Blogbeitrag gibt einen Überblick über die Tests, die wir durchgeführt haben, um die im Leitfaden zur Dimensionierung vorgestellten Ergebnisse zu erzielen. Er beschreibt die verwendete Topologie, die durchgeführten Tests und wie wir die im Leitfaden aufgeführten Preise ermittelt haben.

Hinweis: Obwohl wir den Leitfaden zur Dimensionierung speziell für NGINX Plus entwickelt haben, haben wir für die Tests NGINX Open Source verwendet, damit jeder unsere Tests ohne ein NGINX Plus-Abonnement reproduzieren kann. Bei den Tests werden keine der erweiterten Funktionen von NGINX Plus verwendet, sodass die Ergebnisse für NGINX Open Source und NGINX Plus identisch sind. NGINX Open Source Version 1.9.7 entspricht ungefähr NGINX Plus Release 7.

Um den Reverse-Proxy in der Testtopologie jedoch besser vom Backend-Webserver unterscheiden zu können, bezeichnen wir Ersteren als NGINX Plus und Letzteren als NGINX (Open Source).

Topologie

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

Zum Testen der Leistung von NGINX Plus wurde eine standardmäßige Back-to-Back-to-Back-Topologie verwendet

Um Datenverkehr vom Client-Rechner zu erzeugen, verwendeten wir wrk, ein Leistungstest-Tool ähnlich wie ab (ApacheBench). Wie im Diagramm dargestellt, wurde der gesamte Datenverkehr an den NGINX Plus Reverse-Proxy weitergeleitet, der die Verbindungen an das NGINX Open Source-Webserver-Backend weiterleitete.

Verwendete Hardware

Für die Tests haben wir die folgende Hardware verwendet.

Rechner CPU Netzwerk ArbeitsspeicherClient 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2,30 GHz, 36 physische (oder 72 HT-)Kerne 2x Intel XL710 40GbE QSFP+ (Rev. 01) 16 GBReverse-Proxy 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2,30 GHz, 36 physische (oder 72 HT-)Kerne 4x Intel XL710 40GbE QSFP+ (Rev. 01) 16 GBWebserver 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2,30 GHz, 36 physische (oder 72 HT-)Kerne 2x Intel XL710 40GbE QSFP+ (Rev. 01) 16 GB

Verwendete Software

Für die Tests haben wir die folgende Software verwendet:

Version 4.0.0 von wrk auf dem Client-Rechner erzeugte den Datenverkehr, den NGINX als Proxy weiterleitete. Wir installierten es gemäß dieser Anleitung.
Version 1.9.7 von NGINX Open Source lief auf den Rechnern Reverse Proxy und Web Server. Wir installierten sie gemäß dieser nginx.org aus dem offiziellen Repository anhand dieser Anleitung.
Ubuntu Linux 14.04.1 lief auf allen drei Rechnern.

Testmethodik

Wir haben die Leistung des NGINX Plus-Reverse-Proxy-Servers mit unterschiedlich vielen CPUs getestet. Ein Worker-Prozess von NGINX Plus beansprucht eine einzelne CPU. Um die Leistung mit unterschiedlich vielen CPUs zu messen, haben wir daher die Anzahl der Worker-Prozesse variiert und die Tests mit zwei Worker-Prozessen, vier, acht und so weiter wiederholt. Einen Überblick über die Architektur von NGINX finden Sie in unserem Blog.

Hinweis: Um die Anzahl der worker-Prozesse manuell festzulegen, verwenden Sie die Direktive worker_processes. Der Standardwert ist auto. Damit erkennt NGINX Plus die Anzahl der CPUs und führt pro CPU einen worker-Prozess aus.

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 über eine Keep-Alive-Verbindung Anfragen für eine 1-KB-Datei. Der Reverse-Proxy verarbeitet jede Anfrage und leitet sie über eine weitere Keep-Alive-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 bestehende Keepalive-Verbindung an den Webserver weiter. Der Webserver sendet für jede Anfrage eine Antwort mit 0 Byte zurück.
Durchsatz – Misst den Durchsatz, den NGINX Plus bei der Bereitstellung von 1‑MB-Dateien über HTTP aufrechterhalten kann.

Tests ausführen

Zur Erzeugung des gesamten Client-Datenverkehrs verwendeten wir wrk mit den folgenden Optionen:

Die Option „-c“ gibt die Anzahl der zu erstellenden TCP-Verbindungen an. Für unsere Tests haben wir sie auf 50 Verbindungen festgelegt.
Die Option -d gibt an, wie lange Datenverkehr erzeugt werden soll. Unsere Tests liefen jeweils 3 Minuten.
Die Option „-t“ gibt die Anzahl der zu erstellenden Threads an. Wir haben einen einzelnen Thread angegeben.

Um jede CPU vollständig auszulasten, verwendeten wir taskset, womit sich ein einzelner wrk-Prozess an eine CPU binden lässt. Diese Methode liefert konsistentere Ergebnisse als eine 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:

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1kb.bin &
done

Bei diesem Test wurde eine Instanz von wrk pro CPU gestartet, insgesamt 36 auf unserem Clientrechner. Jede Instanz stellte 50 TCP-Verbindungen her und sendete darüber 3 Minuten (180 Sekunden) lang kontinuierlich Anfragen für eine 1-KB-Datei.

SSL/TLS-Transaktionen pro Sekunde

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

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Connection: close' https://Reverse-Proxy-Server-IP-address/0kb.bin &
done

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

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

Durchsatz

Zur Messung des Durchsatzes haben wir das folgende Skript ausgeführt:

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1mb.bin &
done

Der einzige Unterschied zum ersten Test besteht in der größeren Dateigröße von 1 MB. Wir haben festgestellt, dass eine noch größere Datei (10 MB) den Gesamtdurchsatz nicht erhöhte.

Mehrere Netzwerkkarten

In unseren Tests haben wir mehrere Netzwerkkarten verwendet. Das folgende, leicht angepasste Skript stellte sicher, dass der Datenverkehr gleichmäßig auf die beiden Karten verteilt wurde:

for i in `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; do    n=`echo $(($i+number-of-CPUs/2))`;
    taskset -c $i ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-1/1kb.bin &
    taskset -c $n ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-2/1kb.bin &
done

Preise

Nachdem uns die Leistungswerte für unterschiedliche Anzahlen von Prozessorkernen vorlagen, bestand der letzte Schritt darin, die Kosten für Server mit den entsprechenden Spezifikationen zu ermitteln. Wir verwendeten die Preise von Dell PowerEdge-Servern, deren Spezifikationen mit denen der in unseren Tests eingesetzten Intel-Hardware vergleichbar waren. Der nachfolgende 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 im Leitfaden zur Dimensionierung gelten für die folgenden Dell-Hardwarekonfigurationen.

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

Servermodell Technische Daten PreisDell PowerEdge R230 CPU: Intel Core i3-6100 mit 2 Kernen, 3,7 GHz, 2C/4T
RAM: 4 GB
Festplatte: 500 GB
Netzwerkkarte: Intel X710, 2 × 10 GbE, 1.200 $CPU: Intel® Xeon® E3-1220 v5, 3,0 GHz, 4C/8T
RAM: 4 GB
Festplatte: 500 GB
Netzwerkkarte: Intel XL710, 2 × 40 GbE, 1.400 $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: 2 × Intel® Xeon® E5-2630 v3, 2,4 GHz, 8C/16T
RAM: 8 GB
Festplatte: 500 GB
Netzwerkkarte: Intel XL710, 2 × 40 GbE, 3.000 $Dell PowerEdge R630 CPU: 2 × Intel® Xeon® E5-2697A v4, 2,6 GHz, 16C/32T
RAM: 8 GB
Festplatte: 500 GB
Netzwerkkarte: Intel XL710, 2 × 40 GbE, 8.000 $CPU: 2 × Intel® Xeon® E5-2699 v3, 2,3 GHz, 18C/36T
RAM: 8 GB
Festplatte: 500 GB
Netzwerkkarte: Intel XL710, 2 × 40 GbE, 11.000 $

NGINX Plus Reverse-Proxy-Konfiguration

Die folgende Konfiguration wurde auf dem NGINX Plus Reverse Proxy verwendet. Beachten Sie die beiden Gruppen der Direktiven keepalive_timeout und keepalive_requests:

Für SSL/TLS-TPS-Tests legten wir die Werte für beide Direktiven so fest, dass die Verbindungen nur für eine einzige Anfrage geöffnet blieben, da mit diesem Test ermittelt werden sollte, wie viele SSL/TLS-Verbindungen NGINX Plus pro Sekunde verarbeiten kann. Außerdem wurde das SSL/TLS-Sitzungs-Caching deaktiviert.
Für die RPS-Tests wurden die Direktiven so abgestimmt, dass die Verbindungen so lange wie möglich aufrechterhalten wurden.

Ansonsten handelt es sich um eine recht standardmäßige Reverse-Proxy-Serverkonfiguration, bei der NGINX Plus mithilfe der Direktive proxy_pass Anfragen an einen Webserver weiterleitet.

user                 nginx;worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log    off;
    include       /etc/nginx/mime.types;
    default_type  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 on;

    # RPS tests
    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    # SSL/TLS TPS tests
    #keepalive_timeout  0;  
    #keepalive_requests 1; 
  
    upstream webserver {
        server Web-Server-IP-address;
    }

    server {
        listen 80;
        listen 443 ssl backlog=102400 reuseport;

        ssl_certificate     /etc/nginx/ssl/rsa-cert.crt;
        ssl_certificate_key /etc/nginx/ssl/rsa-key.key;
        ssl_session_tickets off;
        ssl_session_cache   off;

        root /var/www/html;
            location / {
                proxy_pass http://webserver;
            }
        }
    }
}

NGINX-Webserver-Konfiguration

Die folgende Konfiguration wurde auf dem NGINX-Webserver verwendet. Er stellt statische Dateien aus /var/www/html/ bereit, wie durch die root-Direktive festgelegt. Die statischen Dateien wurden mit dd erzeugt; dieses Beispiel erstellt eine 1 KB große Datei, die ausschließlich Nullen enthält:

dd if=/dev/zero of=1kb.bin bs=1KB count=1

Die Konfiguration:

user                 nginx;
worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log   off;
    include      /etc/nginx/mime.types;
    default_type 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 on;

    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    server {
        listen 80;
        root /var/www/html;
    }
}