Partage de sockets dans NGINX version 1.9.1

NGINX 1.9.1 introduit une nouvelle fonctionnalité qui permet d'utiliser l' option de socket SO_REUSEPORT , qui est disponible dans les versions plus récentes de nombreux systèmes d'exploitation, notamment DragonFly BSD et Linux (version du noyau 3.9 et ultérieure). Cette option de socket permet à plusieurs sockets d'écouter sur la même combinaison d'adresse IP et de port. Le noyau équilibre ensuite la charge des connexions entrantes sur les sockets.

Éditeur – Pour les utilisateurs de NGINX Plus, cette fonctionnalité est prise en charge dans NGINX Plus Release 7 (R7) et versions ultérieures. Pour un aperçu de toutes les nouvelles fonctionnalités de cette version, consultez l'annonce de NGINX Plus R7 sur notre blog.

L’option de socket SO_REUSEPORT a de nombreuses applications potentielles dans le monde réel. D'autres services peuvent l'utiliser pour faciliter les mises à niveau progressives des exécutables (NGINX prend déjà en charge les mises à niveau progressives par différents moyens ). Pour NGINX, l’activation de cette option de socket peut améliorer les performances dans certains scénarios en réduisant les conflits de verrouillage.

Comme illustré dans la figure, lorsque l'option SO_REUSEPORT n'est pas activée, un seul socket d'écoute informe les travailleurs des connexions entrantes et chaque travailleur essaie d'établir une connexion.

Avec l'option SO_REUSEPORT activée, il existe plusieurs écouteurs de socket pour chaque combinaison d'adresse IP et de port, un pour chaque processus de travail. Le noyau détermine quel écouteur de socket disponible (et par implication, quel travailleur) obtient la connexion. Cela peut réduire les conflits de verrouillage entre les travailleurs acceptant de nouvelles connexions et améliorer les performances sur les systèmes multicœurs. Cependant, cela peut également signifier que lorsqu'un travailleur est bloqué par une opération de blocage, le blocage affecte non seulement les connexions que le travailleur a déjà acceptées, mais également les demandes de connexion que le noyau a attribuées au travailleur depuis qu'il a été bloqué.

Configuration du partage de socket

Pour activer l'option de socket SO_REUSEPORT , incluez le nouveau paramètre reuseport à la directive listen pour le trafic HTTP ou TCP (module stream ), comme dans ces exemples :

http { serveur { écouter 80  réutiliser ; nom_serveur localhost; # ... } } flux { serveur { écouter 12345  réutiliser le rapport ; # ... } }

L'inclusion du paramètre reuseport désactive également la directive accept_mutex pour le socket, car le mutex est redondant avec reuseport . Il peut toujours être utile de définir accept_mutex s'il existe des ports sur lesquels vous ne définissez pas reuseport .

Analyse comparative des performances avec reuseport

J’ai exécuté un test de performance WRK avec 4 workers NGINX sur une instance AWS à 36 cœurs. Pour éliminer les effets de réseau, j'ai exécuté le client et NGINX sur localhost, et j'ai également demandé à NGINX de renvoyer la chaîne OK au lieu d'un fichier. J'ai comparé trois configurations NGINX : la configuration par défaut (équivalente à accept_mutex on ), avec accept_mutex off et avec reuseport . Comme le montre la figure, reuseport augmente les requêtes par seconde de 2 à 3 fois et réduit à la fois la latence et l'écart type de latence.

J'ai également exécuté une analyse comparative connexe avec le client et NGINX sur des hôtes séparés et avec NGINX renvoyant un fichier HTML. Comme le montre le tableau suivant, avec le réemploi, la diminution de la latence était similaire à celle du benchmark précédent, et l’écart type a diminué encore plus considérablement (presque dix fois). D’autres résultats (non présentés dans le tableau) sont également encourageants. Avec reuseport , la charge a été répartie uniformément sur les processus de travail. Dans la condition par défaut (équivalente à accept_mutex activé ), certains travailleurs ont reçu un pourcentage de charge plus élevé, et avec accept_mutex désactivé, tous les travailleurs ont subi une charge élevée.

Dans ces benchmarks, le taux de demandes de connexion est élevé mais les demandes ne nécessitent pas de traitement approfondi. D’autres tests préliminaires indiquent également que la réutilisation améliore considérablement les performances lorsque le trafic correspond à ce profil. (Le paramètre reuseport n'est pas disponible sur la directive listen dans le contexte de messagerie , par exemple, car le trafic de messagerie ne correspond certainement pas au profil.) Nous vous encourageons à tester reuseport pour déterminer s'il améliore les performances de votre déploiement NGINX, plutôt que de l'appliquer en masse. Pour quelques conseils sur les tests de performances de NGINX, consultez la conférence de Konstantin Pavlov à nginx.conf 2014.

Remerciements

Merci à Yingqi Lu d'Intel et à Sepherosa Ziehau, qui ont chacun contribué à une solution au projet NGINX qui permet d'utiliser l'option de socket SO_REUSEPORT . L’équipe NGINX a combiné les idées des deux contributions pour créer ce que nous pensons être une solution idéale.