{"id":20722,"date":"2026-08-17T08:35:37","date_gmt":"2026-08-17T06:35:37","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/"},"modified":"2026-08-17T08:35:37","modified_gmt":"2026-08-17T06:35:37","slug":"nginx-connexions-des-workers-mise-a-lechelle-de-milliers-de-requetes-trafficboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/","title":{"rendered":"Connexions des workers NGINX \u2013 Prise en charge de milliers de requ\u00eates pour des performances d'h\u00e9bergement optimales"},"content":{"rendered":"<p>Je fais \u00e9voluer de mani\u00e8re cibl\u00e9e le nombre de workers Nginx afin de traiter des milliers de requ\u00eates simultan\u00e9es avec un faible <strong>Latence<\/strong> \u00e0 g\u00e9rer. La cl\u00e9 r\u00e9side dans une combinaison bien \u00e9quilibr\u00e9e entre worker_processes, worker_connections, les descripteurs de fichiers et <strong>\u00c9v\u00e9nements<\/strong>.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>Capacit\u00e9<\/strong> = worker_processes \u00d7 worker_connections ; dans le cas d'un proxy inverse, souvent d\u00e9termin\u00e9 par les connexions client et en amont <strong>doubl\u00e9<\/strong>.<\/li>\n  <li><strong>Descripteurs de fichiers<\/strong> (worker_rlimit_nofile, ulimit) en fonction de la charge de connexion pr\u00e9vue <strong>soulever<\/strong>.<\/li>\n  <li><strong>\u00c9v\u00e9nements<\/strong>- Blocage avec epoll, multi_accept et les files d'attente du noyau en cas de charge \u00e9lev\u00e9e <strong>ajuster<\/strong>.<\/li>\n  <li><strong>Suivi<\/strong> via stub_status et des tests de charge pour les it\u00e9rations <strong>Adaptation<\/strong>.<\/li>\n  <li><strong>Mise \u00e0 l'\u00e9chelle<\/strong> Combiner verticalement et horizontalement, configuration <strong>d\u00e9coupler<\/strong>.<\/li>\n<\/ul>\n\n<h2>Architecture NGINX : Master, Worker et \u00e9v\u00e9nements<\/h2>\n<p>NGINX s'appuie sur un processus ma\u00eetre qui lance plusieurs processus de travail et les g\u00e8re efficacement avec <strong>\u00c9v\u00e9nements<\/strong> trait\u00e9es. Au lieu de traiter des threads par requ\u00eate, chaque worker g\u00e8re de nombreuses connexions de mani\u00e8re non bloquante via un mod\u00e8le bas\u00e9 sur les \u00e9v\u00e9nements, avec une faible <strong>Overhead<\/strong>. Je r\u00e8gle la directive `worker_processes` sur `auto` afin que NGINX exploite les c\u0153urs du processeur et que chaque unit\u00e9 dispose de son propre worker. Cela me permet de mieux r\u00e9partir les connexions entrantes et de maintenir la latence \u00e0 un niveau acceptable m\u00eame en p\u00e9riode de pic de trafic <strong>faible<\/strong>. Pour approfondir la question de la planification des processus, je vous renvoie \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/configurer-de-maniere-optimale-les-processus-de-travail-nginx-pour-ameliorer-les-performances\/\">Optimiser les processus \u00ab worker \u00bb<\/a>, car un parall\u00e9lisme correctement configur\u00e9 d\u00e9termine la capacit\u00e9 de connexion r\u00e9alisable. Il est essentiel que le param\u00e8tre `worker_connections` soit correctement dimensionn\u00e9 pour chaque worker, afin que sa multiplication par le nombre de processus donne le r\u00e9sultat attendu <strong>Charge de pointe<\/strong> couvre.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-worker-rechenzentrum-7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Formule de capacit\u00e9 : worker_processes \u00d7 worker_connections<\/h2>\n<p>Je calcule la capacit\u00e9 approximative en multipliant worker_processes par worker_connections, sachant que les requ\u00eates proxy occupent souvent deux connexions par acc\u00e8s utilisateur, ce qui r\u00e9duit de moiti\u00e9 le nombre effectif. <strong>peut<\/strong>. De nombreuses installations standard d\u00e9marrent avec 512 connexions par worker, ce qui s'av\u00e8re souvent insuffisant pour les charges de travail en production <strong>est<\/strong>. Les valeurs de d\u00e9part pratiques se situent g\u00e9n\u00e9ralement entre 1 024 et 4 096 et d\u00e9pendent du profil de trafic et du mat\u00e9riel. Je pr\u00e9vois une marge de s\u00e9curit\u00e9, c'est-\u00e0-dire au moins un facteur deux par rapport \u00e0 la charge de pointe mesur\u00e9e, afin de pouvoir g\u00e9rer les pics de trafic en toute s\u00e9curit\u00e9 <strong>amortir<\/strong>. Il reste important de proc\u00e9der \u00e0 une validation \u00e0 l'aide de tests et de m\u00e9triques en temps r\u00e9el, afin que les chiffres ne deviennent pas un simple jeu th\u00e9orique <strong>seront<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Sc\u00e9nario<\/strong><\/th>\n      <th><strong>worker_processes<\/strong><\/th>\n      <th><strong>worker_connections<\/strong><\/th>\n      <th><strong>Max. th\u00e9orique.<\/strong><\/th>\n      <th><strong>Effectif (proxy)<\/strong><\/th>\n      <th><strong>FD par travailleur<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Petit site<\/td>\n      <td>2<\/td>\n      <td>1024<\/td>\n      <td>2048<\/td>\n      <td>~1024<\/td>\n      <td>\u22651024<\/td>\n    <\/tr>\n    <tr>\n      <td>API charge moyenne<\/td>\n      <td>4<\/td>\n      <td>2048<\/td>\n      <td>8192<\/td>\n      <td>~4096<\/td>\n      <td>\u2265 2 048<\/td>\n    <\/tr>\n    <tr>\n      <td>Heures de pointe de la boutique<\/td>\n      <td>8<\/td>\n      <td>4096<\/td>\n      <td>32768<\/td>\n      <td>~16384<\/td>\n      <td>\u2265 4 096<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>HTTP\/1.1, HTTP\/2 et TLS : impact sur les workers et la latence<\/h2>\n<p>Les protocoles d\u00e9terminent le profil de connexion. Avec HTTP\/1.1, j'observe souvent un grand nombre de connexions TCP simultan\u00e9es par client, tandis qu'HTTP\/2 les r\u00e9duit \u00e0 quelques flux, mais qui sont en revanche davantage sollicit\u00e9s. <strong>regroupe<\/strong>. Cela permet d'\u00e9conomiser des descripteurs de fichiers, mais transf\u00e8re la charge vers les tampons et la gestion des priorit\u00e9s. Sous TLS, je veille \u00e0 r\u00e9utiliser les sessions afin d'\u00e9viter que des \u00ab handshakes \u00bb co\u00fbteux ne soient effectu\u00e9s \u00e0 chaque requ\u00eate <strong>freiner<\/strong>. Un cache de session partag\u00e9 et des d\u00e9lais d'expiration adapt\u00e9s permettent de r\u00e9duire les pics d'utilisation du processeur. De plus, je ne r\u00e8gle pas la valeur de `keepalive_requests` trop bas, afin que les connexions de longue dur\u00e9e puissent offrir tous leurs avantages <strong>jouer<\/strong>. Pour HTTP\/2, je pr\u00e9vois une concurrence plus \u00e9lev\u00e9e par connexion et je veille \u00e0 disposer de tampons d'envoi et de r\u00e9ception suffisamment grands, sans pour autant utiliser trop de m\u00e9moire <strong>gaspiller<\/strong>. En cas de trafic mixte, j'adopte une approche prudente et je v\u00e9rifie les r\u00e9percussions pour chaque variante de protocole dans le <strong>Test<\/strong>.<\/p>\n\n<h2>Configurer correctement les descripteurs de fichiers et ulimit<\/h2>\n<p>Chaque connexion n\u00e9cessite au moins un descripteur de fichier ; dans le cas d'un proxy inverse, il en faut souvent deux, c'est pourquoi des valeurs ulimit trop basses posent de s\u00e9rieux <strong>Fronti\u00e8res<\/strong> d\u00e9finir. J\u2019augmente la valeur de `worker_rlimit_nofile` de mani\u00e8re \u00e0 ce que `worker_processes` \u00d7 `worker_connections` soit r\u00e9alisable et qu\u2019il reste des r\u00e9serves pour les journaux, les sockets et les caches. Au niveau du syst\u00e8me, j\u2019ajuste les fichiers `limits.conf` et `fs.file-max` afin que le syst\u00e8me d\u2019exploitation autorise le nombre pr\u00e9vu de fichiers ouverts et ne s\u2019arr\u00eate pas pr\u00e9matur\u00e9ment <strong>freine<\/strong>. \u00c0 l'aide de la commande `ulimit -n` et du param\u00e8tre Systemd (LimitNOFILE), je v\u00e9rifie si la configuration est persistante et adapt\u00e9e \u00e0 NGINX. Si vous ignorez ce param\u00e8tre, vous risquez de voir appara\u00eetre soudainement des connexions refus\u00e9es et une augmentation de <strong>Latence<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_connections_3894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>R\u00e9glage fin du bloc \u00ab Events \u00bb : epoll, multi_accept, backlogs<\/h2>\n<p>Sous Linux, j'utilise epoll, car ce m\u00e9canisme permet de g\u00e9rer efficacement un grand nombre de connexions gr\u00e2ce \u00e0 la gestion asynchrone <strong>\u00c9v\u00e9nements<\/strong> g\u00e8re. Avec l'option \u00ab multi_accept on \u00bb, un worker accepte plusieurs nouvelles connexions par \u00e9v\u00e9nement, ce qui permet de lisser les pics de charge et de r\u00e9duire les d\u00e9lais d'acceptation <strong>r\u00e9duit<\/strong>. J'ajuste les param\u00e8tres du noyau tels que net.core.somaxconn et net.ipv4.tcp_max_syn_backlog afin d'\u00e9viter que les files d'attente d'acceptation ne d\u00e9bordent en cas de pic de trafic. Les optimisations TIME_WAIT telles que tcp_tw_reuse r\u00e9duisent les goulots d'\u00e9tranglement au niveau des ports et maintiennent la courbe de d\u00e9bit <strong>\u00e9lev\u00e9<\/strong>. Pour approfondir vos connaissances sur la concurrence et les files d'attente, nous vous recommandons de consulter <a href=\"https:\/\/webhosting.de\/fr\/threadpool-serveur-web-apache-nginx-litespeed-optimisation-configuration\/\">Optimisation du pool de threads<\/a>, m\u00eame si NGINX fonctionne principalement de mani\u00e8re \u00e9v\u00e9nementielle et est donc tr\u00e8s \u00e9conome en ressources <strong>mis \u00e0 l'\u00e9chelle<\/strong>.<\/p>\n\n<h2>Bien r\u00e9partir les sockets de liste : reuseport, backlog et accept_mutex<\/h2>\n<p>Lorsque le nombre de connexions simultan\u00e9es est tr\u00e8s \u00e9lev\u00e9, je redimensionne activement le chemin de r\u00e9ception. Avec <strong>reuseport<\/strong> Chaque worker dispose de son propre socket d'\u00e9coute ; cela \u00e9limine la concurrence lors de l'acceptation et la charge est r\u00e9partie de mani\u00e8re homog\u00e8ne sur tous les c\u0153urs. Je d\u00e9finis explicitement la file d'attente d'\u00e9coute afin de g\u00e9rer les pics de trafic de courte dur\u00e9e. Dans cette configuration, le mutex `accept_mutex` n\u2019est plus n\u00e9cessaire. En revanche, sans `reuseport`, `accept_mutex` peut <strong>aider<\/strong>, afin d'att\u00e9nuer les effets de meute au niveau de la commande \u00ab accept \u00bb. Important : les tailles des files d'attente dans NGINX et le noyau (somaxconn) doivent <strong>aller ensemble<\/strong>, sinon l'effet sera r\u00e9duit \u00e0 n\u00e9ant.<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # accept_mutex on;   # : g\u00e9n\u00e9ralement inutile avec reuseport\n}\n\nserver {\n    listen 443 ssl http2 reuseport backlog=65535;\n    # ...\n}\n<\/code><\/pre>\n<p>De plus, j'affecte les workers \u00e0 des c\u0153urs de processeur si n\u00e9cessaire (worker_cpu_affinity), afin de garantir la stabilit\u00e9 des lignes de cache et de la charge IRQ. Dans les environnements fortement NUMA, cela r\u00e9duit les <strong>circulation transversale<\/strong> dans la m\u00e9moire.<\/p>\n\n<h2>Proxy inverse, serveurs en amont et Keep-Alive<\/h2>\n<p>En tant que proxy inverse, NGINX maintient souvent deux connexions par requ\u00eate : une vers le client et une vers le backend, ce qui permet une planification r\u00e9aliste des capacit\u00e9s <strong>double<\/strong> compte. J'active Keep-Alive de mani\u00e8re judicieuse afin que les connexions en amont restent r\u00e9utilisables et que la surcharge par requ\u00eate <strong>baisse<\/strong>. Cela me permet de r\u00e9duire la charge sur PHP-FPM, le serveur d'applications ou les microservices et de lib\u00e9rer des slots pour de nouvelles sessions utilisateur. L'\u00e9quilibre entre les d\u00e9lais d'expiration, la dur\u00e9e d'inactivit\u00e9 et la r\u00e9utilisation d\u00e9termine la mani\u00e8re dont les connexions sont recycl\u00e9es <strong>seront<\/strong>. Si vous souhaitez en savoir plus sur les principes de base, vous trouverez dans <a href=\"https:\/\/webhosting.de\/fr\/http-connexions-persistantes-serveur-web-charge-performance-reseau\/\">Connexions persistantes<\/a> conseils pratiques sur l'utilisation des ressources et l'optimisation du r\u00e9seau<strong>Utilisez<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-worker-connections-scalability-2941.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pools en amont, d\u00e9lais d'attente et tentatives de reconnexion<\/h2>\n<p>Pour \u00e9viter que les workers n'aient \u00e0 attendre des backends lents, je g\u00e8re des d\u00e9lais d'expiration courts et des tentatives de reconnexion bien dos\u00e9es. Je maintiens les pools de keepalive en amont \u00e0 une taille suffisante pour que les connexions restent actives, mais pas trop grande pour \u00e9viter que les descripteurs de fichiers inactifs n'occupent de la m\u00e9moire et des slots <strong>lier<\/strong>. Je limite le nombre de tentatives \u00e0 quelques-unes et je ne bascule que en cas d'erreurs de transport manifestes ; cela me permet d'\u00e9viter les effets de \u00ab thundering herd \u00bb en cas de br\u00e8ves interruptions du backend.<\/p>\n<pre><code>upstream app_backend {\n    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;\n    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;\n    keepalive 64 ;  Connexions en amont r\u00e9utilisables #\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout   2s;\n        proxy_read_timeout 15s;\n proxy_send_timeout 15s;\n proxy_next_upstream     error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n    }\n}\n<\/code><\/pre>\n<p>En parall\u00e8le, je r\u00e8gle les param\u00e8tres de Keep-Alive (d\u00e9lais d'expiration, nombre de requ\u00eates par connexion) afin de lib\u00e9rer rapidement les ressources occup\u00e9es par des clients peu actifs <strong>\u00e0 valider<\/strong>.<\/p>\n\n<h2>Planifier judicieusement la mise \u00e0 l'\u00e9chelle : combiner les approches verticale et horizontale<\/h2>\n<p>Pour les volumes de trafic \u00e9lev\u00e9s, je privil\u00e9gie une approche combinant l'\u00e9volutivit\u00e9 verticale et horizontale <strong>Consid\u00e9rer<\/strong>. Je proc\u00e8de \u00e0 une \u00e9volutivit\u00e9 verticale en augmentant le nombre de c\u0153urs de processeur, la m\u00e9moire vive, en utilisant des SSD rapides et en optimisant la configuration r\u00e9seau, afin que chaque worker fonctionne de mani\u00e8re fluide <strong>travaille<\/strong>. Pour l'\u00e9volutivit\u00e9 horizontale, j'utilise des n\u0153uds NGINX sans \u00e9tat, une configuration g\u00e9r\u00e9e de mani\u00e8re centralis\u00e9e et une journalisation distribu\u00e9e, afin que la capacit\u00e9 totale augmente de mani\u00e8re lin\u00e9aire <strong>grandit<\/strong>. Les caches sur site et les politiques bien d\u00e9finies via Maps ou l'API permettent de d\u00e9ployer rapidement les modifications. Cette s\u00e9paration r\u00e9duit les effets secondaires et aide \u00e0 g\u00e9rer de nouveaux mod\u00e8les de trafic sans avoir \u00e0 modifier chaque n\u0153ud. <strong>servir<\/strong>.<\/p>\n\n<h2>Point de vue de l'h\u00e9bergement : latence, taux d'erreur et exp\u00e9rience utilisateur<\/h2>\n<p>Un nombre insuffisant de `worker_connections` entra\u00eene des connexions refus\u00e9es, des d\u00e9lais d'attente et une baisse des performances <strong>Exp\u00e9rience utilisateur<\/strong>. Les applications dynamiques telles que les CMS ou les boutiques en ligne en ressentent imm\u00e9diatement les effets, car l'affichage d'une page g\u00e9n\u00e8re plusieurs requ\u00eates vers le backend et les slots sont satur\u00e9s plus rapidement <strong>\u00e0 peine<\/strong> . C'est pourquoi je commence par des valeurs mod\u00e9r\u00e9es, telles que 1024 ou 2048 par worker, puis je les augmente progressivement en fonction des mesures r\u00e9elles. En parall\u00e8le, je veille \u00e0 ce que les services en amont restent performants et je m'assure qu'il y ait suffisamment de descripteurs de fichiers pour \u00e9viter tout <strong>Limites<\/strong> intervenir. Les tests de performance montrent que des plateformes soigneusement optimis\u00e9es offrent ici de r\u00e9els avantages et permettent de g\u00e9rer de mani\u00e8re fiable les pics de trafic <strong>intercepter<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_connections_performance_2394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e9moire, mise en m\u00e9moire tampon et chemins d'E\/S<\/h2>\n<p>Chaque connexion occupe de la m\u00e9moire vive pour les m\u00e9tadonn\u00e9es et les tampons. Je dimensionne les param\u00e8tres `proxy_buffers`, `client_body_buffer_size` et `large_client_header_buffers` de mani\u00e8re \u00e0 ce que les requ\u00eates typiques puissent y tenir, sans pour autant allouer syst\u00e9matiquement trop de RAM en cas de valeurs aberrantes. <strong>lier<\/strong>. Pour les contenus statiques, les options `sendfile` et `tcp_nopush` acc\u00e9l\u00e8rent la diffusion, tandis que l'option `tcp_nodelay` est utilis\u00e9e pour les petites r\u00e9ponses o\u00f9 la latence est un facteur critique <strong>important<\/strong> reste. Si les ressources sont stock\u00e9es sur un support de stockage plus lent, les options `aio threads` et `thread_pool` permettent d'att\u00e9nuer les effets de blocage. Avec `open_file_cache`, je r\u00e9duis les acc\u00e8s aux fichiers et les appels \u00e0 `stat()`, mais je tiens compte des besoins suppl\u00e9mentaires en descripteurs de fichiers (FD). J'enregistre les journaux en mode tamponn\u00e9 (access_log \u2026 buffer=\u2026 flush=\u2026), afin que les pics d'E\/S n'affectent pas les temps de r\u00e9ponse <strong>influencer<\/strong>.<\/p>\n\n<h2>\u00c9quilibre entre s\u00e9curit\u00e9 et performances TLS<\/h2>\n<p>Les protocoles TLS sollicitent fortement le processeur. Je combine la r\u00e9utilisation des sessions avec des param\u00e8tres de cl\u00e9 mod\u00e9r\u00e9s et j'active les optimisations cumulables telles que les caches de session et les tickets, dans la mesure o\u00f9 cela est compatible avec l'exploitation <strong>correspondent \u00e0<\/strong>. Le juste \u00e9quilibre entre s\u00e9curit\u00e9 et performances permet de maintenir des latences stables sans compromettre la qualit\u00e9 du chiffrement. En cas de charge \u00e9lev\u00e9e, j'observe s\u00e9par\u00e9ment les 95e et 99e centiles, car sinon les pics TLS passeraient inaper\u00e7us derri\u00e8re les valeurs moyennes <strong>cacher<\/strong>. HTTP\/2 r\u00e9duit le nombre de connexions, mais n\u00e9cessite une attention particuli\u00e8re en mati\u00e8re de contr\u00f4le de flux et de compression des en-t\u00eates afin de ma\u00eetriser les profils de CPU et de m\u00e9moire <strong>conserver<\/strong>.<\/p>\n\n<h2>La r\u00e9silience en situation de surcharge : limites et l\u00e2cher-prise en douceur<\/h2>\n<p>Afin de pr\u00e9server la latence, il convient de proc\u00e9der \u00e0 un <strong>modelage<\/strong> indispensable en cas de pic de charge. Avec `limit_conn`, je limite le nombre de connexions parall\u00e8les par cl\u00e9 (par exemple, une adresse IP ou une session) ; `limit_req` r\u00e9gule les pics de charge et prot\u00e8ge les backends contre les requ\u00eates synchrones <strong>Prendre d'assaut<\/strong>. J'applique des r\u00e8gles plus strictes aux points de terminaison critiques qu'aux ressources statiques. En cas de pic de trafic soudain, je renvoie des codes d'erreur 429\/503 bien d\u00e9finis avec un d\u00e9lai de r\u00e9essai (\u00ab Retry-After \u00bb), plut\u00f4t que de traiter toutes les requ\u00eates de mani\u00e8re uniforme <strong>mourir de faim<\/strong> Je suspends les connexions persistantes (lingering_close) afin de lib\u00e9rer les ressources de mani\u00e8re contr\u00f4l\u00e9e et d'\u00e9viter les attaques de type Slowloris. <strong>r\u00e9futer<\/strong>. Ce \u00ab sheddage \u00bb actif maintient la latence p95\/p99 dans la zone verte, m\u00eame lorsque la demande totale d\u00e9passe temporairement la capacit\u00e9 nominale <strong>se trouve<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/hosting-performance-9047.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Int\u00e9gration de conteneurs et de syst\u00e8mes : lever les limites l\u00e0 o\u00f9 elles apparaissent<\/h2>\n<p>Dans les conteneurs, les limites sont souvent plus strictes. Je v\u00e9rifie les limites cgroup (CPU, RAM), je configure ulimit -n de mani\u00e8re appropri\u00e9e au sein du conteneur et j'int\u00e8gre LimitNOFILE dans la d\u00e9finition du service. Les param\u00e8tres sysctl tels que somaxconn et tcp_max_syn_backlog doivent \u00eatre d\u00e9finis sur le <strong>H\u00f4te<\/strong> prennent effet ; les espaces de noms n'isolent pas toujours ces param\u00e8tres de mani\u00e8re transparente. Sur les plateformes orchestr\u00e9es, je planifie la capacit\u00e9 par pod\/n\u0153ud, j'affecte les workers aux c\u0153urs qui leur sont attribu\u00e9s et je veille \u00e0 ce que les chemins r\u00e9seau soient stables (par exemple, pas de sauts NAT inutiles), afin que la courbe de latence <strong>calme<\/strong> reste. J'accompagne les mises \u00e0 jour progressives avec `worker_shutdown_timeout` afin que les connexions existantes soient ferm\u00e9es correctement <strong>s'\u00e9teindre<\/strong>.<\/p>\n\n<h2>Suivi et optimisation it\u00e9rative<\/h2>\n<p>Sans visibilit\u00e9, les \u00e9tapes de mise au point restent <strong>Risque<\/strong>. J'active stub_status ou d'autres solutions pour surveiller en continu les connexions actives, les taux d'acceptation et les rejets. Lors des tests de charge, je simule des mod\u00e8les d'acc\u00e8s r\u00e9alistes et j'identifie les goulots d'\u00e9tranglement au niveau des files d'attente d'acceptation, des latences en amont ou du CPU-<strong>Saturation<\/strong>. Ensuite, j'ajuste avec pr\u00e9caution les param\u00e8tres `worker_connections`, les processus, les limites de fichiers et les param\u00e8tres TCP, puis je v\u00e9rifie \u00e0 nouveau l'effet obtenu. Ce cycle garantit la fiabilit\u00e9 de la plateforme et \u00e9vite les mauvaises surprises <strong>Temps<\/strong>.<\/p>\n\n<h2>Exemple de configuration et m\u00e9thode de calcul<\/h2>\n<p>Supposons que je pr\u00e9voie 2 000 requ\u00eates \u00ab in-flight \u00bb simultan\u00e9es aux heures de pointe et que j'utilise un proxy inverse ; dans ce cas, je pr\u00e9vois environ 4 000 slots de connexion, plus <strong>Tampon<\/strong>. Lorsque NGINX fonctionne sur quatre c\u0153urs de processeur, je commence par exemple avec `worker_processes auto` et `worker_connections` compris entre 1 000 et 2 000 par worker. Je d\u00e9finis la limite de descripteurs de fichiers par worker \u00e0 une valeur suffisamment \u00e9lev\u00e9e pour que les connexions, les journaux et les sockets internes disposent de suffisamment de <strong>Place<\/strong> . Je configure le bloc \u00ab Events \u00bb en mode epoll, j'active multi_accept et j'augmente les backlogs du noyau en fonction de mon trafic de pointe. En voici un extrait minimaliste, que j'affine ensuite \u00e0 l'aide de benchmarks <strong>vote<\/strong>:<\/p>\n<pre><code>worker_processes  auto;\nworker_rlimit_nofile  65535;\n\nevents {\n    use epoll;\n    worker_connections  2048;\n    multi_accept on;\n}\n\nhttp {\n    keepalive_timeout   65;\n    sendfile on;\n    # autres options de proxy\/cache...\n}\n<\/code><\/pre>\n<p>De plus, j'ajoute des optimisations au niveau des listes et en amont afin d'optimiser le chemin de r\u00e9ception et le chemin backend sous charge :<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # worker_cpu_affinity auto;  # : attribuer des c\u0153urs de mani\u00e8re fixe si n\u00e9cessaire\n}\n\nhttp {\n    # Optimisations TLS\/session \u00e0 titre d'exemple\n    ssl_session_cache    shared:SSL:50m;\n    ssl_session_timeout  1h;\n\n upstream app_backend {\n server 10.0.0.11:8080;\n server 10.0.0.12:8080;\n keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2 reuseport backlog=65535;\n\n location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout     2s;\n            proxy_read_timeout 15s;\n proxy_next_upstream error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n }\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/developer_desk_nginx_5823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En r\u00e9sum\u00e9 : des rep\u00e8res concrets<\/h2>\n<p>J'adapte le param\u00e8tre `worker_processes` au nombre de c\u0153urs du processeur et je d\u00e9finis g\u00e9n\u00e9ralement le param\u00e8tre `worker_connections` entre 1024 et <strong>4096<\/strong>. Avec le proxy inverse, je pr\u00e9vois deux connexions par requ\u00eate et je conserve une marge d'au moins le double du pic mesur\u00e9<strong>Dernier<\/strong>. Je d\u00e9finis worker_rlimit_nofile ainsi que les limites syst\u00e8me \u00e0 des valeurs suffisamment \u00e9lev\u00e9es pour que les param\u00e8tres du fichier nginx.conf restent r\u00e9ellement exploitables. Je limite le bloc Events \u00e0 epoll et multi_accept, tandis que les backlogs du noyau permettent de g\u00e9rer de br\u00e8ves pics de trafic <strong>amortir<\/strong>. Gr\u00e2ce \u00e0 un suivi et \u00e0 des ajustements progressifs, j'en fais un moteur de trafic fiable, capable de g\u00e9rer proprement l'augmentation du nombre de visites <strong>porte<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>D\u00e9couvrez comment configurer correctement les connexions des workers nginx afin de faire \u00e9voluer NGINX en toute s\u00e9curit\u00e9 et d'optimiser les performances d'h\u00e9bergement lorsque le nombre de requ\u00eates s'\u00e9l\u00e8ve \u00e0 plusieurs milliers.<\/p>","protected":false},"author":1,"featured_media":20715,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20722","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"128","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"nginx worker","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20715","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20722","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20722"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20722\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20715"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20722"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}