{"id":15847,"date":"2025-12-06T18:22:12","date_gmt":"2025-12-06T17:22:12","guid":{"rendered":"https:\/\/webhosting.de\/http-keep-alive-tuning-serverlast-performance-optimierung-flow\/"},"modified":"2025-12-06T18:22:12","modified_gmt":"2025-12-06T17:22:12","slug":"http-keep-alive-reglage-charge-du-serveur-optimisation-des-performances-flux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/http-keep-alive-tuning-serverlast-performance-optimierung-flow\/","title":{"rendered":"R\u00e9glage HTTP Keep-Alive : gestion des connexions et charge du serveur"},"content":{"rendered":"<p>HTTP Keep-Alive r\u00e9duit les handshakes et maintient les connexions ouvertes afin que plusieurs requ\u00eates puissent passer par le m\u00eame socket et que la <strong>Charge du serveur<\/strong> diminue. Gr\u00e2ce \u00e0 un r\u00e9glage cibl\u00e9, je contr\u00f4le les d\u00e9lais d'attente, les limites et les travailleurs, je r\u00e9duis <strong>Latence<\/strong> et augmentez le d\u00e9bit sans modifier le code.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>R\u00e9utilisation de la connexion<\/strong> r\u00e9duit la charge CPU et les handshakes.<\/li>\n  <li>Court <strong>Timeouts<\/strong> emp\u00eachent les connexions inactives.<\/li>\n  <li>Propre <strong>Limites<\/strong> pour stabiliser la charge keepalive_requests.<\/li>\n  <li><strong>HTTP\/2<\/strong> et HTTP\/3 encore plus \u00e9troitement.<\/li>\n  <li>R\u00e9aliste <strong>tests de charge<\/strong> Enregistrer les param\u00e8tres.<\/li>\n<\/ul>\n\n<h2>Comment fonctionne HTTP Keep-Alive<\/h2>\n\n<p>Au lieu d'ouvrir une nouvelle connexion TCP pour chaque ressource, je r\u00e9utilise une connexion existante et \u00e9conomise ainsi <strong>Poign\u00e9es de main<\/strong> et les allers-retours. Cela r\u00e9duit les temps d'attente, car ni les configurations TCP ni TLS ne doivent fonctionner en permanence et le pipeline r\u00e9pond rapidement. Le client reconna\u00eet via l'en-t\u00eate que la connexion reste ouverte et envoie d'autres requ\u00eates les unes apr\u00e8s les autres ou avec multiplexage (avec HTTP\/2\/3) via le m\u00eame <strong>prise<\/strong>. Le serveur g\u00e8re la phase d'inactivit\u00e9 via un d\u00e9lai d'expiration Keep-Alive et met fin \u00e0 la connexion si aucune requ\u00eate n'est re\u00e7ue pendant une p\u00e9riode trop longue. Ce comportement acc\u00e9l\u00e8re sensiblement les pages contenant de nombreux \u00e9l\u00e9ments et soulage le processeur, car il y a moins de connexions \u00e0 \u00e9tablir.<\/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\/2025\/12\/http-keepalive-server-9347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>R\u00e9utilisation des connexions : impact sur la charge du serveur<\/h2>\n\n<p>Chaque nouvelle connexion \u00e9vit\u00e9e permet d'\u00e9conomiser <strong>temps CPU<\/strong> pour le travail du noyau et TLS, ce que je constate dans la surveillance sous la forme d'une courbe de charge plus r\u00e9guli\u00e8re. Les donn\u00e9es montrent que la r\u00e9utilisation des sockets existants peut augmenter le d\u00e9bit jusqu'\u00e0 50 % lorsque de nombreuses petites requ\u00eates sont g\u00e9n\u00e9r\u00e9es. Dans les benchmarks avec de nombreuses requ\u00eates GET, la dur\u00e9e totale est parfois r\u00e9duite de moiti\u00e9, car il y a moins de handshakes et moins de changements de contexte. La charge r\u00e9seau diminue \u00e9galement, car les paquets SYN\/ACK sont moins fr\u00e9quents et le serveur dispose de plus de ressources pour la logique d'application proprement dite. Cette interaction permet d'obtenir des r\u00e9ponses plus rapides et plus stables. <strong>Temps de r\u00e9action<\/strong> en charge.<\/p>\n\n<h2>Risques : d\u00e9lais d'attente trop longs et connexions ouvertes<\/h2>\n\n<p>Un d\u00e9lai d'expiration Keep-Alive trop g\u00e9n\u00e9reux laisse les connexions inactives et bloque <strong>Travailleur<\/strong> ou des threads, m\u00eame si aucune requ\u00eate n'est en attente. En cas de trafic \u00e9lev\u00e9, les sockets ouverts augmentent, atteignent les limites des descripteurs de fichiers et font grimper la consommation de m\u00e9moire. De plus, des d\u00e9lais d'attente client inappropri\u00e9s g\u00e9n\u00e8rent des connexions \u201e mortes \u201c qui envoient des requ\u00eates \u00e0 des sockets d\u00e9j\u00e0 ferm\u00e9es et produisent des messages d'erreur. Les passerelles d'entr\u00e9e et NAT peuvent fermer les lignes inactives avant le serveur, ce qui entra\u00eene des r\u00e9initialisations sporadiques. C'est pourquoi je limite d\u00e9lib\u00e9r\u00e9ment les temps d'inactivit\u00e9, fixe des limites claires et maintiens la <strong>contrepartie<\/strong> (clients, proxys).<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/keepalive_tuning_meeting_8421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP Keep-Alive vs TCP Keepalive<\/h2>\n\n<p>Je fais une distinction stricte entre HTTP Keep-Alive (connexions persistantes au niveau de l'application) et le m\u00e9canisme TCP \u201e keepalive \u201c. HTTP Keep-Alive contr\u00f4le si d'autres requ\u00eates HTTP passent par le m\u00eame socket. TCP Keepalive, en revanche, envoie des paquets de test \u00e0 intervalles r\u00e9guliers afin de d\u00e9tecter les contreparties \u201e mortes \u201c. Pour l'optimisation des performances, c'est principalement HTTP Keep-Alive qui compte. J'utilise TCP Keepalive de mani\u00e8re cibl\u00e9e pour les longues phases d'inactivit\u00e9 (par exemple, pour les connexions p\u00e9riph\u00e9riques ou dans les r\u00e9seaux d'entreprise avec des pare-feu agressifs), mais je d\u00e9finis les intervalles de mani\u00e8re d\u00e9fensive afin d'\u00e9viter toute charge r\u00e9seau inutile.<\/p>\n\n<h2>Cas particuliers : long polling, SSE et WebSockets<\/h2>\n\n<p>Les flux longue dur\u00e9e (\u00e9v\u00e9nements envoy\u00e9s par le serveur), le long polling ou les WebSockets entrent en conflit avec les d\u00e9lais d'inactivit\u00e9 courts. Je s\u00e9pare ces points de terminaison des routes API ou Asset standard, je leur attribue des d\u00e9lais d'attente plus longs et des pools de travailleurs d\u00e9di\u00e9s, et je limite les flux simultan\u00e9s par IP. Ainsi, les flux longue dur\u00e9e ne bloquent pas les ressources pour les requ\u00eates courtes classiques. Pour les SSE et les WebSockets, il vaut mieux d\u00e9finir des limites claires, des d\u00e9lais d'attente en lecture\/\u00e9criture et un intervalle de heartbeat ou ping\/pong pr\u00e9cis plut\u00f4t que d'augmenter globalement tous les d\u00e9lais d'attente.<\/p>\n\n<h2>Param\u00e8tres Keep Alive centraux dans le serveur Web<\/h2>\n\n<p>J'active presque toujours Keep-Alive, je d\u00e9finis un d\u00e9lai d'inactivit\u00e9 court et je limite le nombre de requ\u00eates par connexion afin de pr\u00e9server les ressources. <strong>recycler<\/strong>. De plus, je r\u00e9gule les pools de travailleurs\/threads afin que les connexions inactives n'occupent pas trop de processus. Le tableau suivant pr\u00e9sente les directives, les objectifs et les valeurs de d\u00e9part types que j'utilise r\u00e9guli\u00e8rement dans la pratique. Les valeurs varient en fonction de l'application et du profil de latence, mais elles constituent une base solide pour les premiers tests. Ensuite, je peaufine progressivement les d\u00e9lais d'attente, les limites et <strong>Fils de discussion<\/strong> \u00e0 partir de donn\u00e9es de mesure r\u00e9elles.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Serveur\/composant<\/th>\n      <th>directive<\/th>\n      <th>Objectif<\/th>\n      <th>valeur initiale<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Apache<\/td>\n      <td>KeepAlive<\/td>\n      <td>Activer les connexions persistantes<\/td>\n      <td>On<\/td>\n    <\/tr>\n    <tr>\n      <td>Apache<\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>Temps d'inactivit\u00e9 jusqu'\u00e0 la fin de la connexion<\/td>\n      <td>5 \u00e0 15 s<\/td>\n    <\/tr>\n    <tr>\n      <td>Apache<\/td>\n      <td>MaxKeepAliveRequests<\/td>\n      <td>Nombre maximal de requ\u00eates par connexion<\/td>\n      <td>100\u2013500<\/td>\n    <\/tr>\n    <tr>\n      <td>Nginx<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>Temps d'inactivit\u00e9 jusqu'\u00e0 la fin de la connexion<\/td>\n      <td>5 \u00e0 15 s<\/td>\n    <\/tr>\n    <tr>\n      <td>Nginx<\/td>\n      <td>keepalive_requests<\/td>\n      <td>Nombre maximal de requ\u00eates par connexion<\/td>\n      <td>100<\/td>\n    <\/tr>\n    <tr>\n      <td>HAProxy<\/td>\n      <td>option http-keep-alive<\/td>\n      <td>Autoriser les connexions persistantes<\/td>\n      <td>actif<\/td>\n    <\/tr>\n    <tr>\n      <td>Noyau\/Syst\u00e8me d'exploitation<\/td>\n      <td>somaxconn, tcp_max_syn_backlog<\/td>\n      <td>Files d'attente pour les connexions<\/td>\n      <td>adapt\u00e9 au trafic<\/td>\n    <\/tr>\n    <tr>\n      <td>Noyau\/Syst\u00e8me d'exploitation<\/td>\n      <td>Limites FD (ulimit -n)<\/td>\n      <td>Fichiers ouverts\/sockets<\/td>\n      <td>&gt;= 100k en cas de trafic \u00e9lev\u00e9<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Apache : valeurs de d\u00e9marrage, MPM et contr\u00f4le des workers<\/h2>\n\n<p>Pour les sites tr\u00e8s parall\u00e8les, j'utilise le MPM dans Apache. <strong>\u00e9v\u00e9nement<\/strong>, car il g\u00e8re les connexions Idle-Keep-Alive plus efficacement que l'ancien prefork. En pratique, je choisis souvent 5 \u00e0 15 secondes pour KeepAliveTimeout afin que les clients puissent regrouper les ressources sans bloquer les travailleurs pendant longtemps. Avec MaxKeepAliveRequests 100-500, j'impose un recyclage mod\u00e9r\u00e9, ce qui pr\u00e9vient les fuites et lisse les pics de charge. Je r\u00e9duis le d\u00e9lai d'expiration g\u00e9n\u00e9ral \u00e0 120-150 secondes afin que les requ\u00eates bloqu\u00e9es ne monopolisent pas les processus. Si vous souhaitez approfondir vos connaissances sur les threads et les processus, vous trouverez des informations importantes sur <a href=\"https:\/\/webhosting.de\/fr\/threadpool-serveur-web-apache-nginx-litespeed-optimisation-configuration\/\">Param\u00e8tres du pool de threads<\/a> pour diff\u00e9rents serveurs web.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/http-keepalive-serverlast-3028.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Nginx et HAProxy : mod\u00e8les pratiques et anti-mod\u00e8les<\/h2>\n\n<p>Avec les proxys invers\u00e9s, j'observe souvent deux erreurs : soit Keep-Alive est d\u00e9sactiv\u00e9 globalement pour des \u201e raisons de s\u00e9curit\u00e9 \u201c (ce qui entra\u00eene une charge de handshake massive), soit les d\u00e9lais d'inactivit\u00e9 sont \u00e9lev\u00e9s alors que le trafic est faible (ce qui mobilise des ressources). Je consid\u00e8re que les d\u00e9lais d'attente front-end sont plus courts que les d\u00e9lais d'attente back-end, afin que les proxys puissent rester ouverts m\u00eame lorsque les clients ferment la connexion. De plus, je s\u00e9pare les pools en amont par classes de service (actifs statiques vs API), car leur s\u00e9quence de requ\u00eates et leur temps d'inactivit\u00e9 d\u00e9pendent du profil. Il est \u00e9galement essentiel de disposer d'un <strong>Longueur du contenu<\/strong>\/<strong>Encodage de transfert<\/strong>-Manipulation : des indications de longueur erron\u00e9es emp\u00eachent la r\u00e9utilisation des connexions et provoquent \u201e connection: close \u201c, ce qui entra\u00eene des reconnexions inutiles.<\/p>\n\n<h2>Nginx et HAProxy : utiliser correctement les pools en amont<\/h2>\n\n<p>Avec Nginx, je gagne beaucoup de temps lorsque je maintiens des connexions en amont vers les backends et que j'utilise <strong>keepalive<\/strong> J'ajuste la taille des pools. Cela r\u00e9duit les configurations TLS vers les serveurs d'applications et diminue consid\u00e9rablement la charge CPU \u00e0 cet endroit. J'observe le nombre de sockets en amont ouverts, les taux de r\u00e9utilisation et les distributions de latence dans les journaux afin d'augmenter ou de r\u00e9duire la taille des pools de mani\u00e8re cibl\u00e9e. Du c\u00f4t\u00e9 du noyau, j'augmente les limites FD et j'ajuste somaxconn et tcp_max_syn_backlog afin que les files d'attente ne d\u00e9bordent pas. Ainsi, le proxy reste r\u00e9actif m\u00eame en cas de parall\u00e9lisme \u00e9lev\u00e9 et r\u00e9partit le trafic de mani\u00e8re uniforme sur les <strong>back-ends<\/strong>.<\/p>\n\n<h2>Optimisation TLS et QUIC pour r\u00e9duire la surcharge<\/h2>\n\n<p>Pour que Keep-Alive puisse d\u00e9ployer pleinement ses effets, j'optimise la couche TLS : TLS 1.3 avec reprise (tickets de session) raccourcit les handshakes, OCSP-Stapling raccourcit les v\u00e9rifications de certificats, une cha\u00eene de certificats all\u00e9g\u00e9e r\u00e9duit les octets et le CPU. Je n'utilise 0-RTT que pour les requ\u00eates idempotentes et avec prudence afin d'\u00e9viter les risques de rejeu. Avec HTTP\/3 (QUIC), c'est <em>idle_timeout<\/em> d\u00e9cisif : trop \u00e9lev\u00e9, le stockage co\u00fbte cher, trop bas, les flux s'interrompent. Je teste \u00e9galement comment <em>fen\u00eatre de congestion initiale<\/em> et les limites d'amplification agissent sur les connexions froides, en particulier sur de longues distances.<\/p>\n\n<h2>Utilisation cibl\u00e9e de HTTP\/2, HTTP\/3 et du multiplexage<\/h2>\n\n<p>HTTP\/2 et HTTP\/3 regroupent plusieurs requ\u00eates sur une seule connexion et \u00e9liminent <strong>T\u00eate de ligne<\/strong>-Blocage au niveau de l'application. Cela profite encore davantage \u00e0 Keep-Alive, car moins de connexions sont \u00e9tablies. Dans mes configurations, je veille \u00e0 configurer les priorit\u00e9s et le contr\u00f4le de flux de mani\u00e8re \u00e0 ce que les ressources critiques fonctionnent en premier. Je v\u00e9rifie \u00e9galement si le regroupement des connexions est utile, par exemple lorsque plusieurs noms d'h\u00f4tes utilisent le m\u00eame certificat. Un coup d'\u0153il \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/http3-vs-http2-test-de-performance-dhebergement-web-topserver\/\">HTTP\/3 vs. HTTP\/2<\/a> aide \u00e0 choisir le protocole adapt\u00e9 aux profils d'utilisateurs mondiaux.<\/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\/2025\/12\/http-keepalive-office-9347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Clients et piles d'applications : configurer correctement le pooling<\/h2>\n\n<p>Le c\u00f4t\u00e9 client et application d\u00e9termine \u00e9galement la r\u00e9utilisation : dans Node.js, j'active pour HTTP\/HTTPS le <em>keepAlive<\/em>Agent avec un nombre limit\u00e9 de sockets par h\u00f4te. En Java, je d\u00e9finis des tailles de pool et des d\u00e9lais d'inactivit\u00e9 raisonnables pour HttpClient\/OkHttp ; en Go, j'ajuste <em>MaxIdleConns<\/em> et <em>MaxIdleConnsPerHost<\/em> Les clients gRPC b\u00e9n\u00e9ficient de connexions longues, mais je d\u00e9finis des intervalles de ping et <em>d\u00e9lais d'expiration keepalive<\/em> de mani\u00e8re \u00e0 ce que les proxys ne provoquent pas de flood. La coh\u00e9rence est importante : des reconnexions client trop agressives compromettent toute optimisation du serveur.<\/p>\n\n<h2>Essais de charge et strat\u00e9gie de mesure<\/h2>\n\n<p>Tourner \u00e0 l'aveuglette lors des temps morts apporte rarement une stabilit\u00e9 <strong>R\u00e9sultats<\/strong>, c'est pourquoi je proc\u00e8de \u00e0 des mesures syst\u00e9matiques. Je simule des chemins d'utilisateurs typiques avec de nombreux petits fichiers, un degr\u00e9 de parall\u00e9lisation r\u00e9aliste et une latence r\u00e9partie g\u00e9ographiquement. Pendant ce temps, j'enregistre les taux de r\u00e9utilisation, la dur\u00e9e moyenne de connexion, les codes d'erreur et le rapport entre les sockets ouverts et le nombre de travailleurs. Je varie ensuite le KeepAliveTimeout par petits paliers et je compare les courbes des temps de r\u00e9ponse et de la consommation CPU. Ce n'est que lorsque les m\u00e9triques restent stables sur plusieurs ex\u00e9cutions que je reprends les valeurs dans le <strong>Production<\/strong>.<\/p>\n\n<h2>Observabilit\u00e9 : quelles m\u00e9triques comptent ?<\/h2>\n\n<p>Je surveille des indicateurs concrets : nouvelles connexions par seconde, rapport r\u00e9utilisation\/reconstruction, poign\u00e9es de main TLS par seconde, sockets ouverts et leur temps de s\u00e9jour, 95e\/99e centile de latence, r\u00e9partition des codes d'\u00e9tat (y compris 408\/499), ainsi que les \u00e9tats du noyau tels que TIME_WAIT\/FIN_WAIT2. Les pics de handshakes, l'augmentation des 499 et la croissance des buckets TIME_WAIT indiquent souvent des d\u00e9lais d'inactivit\u00e9 trop courts ou des pools trop petits. Une logique correctement instrument\u00e9e rend le r\u00e9glage reproductible et emp\u00eache les optimisations de n'avoir qu'un effet placebo.<\/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\/2025\/12\/entwicklerdesk_http_4312.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Synchronisation du d\u00e9lai d'attente entre le client et le serveur<\/h2>\n\n<p>Les clients doivent fermer les connexions inactives un peu plus t\u00f4t que le serveur afin d'\u00e9viter les \u201e morts \u201c.\u201c <strong>Prises<\/strong> apparaissent. Dans les applications frontales, je d\u00e9finis donc des d\u00e9lais d'attente HTTP client plus courts que sur le serveur web et je documente ces sp\u00e9cifications. Il en va de m\u00eame pour les \u00e9quilibreurs de charge : leur d\u00e9lai d'attente inactif ne doit pas \u00eatre inf\u00e9rieur \u00e0 celui du serveur. Je surveille \u00e9galement les valeurs d'inactivit\u00e9 NAT et pare-feu afin que les connexions ne disparaissent pas dans le chemin r\u00e9seau. Cette interaction fluide emp\u00eache les r\u00e9initialisations sporadiques et stabilise <strong>Retransmissions<\/strong>.<\/p>\n\n<h2>R\u00e9silience et s\u00e9curit\u00e9 sous charge<\/h2>\n\n<p>Les connexions persistantes ne doivent pas \u00eatre une invitation pour Slowloris &amp; Co. Je d\u00e9finis des d\u00e9lais d'attente courts pour la lecture des en-t\u00eates\/corps, je limite la taille des en-t\u00eates, je limite les connexions simultan\u00e9es par IP et je veille \u00e0 la contre-pression dans les flux ascendants. En cas d'erreurs de protocole, je ferme syst\u00e9matiquement les connexions (au lieu de les laisser ouvertes) et emp\u00eache ainsi le Request Smuggling. De plus, je d\u00e9finis des <em>gr\u00e2ce<\/em>-Temps lors de la fermeture, afin que le serveur termine proprement les r\u00e9ponses ouvertes sans laisser les connexions ind\u00e9finiment dans <em>persistant<\/em>-conditions.<\/p>\n\n<h2>Facteurs d'h\u00e9bergement et architecture<\/h2>\n\n<p>Des processeurs puissants, des cartes r\u00e9seau rapides et suffisamment de m\u00e9moire vive <strong>RAM<\/strong> acc\u00e9l\u00e8rent les poign\u00e9es de main, les changements de contexte et le cryptage, ce qui permet d'exploiter pleinement le r\u00e9glage Keep-Alive. Un proxy inverse devant l'application simplifie le d\u00e9chargement, centralise les d\u00e9lais d'expiration et augmente le taux de r\u00e9utilisation vers les backends. Pour plus de contr\u00f4le sur TLS, la mise en cache et le routage, je mise sur une approche claire. <a href=\"https:\/\/webhosting.de\/fr\/architecture-reverse-proxy-avantages-performance-securite-mise-a-lechelle-infrastructure\/\">Architecture proxy inverse<\/a>. Il reste important de supprimer rapidement les limites telles que ulimit -n et accept-Queues afin que l'infrastructure puisse supporter un parall\u00e9lisme \u00e9lev\u00e9. Gr\u00e2ce \u00e0 une observabilit\u00e9 claire, je d\u00e9tecte plus rapidement les goulots d'\u00e9tranglement et je peux <strong>Limites<\/strong> Serrer correctement.<\/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\/2025\/12\/serverraum-verbindung-9823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>D\u00e9ploiements, drainage et subtilit\u00e9s du syst\u00e8me d'exploitation<\/h2>\n\n<p>Lors des d\u00e9ploiements progressifs, je laisse les connexions Keep-Alive s'\u00e9teindre de mani\u00e8re contr\u00f4l\u00e9e : je n'accepte plus de nouvelles requ\u00eates, mais celles qui existent peuvent \u00eatre bri\u00e8vement servies (drain). Cela me permet d'\u00e9viter les interruptions de connexion et les pics 5xx. Au niveau du syst\u00e8me d'exploitation, je garde un \u0153il sur la plage de ports \u00e9ph\u00e9m\u00e8res, <em>somaxconn<\/em>, SYN-Backlog et <em>tcp_fin_timeout<\/em>, sans utiliser d'astuces obsol\u00e8tes telles que la r\u00e9utilisation agressive de TIME_WAIT. <em>SO_REUSEPORT<\/em> Je r\u00e9partis la charge sur plusieurs processus de travail afin de r\u00e9duire la concurrence Accept. L'objectif est toujours le m\u00eame : traiter de mani\u00e8re stable un grand nombre de connexions de courte dur\u00e9e sans engorger les files d'attente du noyau.<\/p>\n\n<h2>R\u00e9sum\u00e9 : le tuning comme levier de performance<\/h2>\n\n<p>L'utilisation syst\u00e9matique de HTTP Keep-Alive r\u00e9duit le nombre de connexions \u00e9tablies et diminue la charge du serveur. <strong>Charge CPU<\/strong> et des r\u00e9ponses nettement plus rapides. Des d\u00e9lais d'inactivit\u00e9 courts, des limites claires par connexion et des travailleurs suffisamment dimensionn\u00e9s permettent de ma\u00eetriser les sockets inactifs. Gr\u00e2ce \u00e0 HTTP\/2\/3, aux pools en amont et aux limites OS coordonn\u00e9es, je peux faire \u00e9voluer le parall\u00e9lisme sans perdre en stabilit\u00e9. Des tests de charge r\u00e9alistes montrent si les r\u00e9glages sont vraiment efficaces et o\u00f9 se trouvent les prochains points de pourcentage. En combinant ces \u00e9l\u00e9ments, vous augmentez le d\u00e9bit, maintenez les latences \u00e0 un faible niveau et utilisez les ressources existantes. <strong>Ressources<\/strong> au maximum.<\/p>","protected":false},"excerpt":{"rendered":"<p>Apprenez comment r\u00e9duire la charge du serveur, diminuer les latences et am\u00e9liorer durablement les performances du serveur web gr\u00e2ce au r\u00e9glage HTTP Keep-Alive et \u00e0 une gestion optimale des connexions.<\/p>","protected":false},"author":1,"featured_media":15840,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-15847","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":"2014","_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":null,"_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":"HTTP Keep-Alive","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":"15840","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/15847","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=15847"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/15847\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/15840"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=15847"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=15847"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=15847"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}