Socket-Sharding in NGINX Release 1.9.1

NGINX 1.9.1 führt eine neue Funktion ein, die die Verwendung der Socket-Option SO_REUSEPORT ermöglicht , die in neueren Versionen vieler Betriebssysteme verfügbar ist, darunter DragonFly BSD und Linux (Kernelversion 3.9 und höher). Diese Socket-Option ermöglicht es mehreren Sockets, auf derselben Kombination aus IP-Adresse und Port zu lauschen. Der Kernel verteilt dann die Last eingehender Verbindungen über die Sockets.

Editor – Für NGINX Plus-Benutzer wird diese Funktion in NGINX Plus Release 7 (R7) und höher unterstützt. Eine Übersicht über alle neuen Funktionen in dieser Version finden Sie unter „Ankündigung von NGINX Plus R7“ in unserem Blog.

Für die Socket-Option SO_REUSEPORT gibt es viele potenzielle Anwendungen in der Praxis. Andere Dienste können es für einfache Rolling Upgrades von ausführbaren Dateien verwenden (NGINX unterstützt Rolling Upgrades bereits auf verschiedene Weise ). Bei NGINX kann das Aktivieren dieser Socket-Option in bestimmten Szenarien die Leistung durch die Reduzierung von Sperrkonflikten verbessern.

Wie in der Abbildung dargestellt, benachrichtigt ein einzelner Abhörsocket die Worker über eingehende Verbindungen, wenn die Option SO_REUSEPORT nicht aktiviert ist, und jeder Worker versucht, eine Verbindung herzustellen.

Wenn die Option SO_REUSEPORT aktiviert ist, gibt es für jede Kombination aus IP-Adresse und Port mehrere Socket-Listener, einen für jeden Arbeitsprozess. Der Kernel bestimmt, welcher verfügbare Socket-Listener (und implizit welcher Worker) die Verbindung erhält. Dadurch können Sperrkonflikte zwischen Workern, die neue Verbindungen akzeptieren, verringert und die Leistung auf Multi-Core-Systemen verbessert werden. Dies kann jedoch auch bedeuten, dass, wenn ein Worker durch eine blockierende Operation blockiert wird, die Blockierung nicht nur Verbindungen betrifft, die der Worker bereits akzeptiert hat, sondern auch Verbindungsanforderungen, die der Kernel dem Worker seit der Blockierung zugewiesen hat.

Socket-Sharding konfigurieren

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

http { Server { hören 80  Wiederverwendungsport ; Servername lokaler Host; # ... } } Stream { Server { abhören 12345  Wiederverwendungsport ; # ... } }

Durch die Einbeziehung des Parameters „reuseport“ wird auch die Direktive „accept_mutex“ für den Socket deaktiviert, da der Mutex mit „reuseport“ redundant ist. Es kann sich dennoch lohnen, accept_mutex festzulegen, wenn es Ports gibt, für die Sie reuseport nicht festlegen.

Leistungsbenchmarking mit Reuseport

Ich habe einen Wrk -Benchmark mit 4 NGINX-Workern auf einer 36-Core-AWS-Instanz ausgeführt. Um Netzwerkeffekte auszuschließen, habe ich sowohl den Client als auch NGINX auf dem lokalen Host ausgeführt und NGINX hat außerdem die Zeichenfolge „OK“ anstelle einer Datei zurückgegeben. Ich habe drei NGINX-Konfigurationen verglichen: die Standardkonfiguration (entspricht „accept_mutex aktiviert “), mit „accept_mutex deaktiviert “ und mit „reuseport“ . Wie in der Abbildung gezeigt, erhöht Reuseport die Anfragen pro Sekunde um das Zwei- bis Dreifache und reduziert sowohl die Latenz als auch die Standardabweichung für die Latenz.

Ich habe auch einen zugehörigen Benchmark mit dem Client und NGINX auf separaten Hosts ausgeführt und wobei NGINX eine HTML-Datei zurückgegeben hat. Wie aus der folgenden Tabelle hervorgeht, war die Verringerung der Latenz mit Reuseport ähnlich wie beim vorherigen Benchmark, und die Standardabweichung verringerte sich sogar noch drastischer (fast um das Zehnfache). Auch andere Ergebnisse (nicht in der Tabelle aufgeführt) waren ermutigend. Mit reuseport wurde die Last gleichmäßig auf die Arbeitsprozesse verteilt. Unter der Standardbedingung (entspricht „accept_mutex aktiviert “) wurde einigen Workern ein höherer Prozentsatz der Last zugewiesen, und wenn „accept_mutex deaktiviert“ war, war die Last auf allen Workern hoch.

Bei diesen Benchmarks ist die Rate der Verbindungsanfragen hoch, die Anfragen erfordern jedoch keine umfangreiche Verarbeitung. Auch andere vorläufige Tests zeigen, dass Reuseport die Leistung am meisten verbessert, wenn der Datenverkehr diesem Profil entspricht. (Der Parameter „reuseport“ ist beispielsweise bei der Listen- Direktive im Mail- Kontext nicht verfügbar, da der E-Mail-Verkehr definitiv nicht zum Profil passt.) Wir empfehlen Ihnen, Reuseport zu testen, um festzustellen, ob es die Leistung Ihrer NGINX-Bereitstellung verbessert, anstatt es pauschal anzuwenden. Einige Tipps zum Testen der NGINX-Leistung finden Sie im Vortrag von Konstantin Pavlov auf der nginx.conf 2014.

Danksagung

Dank geht an Yingqi Lu von Intel und Sepherosa Ziehau, die jeweils eine Lösung zum NGINX-Projekt beigetragen haben, die die Verwendung der Socket-Option SO_REUSEPORT ermöglicht. Das NGINX-Team hat Ideen aus beiden Beiträgen kombiniert, um unserer Meinung nach eine ideale Lösung zu schaffen.