{"id":20890,"date":"2026-08-22T11:51:32","date_gmt":"2026-08-22T09:51:32","guid":{"rendered":"https:\/\/webhosting.de\/so-reuseport-linux-webserver-performance-optimierung-core\/"},"modified":"2026-08-22T11:51:32","modified_gmt":"2026-08-22T09:51:32","slug":"reuseport-linux-serveur-web-optimisation-des-performances-coeur","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/so-reuseport-linux-webserver-performance-optimierung-core\/","title":{"rendered":"SO_REUSEPORT sous Linux : des performances accrues pour les serveurs Web"},"content":{"rendered":"<p>Je vais vous montrer comment SO_REUSEPORT acc\u00e9l\u00e8re les serveurs web Linux g\u00e9rant de nombreuses connexions simultan\u00e9es et \u00e9limine les goulots d'\u00e9tranglement au niveau du <strong>Accept<\/strong> supprim\u00e9. Pour cela, je mise sur des m\u00e9thodes pratiques claires afin que tu puisses tirer davantage parti des syst\u00e8mes multic\u0153urs <strong>Performance<\/strong> tu sors.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>Goulot d'\u00e9tranglement \u00ab Accept \u00bb<\/strong> \u00e9viter et r\u00e9duire la latence<\/li>\n  <li><strong>Multic\u0153ur<\/strong> Optimisation de l'utilisation des ressources gr\u00e2ce \u00e0 la r\u00e9partition du noyau<\/li>\n  <li><strong>Thundering-Herd<\/strong> r\u00e9duire consid\u00e9rablement<\/li>\n  <li><strong>Architecture<\/strong> simplifier sans dispatcher \u00ab userland \u00bb<\/li>\n  <li><strong>Nginx<\/strong> et utiliser directement d'autres serveurs<\/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\/webserver-performance-3471.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ce que SO_REUSEPORT permet de r\u00e9soudre sur le plan technique<\/h2>\n\n<p>SO_REUSEPORT attribue \u00e0 chaque worker son propre socket d'\u00e9coute, ce qui me permet d'utiliser le classique <strong>goulot de bouteille<\/strong> lors de l'acceptation centrale. Auparavant, tout passait par un seul socket, ce qui entra\u00eenait une concurrence entre les threads et augmentait les temps d'attente. Aujourd'hui, le noyau r\u00e9partit les nouvelles connexions directement sur plusieurs sockets, ce qui <strong>Latence<\/strong> r\u00e9duit sensiblement. Je supprime ainsi le besoin de processus de r\u00e9partition distincts et \u00e9vite les changements de contexte. En cas de charge \u00e9lev\u00e9e, les temps de r\u00e9ponse restent plus constants, car aucun \u00e9couteur ne ralentit le syst\u00e8me.<\/p>\n\n<h2>SO_REUSEPORT vs SO_REUSEADDR : une br\u00e8ve distinction<\/h2>\n\n<p>SO_REUSEADDR m'aide \u00e0 red\u00e9marrer rapidement, car je peux r\u00e9utiliser les ports malgr\u00e9 <strong>TIME_WAIT<\/strong> peut se reconnecter. SO_REUSEPORT a un autre effet : plusieurs \u00e9couteurs simultan\u00e9s sur la m\u00eame combinaison IP\/port. Ce n'est que lorsque je d\u00e9finis SO_REUSEPORT avant l'appel \u00e0 bind() que le noyau autorise le fonctionnement parall\u00e8le <strong>Bind<\/strong>-Op\u00e9ration. L\u2019ordre reste important : si un port est occup\u00e9 sans cette option, aucun autre socket ne pourra s\u2019y ajouter. Pour les workers parall\u00e8les, SO_REUSEPORT est donc une option cl\u00e9.<\/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\/optimierte_webserver_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fonctionnement au niveau du noyau : groupes Reuseport et hachage<\/h2>\n\n<p>Tous les sockets pr\u00e9sentant une combinaison IP\/port identique et pour lesquels SO_REUSEPORT est activ\u00e9 sont regroup\u00e9s dans un <strong>Groupe<\/strong>. Pour chaque nouvelle connexion, le noyau calcule un hachage \u00e0 partir des param\u00e8tres source et destination. Sur cette base, il attribue la connexion \u00e0 un \u00e9couteur appropri\u00e9, assurant ainsi une r\u00e9partition relativement \u00e9quitable. Je b\u00e9n\u00e9ficie d\u2019une meilleure localit\u00e9 du cache, car chaque processeur traite plus souvent \u201e ses \u201c connexions. Pour les cas particuliers, BPF peut <strong>S\u00e9lection<\/strong> continuer \u00e0 l'adapter, par exemple pour mettre en \u0153uvre ses propres strat\u00e9gies.<\/p>\n\n<h2>Pratique : configurer correctement Nginx<\/h2>\n\n<p>Dans Nginx, j'active la r\u00e9utilisation des ports (reuseport) \u00e0 l'aide de la directive \u00ab list \u00bb et j'utilise plusieurs <strong>Travailleur<\/strong>-processus. Un exemple : d\u00e9finir `worker_processes` sur le nombre de c\u0153urs et ajouter \u201e `listen 80 reuseport;` \u201c dans le bloc serveur. Chaque worker dispose alors de son propre \u00e9couteur, et le noyau r\u00e9partit automatiquement les nouvelles connexions. Pour plus de d\u00e9tails sur le nombre optimal de workers, je vous renvoie \u00e0 la <a href=\"https:\/\/webhosting.de\/fr\/configurer-de-maniere-optimale-les-processus-de-travail-nginx-pour-ameliorer-les-performances\/\">Processus de travail Nginx<\/a>. Cela me permet d'obtenir des taux de requ\u00eates plus \u00e9lev\u00e9s et une charge de travail uniforme sur les c\u0153urs.<\/p>\n\n<h2>Exploiter efficacement les processeurs multic\u0153urs<\/h2>\n\n<p>Avec plusieurs workers et SO_REUSEPORT, j'utilise <strong>Multic\u0153ur<\/strong>-syst\u00e8mes de mani\u00e8re plus homog\u00e8ne. J'affecte les workers aux c\u0153urs via l'affinit\u00e9 CPU afin de r\u00e9duire le \u201e cache-hopping \u201c. Les param\u00e8tres RSS\/RPS de la carte r\u00e9seau permettent de r\u00e9partir correctement les paquets entrants entre les files d'attente. Ainsi, les connexions sont plus souvent attribu\u00e9es \u00e0 des c\u0153urs \u00ab adapt\u00e9s \u00bb, ce qui am\u00e9liore la <strong>D\u00e9bit<\/strong>- augmente le d\u00e9bit. Cet effet est particuli\u00e8rement visible lors de nombreuses connexions courtes et de proc\u00e9dures de n\u00e9gociation TLS.<\/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\/linux-server-performance-boost-2341.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Surveillance, red\u00e9marrages progressifs et pi\u00e8ges \u00e0 \u00e9viter<\/h2>\n\n<p>Je planifie les red\u00e9marrages progressifs avec prudence, car la fermeture d'un socket d'\u00e9coute peut entra\u00eener la perte de <strong>arri\u00e9r\u00e9<\/strong>-entr\u00e9es. Avant de fermer les workers, je les laisse vider leurs files d'attente et ce n'est qu'ensuite que je les retire du service. Pour les journaux, j'utilise des fichiers distincts par worker afin de pouvoir retracer la r\u00e9partition ult\u00e9rieurement. Les outils de surveillance doivent prendre en compte plusieurs processus, sinon les m\u00e9triques peuvent induire en erreur. En ce qui concerne les liaisons IP, je veille \u00e0 la coh\u00e9rence, car sinon 0.0.0.0 et les adresses IP sp\u00e9cifiques <strong>Conflits<\/strong> peuvent produire.<\/p>\n\n<h2>SO_REUSEPORT au-del\u00e0 du protocole HTTP<\/h2>\n\n<p>Ce principe m'aide \u00e9galement \u00e0 <strong>UDP<\/strong>- des services tels que le DNS, le streaming ou les serveurs de jeux. De nombreux nouveaux paquets par seconde sont ainsi r\u00e9partis entre plusieurs \u00e9couteurs, sans que j\u2019aie besoin d\u2019un \u00e9quilibreur de charge en espace utilisateur. Les proxys TCP, les passerelles et les plateformes IoT en b\u00e9n\u00e9ficient \u00e9galement. Il reste important de d\u00e9finir le nombre correct de workers afin que le mat\u00e9riel et les logiciels fonctionnent en synchronisation. Je combine cette configuration avec des <strong>Limites<\/strong> pour les descripteurs de fichiers et les valeurs de d\u00e9lai d'expiration correctes.<\/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\/linux_nacht_webserver_7834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimisation de la pile r\u00e9seau : IRQ, d\u00e9chargements, tampons<\/h2>\n\n<p>Je v\u00e9rifie la r\u00e9partition des IRQ de la carte r\u00e9seau afin que les files d'attente soient attribu\u00e9es aux <strong>CPU<\/strong>-c\u0153urs. Lorsque cela s'av\u00e8re pertinent, j'utilise GRO\/LRO et les d\u00e9chargements, mais je teste toujours la latence. Je d\u00e9finis d\u00e9lib\u00e9r\u00e9ment la taille du tampon de socket, car des valeurs trop faibles ralentissent le syst\u00e8me lors des pics d'activit\u00e9 et des valeurs trop \u00e9lev\u00e9es gaspillent de la m\u00e9moire ; pour en savoir plus, voir <a href=\"https:\/\/webhosting.de\/fr\/server-socket-buffers-hosting-tuning-bufferopti\/\">Tampon de socket<\/a>. Je v\u00e9rifie \u00e9galement que les param\u00e8tres sysctl tels que somaxconn et net.core.somaxconn correspondent au profil de charge. Je mesure l'impact de chaque modification s\u00e9par\u00e9ment afin d'obtenir des r\u00e9sultats r\u00e9els <strong>Gains<\/strong> de voir.<\/p>\n\n<h2>Comparaison des configurations courantes de serveurs web<\/h2>\n\n<p>Le tableau suivant pr\u00e9sente les caract\u00e9ristiques typiques de diff\u00e9rents mod\u00e8les de listeners et m'aide \u00e0 <strong>Choix<\/strong> de la conception. Je me concentre sur le chemin d'acceptation, la latence sous charge, les capacit\u00e9s d'\u00e9volutivit\u00e9, la complexit\u00e9 de l'architecture et l'utilisation du processeur. Cela me permet d'identifier rapidement la configuration la mieux adapt\u00e9e \u00e0 mon profil de trafic. Je fais la distinction entre la th\u00e9orie et la pratique en v\u00e9rifiant ensuite les indicateurs r\u00e9els. Les <strong>Matrice<\/strong> sert de point de d\u00e9part pour des tests cibl\u00e9s.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Configuration<\/th>\n      <th>Chemin Accept<\/th>\n      <th>Latence en charge<\/th>\n      <th>Mise \u00e0 l'\u00e9chelle<\/th>\n      <th>frais d'architecture<\/th>\n      <th>Utilisation du CPU<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Un \u00e9couteur sans SO_REUSEPORT<\/td>\n      <td>A <strong>prise<\/strong><\/td>\n      <td>se l\u00e8ve t\u00f4t<\/td>\n      <td>limit\u00e9<\/td>\n      <td>faible<\/td>\n      <td>in\u00e9gal<\/td>\n    <\/tr>\n    <tr>\n      <td>Plusieurs workers avec SO_REUSEPORT<\/td>\n      <td>Noyau-<strong>Distribution<\/strong><\/td>\n      <td>constant<\/td>\n      <td>\u00e9lev\u00e9<\/td>\n      <td>faible<\/td>\n      <td>plus uniforme<\/td>\n    <\/tr>\n    <tr>\n      <td>Dispatcher en espace utilisateur<\/td>\n      <td>r\u00e9ception centralis\u00e9e<\/td>\n      <td>moyen<\/td>\n      <td>moyen<\/td>\n      <td>\u00e9lev\u00e9<\/td>\n      <td>changeant<\/td>\n    <\/tr>\n    <tr>\n      <td>SO_REUSEPORT + logique BPF<\/td>\n      <td>s\u00e9lection personnalis\u00e9e<\/td>\n      <td>tr\u00e8s r\u00e9gulier<\/td>\n      <td>tr\u00e8s \u00e9lev\u00e9<\/td>\n      <td>moyen<\/td>\n      <td>tr\u00e8s r\u00e9gulier<\/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\/entwicklerschreibtisch0391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bien planifier les tests de performance<\/h2>\n\n<p>Je teste avec et sans SO_REUSEPORT afin d'obtenir des r\u00e9sultats r\u00e9els <strong>Diff\u00e9rences<\/strong> \u00e0 observer. Les indicateurs pertinents sont le nombre de requ\u00eates par seconde, les latences p95\/p99 et l'utilisation du processeur par c\u0153ur. Je fais varier le nombre de workers et je recherche le juste \u00e9quilibre entre les changements de contexte et la charge de travail. Je choisis des donn\u00e9es de test proches de la r\u00e9alit\u00e9, incluant le protocole TLS, le Keep-Alive ainsi que du contenu statique et dynamique. Je consigne les r\u00e9sultats de mani\u00e8re reproductible afin de pouvoir, plus tard, <strong>Modifications<\/strong> peut comparer.<\/p>\n\n<h2>Apache : bien utiliser le module MPM Event<\/h2>\n\n<p>Apache en b\u00e9n\u00e9ficie \u00e9galement lorsque je dissocie le chemin Accept et que je <strong>\u00e9v\u00e9nement<\/strong>- Utiliser MPM correctement. Le choix entre Event-MPM et Worker-MPM d\u00e9pend du profil de connexion et des ressources. Je tiens compte du Keep-Alive, des pools de threads et des limites pour les clients. Cet aper\u00e7u m'aide \u00e0 faire un classement succinct : <a href=\"https:\/\/webhosting.de\/fr\/mpm-event-apache-vs-mpm-worker-optimisation-du-serveur-web\/\">MPM \u00e9v\u00e9nementiel vs MPM travailleur<\/a>. En association avec SO_REUSEPORT, je travaille de mani\u00e8re cibl\u00e9e \u00e0 obtenir une r\u00e9partition homog\u00e8ne <strong>Dernier<\/strong> par processus.<\/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\/server-performance-linux-4852.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limites et subtilit\u00e9s de la r\u00e9partition<\/h2>\n<p>SO_REUSEPORT r\u00e9partit les connexions entrantes de mani\u00e8re relativement \u00e9quitable via un hachage, mais pas de fa\u00e7on parfaitement uniforme. Les pics de charge peuvent affecter davantage certains workers pendant un court instant si les param\u00e8tres source\/destination entra\u00eenent une r\u00e9partition d\u00e9favorable. Je surveille donc les m\u00e9triques des workers (connexions accept\u00e9es, connexions actives, utilisation du processeur) et j'ajuste le nombre de workers, les affinit\u00e9s et les files d'attente RSS. Les connexions Keep-Alive restent sur le listener d\u2019origine, ce qui assure une localisation souhait\u00e9e dans le cache, mais peut \u00e9galement entra\u00eener des mod\u00e8les de charge \u201e collants \u201c. Pour les requ\u00eates tr\u00e8s h\u00e9t\u00e9rog\u00e8nes (charge mixte CPU\/E\/S), je pr\u00e9vois des tampons afin d\u2019amortir les pics de charge de courte dur\u00e9e.<\/p>\n\n<h2>Le chemin \u00ab Accept \u00bb en d\u00e9tail : Backlog, somaxconn et files d'attente SYN<\/h2>\n<p>Je fais la distinction entre la file d'attente de la liste (SYN-Backlog) et la file d'attente d'acceptation. Des param\u00e8tres tels que net.ipv4.tcp_max_syn_backlog, tcp_syncookies et net.core.somaxconn d\u00e9terminent le nombre de tentatives de connexion et de sockets pleinement \u00e9tablis pouvant \u00eatre conserv\u00e9s. Le backlog s'applique s\u00e9par\u00e9ment \u00e0 chaque socket d'\u00e9coute ; avec SO_REUSEPORT, la capacit\u00e9 th\u00e9orique du tampon se multiplie sur l'ensemble des workers. En pratique, cependant, ce sont la carte r\u00e9seau et la charge du processeur qui constituent les limites. Je veille \u00e0 la coh\u00e9rence des files d\u2019attente et je mesure les taux de perte et de retransmission afin de d\u00e9tecter rapidement les goulots d\u2019\u00e9tranglement.<\/p>\n\n<h2>D\u00e9tails sur Nginx : accept_mutex, arr\u00eat des workers et TLS<\/h2>\n<p>D\u00e8s que j'utilise reuseport, je d\u00e9sactive accept_mutex dans Nginx, car c'est le noyau qui se charge de l'allocation \u00e9quitable. Lors d'un red\u00e9marrage progressif, je choisis l'option \u201e graceful \u201c et j'attends la fin des connexions Keep-Alive afin qu'aucun transfert en cours ne soit interrompu. C\u00f4t\u00e9 TLS, je veille \u00e0 ce que les cl\u00e9s de ticket soient communes entre les workers et les instances, afin que la reprise et les identifiants de session fonctionnent ind\u00e9pendamment du listener attribu\u00e9. Je m\u2019assure que les workers ne deviennent pas trop volumineux (empreinte m\u00e9moire et cache) afin d\u2019\u00e9viter les caches froids lors des changements de processus.<\/p>\n\n<h2>Activation des sockets systemd, conteneurs et orchestration<\/h2>\n<p>Lorsque systemd ouvre des sockets \u00e0 l'avance, il doit activer SO_REUSEPORT, sinon les liaisons parall\u00e8les sont bloqu\u00e9es. Dans les environnements de conteneurs, je veille \u00e0 ce que le nombre de workers souhait\u00e9 g\u00e9n\u00e8re bien le nombre de processus requis par pod\/conteneur et \u00e0 ce que l'allocation CPU du cgroup corresponde \u00e0 la strat\u00e9gie d'affinit\u00e9. Dans les orchestrateurs, je planifie la strat\u00e9gie de mise \u00e0 jour progressive de mani\u00e8re \u00e0 ce que le groupe Reuseport reste stable pendant les d\u00e9ploiements et ne bloque aucun port de mani\u00e8re exclusive. Les contr\u00f4les d'int\u00e9grit\u00e9 ne doivent pas g\u00e9n\u00e9rer de bruit inutile par travailleur ni fausser la r\u00e9partition.<\/p>\n\n<h2>Prise en charge NUMA et localit\u00e9 m\u00e9moire<\/h2>\n<p>Sur les syst\u00e8mes NUMA, j'affecte les workers aux c\u0153urs d'un m\u00eame n\u0153ud NUMA et je m'assure que les IRQ des cartes r\u00e9seau y soient de pr\u00e9f\u00e9rence achemin\u00e9es. Je surveille les acc\u00e8s \u00e0 la m\u00e9moire distante et les migrations de pages, car ils provoquent des pics de latence. Lorsque la charge de travail \u00e9volue fortement, une r\u00e9plication par n\u0153ud NUMA avec son propre port\/front-end peut s\u2019av\u00e9rer judicieuse ; en combinaison avec SO_REUSEPORT, j\u2019obtiens des latences tr\u00e8s stables tant que les chemins de donn\u00e9es et de code restent locaux au n\u0153ud.<\/p>\n\n<h2>HTTP\/3 et l'utilisation de l'UDP<\/h2>\n<p>Avec HTTP\/3 (QUIC), je tire particuli\u00e8rement parti de SO_REUSEPORT dans le chemin UDP : de nombreuses poign\u00e9es de main et connexions de courte dur\u00e9e sont r\u00e9parties sans \u00e9quilibrateur de charge suppl\u00e9mentaire c\u00f4t\u00e9 utilisateur. Je veille \u00e0 ce que les tampons UDP soient suffisamment grands et je v\u00e9rifie les compteurs de paquets perdus pour chaque file d\u2019attente. Comme QUIC lie logiquement les connexions au 5-tuple, la r\u00e9partition reste stable ; je me prot\u00e8ge n\u00e9anmoins \u00e0 l\u2019aide de strat\u00e9gies coh\u00e9rentes de r\u00e9essais et de jetons, afin que la s\u00e9lection des workers reste transparente et performante.<\/p>\n\n<h2>R\u00e9glage fin d'eBPF pour Reuseport<\/h2>\n<p>Gr\u00e2ce \u00e0 un programme BPF Reuseport, je peux contr\u00f4ler davantage la s\u00e9lection des sockets, par exemple en fonction du nom d'h\u00f4te de destination (SNI), des priorit\u00e9s locales ou de la charge par worker. Je n'y recourt que lorsque la r\u00e9partition par hachage par d\u00e9faut ne suffit pas, car une logique suppl\u00e9mentaire augmente la complexit\u00e9. Pour le d\u00e9pannage, je v\u00e9rifie si les programmes BPF sont bien charg\u00e9s et fonctionnent sans erreur, et je pr\u00e9vois une strat\u00e9gie de secours au cas o\u00f9 la politique devrait \u00eatre d\u00e9sactiv\u00e9e.<\/p>\n\n<h2>R\u00e9silience et s\u00e9curit\u00e9 DDoS<\/h2>\n<p>SO_REUSEPORT augmente la capacit\u00e9 d'accueil \u2013 ce qui est \u00e0 la fois une aubaine et un risque. Je d\u00e9finis des limites de d\u00e9bit et de connexion par worker afin d\u2019\u00e9viter que certains processus ne soient surcharg\u00e9s de mani\u00e8re disproportionn\u00e9e. En combinaison avec des SYN-cookies, des d\u00e9lais d\u2019expiration mod\u00e9r\u00e9s et des limites L7 bien d\u00e9finies, j\u2019emp\u00eache les pics de charge de monopoliser durablement les ressources. Je s\u00e9pare les journaux afin d'identifier plus rapidement les sch\u00e9mas d'abus par worker et, si n\u00e9cessaire, j'utilise iptables\/nftables pour limiter pr\u00e9cocement les sources malveillantes.<\/p>\n\n<h2>D\u00e9bogage et v\u00e9rification<\/h2>\n<p>Je v\u00e9rifie la configuration \u00e0 l'aide de `ss -ltnp` (TCP) ou `ss -lunp` (UDP) afin de d\u00e9tecter la pr\u00e9sence de plusieurs \u00e9couteurs sur la m\u00eame combinaison IP\/port. \u00c0 l'aide de `perf`, `top\/htop` et `mpstat`, je v\u00e9rifie que l'utilisation du processeur reste r\u00e9guli\u00e8re. Les compteurs netstat\/ss, les messages dmesg et les statistiques de paquets perdus de la carte r\u00e9seau (ethtool -S) indiquent si des files d'attente sont satur\u00e9es. Pour des analyses plus approfondies, tcpdump et les \u00e9v\u00e9nements Perf fournissent des informations sur les chemins d'acceptation, les retransmissions et les tentatives de r\u00e9\u00e9mission. La corr\u00e9lation reste essentielle : il faut toujours examiner les m\u00e9triques par worker, par processeur et par file d\u2019attente.<\/p>\n\n<h2>\u00c9viter les erreurs de configuration courantes<\/h2>\n<ul>\n  <li>Un worker sans SO_REUSEPORT se connecte en premier et bloque tous les autres.<\/li>\n  <li>Utilisation conjointe de 0.0.0.0 et d'adresses IP sp\u00e9cifiques \u2013 les \u00e9couteurs sont r\u00e9partis dans des groupes distincts.<\/li>\n  <li>La fonction `accept_mutex` est activ\u00e9e dans Nginx malgr\u00e9 l'option `reuseport` \u2013 s\u00e9rialisation inutile.<\/li>\n  <li>Backlogs incompatibles : le backlog de somaxconn est inf\u00e9rieur \u00e0 celui d\u00e9fini sur le serveur.<\/li>\n  <li>Absence de configuration commune des tickets TLS \u2013 le taux de reprise s'effondre.<\/li>\n  <li>RSS mal dimensionn\u00e9 \u2013 la charge IRQ se concentre sur quelques c\u0153urs.<\/li>\n<\/ul>\n\n<h2>Planification des capacit\u00e9s : taille des workers et limites FD<\/h2>\n<p>Je trouve un \u00e9quilibre entre le nombre de workers, la m\u00e9moire RAM allou\u00e9e par worker, le nombre de fichiers ouverts et le nombre de connexions. Un nombre trop \u00e9lev\u00e9 de processus augmente les changements de contexte et la pression sur le cache, tandis qu'un nombre trop faible r\u00e9duit le parall\u00e9lisme. Je d\u00e9finis les limites de descripteurs de fichiers de mani\u00e8re g\u00e9n\u00e9reuse et coh\u00e9rente (ulimit, limites systemd, limites dures\/souples), car chaque worker a besoin de ses propres descripteurs de fichiers pour les sockets, les journaux et les connexions en amont. Je pr\u00e9vois \u00e9galement suffisamment de ports \u00e9ph\u00e9m\u00e8res et surveille le volume de TIME_WAIT afin que les pics de trafic \u00e0 court terme ne se perdent pas en chemin.<\/p>\n\n<h2>Tests de performance : pi\u00e8ges courants<\/h2>\n<p>Je pr\u00e9chauffe les serveurs et les caches, je calibre le g\u00e9n\u00e9rateur de charge (pour \u00e9viter tout goulot d'\u00e9tranglement cach\u00e9) et je s\u00e9pare le r\u00e9seau de contr\u00f4le du r\u00e9seau de donn\u00e9es. Les tests durent suffisamment longtemps pour mesurer les valeurs p99\/p999 de mani\u00e8re stable, et je fais varier les temps de r\u00e9flexion (Think-Times), les taux de maintien de connexion (Keep-Alive) et les param\u00e8tres TLS. Je consigne \u00e9galement les param\u00e8tres du noyau et du serveur afin que les ex\u00e9cutions ult\u00e9rieures restent comparables. Lorsque j'utilise des politiques eBPF, je documente s\u00e9par\u00e9ment leur version et leur effet afin de ne pas confondre cause et effet.<\/p>\n\n<h2>Liste de contr\u00f4le pour le d\u00e9marrage<\/h2>\n\n<p>Je v\u00e9rifie d'abord la version du noyau et je m'assure que SO_REUSEPORT est disponible et correctement <strong>fix\u00e9<\/strong> . Ensuite, j'active l'option dans la configuration du serveur web et je configure le nombre souhait\u00e9 de workers. Je v\u00e9rifie somaxconn, les limites des descripteurs de fichiers et les files d'attente des cartes r\u00e9seau. Je r\u00e9alise ensuite des tests de charge, je compare les m\u00e9triques et j'it\u00e8re. Pour finir, je renforce la journalisation, la strat\u00e9gie de red\u00e9marrage et <strong>affinit\u00e9<\/strong> \u00e0 partir de<\/p>\n\n<h2>R\u00e9sum\u00e9<\/h2>\n\n<p>SO_REUSEPORT \u00e9limine le goulot d'\u00e9tranglement li\u00e9 \u00e0 la commande \u00ab Accept \u00bb, r\u00e9partit les nouvelles connexions via un hachage du noyau et offre de meilleures performances sur les syst\u00e8mes multic\u0153urs. <strong>D\u00e9bit<\/strong> . J\u2019utilise plusieurs \u00e9couteurs par port, ce qui me permet d\u2019\u00e9viter le probl\u00e8me du \u201e\u00a0thundering herd\u00a0\u201c et de ne pas avoir \u00e0 recourir \u00e0 un r\u00e9partiteur s\u00e9par\u00e9. Dans Nginx, cela s\u2019obtient avec \u00ab listen \u2026 reuseport \u00bb et un nombre appropri\u00e9 de workers. En combinaison avec l\u2019affinit\u00e9 CPU, une r\u00e9partition optimis\u00e9e des IRQ et des tampons adapt\u00e9s, je garantis une <strong>Latence<\/strong> sous charge. En v\u00e9rifiant, testant et affinant ces \u00e9tapes, on am\u00e9liore les performances sans frais suppl\u00e9mentaires en euros li\u00e9s au mat\u00e9riel.<\/p>","protected":false},"excerpt":{"rendered":"<p>D\u00e9couvrez comment SO_REUSEPORT am\u00e9liore les performances de votre serveur web sous Linux. Apprenez comment fonctionne cette option de socket et comment l'utiliser dans Nginx et d'autres services.<\/p>","protected":false},"author":1,"featured_media":20883,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20890","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":"SO_REUSEPORT Linux","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":"20883","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20890","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=20890"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20890\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20883"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}