Socket-Sharding in NGINX Version 1.9.1

Andrew Hutchings

NGINX 1.9.1 führt eine neue Funktion ein, die die Verwendung der Socket-Option SO_REUSEPORT ermöglicht. Diese ist in neueren Versionen vieler Betriebssysteme verfügbar, darunter DragonFly BSD und Linux (ab Kernel-Version 3.9). Mit dieser Socket-Option können mehrere Sockets dieselbe Kombination aus IP-Adresse und Port überwachen. Der Kernel verteilt dann die eingehenden Verbindungen gleichmäßig auf die Sockets.

Anmerkung der Redaktion – Für Benutzer von NGINX Plus wird diese Funktion ab NGINX Plus Release 7 (R7) unterstützt. Einen Überblick über alle neuen Funktionen dieser Version finden Sie im Beitrag „Ankündigung von NGINX Plus R7“ in unserem Blog.

Die Socket-Option „SO_REUSEPORT“ bietet zahlreiche potenzielle Einsatzmöglichkeiten in der Praxis. Andere Dienste können sie für einfache unterbrechungsfreie Upgrades ausführbarer Dateien nutzen (NGINX unterstützt unterbrechungsfreie Upgrades bereits mit anderen Mitteln). Bei NGINX kann die Aktivierung dieser Socket-Option in bestimmten Szenarien die Leistung verbessern, indem Sperrkonflikte reduziert werden.

Wie in der Abbildung dargestellt, benachrichtigt ein einzelner lauschender Socket die Worker über eingehende Verbindungen, wenn die Option SO_REUSEPORT nicht aktiviert ist, und jeder Worker versucht, eine Verbindung anzunehmen.

Wenn die Option SO_REUSEPORT aktiviert ist, gibt es für jede Kombination aus IP-Adresse und Port mehrere lauschende Sockets – einen für jeden Worker-Prozess. Der Kernel bestimmt, welcher verfügbare lauschende Socket (und damit welcher Worker) die Verbindung erhält. Dadurch können Sperrkonflikte zwischen Workern, die neue Verbindungen annehmen, reduziert und die Leistung auf Mehrkernsystemen verbessert werden. Dies kann jedoch auch dazu führen, dass ein durch eine blockierende Operation angehaltener Worker nicht nur die bereits von ihm angenommenen Verbindungen beeinträchtigt, sondern auch Verbindungsanfragen, die ihm der Kernel seit Beginn der Blockierung zugewiesen hat.

Socket-Sharding konfigurieren

Um die Socket-Option SO_REUSEPORT zu aktivieren, fügen Sie den neuen Parameter reuseport zur Direktive listen für HTTP- oder TCP-Datenverkehr (Modul stream) hinzu, wie in den folgenden Beispielen:

http {     server {
          listen 80 reuseport;
          server_name  localhost;
          # ...
     }
}

stream {
     server {
          listen 12345 reuseport;
          # ...
     }
}

Durch die Angabe des Parameters „reuseport“ wird außerdem die Direktive „accept_mutex“ für den Socket deaktiviert, da der Mutex bei Verwendung von „reuseport“ redundant ist. Es kann dennoch sinnvoll sein, „accept_mutex“ zu setzen, wenn es Ports gibt, für die „reuseport“ nicht festgelegt ist.

Leistungsvergleich mit reuseport

Ich führte einen wrk-Benchmark mit 4 NGINX-Workern auf einer AWS-Instanz mit 36 Kernen durch. Um Netzwerkeffekte auszuschließen, ließ ich sowohl den Client als auch NGINX auf localhost laufen und NGINX außerdem anstelle einer Datei die Zeichenfolge OK zurückgeben. Ich verglich drei NGINX-Konfigurationen: die Standardeinstellung (entspricht accept_mutex on), mit accept_mutex off und mit reuseport. Wie die Abbildung zeigt, erhöht reuseport die Anzahl der Anfragen pro Sekunde um das 2- bis 3-Fache und reduziert sowohl die Latenz als auch deren Standardabweichung.

Ich führte außerdem einen ähnlichen Benchmark durch, bei dem der Client und NGINX auf separaten Hosts ausgeführt wurden und NGINX eine HTML-Datei zurückgab. Wie die folgende Tabelle zeigt, war mit reuseport die Verringerung der Latenz ähnlich wie beim vorherigen Benchmark, während die Standardabweichung noch deutlicher zurückging (um fast das Zehnfache). Auch die anderen Ergebnisse (die nicht in der Tabelle aufgeführt sind) waren vielversprechend. Mit reuseport wurde die Last gleichmäßig auf die Worker-Prozesse verteilt. Unter der Standardeinstellung (entspricht accept_mutex on) entfiel auf einige Worker ein höherer Anteil der Last, während bei accept_mutex off alle Worker einer hohen Last ausgesetzt waren.

Latenz (ms) Standardabweichung der Latenz (ms) CPU-AuslastungStandard 15.65 26.59 0.3accept_mutex off 15.59 26.48 10reuseport 12.35 3.15 0.3

In diesen Benchmarks ist die Rate der Verbindungsanfragen hoch, die Anfragen erfordern jedoch keine umfangreiche Verarbeitung. Weitere vorläufige Tests deuten ebenfalls darauf hin, dass reuseport die Leistung am stärksten verbessert, wenn der Datenverkehr diesem Profil entspricht. (Der Parameter reuseport ist beispielsweise für die Direktive listen im Kontext mail nicht verfügbar, da E-Mail-Datenverkehr diesem Profil eindeutig nicht entspricht.) Wir empfehlen Ihnen, reuseport zu testen, um festzustellen, ob es die Leistung Ihrer NGINX-Bereitstellung verbessert, anstatt es pauschal einzusetzen. Tipps zum Testen der NGINX-Leistung finden Sie in Konstantin Pavlovs Vortrag auf der nginx.conf 2014.

Danksagungen

Unser Dank gilt Yingqi Lu von Intel und Sepherosa Ziehau, die jeweils eine Lösung zum NGINX-Projekt beigetragen haben, welche die Verwendung der Socket-Option SO_REUSEPORT ermöglicht. Das NGINX-Team hat Ideen aus beiden Beiträgen kombiniert und so eine Lösung geschaffen, die wir für ideal halten.

Über den Autor

Andrew Hutchings

Weitere Blogbeiträge von Andrew Hutchings