Adoptons une approche pragmatique.

Toutes ces limites ont été codées en dur et conçues au siècle dernier, lorsque le matériel était lent et coûteux. Nous sommes en 2016, et un grille-pain moyen peut traiter plus de demandes que les valeurs par défaut.

Les paramètres par défaut sont en fait dangereux. Avoir des centaines d'utilisateurs sur un site web n'a rien d'impressionnant.

processus_travailleur

Un cadre connexe, expliquons-le tant que nous sommes sur le sujet.

nginx comme équilibreur de charge :

• 1 travailleur pour l'équilibrage de la charge HTTP.
• 1 travailleur par cœur pour l'équilibrage de la charge HTTPS.

nginx comme serveurs web :

Cette question est délicate.

Certaines applications/frameworks/middleware (par exemple php-fpm) sont exécutées en dehors de nginx. Dans ce cas, un travailleur nginx est suffisant car c'est généralement l'application externe qui effectue le traitement lourd et consomme les ressources.

En outre, certaines applications/frameworks/middleware ne peuvent traiter qu'une seule demande à la fois et il est contre-productif de les surcharger.

D'une manière générale, un travailleur est toujours une valeur sûre.

Sinon, vous pouvez mettre un travailleur par noyau si vous savez ce que vous faites. Je considérerais cette solution comme une optimisation et je conseillerais de procéder à des analyses comparatives et à des tests appropriés.

connexions_travailleurs

Le nombre total de connexions est de worker_process * worker_connections . La moitié en mode équilibreur de charge.

Nous arrivons maintenant à la partie "grille-pain". Il existe de nombreuses limites de système très sous-estimées :

• ulimits est 1k maximum de fichiers ouverts par processus sous linux (1k soft, 4k hard sur certaines distro)
• Les limites de systemd sont à peu près les mêmes que celles de ulimits.
• La valeur par défaut de nginx est de 512 connexions par travailleur.
• Il pourrait y en avoir d'autres : SELinux, sysctl, supervisord (chaque distro+version est légèrement différente)

1k connexions_travailleurs

Par défaut, il est prudent de mettre 1 000 partout.

Il est suffisamment élevé pour être supérieur à ce que la plupart des sites internes et inconnus rencontreront jamais. Il est suffisamment bas pour ne pas heurter d'autres limites du système.

10k connexions_travailleurs

Il est très courant d'avoir des milliers de clients, surtout pour un site web public. J'ai arrêté de compter le nombre de sites web que j'ai vus s'effondrer à cause du faible nombre de défauts.

Le minimum acceptable pour la production est de 10 000. Les limites du système concerné doivent être augmentées pour le permettre.

Il n'existe pas de limite trop élevée (une limite n'a tout simplement aucun effet s'il n'y a pas d'utilisateurs). En revanche, une limite trop basse est une chose bien réelle qui se traduit par des utilisateurs rejetés et un site mort.

Plus de 10 000

10 km, c'est bien et c'est facile.

Nous pourrions fixer une limite arbitraire de 1000 kilos (ce n'est qu'une limite après tout) mais cela n'a pas beaucoup de sens pratique, nous n'avons jamais ce trafic et nous ne pourrions pas l'accepter de toute façon.

Nous nous en tiendrons à un chiffre raisonnable de 10 000. Les services qui demandent (et peuvent réellement faire) plus nécessiteront un réglage spécial et une analyse comparative.

Scénario spécial : Utilisation avancée

Parfois, nous savons que le serveur n'a pas beaucoup de ressources et nous nous attendons à des pics auxquels nous ne pouvons pas faire grand-chose. Nous préférons refuser des utilisateurs plutôt que d'essayer. Dans ce cas, fixez une limite de connexion raisonnable et configurez de bons messages d'erreur et une bonne gestion.

Parfois, les serveurs dorsaux fonctionnent bien, mais seulement jusqu'à un certain niveau. une certaine charge En revanche, si l'on en fait plus, les choses se gâtent rapidement. Nous préférons un ralentissement plutôt qu'une panne des serveurs. Dans ce cas, configurez la file d'attente avec des limites strictes, laissez nginx tamponner toute la chaleur pendant que les requêtes sont drainées à un rythme plafonné.

ulimit -a vous indique le nombre de fichiers ouverts que votre système permet à un processus d'utiliser.

En outre, net.ipv4.ip_local_port_range définit le nombre total de sockets à activer par IP.

Ainsi, votre worker_connections ne peut pas être supérieure à l'une de ces valeurs, sinon les connexions de vos clients seront mises en file d'attente jusqu'à ce que l'option net.core.netdev_max_backlog - la taille totale de la file d'attente TCP.

Gardez à l'esprit que si vous utilisez nginx comme reverse-proxy, cela utilise deux sockets par connexion. Vous pourriez vouloir jouer un peu avec net.ipv4.tcp_fin_timeout et d'autres délais liés à tcp dans le noyau pour essayer de changer rapidement l'état des sockets. Une autre chose à noter est que chaque socket alloue de la mémoire à la pile de mémoire TCP, vous pouvez également définir certaines limites de la pile de mémoire TCP en utilisant la commande sysctl Vous pouvez exercer une plus grande pression sur la mémoire vive tant que vous disposez d'un processeur et d'un nombre suffisant de gestionnaires de fichiers.

Pour information, il est possible, avec des ressources informatiques suffisantes, d'avoir un serveur avec environ 32 Go de mémoire vive et quelques interfaces réseau virtuelles pour gérer 1 million de connexions simultanées avec quelques réglages du noyau à l'aide de sysctl. Au cours de mes tests, lorsque j'ai traité plus de 1 million de connexions et envoyé une charge utile d'environ 700 octets, le serveur prenait environ 10 secondes pour mettre à jour environ 1,2 million de clients simultanés. L'étape suivante a consisté à augmenter la bande passante du réseau en connectant quelques cartes réseau supplémentaires et en supprimant les cartes réseau virtuelles. Il est possible d'établir une communication en temps quasi réel avec plus de 1,2 million de clients, compte tenu de la charge utile, de la bande passante et du temps raisonnable nécessaire pour mettre à jour tous les clients.

Bonne mise au point !

Le dimensionnement approprié peut être découvert par des tests, car il varie en fonction du type de trafic traité par Nginx.

Théoriquement, nginx peut gérer : max clients = worker_processes * worker_connections (* =multiplier) et worker_processes = nombre de processeurs

Pour connaître les processeurs, utilisez : grep processeur /proc/cpuinfo | wc -l

La réponse de Marcel doit vraiment être votée ! Si les ulimits sont fixés à une valeur par défaut d'environ 1k, max_connections devrait être fixé à la même valeur, sinon il n'y a aucun avantage à fixer max_connections à 10k.

Vous obtiendrez des requêtes en file d'attente et des sockets fermés sur nginx si "votre worker_connections ne peut pas être supérieur à l'un d'entre eux, ou vos connexions client seront mises en file d'attente jusqu'à net.core.netdev_max_backlog - la taille totale de la file d'attente TCP".

Un processus unique peut ouvrir autant de connexions que les limites le permettent. num_workers * max_connections est la formule, mais les connexions maximales et les limites en dehors du loadbalancer/proxy doivent être prises en compte pour obtenir des valeurs raisonnables. Définir max_connexion à une valeur très élevée peut se retourner contre vous car les limites seront un facteur limitant.

Il peut être utile de fixer des limites inférieures lorsque les ressources sont limitées. Certaines connexions, par exemple les connexions de type "keep-alive" (non seulement avec les clients, mais aussi avec les utilisateurs de l'Internet), sont très difficiles à gérer. avec les serveurs en amont ), gaspillent effectivement vos ressources (même si nginx est très efficace, ce qui est le cas) et ne sont pas nécessaires au bon fonctionnement d'un serveur polyvalent, ce qui signifie qu'ils peuvent être abandonnés en toute sécurité pour libérer plus de ressources pour le reste de l'opération.

Le fait d'avoir une limite de ressources plus basse indiquerait donc à nginx que vous êtes peut-être à court de ressources physiques, et que celles qui sont disponibles devraient être allouées à de nouvelles connexions, plutôt que de servir les connexions keep-alive qui tournent au ralenti au détriment des nouvelles connexions qui ont du mal à être établies pour répondre à des besoins plus urgents.

Quelle est la valeur recommandée ? C'est la valeur par défaut.

Les valeurs par défaut sont toutes indiquées dans la documentation :

Valeur par défaut : worker_connections 512 ;

Et peut être confirmée au niveau du code source à event/ngx_event.c , aussi

13#define DEFAULT_CONNECTIONS 512