Qu'est-ce que la segmentation des sockets sur le serveur Nginx

La version 1.9.1 de nginx introduit une nouvelle fonctionnalité : permettre l'utilisation de l'option de socket so_reuseport, qui est disponible dans les nouvelles versions de nombreux systèmes d'exploitation, dont dragonfly BSD et Linux (version 3.9 et ultérieure du noyau). Cette option de socket permet à plusieurs sockets d’écouter sur la même combinaison IP et port. Le noyau est capable d'équilibrer la charge des connexions entrantes sur ces sockets. (Pour les clients nginx plus, cette fonctionnalité sera disponible dans la version 7, qui sortira d'ici la fin de l'année)

L'option so_reuseport a de nombreuses applications potentielles dans le monde réel. D'autres services peuvent également l'utiliser pour simplement implémenter des mises à niveau propagées pendant l'exécution (nginx prend déjà en charge les mises à niveau propagées). Pour nginx, l'activation de cette option peut réduire les conflits de verrouillage dans certains scénarios et améliorer les performances.

Comme décrit dans la figure ci-dessous, lorsque l'option so_reuseport est valide, un socket d'écoute distinct informe le processus de travail de la connexion accédée et chaque thread de travail tente d'obtenir la connexion.

Lorsque l'option so_reuseport est activée, il existe plusieurs écouteurs de socket pour chaque adresse IP et connexion liée au port, et chaque processus de travail peut en recevoir un. Le noyau du système détermine quel écouteur de socket valide (et implicitement pour quel processus de travail) obtient la connexion. Cela peut réduire la concurrence de verrouillage entre les processus de travail lors de l'obtention de nouvelles connexions (Note du traducteur : concurrence entre les processus de travail demandant l'obtention de verrous de ressources mutuellement exclusifs) et peut améliorer les performances sur les systèmes multicœurs. Cependant, cela signifie également que lorsqu'un processus de travail tombe dans une opération de blocage, le blocage affecte non seulement le processus de travail qui a accepté la connexion, mais amène également le processus de travail prévu pour être alloué par le noyau pour envoyer la demande de connexion et donc devient bloqué.

Configurer un socket partagé

Pour que l'option de socket so_reuseport fonctionne, le nouveau paramètre reuseport doit être introduit directement pour l'élément d'écoute dans l'option de communication http ou tcp (mode flux), comme le exemple suivant :
Le code est le suivant : server { Listen 12345 reuseport;

                                                                          

Après avoir référencé le paramètre reuseport, le paramètre accept_mutex ne sera pas valide pour le socket référencé, car le mutex (mutex) est redondant pour le réutilisation. Pour les ports qui n'utilisent pas reuseport, il est toujours utile de définir accept_mutex.

Test de performance de référence de Reuseport

J'ai exécuté l'outil de référence sur une instance AWS à 36 cœurs pour tester 4 processus de travail nginx afin de réduire l'impact du réseau, le client et nginx s'exécutent localement et laissent nginx renvoyer le. ok chaîne plutôt qu'un fichier. J'ai comparé trois configurations nginx : default (équivalent à accept_mutex on), accept_mutex off et reuseport. Comme le montre la figure, les requêtes par seconde de réutilisation sont deux à trois fois supérieures à celles des autres, tandis que la latence et l'écart type de latence sont également réduits.





J'ai effectué un autre test de performances connexe : le client et nginx étaient sur des machines différentes et nginx a renvoyé un fichier html. Comme le montre le tableau ci-dessous, la réduction de la latence grâce à la réutilisation est similaire au test de performances précédent, la réduction de l'écart type de la latence étant plus significative (près d'un dixième). D'autres résultats (non présentés dans le tableau) sont tout aussi encourageants. Grâce à reuseport, la charge est répartie uniformément entre les processus de travail. Dans des conditions par défaut (équivalentes à accept_mutex on), certains Workers reçoivent un pourcentage de charge plus élevé, tandis qu'avec accept_mutex off, tous les Workers reçoivent une charge plus élevée.

Copier le code Le code est le suivant :

latence (ms) latence stdev (ms) charge du processeur

par défaut 15,65 26,59 0,3

accept_mutex off 15,59 26,48 10

reuseport 12,35 3,15 0,3

In ces tests de performances, la vitesse de demande de connexion est très élevé, mais la demande ne nécessite pas beaucoup de traitement. D'autres tests de base doivent souligner que la réutilisation peut également améliorer considérablement les performances lorsque le trafic des applications correspond à ce scénario. (Le paramètre reuseport ne peut pas être utilisé dans la directive d'écoute dans le contexte de messagerie, tel que le courrier électronique, car le trafic de courrier électronique ne correspondra certainement pas à ce scénario.) Nous vous encourageons à tester d'abord plutôt que de l'appliquer directement à grande échelle.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!