{"id":18056,"date":"2026-03-03T18:23:49","date_gmt":"2026-03-03T17:23:49","guid":{"rendered":"https:\/\/webhosting.de\/http-keepalive-timeout-server-performance-konfiguration\/"},"modified":"2026-03-03T18:23:49","modified_gmt":"2026-03-03T17:23:49","slug":"http-keepalive-timeout-configuration-de-la-performance-du-serveur","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/http-keepalive-timeout-server-performance-konfiguration\/","title":{"rendered":"HTTP Keep-Alive Timeout : configuration optimale pour les performances du serveur"},"content":{"rendered":"<p>En mettant l'accent sur <strong>HTTP Keep-Alive Timeout<\/strong> je te montre comment r\u00e9gler les temps d'inactivit\u00e9 de mani\u00e8re \u00e0 ce que les connexions soient r\u00e9utilis\u00e9es sans bloquer les threads. J'explique des valeurs concr\u00e8tes, je montre des pi\u00e8ges typiques et je fournis des configurations \u00e9prouv\u00e9es pour <strong>nginx<\/strong>, Apache et le syst\u00e8me d'exploitation.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>Balance<\/strong>: trop court augmente les poign\u00e9es de main, trop long bloque les threads.<\/li>\n  <li><strong>Valeurs<\/strong>: G\u00e9n\u00e9ralement 5-15 s et 100-500 requ\u00eates par connexion.<\/li>\n  <li><strong>Coordination<\/strong>: coordonner les timeouts du client, du LB et du pare-feu.<\/li>\n  <li><strong>Cas sp\u00e9ciaux<\/strong>: traiter s\u00e9par\u00e9ment les WebSockets, SSE, Long Polling.<\/li>\n  <li><strong>Suivi<\/strong>: Observer les sockets ouverts, les FD et les latences.<\/li>\n<\/ul>\n\n<h2>HTTP Keep-Alive en bref<\/h2>\n<p>Je maintiens les connexions TCP avec <strong>Keep-Alive<\/strong> ouvert pour que plusieurs requ\u00eates utilisent la m\u00eame ligne. Cela me permet d'\u00e9conomiser des handshakes TCP et TLS r\u00e9p\u00e9t\u00e9s et de r\u00e9duire la charge de travail. <strong>CPU<\/strong>-Overhead se fait sentir. Cela s'av\u00e8re particuli\u00e8rement utile pour les nombreux petits fichiers tels que les ic\u00f4nes, JSON ou CSS. Chaque nouvelle connexion \u00e9vit\u00e9e r\u00e9duit les changements de contexte et all\u00e8ge les routines du noyau. Dans les benchmarks avec une forte proportion de GET, la dur\u00e9e totale diminue nettement, car il y a moins de paquets SYN\/ACK et plus de temps de calcul est consacr\u00e9 \u00e0 la logique de l'application.<\/p>\n<p>Je mesure rapidement l'effet : les latences moyennes flottantes deviennent plus lisses et le nombre de nouvelles connexions TCP par seconde diminue. Je n'obtiens pas cela par magie, mais gr\u00e2ce \u00e0 <strong>Recours \u00e0 la connexion<\/strong> et des limites raisonnables. Il est important de noter que Keep-Alive ne remplace pas un rendu rapide ou une mise en cache. Il r\u00e9duit les temps d'attente \u00e0 la fronti\u00e8re du r\u00e9seau, tandis que l'application elle-m\u00eame doit continuer \u00e0 r\u00e9pondre efficacement. Ces deux \u00e9l\u00e9ments combin\u00e9s mettent en valeur la <strong>Performance<\/strong> de mani\u00e8re perceptible.<\/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\/03\/server-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendre le bon d\u00e9lai d'attente<\/h2>\n<p>Le d\u00e9lai d'attente d\u00e9termine la dur\u00e9e pendant laquelle une connexion inactive reste ouverte avant que le serveur ne la ferme. <strong>ferme<\/strong>. Si je le fais trop court, les clients ouvrent constamment de nouvelles connexions TCP, ce qui <strong>Overhead<\/strong> de l'ordinateur. Si je le fixe \u00e0 une dur\u00e9e trop longue, les connexions en mode veille parquent des travailleurs ou des threads pr\u00e9cieux. Tout l'art consiste \u00e0 trouver un \u00e9quilibre entre la r\u00e9utilisation et la consommation de ressources. Je teste de mani\u00e8re pratique : d'abord un r\u00e9glage approximatif, puis un ajustement fin \u00e0 l'aide de tests de charge.<\/p>\n<p>Je fais en outre attention au rapport entre les temps de r\u00e9ponse et les fen\u00eatres d'inactivit\u00e9. Si l'interaction typique de l'utilisateur entre deux clics est de 2 \u00e0 4 secondes, 5 \u00e0 15 secondes de d\u00e9lai d'attente couvrent g\u00e9n\u00e9ralement le mod\u00e8le r\u00e9el. Les appels API courts supportent facilement 5-10 secondes, les charges de travail m\u00e9dias plut\u00f4t 10-15 secondes. Il est important de noter que je n'exag\u00e8re pas : les timeouts trop longs entra\u00eenent rarement une augmentation des performances. <strong>D\u00e9bit<\/strong>, mais qui entra\u00eenent souvent des blocages <strong>Ressources<\/strong>. Je le constate rapidement \u00e0 l'augmentation du nombre de sockets ouverts et du nombre de FD.<\/p>\n\n<h2>S\u00e9parer proprement les types de timeout<\/h2>\n<p>Je fais une distinction stricte entre <strong>D\u00e9lai d'attente en mode veille<\/strong> (Keep-Alive), <strong>D\u00e9lai de lecture\/d'en-t\u00eate<\/strong> (combien de temps le serveur attend les requ\u00eates entrantes) et <strong>Timeout d'envoi\/d'\u00e9criture<\/strong> (combien de temps l'envoi en direction du client est tol\u00e9r\u00e9). Ces cat\u00e9gories remplissent des fonctions diff\u00e9rentes :<\/p>\n<ul>\n  <li><strong>D\u00e9lai d'attente en mode veille :<\/strong> Contr\u00f4le la r\u00e9utilisation et la dur\u00e9e de stationnement des connexions inactives.<\/li>\n  <li><strong>D\u00e9lai d'attente de lecture\/en-t\u00eate :<\/strong> Prot\u00e8ge contre les clients lents (slowloris) et les en-t\u00eates \u00e0 moiti\u00e9 envoy\u00e9s.<\/li>\n  <li><strong>Timeout d'envoi\/d'\u00e9criture :<\/strong> Emp\u00eache le serveur d'attendre ind\u00e9finiment une r\u00e9ception lente chez le client.<\/li>\n<\/ul>\n<p>\u00c0 l'adresse suivante : <strong>nginx<\/strong> j'utilise d\u00e9lib\u00e9r\u00e9ment, en plus de keepalive_timeout, header_timeout\/read_timeout et send_timeout par contexte (http\/server\/localisation). Depuis les versions r\u00e9centes, j'utilise en option <strong>keepalive_time<\/strong>, pour plafonner la dur\u00e9e de vie maximale d'une connexion, m\u00eame si elle reste active. Dans <strong>Apache<\/strong> j'utilise en compl\u00e9ment <strong>RequestReadTimeout<\/strong> (mod_reqtimeout) et v\u00e9rifie <strong>D\u00e9lai d'attente<\/strong> (global) s\u00e9par\u00e9 de <strong>KeepAliveTimeout<\/strong>. Cette s\u00e9paration est un \u00e9l\u00e9ment important contre l'engagement de ressources sans utilit\u00e9 r\u00e9elle.<\/p>\n\n<h2>Valeurs recommand\u00e9es dans la pratique<\/h2>\n<p>Pour les environnements productifs, je fixe un d\u00e9lai d'attente de 5 \u00e0 15 secondes et 100 \u00e0 500 requ\u00eates par connexion. Cette fourchette permet d'atteindre de bons taux d'utilisation des connexions et de limiter le nombre de connexions dormantes. Sur <strong>nginx<\/strong> j'utilise keepalive_timeout 10s comme valeur de d\u00e9part et keepalive_requests 200. En cas de trafic tr\u00e8s important, j'augmente mod\u00e9r\u00e9ment si je vois trop de nouvelles connexions TCP. Si le trafic est faible, je diminue \u00e0 nouveau afin d'\u00e9viter une vague d'inactivit\u00e9.<\/p>\n<p>Ceux qui vont plus loin profitent d'un processus de r\u00e9glage clair avec des points de mesure. Pour ce faire, je r\u00e9sume mes lignes directrices dans un guide pratique qui d\u00e9crit le parcours de la mesure au contr\u00f4le en passant par la configuration. Pour un d\u00e9marrage rapide, je renvoie \u00e0 mes \u00e9tapes dans <a href=\"https:\/\/webhosting.de\/fr\/http-keep-alive-reglage-charge-du-serveur-optimisation-des-performances-flux\/\">R\u00e9glage Keep Alive<\/a>. Comment contr\u00f4ler <strong>R\u00e9utilisation<\/strong> et les limites et \u00e9vite les surprises. En fin de compte, ce qui compte, c'est une faible latence et une stabilit\u00e9 des donn\u00e9es. <strong>D\u00e9bit<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/http-keep-alive-optimierung-1723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Risques de temps morts trop longs<\/h2>\n<p>Un long timeout maintient artificiellement les connexions <strong>ouvert<\/strong> et bloque les travailleurs bien qu'aucune requ\u00eate ne suive. Cela fait gonfler les sockets et fait grimper le nombre de descripteurs de fichiers. Lorsque le processus atteint ses limites, je vois des erreurs d'acceptation de rejet ou des files d'attente lors de l'\u00e9tablissement de la connexion. La m\u00e9moire augmente, le garbage collector ou l'allocator co\u00fbtent du temps suppl\u00e9mentaire et la latence augmente. En cas d'erreur, les clients envoient des messages sur des sockets d\u00e9j\u00e0 ferm\u00e9es et re\u00e7oivent des messages crypt\u00e9s. <strong>Erreur<\/strong>.<\/p>\n<p>J'\u00e9vite cela en fixant des valeurs mod\u00e9r\u00e9es et en v\u00e9rifiant r\u00e9guli\u00e8rement les m\u00e9triques. Si les connexions en mode veille augmentent trop en cas de faible charge, j'abaisse le d\u00e9lai d'attente. Si je vois beaucoup de nouvelles connexions par seconde pendant les pics de trafic, je l'augmente prudemment par petites \u00e9tapes. C'est ainsi que je maintiens la <strong>Capacit\u00e9<\/strong> et \u00e9vite les connexions mortes. Le r\u00e9sultat est un syst\u00e8me plus calme avec moins de <strong>Pointes<\/strong> dans les virages.<\/p>\n\n<h2>Configuration : nginx, Apache et couche OS<\/h2>\n<p>Je commence au niveau du serveur web et je d\u00e9finis le d\u00e9lai d'attente et les limites. Sur <strong>nginx<\/strong> je r\u00e8gle keepalive_timeout 5-15s et keepalive_requests 100-500. Dans Apache avec event-MPM, je combine KeepAlive On, KeepAliveTimeout 5-15 et MaxKeepAliveRequests 100-500. Ensuite, je calibre les pools de travailleurs ou de threads en fonction de la charge attendue. Cela \u00e9vite que les alives de mise en veille ne deviennent productifs. <strong>Slots<\/strong> lier.<\/p>\n<p>Au niveau du syst\u00e8me d'exploitation, j'augmente les limites et les files d'attente. Je fixe ulimit -n \u00e0 au moins 100.000, j'ajuste net.core.somaxconn et tcp_max_syn_backlog et je v\u00e9rifie la gestion de TIME_WAIT. Je m'assure ainsi que le noyau et le processus ont suffisamment de <strong>Ressources<\/strong> pour les mettre \u00e0 disposition. Pour finir, je v\u00e9rifie les chemins du NIC \u00e0 l'app en passant par l'\u00e9quilibrage des IRQ. Cela me permet de rep\u00e9rer \u00e0 temps les goulets d'\u00e9tranglement et de maintenir les <strong>Latence<\/strong> bas.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Composant<\/th>\n      <th>Directive\/Setting<\/th>\n      <th>Recommandation<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>5 \u00e0 15 s<\/td>\n      <td><strong>Plus court<\/strong> en cas de faible trafic, plus long en cas de nombreuses petites requ\u00eates<\/td>\n    <\/tr>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_requests<\/td>\n      <td>100\u2013500<\/td>\n      <td>Recycle les compos\u00e9s et r\u00e9duit <strong>Leaks<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Apache (\u00e9v\u00e9nement)<\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>5 \u00e0 15 s<\/td>\n      <td>Event-MPM g\u00e8re Idle plus efficacement que <strong>prefork<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Syst\u00e8me d'exploitation<\/td>\n      <td>ulimit -n<\/td>\n      <td>\u2265 100.000<\/td>\n      <td>Plus de DA ouverts pour beaucoup <strong>Prises<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Syst\u00e8me d'exploitation<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>Augmenter<\/td>\n      <td>Moins de connexions refus\u00e9es sous <strong>Charge de pointe<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/server-optimization-http-keep-alive-4317.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Proxy inverse et r\u00e9utilisation en amont<\/h2>\n<p>Je pense Keep-Alive toujours <strong>de bout en bout<\/strong>. Derri\u00e8re le serveur Edge se trouve souvent une cha\u00eene de serveurs d'applications Reverse Proxy \u2192. Pour nginx, j'active sur la page amont mes propres <strong>Piscines Keep-Alive<\/strong> (upstream keepalive, keepalive_requests, keepalive_timeout), d\u00e9finir proxy_http_version 1.1 et supprimer \u201eConnection : close\u201c. Ainsi, j'\u00e9conomise aussi <em>interne<\/em> handshake et d\u00e9leste les backends d'apps (Node.js, Java, PHP-FPM). Dans Apache avec mod_proxy, je garde \u00e9galement des connexions persistantes vers les serveurs backend et je les limite par destination afin qu'un hotspot ne monopolise pas les pools.<\/p>\n<p>Je mesure s\u00e9par\u00e9ment : le taux de r\u00e9utilisation Client\u2192Edge et Edge\u2192Backend. Si je vois une bonne r\u00e9utilisation \u00e0 la p\u00e9riph\u00e9rie, mais beaucoup de nouvelles connexions au backend, j'augmente s\u00e9lectivement les pools en amont. Cela me permet de passer \u00e0 l'\u00e9chelle sans augmenter globalement les d\u00e9lais d'attente du front-end.<\/p>\n\n<h2>Travailleurs, threads et limites du syst\u00e8me d'exploitation<\/h2>\n<p>Je ne dimensionne pas les workers, les \u00e9v\u00e9nements et les threads en fonction de valeurs souhait\u00e9es, mais en fonction de <strong>profil de charge<\/strong>. Pour cela, j'observe les requ\u00eates actives, les travailleurs au repos, l'utilisation des boucles d'\u00e9v\u00e9nements et les changements de contexte. Si des threads sont parqu\u00e9s au ralenti, j'abaisse le d\u00e9lai d'attente ou les limites maximales de ralenti par thread. Si je vois un CPU \u00e0 100 % en permanence, je v\u00e9rifie les queues d'acceptation, la r\u00e9partition des IRQ et la pile r\u00e9seau. De petites corrections des limites FD et des backlogs apportent souvent de grands avantages. <strong>Effets<\/strong>.<\/p>\n<p>Je pr\u00e9vois une marge de man\u0153uvre r\u00e9aliste. Une r\u00e9serve de 20 \u00e0 30 % dans les threads et les FD me permet de faire face aux pics. Si j'exag\u00e8re, je perds des caches et le gaspillage augmente. Si j'exag\u00e8re, les requ\u00eates finissent dans des files d'attente ou expirent. Le bon \u00e9quilibre entre <strong>Capacit\u00e9<\/strong> et l'efficacit\u00e9 maintient les latences \u00e0 un niveau bas et prot\u00e8ge les <strong>Stabilit\u00e9<\/strong>.<\/p>\n\n<h2>Coordonner les d\u00e9lais d'attente des clients, des \u00e9quilibreurs de charge et des pare-feu<\/h2>\n<p>Je fixe des limites de temps tout au long du parcours pour \u00e9viter les morts. <strong>Connexions<\/strong> se produisent. Les clients ferment id\u00e9alement un peu plus t\u00f4t que le serveur. L'\u00e9quilibreur de charge ne doit pas couper plus court, sinon je vois des r\u00e9initialisations inattendues. J'int\u00e8gre les valeurs NAT et Firewall Idle, afin que les connexions ne se fassent pas dans le chemin du r\u00e9seau. <strong>disparaissent<\/strong>. Ce r\u00e9glage permet d'\u00e9viter les retransmissions et de lisser les courbes de charge.<\/p>\n<p>Avec des diagrammes clairs, je garde la cha\u00eene compr\u00e9hensible : client \u2192 LB \u2192 serveur web \u2192 app. Pour chaque maillon, je documente les timeouts d'inactivit\u00e9, les timeouts de lecture\/\u00e9criture et les strat\u00e9gies de retry. Si je modifie une valeur, je v\u00e9rifie les valeurs voisines. Ainsi, le chemin reste coh\u00e9rent et j'obtiens des r\u00e9sultats de mesure reproductibles. Cette discipline permet de gagner du temps lors de la <strong>D\u00e9pannage<\/strong> et augmente la <strong>Fiabilit\u00e9<\/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\/03\/optimal_configuration_server_9837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e9curit\u00e9 : protection contre les slowloris et l'abus d'idle<\/h2>\n<p>Ouvrir des timeouts trop g\u00e9n\u00e9reux <strong>Surfaces d'attaque<\/strong>. Je fixe donc des limites qui permettent une r\u00e9utilisation l\u00e9gitime, mais qui rendent difficile l'ouverture malveillante. Dans nginx, les limites header et read_timeout, request_headers_size et une limite sup\u00e9rieure stricte pour keepalive_requests sont utiles. Dans Apache, j'utilise mod_reqtimeout et je limite les connexions parall\u00e8les par IP. Limites de d\u00e9bit et <strong>limit_conn<\/strong> dans nginx prot\u00e8gent en outre contre les inondations de nombreuses sockets inoccup\u00e9es. Pour les points de terminaison \u00e0 longue distance, je s\u00e9pare des pools d\u00e9di\u00e9s afin que les attaques sur les flux ne lient pas les API-workers r\u00e9guliers.<\/p>\n\n<h2>Cas particuliers : long polling, SSE et WebSockets<\/h2>\n<p>Les flux longs entrent en collision avec les flux courts <strong>Timeouts<\/strong> et ont besoin de leurs propres r\u00e8gles. Je s\u00e9pare techniquement ces points finaux des routes API et des routes d'actifs classiques. Pour SSE et WebSockets, je fixe des d\u00e9lais d'attente plus \u00e9lev\u00e9s, des pools de travailleurs d\u00e9di\u00e9s et des limites strictes par IP. Avec Heartbeats ou Ping\/Pong, je garde la connexion vivante et je d\u00e9tecte rapidement les interruptions. Ainsi, les flux ne bloquent pas les threads pour les connexions r\u00e9guli\u00e8res. <strong>Requ\u00eates courtes<\/strong>.<\/p>\n<p>Je limite les connexions simultan\u00e9es et je les mesure activement. Les limites trop \u00e9lev\u00e9es consomment des FD et de la m\u00e9moire. Des limites trop \u00e9troites coupent les utilisateurs l\u00e9gitimes. Avec des m\u00e9triques propres sur les connexions ouvertes, inactives, actives et interrompues, je trouve le \"sweet spot\". Cette s\u00e9paration m'\u00e9vite d'avoir \u00e0 g\u00e9rer des <strong>Augmentations<\/strong> des timeouts et prot\u00e8ge les <strong>Capacit\u00e9<\/strong>.<\/p>\n\n<h2>HTTP\/2, multiplexage et Keep-Alive<\/h2>\n<p>HTTP\/2 multiplexe plusieurs flux via une <strong>Connexion<\/strong>, mais reste tributaire des d\u00e9lais d'attente. Je maintiens la fen\u00eatre d'inactivit\u00e9 \u00e0 un niveau mod\u00e9r\u00e9, car des sessions peuvent aussi \u00eatre parqu\u00e9es sous HTTP\/2. Les keepalive_requests \u00e9lev\u00e9s sont moins importants ici, mais un recyclage reste utile. Le head-of-line blocking se d\u00e9place au niveau des trames, je continue donc \u00e0 mesurer la latence par <strong>Flux<\/strong>. Ceux qui souhaitent approfondir la comparaison trouveront des informations de fond sur <a href=\"https:\/\/webhosting.de\/fr\/multiplexage-http2-vs-performances-http11-contexte-optimisation\/\">Multiplexage HTTP\/2<\/a>.<\/p>\n<p>Sous HTTP\/2, je surveille particuli\u00e8rement le nombre de flux actifs par connexion. Un trop grand nombre de flux parall\u00e8les peut surcharger les fils d'application. Je freine alors les limites ou augmente le nombre de serveurs. Ici aussi, la r\u00e8gle est la suivante : mesurer, ajuster, mesurer \u00e0 nouveau. Cela permet de maintenir la <strong>Temps de r\u00e9ponse<\/strong> juste et pr\u00e9serv\u00e9 <strong>Ressources<\/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\/03\/dev_desk_HTTP_timeout_4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>TLS, r\u00e9sum\u00e9s de session et HTTP\/3\/QUIC<\/h2>\n<p>Les handshakes TLS sont chers. Je mets <strong>R\u00e9somption de session<\/strong> (tickets\/IDs) et OCSP-Stapling, afin que les reconnexions soient plus rapides si une connexion se termine malgr\u00e9 tout. Sous HTTP\/3, QUIC prend en charge la couche de transport : ici, l'attribut <strong>QUIC idle timeout<\/strong> similaire \u00e0 Keep-Alive, mais bas\u00e9 sur UDP. L\u00e0 aussi, je maintiens les fen\u00eatres \u00e0 un niveau mod\u00e9r\u00e9 et je mesure les retransmissions, car les pertes de paquets ont un effet diff\u00e9rent de celui du TCP. Pour les environnements mixtes (H1\/H2\/H3), je choisis des valeurs indicatives uniformes et j'ajuste finement par protocole.<\/p>\n\n<h2>Monitoring, m\u00e9triques et tests de charge<\/h2>\n<p>Je fais plus confiance aux donn\u00e9es de mesure qu'\u00e0 mon instinct et je commence par des objectifs clairs. <strong>KPIs<\/strong>. Les \u00e9l\u00e9ments importants sont : les sockets ouverts, l'utilisation de FD, les nouvelles connexions\/s, les latences (P50\/P90\/P99), les taux d'erreur et les retransmissions. Je conduis des profils de charge r\u00e9alistes : Warmup, Plateau, Ramp-down. Ensuite, je compare les courbes avant et apr\u00e8s les modifications du timeout. Un coup d'\u0153il sur <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> aide \u00e0 interpr\u00e9ter proprement les temps d'attente.<\/p>\n<p>Je documente chaque adaptation avec un horodatage et des valeurs de mesure. Je conserve ainsi l'historique et j'identifie les corr\u00e9lations. Je prends au s\u00e9rieux les effets n\u00e9gatifs et je les att\u00e9nue rapidement. Les petites \u00e9tapes compr\u00e9hensibles font gagner beaucoup de temps. Au final, ce qui compte, c'est la stabilit\u00e9 <strong>Latence<\/strong> et faible <strong>Taux d'erreur<\/strong> en charge.<\/p>\n\n<h2>M\u00e9thodes et outils de mesure dans la pratique<\/h2>\n<ul>\n  <li><strong>Tests rapides :<\/strong> Avec des outils comme wrk, ab ou vegeta, je v\u00e9rifie les taux de reuse (-H Connection : keep-alive vs. close), les connexions\/s et les percentiles de latence.<\/li>\n  <li><strong>Vue du syst\u00e8me :<\/strong> ss\/netstat indiquent des \u00e9tats (ESTABLISHED, TIME_WAIT), lsof -p la consommation de FD, dmesg\/syslog des indications sur les drops.<\/li>\n  <li><strong>M\u00e9triques du serveur web :<\/strong> nginx stub_status\/VTS et Apache mod_status fournissent Active\/Idle\/Waiting et Requests\/s. Cela me permet de d\u00e9tecter les pics d'inactivit\u00e9 ou les goulots d'\u00e9tranglement des travailleurs.<\/li>\n  <li><strong>Traces :<\/strong> Avec le tra\u00e7age distribu\u00e9, j'observe s'il y a des temps d'attente \u00e0 la fronti\u00e8re du r\u00e9seau ou dans l'application.<\/li>\n<\/ul>\n\n<h2>Configurer pas \u00e0 pas<\/h2>\n<p>Tout d'abord, je d\u00e9termine le mod\u00e8le d'utilisation r\u00e9el : combien de requ\u00eates par session, quelles <strong>Intervalles<\/strong> entre les clics, quelle est la taille des r\u00e9ponses. Ensuite, je d\u00e9finis un profil initial : timeout 10 s, keepalive_requests 200, nombre de worker mod\u00e9r\u00e9. Ensuite, je r\u00e9alise des tests de charge avec des donn\u00e9es repr\u00e9sentatives. J'\u00e9value le nombre de nouvelles connexions par seconde et l'occupation FD. Ensuite, j'ajuste les <strong>Valeurs<\/strong> par paliers de 2 \u00e0 3 secondes.<\/p>\n<p>Je r\u00e9p\u00e8te le cycle jusqu'\u00e0 ce que les latences restent stables sous la charge et que les pics de FD n'atteignent pas la limite. En cas de fort trafic, je n'augmente le timeout que si je vois clairement moins de nouvelles connexions et que les worker restent malgr\u00e9 tout libres. En cas de faible charge, je r\u00e9duis le timeout afin d'\u00e9viter les temps morts. Dans des cas particuliers comme SSE, je place des blocs de serveurs d\u00e9di\u00e9s avec des limites plus \u00e9lev\u00e9es. Ce chemin m\u00e8ne \u00e0 un syst\u00e8me <strong>R\u00e9glage<\/strong> sans carton \u00e0 deviner.<\/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\/03\/servereinstellung-performance-1987.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kubernetes, conteneurs et auto-scaling<\/h2>\n<p>Dans les environnements de conteneurs, j'obtiens <strong>conntrack<\/strong>-Limites de pod FD et backlogs de n\u0153uds. Je veille \u00e0 ce que les d\u00e9lais d'attente soient coh\u00e9rents entre Ingress, le service mesh\/proxy et l'application. Pour l'auto-scaling, je veille \u00e0 <strong>Temps de drainage<\/strong>Lorsque les pods se terminent, ils doivent refuser les nouvelles connexions par \u201eConnection : close\u201c et servir proprement les connexions existantes. Des valeurs Keep-Alive trop longues prolongent inutilement les drains, des valeurs trop courtes g\u00e9n\u00e8rent des temp\u00eates de handshake lors du scale-out.<\/p>\n\n<h2>Arr\u00eat progressif et d\u00e9ploiements roulants<\/h2>\n<p>Je pr\u00e9vois la d\u00e9connexion. Avant un d\u00e9ploiement, je r\u00e9duis progressivement Keep-Alive ou j'envoie de fa\u00e7on cibl\u00e9e <strong>Connexion : ferm\u00e9e<\/strong> sur Responses, afin que les clients n'ouvrent pas de nouvelles connexions Idle. Dans nginx, une <strong>worker_shutdown_timeout<\/strong> pour les requ\u00eates en cours. Dans Apache, j'utilise des m\u00e9canismes Graceful et je garde un \u0153il sur MaxConnectionsPerChild\/Worker pour que le recyclage se fasse automatiquement au fil du temps. Ainsi, les d\u00e9ploiements restent fluides, sans couper brutalement les sockets ouverts.<\/p>\n\n<h2>OS-Tuning : ports, timeouts, param\u00e8tres du noyau<\/h2>\n<ul>\n  <li><strong>ports \u00e9ph\u00e9m\u00e8res :<\/strong> Choisir ip_local_port_range large, afin que les connexions de courte dur\u00e9e ne fonctionnent pas en p\u00e9nurie.<\/li>\n  <li><strong>TIME_WAIT :<\/strong> Je surveille les pics de tw. Les piles modernes g\u00e8rent bien cela ; j'\u00e9vite les tweaks douteux (tw_recycle).<\/li>\n  <li><strong>tcp_keepalive_time :<\/strong> Je ne le confonds pas avec HTTP Keep-Alive. Il s'agit d'un m\u00e9canisme du noyau pour d\u00e9tecter les pairs morts - utile derri\u00e8re le NAT, mais qui ne remplace pas la fen\u00eatre HTTP Idle.<\/li>\n  <li><strong>Backlogs et buffers :<\/strong> dimensionner judicieusement somaxconn, tcp_max_syn_backlog et rmem\/wmem afin de ne pas \u00e9trangler en charge.<\/li>\n<\/ul>\n\n<h2>Liste de contr\u00f4le de d\u00e9pannage<\/h2>\n<ul>\n  <li><strong>Beaucoup de nouveaux liens\/s malgr\u00e9 Keep-Alive :<\/strong> Timeout trop court ou les clients\/LB coupent plus t\u00f4t.<\/li>\n  <li><strong>Chiffres Idle \u00e9lev\u00e9s et FDs pleins :<\/strong> Timeout trop long ou pools de travailleurs trop importants pour le mod\u00e8le de trafic.<\/li>\n  <li><strong>Erreur de RST\/timeout lors de sessions prolong\u00e9es :<\/strong> NAT\/Firewall-Idle trop court dans le chemin, asym\u00e9trie entre les maillons.<\/li>\n  <li><strong>Longues latences de queue (P99) :<\/strong> V\u00e9rifier les timeouts d'envoi\/de lecture, les clients lents ou les backlogs surcharg\u00e9s.<\/li>\n  <li><strong>Backends surcharg\u00e9s malgr\u00e9 une charge Edge faible :<\/strong> Rejet en amont absent ou sous-dimensionn\u00e9.<\/li>\n<\/ul>\n\n<h2>Profils pratiques et valeurs de d\u00e9part<\/h2>\n<ul>\n  <li><strong>API-first (appels courts) :<\/strong> Keep-Alive 5-10 s, keepalive_requests 200-300, header\/read timeouts serr\u00e9s.<\/li>\n  <li><strong>Commerce \u00e9lectronique (mixte) :<\/strong> 8-12 s, 200-400, l\u00e9g\u00e8rement plus g\u00e9n\u00e9reux pour les images de produits et les hits de cache.<\/li>\n  <li><strong>Assets\/similaire \u00e0 un CDN (nombreux petits fichiers) :<\/strong> 10-15 s, 300-500, des pools amont forts et des limites FD \u00e9lev\u00e9es.<\/li>\n  <li><strong>Intranet\/faible charge :<\/strong> 5-8 s, 100-200, pour que Idle ne domine pas.<\/li>\n<\/ul>\n\n<h2>En bref<\/h2>\n<p>Je r\u00e8gle le d\u00e9lai d'attente HTTP Keep-Alive de mani\u00e8re \u00e0 ce que les connexions soient r\u00e9utilis\u00e9es sans bloquer les threads. En pratique, 5-15 secondes et 100-500 requ\u00eates par connexion donnent de tr\u00e8s bons r\u00e9sultats. Je coordonne les timeouts des clients, des load balancers et des firewalls, je s\u00e9pare les longues distances comme les WebSockets et je r\u00e9gule les limites OS. Avec un monitoring propre, des tests de charge r\u00e9alistes et des petits pas, je parviens \u00e0 obtenir des taux d'occupation bas. <strong>Latence<\/strong> et de haute <strong>D\u00e9bit<\/strong>. Celui qui respecte cette discipline obtient des performances mesurables \u00e0 partir du mat\u00e9riel existant.<\/p>","protected":false},"excerpt":{"rendered":"<p>Param\u00e8tres optimaux de timeout HTTP Keep-Alive pour une meilleure performance du serveur. Guide pratique pour le r\u00e9glage du serveur web et la gestion des connexions.<\/p>","protected":false},"author":1,"featured_media":18049,"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-18056","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":"848","_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":"HTTP Keep-Alive Timeout","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":"18049","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18056","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=18056"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18056\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/18049"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=18056"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=18056"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=18056"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}