Prenons l'approche pragmatique.
Toutes ces limites sont des choses qui ont été codées en dur et conçues au cours du siècle dernier lorsque le matériel était lent et coûteux. Nous sommes en 2016 maintenant, un grille-pain Wall-Mart 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.
worker_process
Un paramètre connexe, expliquons-le pendant que nous sommes sur le sujet.
nginx comme équilibreur de charge:
- 1 travailleur pour l'équilibrage de charge HTTP.
- 1 travailleur par cœur pour l'équilibrage de charge HTTPS.
nginx en tant que serveurs Web:
Celui-ci est délicat.
Certaines applications / frameworks / middleware (par exemple php-fpm) sont exécutés en dehors de nginx. Dans ce cas, 1 travailleur nginx suffit, car c'est généralement l'application externe qui effectue le traitement lourd et consomme les ressources.
De plus, certaines applications / frameworks / middleware ne peuvent traiter qu'une seule demande à la fois et cela se retourne pour les surcharger.
De manière générale, 1 travailleur est toujours une valeur sûre.
Sinon, vous pouvez mettre un travailleur par cœur si vous savez ce que vous faites. Je considérerais cette route comme une optimisation et je conseillerais une analyse comparative et des tests appropriés.
connexions_ouvriers
Le nombre total de connexions est worker_process * worker_connections
. La moitié en mode équilibreur de charge.
Nous arrivons maintenant à la partie grille-pain. Il existe de nombreuses limites du système sérieusement sous-estimées:
- ulimits est 1k max de fichiers ouverts par processus sur linux (1k soft, 4k hard sur certaines distributions)
- les limites de systemd sont à peu près les mêmes que les ulimits.
- nginx par défaut est 512 connexions par travailleur.
- Il pourrait y en avoir plus: SELinux, sysctl, supervisord (chaque version de distribution + est légèrement différente)
1k connexions_travailleurs
Le défaut par défaut est de mettre 1k partout.
Il est suffisamment élevé pour être plus que la plupart des sites internes et inconnus ne rencontreront jamais. Il est suffisamment bas pour ne toucher aucune autre limite du système.
10k connexions_travailleurs
Il est très courant d'avoir des milliers de clients, en particulier pour un site Web public. J'ai arrêté de compter le nombre de sites Web que j'ai vus en raison des faibles valeurs par défaut.
Le minimum acceptable pour la production est de 10k. Les limites du système associé doivent être augmentées pour le permettre.
Il n'y a pas de limite trop élevée (une limite n'a tout simplement aucun effet s'il n'y a pas d'utilisateurs). Cependant, une limite trop basse est une chose très réelle qui se traduit par des utilisateurs rejetés et un site mort.
Plus de 10k
10k est agréable et facile.
Nous pourrions fixer des limites arbitraires de 1000kk (ce n'est qu'une limite après tout) mais cela n'a pas beaucoup de sens pratique, nous n'obtenons jamais ce trafic et ne pouvons pas le prendre de toute façon.
Restons-en à 10k comme paramètre raisonnable. Les services qui vont (et peuvent vraiment faire) davantage nécessiteront un réglage et une analyse comparative spéciaux.
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 que nous ne pouvons pas faire grand-chose. Nous préférons refuser les utilisateurs que d'essayer. Dans ce cas, définissez une limite de connexion raisonnable et configurez de bons messages d'erreur et une bonne gestion.
Parfois, les serveurs d'arrière-plan fonctionnent bien et bien, mais jusqu'à une certaine charge , rien de plus et tout va vite au sud. Nous préférons ralentir plutôt que de faire planter les serveurs. Dans ce cas, configurez la mise en file d'attente avec des limites strictes, laissez nginx mettre en mémoire tampon toute la chaleur pendant que les demandes sont drainées à un rythme limité.