{"id":20714,"date":"2026-08-16T18:19:23","date_gmt":"2026-08-16T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/"},"modified":"2026-08-16T18:19:23","modified_gmt":"2026-08-16T16:19:23","slug":"configurer-de-maniere-optimale-les-processus-de-travail-nginx-pour-ameliorer-les-performances","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/","title":{"rendered":"Configurer de mani\u00e8re optimale les processus de travail NGINX pour des performances maximales"},"content":{"rendered":"<p>Je configure <strong>NGINX Worker<\/strong> de mani\u00e8re \u00e0 ce que les param\u00e8tres `worker_processes`, `worker_connections` et `worker_rlimit_nofile` soient parfaitement align\u00e9s et qu'Epoll fonctionne dans la boucle d'\u00e9v\u00e9nements. Je peux ainsi utiliser <strong>Noyaux du CPU<\/strong> Assure une efficacit\u00e9 optimale, permette de pr\u00e9voir l'\u00e9volutivit\u00e9 des connexions simultan\u00e9es et maintient les latences \u00e0 un faible niveau lors des pics de charge.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Les points cl\u00e9s suivants te fournissent des indications imm\u00e9diates pour mettre en place une configuration robuste des workers NGINX.<\/p>\n<ul>\n  <li><strong>worker_processes<\/strong> le lier au nombre de c\u0153urs logiques, de pr\u00e9f\u00e9rence avec \u201e auto \u201c.<\/li>\n  <li><strong>worker_connections<\/strong> les r\u00e9gler de mani\u00e8re \u00e0 couvrir largement les pics r\u00e9els.<\/li>\n  <li><strong>rlimit_nofile<\/strong> et augmenter les limites du syst\u00e8me d'exploitation en fonction du d\u00e9bit de connexion.<\/li>\n  <li><strong>epoll<\/strong> et activer multi_accept afin d'exploiter efficacement la boucle d'\u00e9v\u00e9nements.<\/li>\n  <li><strong>Tests de charge<\/strong> avancer et affiner progressivement, par petites \u00e9tapes.<\/li>\n<\/ul>\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-optimierung-serverraum-5961.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Architecture NGINX : comprendre les n\u0153uds ma\u00eetres et les n\u0153uds de travail<\/h2>\n<p>Je s\u00e9pare les t\u00e2ches de <strong>Master<\/strong> et les workers : le ma\u00eetre charge les configurations, ouvre les sockets et lance les processus, tandis que les workers traitent les requ\u00eates dans la boucle d'\u00e9v\u00e9nements. Chaque worker fonctionne de mani\u00e8re autonome, r\u00e9agit aux \u00e9v\u00e9nements et peut g\u00e9rer des milliers de connexions sans provoquer de blocages. Ce mod\u00e8le est particuli\u00e8rement efficace lorsque j\u2019utilise les c\u0153urs de processeur de mani\u00e8re optimale et que j\u2019exploite au mieux la boucle d\u2019\u00e9v\u00e9nements via epoll. Je tiens compte du fait que chaque saut de proxy suppl\u00e9mentaire mobilise des ressources de connexion, ce qui se r\u00e9percute sur les limites. Comprendre ces r\u00f4les permet de prendre des d\u00e9cisions \u00e9clair\u00e9es concernant <strong>Ressources<\/strong> et permet d'\u00e9viter les goulots d'\u00e9tranglement \u00e0 un stade pr\u00e9coce.<\/p>\n\n<h2>Bien articuler les trois directives cl\u00e9s<\/h2>\n<p>Je consid\u00e8re <strong>worker_processes<\/strong>, worker_connections et worker_rlimit_nofile ne doivent jamais \u00eatre r\u00e9gl\u00e9s isol\u00e9ment, mais toujours ensemble. Le nombre total de connexions possibles correspond au nombre de workers multipli\u00e9 par le nombre de connexions par worker ; c'est \u00e0 partir de l\u00e0 que je d\u00e9termine les limites pour les descripteurs de fichiers. Si ces param\u00e8tres ne sont pas harmonis\u00e9s, je me heurte \u00e0 des erreurs du type \u201e too many open files \u201c ou \u00e0 des d\u00e9lais d\u2019attente trop longs. En cas de charge \u00e9lev\u00e9e, j\u2019ai besoin d\u2019une cha\u00eene coh\u00e9rente : un nombre suffisant de processus, un nombre g\u00e9n\u00e9reux de connexions, une valeur rlimit_nofile correctement augment\u00e9e et des param\u00e8tres du syst\u00e8me d\u2019exploitation adapt\u00e9s. C\u2019est ainsi que j\u2019\u00e9vite qu\u2019un <strong>Limite<\/strong> a r\u00e9duit la capacit\u00e9 totale.<\/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_meeting_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>worker_processes : choisir le nombre de mani\u00e8re cibl\u00e9e<\/h2>\n<p>Je mets <strong>worker_processes<\/strong> En r\u00e8gle g\u00e9n\u00e9rale, on le r\u00e8gle sur \u201e auto \u201c afin que NGINX d\u00e9tecte le nombre de c\u0153urs logiques du processeur et puisse utiliser chaque c\u0153ur. Un worker par c\u0153ur \u00e9vite les changements de contexte inutiles et r\u00e9partit la charge de mani\u00e8re optimale, ce qui permet de pr\u00e9voir le temps de r\u00e9ponse. Sur les machines dot\u00e9es d\u2019un tr\u00e8s grand nombre de c\u0153urs, je teste d\u00e9lib\u00e9r\u00e9ment des nombres de workers plus faibles afin de comparer les coups de cache et l\u2019utilisation des c\u0153urs. Si les m\u00e9triques indiquent que les c\u0153urs sont surcharg\u00e9s ou que les \u00e9checs TLB augmentent, j\u2019ajuste progressivement le nombre de workers. Mesurer d\u2019abord, modifier ensuite : c\u2019est ainsi que je m\u2019assure d\u2019obtenir des r\u00e9sultats fiables. <strong>R\u00e9sultats<\/strong>.<\/p>\n\n<h2>worker_connections : augmenter les connexions de mani\u00e8re planifi\u00e9e<\/h2>\n<p>Je choisis la <strong>worker_connections<\/strong> en fonction du trafic cible et de la composition des protocoles, souvent \u00e0 partir de 2048 ou 4096. Pour les API tr\u00e8s sollicit\u00e9es, j'envisage 8192, \u00e0 condition que les limites du syst\u00e8me d'exploitation et la m\u00e9moire vive le permettent. Je v\u00e9rifie chaque augmentation \u00e0 l\u2019aide de tests de charge, car les connexions ouvertes mobilisent de la m\u00e9moire et influencent le comportement en amont. Lorsque les handshakes SSL ou les transferts en upload volumineux pr\u00e9dominent, je m\u2019appuie davantage sur les profils CPU et E\/S, et pas uniquement sur les chiffres bruts de connexions. Je m\u2019assure ainsi que le nombre d\u00e9fini par worker <strong>Capacit\u00e9<\/strong> reste \u00e9galement utilisable dans la pratique.<\/p>\n\n<h2>Synchroniser worker_rlimit_nofile et les limites du syst\u00e8me d'exploitation<\/h2>\n<p>Je veille \u00e0 ce que <strong>rlimit_nofile<\/strong> couvre au moins la capacit\u00e9 totale th\u00e9orique et est souvent configur\u00e9 avec une marge de s\u00e9curit\u00e9. Pour les sc\u00e9narios de proxy inverse, je pr\u00e9vois un deuxi\u00e8me descripteur vers l'amont pour chaque connexion client. En cons\u00e9quence, je r\u00e8gle volontiers rlimit_nofile \u00e0 une valeur deux fois sup\u00e9rieure au nombre de connexions simultan\u00e9es attendues. J'augmente les limites du noyau et de l'utilisateur (ulimit -n, fs.file-max) de mani\u00e8re \u00e0 ce que NGINX puisse r\u00e9ellement exploiter ces valeurs. Si des messages concernant des fichiers ouverts apparaissent dans le journal des erreurs, j'augmente rapidement ces limites et surveille la <strong>Latence<\/strong> \u00e0 nouveau sous charge.<\/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-performance-optimization-5123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bloc \u00ab \u00c9v\u00e9nements \u00bb : utiliser efficacement epoll et multi_accept<\/h2>\n<p>J'active dans le bloc \u00ab \u00c9v\u00e9nements \u00bb <strong>epoll<\/strong> et je r\u00e8gle multi_accept sur \u201e on \u201c afin que les workers acceptent les connexions en attente en une seule fois. Epoll r\u00e9duit la surcharge en cas de nombreux sockets simultan\u00e9s et s'accorde parfaitement avec la conception non bloquante de NGINX. Ces options s\u2019av\u00e8rent particuli\u00e8rement utiles lors des pics de trafic, car elles acc\u00e9l\u00e8rent la phase d\u2019acceptation et permettent de passer plus rapidement au traitement proprement dit. Sous Linux, c\u2019est ma configuration par d\u00e9faut, que je ne modifie que dans de rares cas particuliers. Si vous souhaitez approfondir le sujet, comparez le mod\u00e8le de boucle d\u2019\u00e9v\u00e9nements avec <a href=\"https:\/\/webhosting.de\/fr\/threadpool-serveur-web-apache-nginx-litespeed-optimisation-configuration\/\">Pool de threads vs. boucle d'\u00e9v\u00e9nements<\/a> et en tire la conclusion suivante : <strong>conclusions<\/strong> pour son propre environnement.<\/p>\n\n<h2>Affinit\u00e9 CPU : attribuer les workers \u00e0 des c\u0153urs<\/h2>\n<p>Je mets <strong>affinit\u00e9_cpu_des_t\u00e2ches<\/strong> de mani\u00e8re cibl\u00e9e lorsque les charges de travail sont constantes et d\u00e9pendantes du processeur. Je r\u00e9partis le sch\u00e9ma d'affectation \u00e0 l'aide de masques de bits afin d'\u00e9viter les changements de contexte et de favoriser la localit\u00e9 du cache. Avec quatre c\u0153urs, j\u2019attribue les masques de mani\u00e8re \u00e0 ce que chaque worker dispose de son propre c\u0153ur. Je v\u00e9rifie ensuite les taux de manques de cache, les latences m\u00e9dianes et les 99e centiles afin d\u2019observer clairement l\u2019effet. Vous trouverez des explications plus d\u00e9taill\u00e9es sur l\u2019affinit\u00e9 et le NUMA sous forme concise sur <a href=\"https:\/\/webhosting.de\/fr\/processus-serveur-affinity-numa-awareness-hosting-ressourcentuning\/\">L'affinit\u00e9 CPU en pratique<\/a>, ce qui, lors du r\u00e9glage fin de <strong>Travailleur<\/strong>- les mises en page.<\/p>\n\n<h2>Planification de la capacit\u00e9 : marge de s\u00e9curit\u00e9 et tests de charge<\/h2>\n<p>Pour les liaisons, je pr\u00e9vois un <strong>Tampon<\/strong> qui soit nettement sup\u00e9rieur aux pics observ\u00e9s, afin que les pics de trafic de courte dur\u00e9e ne d\u00e9passent pas directement les limites. Si je double la charge de pointe comme point de d\u00e9part, je dispose d'une marge de man\u0153uvre solide dans de nombreux sc\u00e9narios. En cas de trafic tr\u00e8s fluctuant, j\u2019\u00e9tends encore la marge de s\u00e9curit\u00e9 jusqu\u2019\u00e0 ce que les 99e centiles s\u2019affichent correctement. Ensuite, je v\u00e9rifie les goulots d\u2019\u00e9tranglement \u00e0 l\u2019aide d\u2019outils tels que wrk ou k6, je surveille les taux d\u2019erreur et j\u2019examine les connexions ouvertes dans l\u2019\u00e9tat. Ce n\u2019est que lorsque les m\u00e9triques sont coh\u00e9rentes que j\u2019augmente ou que je r\u00e9duis de mani\u00e8re cibl\u00e9e certaines <strong>Valeurs<\/strong>.<\/p>\n\n<h2>Configuration et exemples de calcul<\/h2>\n<p>Je calcule la capacit\u00e9 de connexion en multipliant le nombre de workers par le nombre de connexions par worker, puis je fixe des limites sup\u00e9rieures en fonction de ce r\u00e9sultat. Avec quatre c\u0153urs de processeur, le param\u00e8tre \u00ab auto \u00bb et 4 096 connexions par worker, j'obtiens th\u00e9oriquement 16 384 connexions simultan\u00e9es. Dans les sc\u00e9narios de proxy, je r\u00e8gle plut\u00f4t rlimit_nofile \u00e0 32 768 ou plus, afin d\u2019inclure les sockets en amont. Pour les petites machines \u00e0 deux c\u0153urs, 2 048 connexions par worker suffisent souvent, \u00e0 condition que la part des transferts en upload et des connexions TLS reste mod\u00e9r\u00e9e. Le tableau suivant aide \u00e0 classer les <strong>valeurs initiales<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Noyaux du CPU<\/th>\n      <th>worker_processes<\/th>\n      <th>worker_connections (D\u00e9but)<\/th>\n      <th>Valeur minimale de rlimit_nofile (valeur indicative)<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>2<\/td>\n      <td>auto (\u22482)<\/td>\n      <td>2048<\/td>\n      <td>\u2265 4 096<\/td>\n      <td><strong>R\u00e9serve<\/strong> Pr\u00e9voir pour TLS\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td>4<\/td>\n      <td>auto (\u22484)<\/td>\n      <td>4096<\/td>\n      <td>\u2265 16 384<\/td>\n      <td>Avec un proxy, on observe souvent un facteur 2 pour les FD<\/td>\n    <\/tr>\n    <tr>\n      <td>8<\/td>\n      <td>auto (\u22488)<\/td>\n      <td>4096-8192<\/td>\n      <td>\u2265 32 768<\/td>\n      <td><strong>Test de charge<\/strong> d\u00e9cide d'une augmentation<\/td>\n    <\/tr>\n    <tr>\n      <td>16+<\/td>\n      <td>voiture, voire moins<\/td>\n      <td>8192+<\/td>\n      <td>\u2265 65 535<\/td>\n      <td>Tester avec sensibilit\u00e9 et r\u00e9serve<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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_performance_opt_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Workers NGINX et sources en amont : bien pond\u00e9rer les sc\u00e9narios<\/h2>\n<p>Je fais la distinction entre la diffusion statique, le fonctionnement en proxy inverse et la charge de la passerelle API, car ils constituent les <strong>Travailleur<\/strong>- La configuration peut varier en fonction des besoins. Les contenus statiques mobilisent moins de ressources, tandis que le protocole TLS, la compression et les connexions en amont sollicitent davantage le processeur et les descripteurs de fichiers (FD). Plus les cl\u00e9s SSL sont volumineuses et plus il y a de \u201e handshakes \u201c, plus le param\u00e8tre \u00ab un worker par c\u0153ur \u00bb s\u2019av\u00e8re avantageux. Les transferts volumineux font pencher la balance vers les E\/S, ce qui m\u2019am\u00e8ne \u00e0 me concentrer davantage sur rlimit_nofile et les tampons r\u00e9seau. En cas de temps d\u2019attente perceptibles lors de l\u2019acceptation ou des r\u00e9ponses du backend, la vue d\u2019ensemble m\u2019aide \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/serveur-web-file-dattente-latence-traitement-des-requetes-file-dattente-du-serveur\/\">Files d'attente et latence<\/a>, afin d'\u00e9viter les goulots d'\u00e9tranglement <strong>cibl\u00e9<\/strong> \u00e0 r\u00e9soudre.<\/p>\n\n<h2>Flux de travail pratique : \u00e9tape par \u00e9tape vers un serveur plus rapide<\/h2>\n<p>Je commence par dresser un \u00e9tat des lieux de tous les \u00e9l\u00e9ments pertinents <strong>Valeurs<\/strong> Dans le fichier nginx.conf, je v\u00e9rifie les c\u0153urs de processeur, les valeurs ulimit et les param\u00e8tres du noyau. Ensuite, je r\u00e8gle worker_processes sur \u00ab auto \u00bb, je d\u00e9finis worker_connections sur 4096, par exemple, et j'augmente g\u00e9n\u00e9reusement la valeur de rlimit_nofile. Dans le bloc Events, j'active epoll ainsi que multi_accept, puis je v\u00e9rifie les journaux \u00e0 l'aide d'un rechargement. Je proc\u00e8de ensuite \u00e0 des tests de charge dans des conditions reproductibles, au cours desquels j'observe les temps de r\u00e9ponse, les taux d'erreur et les connexions ouvertes. Lors de l'ajustement fin, je ne modifie toujours qu'une seule variable, je documente chaque \u00e9tape et j'\u00e9value les effets dans les <strong>M\u00e9triques<\/strong>.<\/p>\n\n<h2>Environnement d'h\u00e9bergement : ressources, noyau, r\u00e9seau<\/h2>\n<p>Je veille \u00e0 ce qu'il y en ait suffisamment <strong>CPU<\/strong>- des c\u0153urs, suffisamment de m\u00e9moire vive, des SSD ou NVMe rapides et un noyau Linux r\u00e9cent. C'est la seule fa\u00e7on de garantir le fonctionnement fiable d'epoll, des piles TCP modernes et des fonctionnalit\u00e9s d'offload pertinentes. J'adapte les param\u00e8tres r\u00e9seau tels que `somaxconn` et `tcp_max_syn_backlog` au nombre cible de connexions afin de limiter la longueur des files d'attente d'acceptation. Un fournisseur offrant des performances d\u2019E\/S robustes et une configuration syst\u00e8me librement accessible s\u2019av\u00e8re clairement avantageux dans ce contexte. Des comparaisons montrent que les services avec des <strong>Ressources<\/strong> Augmenter consid\u00e9rablement les marges de man\u0153uvre de NGINX.<\/p>\n\n<h2>Strat\u00e9gie de maintien de connexion : connexions client et en amont<\/h2>\n<p>J'utilise d\u00e9lib\u00e9r\u00e9ment Keepalive comme levier pour optimiser la capacit\u00e9 et r\u00e9duire la latence. C\u00f4t\u00e9 client, je configure <strong>keepalive_timeout<\/strong> pas trop \u00e9lev\u00e9, afin que les sockets inactives ne soient pas inutilement <em>worker_connections<\/em> bloquer. Des valeurs comprises entre 10 et 30 s constituent souvent pour moi un bon compromis entre r\u00e9utilisation et mobilisation des ressources. Avec <strong>keepalive_requests<\/strong> Je limite le nombre de requ\u00eates par connexion afin de couper les sessions de longue dur\u00e9e et d'\u00e9viter la pression sur la m\u00e9moire. C\u00f4t\u00e9 amont (proxy inverse), je maintiens des connexions persistantes avec <strong>keepalive<\/strong> dans le bloc \u00ab upstream \u00bb, ce qui permet d'\u00e9viter les handshakes et la configuration TCP. Pour cela, je dimensionne le nombre par backend de mani\u00e8re prudente en fonction de la capacit\u00e9 du backend (<em>max_conns<\/em>), sinon je g\u00e8re moi-m\u00eame les files d'attente c\u00f4t\u00e9 amont. Important : chaque socket Keepalive compte comme une connexion ouverte et n\u00e9cessite des descripteurs de fichier (FD) ; j'en tiens compte dans <em>rlimit_nofile<\/em> et ma planification de la marge dynamique.<\/p>\n\n<h2>Optimisation des listes : reuseport, backlog et strat\u00e9gie d'acceptation<\/h2>\n<p>Je r\u00e9partis la charge de r\u00e9ception de mani\u00e8re uniforme en <strong>SO_REUSEPORT<\/strong> activer (listen \u2026 reuseport). Chaque worker dispose ainsi de sa propre file d'attente d'acceptation, ce qui r\u00e9duit les \u201e thundering herds \u201c et \u00e9vite les goulots d'\u00e9tranglement. En combinaison avec <strong>multi_accept<\/strong> j'acc\u00e9l\u00e8re sensiblement la phase d'acceptation. Les listes-<strong>backlog<\/strong> (listen \u2026 backlog=) et les param\u00e8tres correspondants du noyau (somaxconn, tcp_max_syn_backlog), je les d\u00e9finis de mani\u00e8re g\u00e9n\u00e9reuse afin que les pics de trafic ne soient pas perdus au niveau de l'entr\u00e9e du socket. L'option <strong>report\u00e9<\/strong> reporte la r\u00e9ponse \u00ab Accept \u00bb jusqu'\u00e0 ce que les donn\u00e9es soient disponibles \u2013 cela peut s'av\u00e9rer utile en cas de nombreuses requ\u00eates \u00e9ph\u00e9m\u00e8res ; sinon, je compare les r\u00e9sultats lors des tests. Je me demande si je <strong>accept_mutex<\/strong> Je d\u00e9termine ce dont j'ai besoin \u00e0 l'aide d'un benchmark : avec reuseport, il est g\u00e9n\u00e9ralement superflu ; sans reuseport, il peut am\u00e9liorer l'\u00e9quit\u00e9, mais n\u00e9cessite une certaine coordination. Je prends ici une d\u00e9cision fond\u00e9e sur les donn\u00e9es, jamais sur une intuition.<\/p>\n\n<h2>Configurer les d\u00e9lais d'expiration et les files d'attente de mani\u00e8re stable<\/h2>\n<p>Je mets <strong>Timeouts<\/strong> de mani\u00e8re \u00e0 ce que les clients lents n'engorgent pas les workers : <em>client_header_timeout<\/em> et <em>client_body_timeout<\/em> Je le garde suffisamment concis pour \u00e9viter les blocages, mais suffisamment d\u00e9taill\u00e9 pour les utilisateurs r\u00e9els. <em>send_timeout<\/em> emp\u00eache que les r\u00e9ponses ne soient bloqu\u00e9es vers le client. Dans le contexte du proxy, je d\u00e9finis <em>proxy_connect_timeout<\/em>, <em>proxy_read_timeout<\/em> et <em>proxy_send_timeout<\/em> rigoureux, afin que les backends bloqu\u00e9s ne paralysent pas le frontend. Pour les backends dont le parall\u00e9lisme est limit\u00e9, j'utilise <strong>file d'attente<\/strong> dans le bloc \u00ab upstream \u00bb avec un d\u00e9lai d'expiration, afin d'amortir les pics de trafic et de signaler les erreurs 503 de mani\u00e8re contr\u00f4l\u00e9e, au lieu de lier tous les workers aux sockets en amont en attente. De plus, je stabilise le syst\u00e8me avec <strong>limit_req<\/strong> (Burst\/Delay) et <strong>limit_conn<\/strong> des chemins sensibles, afin d'\u00e9viter que certains clients ou robots ne mobilisent de mani\u00e8re disproportionn\u00e9e les ressources.<\/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_performance_8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mise en m\u00e9moire tampon, sendfile et AIO : choisir judicieusement les m\u00e9thodes d'E\/S<\/h2>\n<p>Je mets <strong>sendfile<\/strong> pour les fichiers statiques et combine-le avec <em>tcp_nopush<\/em>\/<em>tcp_nodelay<\/em> en fonction de la charge de travail, afin de regrouper efficacement les paquets ou de r\u00e9duire les latences interactives. Pour les fichiers volumineux, j'utilise <strong>directio<\/strong> \u00e0 partir d'un certain seuil, afin d'\u00e9viter la pollution du cache et que le cache de page ne soit pas \u00e9vinc\u00e9. En mode proxy, c'est moi qui d\u00e9cide si <strong>proxy_buffering<\/strong> est utile (transfert rapide vers le client, lecture en amont d\u00e9coupl\u00e9e) ou si, en cas de charges de streaming, je pr\u00e9f\u00e8re <em>proxy_request_buffering<\/em> r\u00e9duire, afin de lancer les t\u00e9l\u00e9chargements d\u00e8s que possible. Les tailles des <em>proxy_buffers<\/em>, <em>proxy_buffer_size<\/em> et <em>tampons d'en-t\u00eate de client volumineux<\/em> Je le g\u00e8re de mani\u00e8re cibl\u00e9e afin d'\u00e9viter que la consommation de m\u00e9moire par connexion n'explose. Pour des acc\u00e8s aux fichiers qui sollicitent moins le processeur, j'envisage <strong>aio<\/strong> (natif ou threads), mais effectuez des tests approfondis, car les caract\u00e9ristiques de la boucle d'\u00e9v\u00e9nements et celles des E\/S s'influencent mutuellement.<\/p>\n\n<h2>HTTP\/2, HTTP\/3 et TLS : impact sur la capacit\u00e9 des workers<\/h2>\n<p>Je tiens compte du fait que <strong>HTTP\/2<\/strong> et <strong>HTTP\/3<\/strong> Modifier la dynamique des connexions : de nombreuses requ\u00eates s'ex\u00e9cutent en tant que <em>flux<\/em> via un nombre r\u00e9duit de connexions TCP ou QUIC. Cela r\u00e9duit le nombre de connexions, mais augmente la charge sur le processeur et les besoins en m\u00e9moire par connexion (multiplexage, compression des en-t\u00eates, TLS\/QUIC). Mon <em>worker_connections<\/em> Je ne l'interpr\u00e8te donc pas aveugl\u00e9ment comme \u201e un nombre \u00e9gal de requ\u00eates \u201c. Je constate <em>flux simultan\u00e9s<\/em> par connexion et par paire <em>keepalive_timeout<\/em> et, le cas \u00e9ch\u00e9ant,. <em>http2_max_concurrent_streams<\/em> . Du c\u00f4t\u00e9 TLS, je tire parti de la reprise de session (tickets\/cache) et de l'OCSP stapling ; cela me permet d'\u00e9viter des handshakes co\u00fbteux et de maintenir des latences faibles. L'inconv\u00e9nient : des keepalives plus longs mobilisent des FD et de la RAM \u2013 je pr\u00e9vois donc <em>rlimit_nofile<\/em> et des quotas de m\u00e9moire assortis de r\u00e9serves r\u00e9alistes. Pour les algorithmes de chiffrement gourmands en ressources CPU, il vaut la peine de tester l'affinit\u00e9 et les acc\u00e9l\u00e9rateurs cryptographiques modernes.<\/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-optimaler-setup-9182.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Observabilit\u00e9 : \u00e9tat, journaux et m\u00e9triques<\/h2>\n<p>J'assure la transparence gr\u00e2ce \u00e0 une approche all\u00e9g\u00e9e <strong>Statut<\/strong>-Endpoint (par exemple, stub_status) pour afficher les connexions actives, les \u00e9tats \u00ab Reading \u00bb, \u00ab Writing \u00bb et \u00ab Waiting \u00bb, ainsi que les requ\u00eates accept\u00e9es. Dans les journaux, je limite le bruit : un format compact <em>log_format<\/em> Les informations relatives \u00e0 l'heure, au statut, aux temps en amont et au nombre d'octets suffisent pour la plupart des analyses. En cas de QPS tr\u00e8s \u00e9lev\u00e9, je d\u00e9sactive le journal d'acc\u00e8s de mani\u00e8re s\u00e9lective (en fonction de l'emplacement) ou je mets les journaux en m\u00e9moire tampon de mani\u00e8re asynchrone afin que les E\/S ne ralentissent pas le syst\u00e8me. Je configure le journal d'erreurs sur <em>warn<\/em> ou <em>erreur<\/em> et ne bascule que bri\u00e8vement vers <em>debug<\/em>. Je corr\u00e8le en permanence les latences (m\u00e9diane\/95e\/99e centile), les connexions ouvertes, les taux d'erreur du backend et la charge CPU par worker ; cela me permet d'ajuster les trois directives cl\u00e9s et de d\u00e9tecter \u00e0 un stade pr\u00e9coce les effets de saturation.<\/p>\n\n<h2>Conteneurs et environnements virtuels : transmettre les limites de mani\u00e8re claire<\/h2>\n<p>Je v\u00e9rifie dans les conteneurs les <strong>cgroup<\/strong>- D\u00e9finissez les limites pour le processeur, la m\u00e9moire vive et les PID, puis harmonisez-les avec les param\u00e8tres NGINX. <em>ulimit -n<\/em> doit \u00eatre suffisamment \u00e9lev\u00e9 au sein du conteneur, sinon mes ajustements de `rlimit_nofile` ne serviront \u00e0 rien. Pour les quotas CPU (par exemple, 2 vCPU), je d\u00e9finis <em>worker_processes<\/em> En cons\u00e9quence, afin que la planification ne provoque pas de congestion artificielle. \u00c0 proximit\u00e9 du r\u00e9seau, je b\u00e9n\u00e9ficie, dans les modes r\u00e9seau \u201e host \u201c, d\u2019une latence de surcharge r\u00e9duite, tandis que les superpositions impliquent des sauts suppl\u00e9mentaires. Sur les h\u00f4tes multi-NUMA, je veille \u00e0 l\u2019affinit\u00e9 et aux sockets de m\u00e9moire afin que les workers ne fonctionnent pas sur plusieurs n\u0153uds. Il en va de m\u00eame pour l\u2019affinit\u00e9 IRQ et RPS\/XPS : si les chemins, de la carte r\u00e9seau \u00e0 l\u2019IRQ jusqu\u2019au c\u0153ur du worker, sont coh\u00e9rents, les pics de latence diminuent de mani\u00e8re mesurable.<\/p>\n\n<h2>Cycle de vie d'une connexion : ports \u00e9ph\u00e9m\u00e8res, TIME_WAIT et r\u00e9serves<\/h2>\n<p>Je pr\u00e9vois suffisamment <strong>ports \u00e9ph\u00e9m\u00e8res<\/strong> (ip_local_port_range) lorsque NGINX agit en tant que client actif vis-\u00e0-vis des serveurs en amont. En cas de d\u00e9bit de connexion tr\u00e8s \u00e9lev\u00e9, j\u2019\u00e9vite une fluctuation excessive des ports gr\u00e2ce \u00e0 la fonctionnalit\u00e9 \u201e Upstream Keepalive \u201c, ce qui r\u00e9duit les piles TIME_WAIT. Je n\u2019utilise les options du noyau relatives \u00e0 la \u00ab r\u00e9utilisation \u00bb qu\u2019avec prudence ; les piles modernes optimisent d\u00e9j\u00e0 beaucoup de choses en interne. Il est plus stable de contr\u00f4ler la dur\u00e9e de vie des connexions \u00e0 l\u2019aide de valeurs de keepalive et de d\u00e9lai d\u2019expiration raisonnables et <em>reuseport<\/em> pour assurer une r\u00e9partition \u00e9quitable. Dans le calcul des capacit\u00e9s, je tiens toujours compte, outre les clients, de l'amont : souvent, ce sont les FD qui constituent le v\u00e9ritable facteur limitant, et non la \u00ab porte d'entr\u00e9e \u00bb.<\/p>\n\n<h2>Rechargements et d\u00e9ploiements fluides, sans interruption<\/h2>\n<p>J'utilise le mod\u00e8le ma\u00eetre\/esclave pour <strong>rechargements en douceur<\/strong>: Le ma\u00eetre charge de nouvelles configurations ; les anciens workers s'arr\u00eatent tandis que les nouveaux prennent le relais en toute transparence. Avec <em>worker_shutdown_timeout<\/em> je laisse aux requ\u00eates le temps de se terminer correctement, sans bloquer les ressources. J'associe les d\u00e9ploiements sans interruption sur l'upstream \u00e0 des contr\u00f4les d'int\u00e9grit\u00e9 et <em>proxy_next_upstream<\/em>-Des r\u00e8gles pour \u00e9viter que certains backends d\u00e9faillants ne fassent grimper la latence globale. Lorsque je modifie la configuration, je ne change toujours qu\u2019un seul param\u00e8tre et je v\u00e9rifie les effets dans les journaux et les m\u00e9triques ; cela me permet d\u2019\u00e9viter les erreurs dues \u00e0 la confusion et de garantir la reproductibilit\u00e9 des performances.<\/p>\n\n<h2>R\u00e9sum\u00e9 succinct<\/h2>\n<p>Je me connecte <strong>worker_processes<\/strong> en fonction du nombre de c\u0153urs (id\u00e9alement \u00ab auto \u00bb), je r\u00e8gle `worker_connections` en fonction de la charge de pointe et j'augmente g\u00e9n\u00e9reusement `rlimit_nofile` ainsi que les limites du syst\u00e8me d'exploitation. Dans le bloc \u00ab Events \u00bb, j'utilise `epoll` et `multi_accept`, je v\u00e9rifie le tout \u00e0 l'aide de tests de charge reproductibles, puis j'ajuste les param\u00e8tres par petites \u00e9tapes. Pour les charges de travail proxy, je pr\u00e9vois des descripteurs suppl\u00e9mentaires et je teste l\u2019affinit\u00e9 CPU lorsque les charges de travail sont constantes. Une pile correctement configur\u00e9e avec un noyau adapt\u00e9, des E\/S rapides et des param\u00e8tres r\u00e9seau pertinents fait toute la diff\u00e9rence. C\u2019est ainsi que j\u2019obtiens <strong>NGINX<\/strong> fiables dans le domaine des performances, ce dont les sites et les API exigeants ont besoin.<\/p>","protected":false},"excerpt":{"rendered":"<p>D\u00e9couvrez comment configurer correctement les processus de travail NGINX et am\u00e9liorer consid\u00e9rablement les performances de votre serveur web gr\u00e2ce \u00e0 un optimisation cibl\u00e9e de NGINX.<\/p>","protected":false},"author":1,"featured_media":20707,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20714","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":"123","_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":"20707","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20714","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=20714"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20714\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20707"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20714"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20714"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20714"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}