Comment optimiser Nginx et Node.js pour les réseaux à forte charge

Réglage du réseau
Si vous ne comprenez pas d'abord les mécanismes de transmission sous-jacents de nginx et de node.js et n'effectuez pas une optimisation ciblée, aussi détaillée que soit l'optimisation des deux, ce sera en vain. Normalement, nginx connecte le client et les applications en amont via le socket TCP.
Notre système a de nombreux seuils et restrictions pour TCP, qui sont définis via les paramètres du noyau. Les valeurs par défaut de ces paramètres sont souvent définies à des fins générales et ne peuvent pas répondre aux exigences de trafic élevé et de courte durée de vie des serveurs Web.
Voici quelques paramètres qui peuvent être utilisés comme candidats pour le réglage de TCP. Pour les rendre efficaces, vous pouvez les placer dans le fichier /etc/sysctl.conf ou les placer dans un nouveau fichier de configuration, tel que /etc/sysctl.d/99-tuning.conf, puis exécuter sysctl -p pour laissez le noyau les charger. Nous utilisons sysctl-cookbook pour effectuer ce travail physique.
Il convient de noter que les valeurs répertoriées ici sont sûres à utiliser, mais il est tout de même recommandé d'étudier la signification de chaque paramètre afin de choisir une valeur plus appropriée en fonction de votre charge, de votre matériel et de votre utilisation.

Copier le code Le code est le suivant :

net.ipv4 .tcp_tw_reuse='1'
net.ipv4.tcp_fin_timeout='15'
net.core.netdev_max_backlog='4096'
net.core.rmem_max='16777216'
net.core.somaxconn='4096'
net.core .wmem_max='16777216'
net.ipv4.tcp_max_syn_backlog='20480'
net.ipv4.tcp_max_tw_buckets='400000'
net.ipv4.tcp_no_metrics_save='1'
net.ipv4.tcp_rmem=' 40 96 87380 span>


Soulignez-en quelques-uns. Un important.

net.ipv4.ip_local_port_range

Afin de servir le client en aval pour l'application en amont, nginx doit ouvrir deux connexions TCP, une vers le client et une vers l'application. Lorsqu'un serveur reçoit de nombreuses connexions, les ports disponibles du système seront rapidement épuisés. En modifiant le paramètre net.ipv4.ip_local_port_range, vous pouvez augmenter la plage de ports disponibles. Si une telle erreur est trouvée dans /var/log/syslog : "possible syn Flooding sur le port 80. envoi de cookies", cela signifie que le système ne trouve pas de port disponible. L'augmentation du paramètre net.ipv4.ip_local_port_range peut réduire cette erreur.

net.ipv4.tcp_tw_reuseLorsque le serveur doit basculer entre un grand nombre de connexions TCP, un grand nombre de connexions dans l'état time_wait seront générées. time_wait signifie que la connexion elle-même est fermée, mais que les ressources n'ont pas été libérées. Définir net_ipv4_tcp_tw_reuse sur 1 permet au noyau d'essayer de recycler les connexions lorsque cela est sûr, ce qui est beaucoup moins cher que de rétablir de nouvelles connexions. net.ipv4.tcp_fin_timeout
Il s'agit du temps minimum qu'une connexion dans l'état time_wait doit attendre avant de recycler. Le rendre plus petit peut accélérer le recyclage.

Comment vérifier l'état de la connexion

Utilisez netstat:
netstat -tan | awk '{print $6}' | (noyau 541)
tcp : 47461 (estab 311, fermé 47135, orphelin 4, synrecv 0, timewait 47135/0), ports 33938transport total ip ipv6
* 541 - -raw 0 0 0
udp 13 10 3
tcp 326 325 1
inet 339 335 4
frag 0 0 0
À mesure que la charge sur le serveur Web augmente progressivement, nous commencerons à rencontrer d'étranges limitations de nginx. La connexion est interrompue et le noyau continue de signaler une inondation de synchronisation. À l'heure actuelle, la charge moyenne et l'utilisation du processeur sont très faibles, et le serveur peut évidemment gérer plus de connexions, ce qui est vraiment frustrant.
Après enquête, nous avons constaté qu'il existe de nombreuses connexions dans l'état time_wait. Voici le résultat de l'un des serveurs :
Il y a 47 135 connexions time_wait ! De plus, on peut voir d'après ss qu'il s'agit toutes de connexions fermées. Cela indique que le serveur a consommé la plupart des ports disponibles et implique également que le serveur alloue de nouveaux ports pour chaque connexion. Le réglage du réseau a quelque peu aidé à résoudre le problème, mais il n'y avait toujours pas assez de ports.
Après des recherches plus approfondies, j'ai trouvé un document sur la directive keepalive de connexion en amont, qui dit :
Définissez le nombre maximum de connexions keepalive inactives au serveur en amont. Ces connexions seront conservées dans le cache du processus de travail.
Intéressant. En théorie, cette configuration minimise le gaspillage de connexions en transmettant les requêtes via les connexions mises en cache. La documentation mentionne également que nous devons définir proxy_http_version sur "1.1" et effacer l'en-tête "connection". Après des recherches plus approfondies, j'ai trouvé que c'était une bonne idée, car http/1.1 optimise considérablement l'utilisation des connexions TCP par rapport à http1.0 et nginx utilise http/1.0 par défaut.
Après modification comme recommandé par le document, notre fichier de configuration de liaison montante devient comme ceci :


Copiez le code Le code est le suivant :

upstream backend_nodejs {
server nodejs-3:5016 max_fails=0 fail_timeout=10s;
server nodejs-4:5016 max_fails=0 fail_timeout=10s;
server nodejs-5:5016 max_fails=0 fail_timeout=10s;
server nodejs- 6:5016 max_fails=0 fail_timeout=10s;
keepalive 512;
}

J'ai également modifié les paramètres proxy dans la section serveur comme suggéré. Dans le même temps, un proxy_next_upstream a été ajouté pour ignorer les serveurs défaillants, le keepalive_timeout du client a été ajusté et le journal d'accès a été désactivé. La configuration devient comme ceci :

Copier le code Le code est le suivant :

server {
listen 80;
server_name fast.gosquared.com;
client_max_body_size 16m;
keepalive_timeout 10;
location / {
proxy_next_upstream error timeout http_500 http_50 2 http_503 http_504;
proxy_set_header connection "";
proxy_http_version 1.1;
proxy_pass http://backend_nodejs;
}
access_log off;
error_log /dev/null crit;
}

Après avoir adopté la nouvelle configuration, j'ai trouvé que les sockets occupés par les serveurs ont diminué de 90%. Les requêtes peuvent désormais être transmises en utilisant beaucoup moins de connexions. La nouvelle sortie est la suivante :
ss -s
total : 558 (noyau 604)
tcp : 4675 (estab 485, fermé 4183, orphelin 0, synrecv 0, timewait 4183/0), ports 2768
transport total ip ipv6
* 604 - -
raw 0 0 0
udp 13 10 3
tcp 492 491 1
inet 505 501 4
node.js
Grâce à la conception basée sur les événements qui peut gérer les E/S de manière asynchrone, node.js peut gérer de grandes montants de connexions et de demandes prêtes à l'emploi. Bien qu'il existe d'autres méthodes de réglage, cet article se concentrera principalement sur l'aspect processus de node.js.
Le nœud est monothread et n'utilisera pas automatiquement plusieurs cœurs. En d’autres termes, l’application ne peut pas obtenir automatiquement toutes les capacités du serveur.
Réalisation du clustering des processus de nœuds
Nous pouvons modifier l'application afin qu'elle crée plusieurs threads et reçoive des données sur le même port, permettant ainsi à la charge de s'étendre sur plusieurs cœurs. Node dispose d'un module de cluster qui fournit tous les outils nécessaires pour atteindre cet objectif, mais les ajouter à l'application nécessite beaucoup de travail manuel. Si vous utilisez Express, eBay dispose d'un module appelé cluster2 qui peut être utilisé.
Empêcher le changement de contexte
Lors de l'exécution de plusieurs processus, vous devez vous assurer que chaque cœur de processeur n'est occupé que par un seul processus à la fois. De manière générale, si le processeur possède n cœurs, nous devrions générer n-1 processus d’application. Cela garantit que chaque processus bénéficie d'une tranche de temps raisonnable, laissant un cœur libre pour que le planificateur du noyau puisse exécuter d'autres tâches. Nous devons également nous assurer qu'aucune autre tâche autre que node.js n'est exécutée sur le serveur pour éviter les conflits de processeur.
Nous avons déjà commis une erreur et déployé deux applications node.js sur le serveur, puis chaque application a ouvert n-1 processus. En conséquence, ils se disputent le processeur, ce qui entraîne une forte augmentation de la charge du système. Bien que nos serveurs soient tous des machines à 8 cœurs, la surcharge de performances causée par le changement de contexte peut toujours être clairement ressentie. Le changement de contexte fait référence au phénomène selon lequel le processeur suspend la tâche en cours afin d'effectuer d'autres tâches. Sur un commutateur, le noyau doit suspendre tous les états du processus en cours, puis charger et exécuter un autre processus. Afin de résoudre ce problème, nous avons réduit le nombre de processus démarrés par chaque application et leur avons permis de partager équitablement le processeur. En conséquence, la charge du système a diminué :



Veuillez prêter attention à l'image ci-dessus pour voir comment cela se produit. la charge du système (ligne bleue) est inférieure au nombre de cœurs de processeur (ligne rouge). Sur d'autres serveurs, nous avons constaté la même chose. Étant donné que la charge de travail totale reste la même, les améliorations de performances dans le graphique ci-dessus ne peuvent être attribuées qu'à la réduction des changements de contexte.

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!