{"id":16437,"date":"2026-01-01T11:50:05","date_gmt":"2026-01-01T10:50:05","guid":{"rendered":"https:\/\/webhosting.de\/keep-alive-webserver-performance-tuning-guide\/"},"modified":"2026-01-01T11:50:05","modified_gmt":"2026-01-01T10:50:05","slug":"guide-doptimisation-des-performances-du-serveur-web-keep-alive","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/keep-alive-webserver-performance-tuning-guide\/","title":{"rendered":"Keep Alive Webserver : configurer correctement le frein silencieux des performances"},"content":{"rendered":"<p>Le serveur web Keep Alive d\u00e9termine souvent le temps d'attente ou la vitesse : mal r\u00e9gl\u00e9, il ralentit silencieusement, correctement r\u00e9gl\u00e9, il acc\u00e9l\u00e8re sensiblement chaque requ\u00eate. Je montre concr\u00e8tement comment je <strong>Keep-Alive<\/strong> Configurez les plages horaires qui fonctionnent et pourquoi les plages ouvertes trop longues <strong>TCP<\/strong>Les connexions co\u00fbtent de la puissance.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>m\u00e9canisme<\/strong>: Les connexions TCP ouvertes permettent d'\u00e9conomiser des handshakes et de r\u00e9duire la latence.<\/li>\n  <li><strong>valeurs fondamentales<\/strong>: s\u00e9lectionner KeepAliveTimeout, MaxKeepAliveRequests et l'activation de mani\u00e8re cibl\u00e9e.<\/li>\n  <li><strong>Charge du serveur<\/strong>: Des plages horaires correctement r\u00e9gl\u00e9es r\u00e9duisent les besoins en CPU et en RAM.<\/li>\n  <li><strong>Cabinet m\u00e9dical<\/strong>: tenir compte syst\u00e9matiquement du comportement du navigateur et des cha\u00eenes de proxy inverse.<\/li>\n  <li><strong>Contr\u00f4le<\/strong>: Mesurer, ajuster, mesurer \u00e0 nouveau \u2013 jusqu'\u00e0 ce que le point id\u00e9al soit atteint.<\/li>\n<\/ul>\n\n<h2>Ce que fait Keep Alive<\/h2>\n\n<p>Au lieu de commencer chaque requ\u00eate par une nouvelle poign\u00e9e de main, Keep-Alive maintient la <strong>TCP<\/strong>-Connexion ouverte et traite plusieurs requ\u00eates via celle-ci. Dans un sc\u00e9nario avec 50 requ\u00eates par seconde provenant de trois clients, le flux de paquets diminue consid\u00e9rablement : d'environ 9 000 \u00e0 environ 540 paquets par minute, car moins de connexions sont \u00e9tablies et moins de poign\u00e9es de main sont effectu\u00e9es. Cela r\u00e9duit les temps d'attente et \u00e9conomise des cycles serveur, ce qui a des effets directs sur <strong>Temps de chargement<\/strong> et d\u00e9bit. Lors des tests, le temps est r\u00e9duit de moiti\u00e9, passant d'environ 1 190 ms \u00e0 environ 588 ms, soit une baisse de plus de 50 %, \u00e0 condition que le reste de la cha\u00eene ne soit pas limit\u00e9. C'est pourquoi j'ancrage toujours Keep-Alive d\u00e8s le d\u00e9but de la configuration et je contr\u00f4le les latences r\u00e9elles dans le trafic en direct.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/keepalive-serverkonfig-9142.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Les bons indicateurs<\/h2>\n\n<p>Je commence par les trois param\u00e8tres qui ont toujours un effet : l'activation, le nombre de requ\u00eates par connexion et le d\u00e9lai avant la fermeture de la <strong>Connexion<\/strong>. L'activation d\u00e9termine si la r\u00e9utilisation a lieu ou non ; le nombre maximal de requ\u00eates contr\u00f4le la dur\u00e9e pendant laquelle une connexion reste ouverte ; le d\u00e9lai d'expiration \u00e9quilibre l'\u00e9conomie et la r\u00e9activit\u00e9. Une fen\u00eatre temporelle trop grande bloque les slots et gaspille de la RAM, car les sockets inactifs restent en place et les workers manquent. Une fen\u00eatre trop courte annule les avantages, car le serveur se d\u00e9connecte trop t\u00f4t et doit red\u00e9marrer. Je m'en tiens \u00e0 des valeurs par d\u00e9faut modestes et ne les augmente que lorsque les mesures confirment de r\u00e9els temps d'attente en mode veille.<\/p>\n\n<h2>HTTP\/1.1 vs HTTP\/2\/3 : classification<\/h2>\n\n<p>Keep-Alive fonctionne par connexion TCP. Avec HTTP\/1.1, plusieurs requ\u00eates se partagent une ligne les unes apr\u00e8s les autres, avec HTTP\/2, plusieurs <strong>flux<\/strong> multiplex\u00e9s via une seule connexion, HTTP\/3 utilise QUIC au lieu de TCP. Voici mon avis \u00e0 ce sujet : un d\u00e9lai d'expiration court reste utile m\u00eame avec HTTP\/2, car les flux inactifs ont un co\u00fbt \u2013 la connexion continue de consommer des ressources, en particulier dans le cas de <strong>TLS<\/strong>. Nginx dispose de sa propre fen\u00eatre d'inactivit\u00e9 pour HTTP\/2 ; je veille \u00e0 ce que les valeurs globales Keep-Alive et les valeurs limites sp\u00e9cifiques \u00e0 HTTP\/2 correspondent entre elles et ne soient pas trop \u00e9lev\u00e9es. Important : Nginx ne communique actuellement qu'avec le client HTTP\/2 ; il maintient le backend <strong>HTTP\/1.1<\/strong>ouvertes. Upstream-Keepalive reste donc obligatoire afin de conserver l'avantage de bout en bout. Des principes similaires s'appliquent \u00e0 HTTP\/3 : m\u00eame si QUIC masque mieux les pertes, un canal ouvert depuis longtemps et inutilis\u00e9 co\u00fbte de la m\u00e9moire et des descripteurs de fichiers. Mon approche reste donc conservatrice : fen\u00eatres d'inactivit\u00e9 courtes, limites claires, et mieux vaut une reconnexion propre qu'une attente sans fin.<\/p>\n\n<h2>Consid\u00e9ration pragmatique de la surcharge TLS<\/h2>\n\n<p>TLS augmente encore davantage les \u00e9conomies r\u00e9alis\u00e9es gr\u00e2ce \u00e0 Keep-Alive, car les handshakes sont plus co\u00fbteux que les simples constructions TCP. Avec TLS 1.3 et Session-Resumption, la charge diminue, mais au final, chaque nouvelle connexion \u00e9vit\u00e9e est un gain. Je v\u00e9rifie trois points dans la pratique : premi\u00e8rement, si le serveur utilise correctement la reprise de session (ne pas laisser les tickets expirer trop t\u00f4t). Deuxi\u00e8mement, si des chiffrements puissants et des protocoles modernes sont actifs sans forcer inutilement les anciens clients. Troisi\u00e8mement, si l'utilisation du CPU reste stable en cas de parall\u00e9lisme \u00e9lev\u00e9. M\u00eame avec la reprise, des fen\u00eatres de keep-alive courtes et stables \u00e9vitent des pics suppl\u00e9mentaires du CPU, car moins de n\u00e9gociations sont lanc\u00e9es. En m\u00eame temps, avec des fen\u00eatres trop longues, je n'emp\u00eache pas les poign\u00e9es de main, mais je d\u00e9place la charge vers l'inactivit\u00e9, ce qui est la variante la plus co\u00fbteuse.<\/p>\n\n<h2>Apache : param\u00e8tres recommand\u00e9s<\/h2>\n\n<p>Avec Apache, j'active KeepAlive sur <strong>On<\/strong>, d\u00e9finissez MaxKeepAliveRequests sur 300-500 et s\u00e9lectionnez g\u00e9n\u00e9ralement une fen\u00eatre temporelle de 2-3 secondes. La valeur 0 pour le nombre maximal de requ\u00eates semble tentante, mais une valeur illimit\u00e9e est rarement judicieuse, car les connexions durent alors trop longtemps. <strong>coller<\/strong>. Pour les applications tr\u00e8s fr\u00e9quent\u00e9es avec des clients stables, je teste 5 \u00e0 10 secondes ; en cas de pics avec de nombreuses visites courtes, je descends \u00e0 1 \u00e0 2 secondes. Il est important de commencer par r\u00e9duire le d\u00e9lai d'expiration, puis d'ajuster plus pr\u00e9cis\u00e9ment le nombre de requ\u00eates afin que les slots ne soient pas bloqu\u00e9s par l'inactivit\u00e9. Si vous n'avez pas acc\u00e8s \u00e0 la configuration principale, vous pouvez contr\u00f4ler le comportement de connexion par r\u00e9pertoire via mod_headers, \u00e0 condition que l'h\u00e9bergeur ait activ\u00e9 cette option.<\/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\/01\/webserver_meeting_7632.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Nginx : r\u00e9glage judicieux<\/h2>\n\n<p>Sous Nginx, Keep-Alive est activ\u00e9 par d\u00e9faut, c'est pourquoi je pr\u00eate particuli\u00e8rement attention au d\u00e9lai d'expiration, aux exceptions du navigateur et au nombre par connexion. Avec keepalive_timeout, je d\u00e9finis le nombre de secondes ouvertes, que j'ajuste progressivement de 1 \u00e0 5 secondes en fonction du mod\u00e8le de trafic ; en cas d'appels API nombreux, 10 secondes peuvent \u00e9galement \u00eatre judicieuses. Avec keepalive_disable, j'exclue les anciens clients probl\u00e9matiques afin qu'ils ne puissent pas <strong>Sessions<\/strong> . Pour les proxys invers\u00e9s vers les flux ascendants, j'utilise \u00e9galement upstream keepalive afin que Nginx r\u00e9utilise les connexions vers le backend et y lie moins de workers. Je maintiens ainsi la coh\u00e9rence du chemin de bout en bout et emp\u00eache les <strong>s\u00e9parations<\/strong> au milieu du flux de requ\u00eates.<\/p>\n\n<h2>Proxy inverse et transfert d'en-t\u00eate<\/h2>\n\n<p>Dans les configurations \u00e0 plusieurs niveaux, j'ai besoin d'une <strong>Strat\u00e9gie<\/strong>, qui transmet correctement les en-t\u00eates HTTP\/1.1 et ne remplace pas accidentellement les valeurs de connexion. Nginx doit communiquer en HTTP\/1.1 avec le backend et tol\u00e9rer explicitement Keep-Alive, tandis qu'Apache utilise les fen\u00eatres temporelles appropri\u00e9es en arri\u00e8re-plan. Les configurations qui forcent Connection: close ou perturbent les chemins de mise \u00e0 niveau sont critiques, car elles annulent le gain suppos\u00e9. Sous Apache, je peux contr\u00f4ler via mod_headers pour chaque emplacement si les connexions restent ouvertes et quelles informations suppl\u00e9mentaires sont d\u00e9finies. Tous les n\u0153uds doivent poursuivre le m\u00eame objectif, sinon un maillon cr\u00e9e la <strong>effet de freinage<\/strong>, que je voulais justement \u00e9viter.<\/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\/01\/keepalive-server-konfigurieren-0923.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>CDN, \u00e9quilibreurs de charge et configurations cloud<\/h2>\n\n<p>Si un CDN ou un \u00e9quilibreur de charge est install\u00e9 en amont, la plupart des connexions client aboutissent l\u00e0. L'origine b\u00e9n\u00e9ficie alors principalement de connexions permanentes et peu nombreuses entre la p\u00e9riph\u00e9rie et l'origine. Je veille \u00e0 ce que l'\u00e9quilibreur fonctionne \u00e9galement avec des fen\u00eatres d'inactivit\u00e9 courtes et que le regroupement de connexions vers le backend soit activ\u00e9. Dans les environnements conteneuris\u00e9s et cloud, le flux de vidange est \u00e9galement important : avant une mise \u00e0 jour progressive, j'envoie le n\u0153ud dans le <strong>Drainage<\/strong>-Status, je laisse les connexions ouvertes expirer rapidement (d\u00e9lai d'attente pas trop long) et je ne lance le remplacement qu'ensuite. Cela me permet d'\u00e9viter les requ\u00eates interrompues et les connexions zombies restantes. Les sessions persistantes (par exemple via des cookies) peuvent fragmenter les pools de connexions ; dans la mesure du possible, je mise sur des connexions \u00e0 faible \u00e9tat. <strong>back-ends<\/strong> ou des magasins de sessions externes afin que la r\u00e9utilisation s'applique de mani\u00e8re uniforme.<\/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\/01\/keepalive_webserver_buero_4621.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vitesse d'h\u00e9bergement dans la pratique<\/h2>\n\n<p>De nombreux environnements partag\u00e9s d\u00e9sactivent Keep-Alive afin de <strong>Slots<\/strong> \u00e9conomiser, mais les pages deviennent lentes et perdent leur interactivit\u00e9. Je v\u00e9rifie donc d\u00e8s le d\u00e9but, \u00e0 l'aide de tests de temps de chargement, si le serveur autorise la r\u00e9utilisation et \u00e0 quoi ressemblent les phases de connexion dans le diagramme en cascade. Si l'outil d\u00e9tecte de longs blocs de handshake entre de nombreux petits actifs, cela signifie g\u00e9n\u00e9ralement que la r\u00e9utilisation fait d\u00e9faut ou que le d\u00e9lai d'attente se termine trop t\u00f4t. Pour affiner les r\u00e9glages, je m'aide d'un guide structur\u00e9 tel que ce guide compact. <a href=\"https:\/\/webhosting.de\/fr\/http-keep-alive-reglage-charge-du-serveur-optimisation-des-performances-flux\/\">R\u00e9glage Keep Alive<\/a>, afin que je puisse effectuer les \u00e9tapes proprement. Cela m'\u00e9vite d'avoir \u00e0 deviner et me permet d'obtenir un r\u00e9sultat tangible en quelques gestes seulement. <strong>\u00e9lan<\/strong> \u00e0 l'avant.<\/p>\n\n<h2>D\u00e9lais d'attente, limites et comportement du navigateur<\/h2>\n\n<p>Les navigateurs modernes ouvrent plusieurs fen\u00eatres parall\u00e8les par h\u00f4te. <strong>Connexions<\/strong>, souvent six, et \u00e9puisent ainsi rapidement la capacit\u00e9 Keep-Alive. Un MaxKeepAliveRequests de 300 suffit dans la pratique pour de nombreux visiteurs simultan\u00e9s, \u00e0 condition que le d\u00e9lai d'expiration ne soit pas inutilement \u00e9lev\u00e9. Si je r\u00e8gle la fen\u00eatre sur trois secondes, des emplacements restent disponibles et le serveur donne la priorit\u00e9 aux clients actifs plut\u00f4t qu'\u00e0 l'inactivit\u00e9. Ce n'est que lorsque les requ\u00eates s'interrompent r\u00e9guli\u00e8rement ou que la r\u00e9utilisation ne fonctionne pas que j'augmente la limite par paliers mod\u00e9r\u00e9s. Les pages comportant de nombreux flux HTTP\/2 doivent \u00eatre consid\u00e9r\u00e9es s\u00e9par\u00e9ment. Les d\u00e9tails sont r\u00e9sum\u00e9s dans <a href=\"https:\/\/webhosting.de\/fr\/multiplexage-http2-vs-performances-http11-contexte-optimisation\/\">Multiplexage HTTP\/2<\/a> tr\u00e8s compact, afin que je puisse classer proprement l'utilisation des canaux et le keep-alive.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Param\u00e8tres<\/th>\n      <th>Directive Apache<\/th>\n      <th>Directive Nginx<\/th>\n      <th>valeur indicative<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>Activation<\/strong><\/td>\n      <td>KeepAlive activ\u00e9<\/td>\n      <td>actif par d\u00e9faut<\/td>\n      <td>Toujours activer<\/td>\n      <td>Sans r\u00e9utilisation, cela augmente <strong>Overhead<\/strong>.<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>D\u00e9lai d'attente<\/strong><\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>2 \u00e0 5 s<\/td>\n      <td>Plus court pour de nombreux appels courts, plus long pour <strong>APIs<\/strong>.<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Nombre\/Conn<\/strong><\/td>\n      <td>MaxKeepAliveRequests<\/td>\n      <td>keepalive_requests<\/td>\n      <td>300\u2013500<\/td>\n      <td>Limite l'engagement des ressources par <strong>Client<\/strong>.<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Exceptions du navigateur<\/strong><\/td>\n      <td>-<\/td>\n      <td>keepalive_disable<\/td>\n      <td>s\u00e9lectif<\/td>\n      <td>D\u00e9sactiver pour les tr\u00e8s anciens <strong>Clients<\/strong>.<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>en amont<\/strong><\/td>\n      <td>ProxyKeepAlive<\/td>\n      <td>maintien de connexion en amont<\/td>\n      <td>actif<\/td>\n      <td>Assure la r\u00e9utilisation Direction <strong>Backend<\/strong>.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Limites du syst\u00e8me d'exploitation et sockets<\/h2>\n\n<p>Au niveau du syst\u00e8me d'exploitation, les descripteurs de fichiers et les param\u00e8tres de socket limitent la capacit\u00e9 r\u00e9elle. Je v\u00e9rifie ulimit -n, les limites du processus et du syst\u00e8me, ainsi que la configuration du serveur web (par exemple worker_connections chez Nginx). Keep-Alive r\u00e9duit certes le nombre de nouvelles connexions, mais augmente la dur\u00e9e pendant laquelle les descripteurs restent occup\u00e9s. Pendant les p\u00e9riodes de forte fr\u00e9quentation, une pression TIME_WAIT peut appara\u00eetre lorsque les connexions se ferment tr\u00e8s rapidement. Dans ce cas, une r\u00e9utilisation propre est pr\u00e9f\u00e9rable \u00e0 des hacks agressifs du noyau. Je fais une distinction claire entre HTTP-<strong>Keep-Alive<\/strong> (protocole d'application) et les sondes TCP Keepalive du noyau : ces derni\u00e8res sont de simples paquets de signes de vie, \u00e0 ne pas confondre avec la fen\u00eatre HTTP ouverte. Je ne modifie les param\u00e8tres par d\u00e9faut du noyau qu'avec un point de mesure et j'interviens en priorit\u00e9 sur le serveur web lui-m\u00eame : des d\u00e9lais d'inactivit\u00e9 courts mais efficaces, un nombre limit\u00e9 de requ\u00eates par connexion et des r\u00e9serves de travail raisonnables.<\/p>\n\n<h2>S\u00e9curit\u00e9 : d\u00e9samorcer Slowloris &amp; Co.<\/h2>\n\n<p>Des valeurs Keep-Alive trop g\u00e9n\u00e9reuses invitent \u00e0 l'abus. Je limite donc non seulement les temps d'inactivit\u00e9, mais aussi les d\u00e9lais d'attente de lecture et de corps. Sous Nginx, j'utilise client_header_timeout et client_body_timeout ; sous Apache, je d\u00e9finis des limites de lecture strictes \u00e0 l'aide de modules appropri\u00e9s afin qu'aucune requ\u00eate lente ne bloque les workers. Les limites de taille d'en-t\u00eate et de corps de requ\u00eate emp\u00eachent en outre le gonflement de la m\u00e9moire. Associ\u00e9es \u00e0 des fen\u00eatres Keep-Alive mod\u00e9r\u00e9es, elles r\u00e9duisent le risque que quelques clients occupent de nombreux sockets. L'ordre reste important : d'abord des d\u00e9lais d'expiration corrects, puis des limites cibl\u00e9es, enfin des r\u00e8gles li\u00e9es au d\u00e9bit ou \u00e0 l'adresse IP. C'est la seule fa\u00e7on de garantir la rapidit\u00e9 des utilisateurs r\u00e9els, tandis que les profils d'attaque restent sans effet.<\/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\/01\/keepalive_config_setup_5723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Surveillance et tests de charge<\/h2>\n\n<p>Apr\u00e8s chaque modification, je mesure l'effet \u00e0 l'aide d'outils tels que ab, wrk ou k6 et je regarde le 95e centile de la <strong>Latence<\/strong>. Je r\u00e9duis d'abord le d\u00e9lai d'attente par paliers clairs et observe si les d\u00e9lais d'attente ou les interruptions de connexion augmentent ; j'ajuste ensuite le nombre de requ\u00eates par connexion. En parall\u00e8le, j'\u00e9value les sockets ouverts, la charge de travail et les besoins en m\u00e9moire afin de r\u00e9duire les temps morts au bon endroit. Pour les temps d'attente r\u00e9currents, il est utile de jeter un \u0153il aux files d'attente dans le backend, mot-cl\u00e9 <a href=\"https:\/\/webhosting.de\/fr\/serveur-web-file-dattente-latence-traitement-des-requetes-file-dattente-du-serveur\/\">Mise en file d'attente du serveur<\/a> et la r\u00e9partition des demandes. Ceux qui travaillent avec des points de mesure identifient rapidement les goulots d'\u00e9tranglement et gagnent un temps pr\u00e9cieux. <strong>D\u00e9pannage<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/webserver-keepalive-4812.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pratiques en mati\u00e8re de journaux et de m\u00e9triques<\/h2>\n\n<p>Je veux voir si les connexions sont r\u00e9ellement r\u00e9utilis\u00e9es. Sous Nginx, j'\u00e9tends le format du journal pour inclure les compteurs de connexion et les dur\u00e9es ; les valeurs m'indiquent si les clients envoient beaucoup de requ\u00eates par connexion ou s'ils ferment apr\u00e8s un ou deux acc\u00e8s. Je proc\u00e8de de la m\u00eame mani\u00e8re avec Apache afin de visualiser le nombre de requ\u00eates par connexion. Cela me permet d'identifier les mod\u00e8les qui b\u00e9n\u00e9ficient davantage du d\u00e9lai d'expiration ou de la limite de requ\u00eates.<\/p>\n\n<pre><code># Nginx : exemple de format de journal \u00e9tendu log_format main_ext '$remote_addr $request ' 'conn=$connection reqs=$connection_requests ' 'rt=$request_time uct=$upstream_connect_time';\n\naccess_log \/var\/log\/nginx\/access.log main_ext ;\n<\/code><\/pre>\n\n<pre><code># Apache : LogFormat avec connexion et dur\u00e9e LogFormat \" %h %r conn:%{c}L reqs:%{REQUESTS_PER_CONN}n time:%D \" keepalive CustomLog logs\/access_log keepalive\n<\/code><\/pre>\n\n<p>Dans le cadre du monitoring, outre la m\u00e9diane, je m'int\u00e9resse surtout aux latences P95\/P99, aux connexions actives, \u00e0 la r\u00e9partition des requ\u00eates\/connexions et aux erreurs (augmentation des 408\/499). Si celles-ci augmentent avec une fen\u00eatre Keep-Alive plus petite, je r\u00e9duis mod\u00e9r\u00e9ment ; si la charge reste stable et la latence meilleure, j'ai trouv\u00e9 le juste milieu.<\/p>\n\n<h2>D\u00e9ploiement et red\u00e9marrages progressifs<\/h2>\n\n<p>Les rechargements et les mises \u00e0 niveau sont compatibles avec Keep-Alive si je les planifie correctement. Avec Nginx, je mise sur des rechargements fluides et laisse les connexions Worker se d\u00e9rouler de mani\u00e8re contr\u00f4l\u00e9e au lieu de les couper brutalement. De courts d\u00e9lais d'inactivit\u00e9 permettent de lib\u00e9rer plus rapidement les anciens Worker. Sous Apache, j'utilise un <strong>graceful<\/strong>-Red\u00e9marrez et surveillez en parall\u00e8le mod_status ou les pages d'\u00e9tat afin que les requ\u00eates en attente ne soient pas interrompues. Avant les d\u00e9ploiements importants, je r\u00e9duis temporairement la fen\u00eatre Keep-Alive afin de vider le syst\u00e8me plus rapidement, puis je la ram\u00e8ne \u00e0 la valeur cible apr\u00e8s avoir v\u00e9rifi\u00e9 la stabilit\u00e9. Important : documentez les modifications et comparez-les avec les profils de charge afin d'\u00e9viter que des ralentissements passent inaper\u00e7us. <strong>R\u00e9gressions<\/strong> s'insinuer.<\/p>\n\n<h2>Erreurs fr\u00e9quentes et mesures correctives<\/h2>\n\n<p>Des cr\u00e9neaux horaires trop longs maintiennent les utilisateurs inactifs <strong>Connexions<\/strong> ouvertes et reportent le probl\u00e8me vers des goulots d'\u00e9tranglement au niveau des travailleurs, ce qui ralentit sensiblement les nouveaux visiteurs. Les requ\u00eates illimit\u00e9es par connexion semblent \u00e9l\u00e9gantes, mais au final, la connexion par socket augmente et les pics de charge deviennent incontr\u00f4lables. Des fen\u00eatres extr\u00eamement courtes, inf\u00e9rieures \u00e0 une seconde, obligent les navigateurs \u00e0 se reconstruire en permanence, ce qui augmente les parts de handshake et rend le frontend saccad\u00e9. Les cha\u00eenes de proxy manquent souvent de coh\u00e9rence : un maillon utilise HTTP\/1.0 ou d\u00e9finit Connection: close, ce qui emp\u00eache la r\u00e9utilisation. Je proc\u00e8de donc dans l'ordre suivant : v\u00e9rifier l'activation, ajuster les d\u00e9lais d'attente par petits paliers, adapter les requ\u00eates par connexion et ne les augmenter que si les mesures montrent un r\u00e9el <strong>Avantages<\/strong> montrer.<\/p>\n\n<h2>Liste de contr\u00f4le pour une mise en \u0153uvre rapide<\/h2>\n\n<p>Je commence par activer Keep-Alive et noter l'heure actuelle. <strong>Valeurs<\/strong>, afin de pouvoir revenir en arri\u00e8re \u00e0 tout moment. Ensuite, je r\u00e8gle le d\u00e9lai d'expiration sur trois secondes, je recharge la configuration et je v\u00e9rifie les connexions ouvertes, la charge et les cascades dans le frontend. Si de nombreuses visites courtes interviennent, je r\u00e9duis le d\u00e9lai \u00e0 deux secondes ; si les API Long Polls s'accumulent, j'augmente mod\u00e9r\u00e9ment le d\u00e9lai \u00e0 cinq \u00e0 dix secondes. Je r\u00e8gle ensuite MaxKeepAliveRequests sur 300-500 et observe si des slots restent libres ou si des clients permanents puissants occupent les connexions trop longtemps. Apr\u00e8s chaque \u00e9tape, je mesure \u00e0 nouveau, documente les effets et conserve la meilleure configuration. <strong>Combinaison<\/strong> fixe.<\/p>\n\n<h2>Bilan succinct<\/h2>\n\n<p>Une configuration correcte de Keep-Alive permet d'\u00e9conomiser des handshakes, de r\u00e9duire la latence et d'offrir plus de <strong>air<\/strong> par requ\u00eate. Avec des fen\u00eatres temporelles courtes, mais pas trop courtes, et un nombre mod\u00e9r\u00e9 de requ\u00eates par connexion, l'h\u00f4te fonctionne de mani\u00e8re nettement plus fluide. Je mise sur de petites modifications avec des points de mesure clairs, plut\u00f4t que de tourner aveugl\u00e9ment vers des valeurs maximales. En orientant de mani\u00e8re coh\u00e9rente l'h\u00e9bergement, le proxy inverse et le backend vers la r\u00e9utilisation, on gagne en rapidit\u00e9 d'interaction sans mobiliser inutilement des ressources. Au final, c'est la mesure qui compte : seuls les indicateurs r\u00e9els montrent si le r\u00e9glage a produit les r\u00e9sultats escompt\u00e9s. <strong>Effet<\/strong> apporte.<\/p>","protected":false},"excerpt":{"rendered":"<p>Configurer correctement le serveur web Keep Alive : comment \u00e9viter les ralentissements silencieux et doubler votre vitesse d'h\u00e9bergement avec Apache et Nginx Tuning.<\/p>","protected":false},"author":1,"featured_media":16430,"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-16437","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":"1676","_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":"Keep Alive Webserver","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":"16430","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16437","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=16437"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16437\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/16430"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=16437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=16437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=16437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}