Je présente le apache Je configure le délai d'expiration du keepalive de manière à ce que les connexions soient réutilisées efficacement, sans bloquer de précieux workers. À l'aide de valeurs de référence claires et de points de mesure, j'ajuste le Délai d'attente spécialement conçu pour améliorer le débit et accélérer le chargement des pages.
Points centraux
- KeepAlive réduit la surcharge TCP/TLS et diminue les latences.
- Délai d'attente détermine la durée pendant laquelle Apache attend de nouvelles requêtes.
- Trop court coûte les poignées de main, trop long lie les workers.
- Valeurs indicatives: 2 à 5 s (API/charge), 3 à 5 s (Web), 5 à 15 s (ressources).
- MPM Événement et le suivi garantissent des résultats concrets.
Le rôle des paramètres Keep-Alive et KeepAliveTimeout dans Apache
La fonctionnalité HTTP Keep-Alive regroupe plusieurs requêtes d'un client sur une seule connexion TCP, ce qui permet d'économiser CPU et les poignées de main TLS. La directive KeepAlive active ce comportement, tandis que KeepAliveTimeout définit le délai d'attente, en secondes, avant qu'Apache ne ferme une connexion inactive. Les valeurs de départ typiques sont « KeepAlive On », « KeepAliveTimeout » = 5 et « MaxKeepAliveRequests » compris entre 100 et 500, ce qui offre un compromis raisonnable. Un délai d’expiration trop généreux maintient les processus inactifs alors qu’aucune autre requête n’arrive. Une valeur trop faible oblige à établir de nouvelles connexions et augmente les latences. J’utilise donc une fenêtre temporelle étroite qui couvre les requêtes associées sans monopoliser les workers pendant trop longtemps.
Trop court ou trop long : le dilemme décisif
Un délai d'attente court entraîne un plus grand nombre de nouvelles connexions par consultation de page, ce qui augmente ainsi Overhead. De nombreux petits éléments, tels que les images, les fichiers CSS et JS, tirent clairement profit de la réutilisation des connexions, c'est-à-dire d'une connexion qui n'est pas trop limitée Délai d'attente. En revanche, des délais d’attente trop longs bloquent des workers précieux et peuvent générer des files d’attente lors des pics de charge. Cela entraîne des réponses lentes ou des messages d’erreur, alors que le traitement proprement dit pourrait s’effectuer rapidement. D’après notre expérience, des délais de 2 à 5 secondes fonctionnent très bien pour les charges de travail denses et rapides, tandis que des délais de 5 à 15 secondes ne sont pertinents que lorsque les ressources sont abondantes. Tout délai supérieur à 60 secondes n’a guère de sens dans les environnements de production, car trop de processus restent inactifs.
Valeurs indicatives recommandées en fonction de la charge de travail
Je me base sur des profils bien définis : les serveurs API disposent généralement de 2 à 3 secondes, car ils nécessitent un débit élevé et une validation rapide de Travailleur nécessaires. Les sites web classiques comportant de nombreuses ressources fonctionnent bien avec des délais de 3 à 5 secondes, ce qui permet de regrouper judicieusement les requêtes en cascade. Les domaines de ressources contenant un très grand nombre de petits fichiers peuvent supporter des délais de 5 à 10 secondes, à condition que les ressources disponibles soient suffisantes. En présence d'un proxy inverse devant Apache, je définis des délais d'expiration courts de 1 à 2 secondes en aval, car le proxy gère les connexions client géré. Ceux qui souhaitent approfondir leurs connaissances sur les principes fondamentaux trouveront une bonne introduction dans le Guide de configuration.
Configurations de démarrage adaptées à la pratique
Pour les sites web modernes utilisant Event-MPM, une valeur initiale de 3 secondes pour KeepAliveTimeout, associée à une valeur de 300 pour MaxKeepAliveRequests, s'avère très efficace. Cela me permet de couvrir la plupart des requêtes associées à une consultation de page sans risquer de temps morts. Je configure souvent les serveurs API avec un délai de 2 secondes et 200 à 300 requêtes MaxKeepAlive, ce qui réduit les temps d'attente et Débit augmenté. Les serveurs très gourmands en ressources, mais disposant d’une marge suffisante au niveau du processeur et de la mémoire vive, tirent souvent profit d’un délai d’expiration de 5 à 10 secondes et d’une valeur de MaxKeepAliveRequests comprise entre 500 et 1 000. Les pages statiques minimalistes tirent rarement profit du Keep-Alive ; dans ce cas, je le désactive parfois lorsque les tests montrent des avantages évidents.
Combiner judicieusement MPM et les directives associées
Le MPM événementiel gère les connexions inactives de manière particulièrement économe, ce qui permet de réduire l'importance d'un délai d'expiration KeepAlive modéré risqué . Je vérifie également la directive globale de délai d'expiration, qui doit être nettement supérieure à KeepAliveTimeout, souvent comprise entre 30 et 60 secondes. Je définis MaxKeepAliveRequests entre 200 et 500 selon le cas, voire davantage pour les hôtes dédiés aux ressources, à condition que Risques d'attaque garder un œil dessus. Ainsi, Apache reste performant, même lorsque les clients récupèrent de nombreux petits fichiers. Les paramètres mal configurés sont critiques, car ils génèrent soit des « handshakes » inutiles, soit bloquent les workers trop longtemps. La meilleure combinaison résulte de tests, d'observations et d'ajustements progressifs.
Optimisation étape par étape avec suivi
Je commence par une analyse du trafic : le nombre de ressources, les temps de chargement habituels, les pics de trafic et les pauses entre les requêtes sont importants pour le Délai d'attente déterminant. Je définis ensuite une valeur de départ : 3 secondes pour les charges de travail mixtes, 2 secondes pour les API, 5 secondes pour les domaines de ressources. Je surveille ensuite les connexions ouvertes, la mémoire vive, le processeur, les temps de réponse et les codes d'erreur. Si de nombreux workers sont occupés par des connexions inactives, je réduis la temps d'attente. En revanche, si de nouvelles connexions apparaissent en nombre croissant et que les latences augmentent, j'ajuste progressivement la durée de 1 à 2 secondes. Le bref article suivant propose une approche structurée : Guide d'optimisation des performances.
Lire les indicateurs et les interpréter correctement
Un coup d’œil à « server-status », aux journaux d’accès et aux diagrammes en cascade permet de voir comment les requêtes se chevauchent dans le temps et quelle est la durée des connexions sont. Des taux élevés de nouvelles connexions TCP/TLS indiquent un délai d'expiration KeepAlive trop court. Un grand nombre de workers inactifs avec des connexions inactives suggère des temps d'attente trop longs. Je recoupe ces constatations avec l’expérience utilisateur : les pages se chargent-elles nettement plus vite ou le nombre d’abandons augmente-t-il ? Face à une augmentation des erreurs 503/504, je réagis en réduisant les temps d’inactivité ou en augmentant Travailleur. C'est ainsi que je me rapproche petit à petit du « sweet spot ».
Profils de charge : site web, API, proxy
Sur les sites web comportant de nombreux éléments, je regroupe plusieurs requêtes en succession rapide sur une seule Connexion, c'est pourquoi un délai de 3 à 5 secondes convient bien. Les API tirent parti d'un délai de 2 à 3 secondes à peine, car dans ce cas, la rapidité de libération des ressources est déterminante. Avec un proxy inverse en amont, je configure Apache pour des phases de backend courtes, souvent de 1 à 2 secondes, car le proxy Client- la persistance. Les pages statiques comportant peu de fichiers ne tirent pratiquement aucun avantage du Keep-Alive ; je teste cette fonctionnalité en l'activant et en la désactivant, puis j'effectue des mesures objectives. C'est le profil qui détermine la valeur optimale, et non des vœux pieux. C'est précisément pour cette raison que je vérifie régulièrement si le trafic a évolué.
Tableau : recommandations et conséquences en matière de délai d'expiration
Le tableau suivant associe des scénarios d'utilisation typiques à des valeurs concrètes et énumère les effets principaux ainsi que les risques. Je m'en sers comme Point de départ puis je compare ces valeurs avec des mesures réelles afin d'ajuster avec précision la valeur finale. Remarque : cette fourchette indique des plages raisonnables, et non une consigne rigide. Les modifications doivent être effectuées par petites étapes afin que je puisse clairement observer la réaction du système. C'est la seule façon de garantir que les effets restent vérifiables et compréhensible.
| Scénario | KeepAliveTimeout | MaxKeepAliveRequests | effet principal | risque potentiel |
|---|---|---|---|---|
| API/microservices | 2 à 3 s | 100-300 | Validation rapide, débit accru | Trop de nouvelles connexions pour une valeur trop faible |
| Site web comportant de nombreux éléments graphiques | 3 à 5 s | 300–500 | Moins de « handshakes », des temps de chargement plus courts | En cas de surcharge, mettre les workers en veille si nécessaire |
| Domaine des ressources (très grand nombre de fichiers) | 5-10 s | 500–1000 | Bon regroupement d'un grand nombre de requêtes | Une liaison plus durable entre les partenaires |
| Proxy inverse devant Apache | 1 à 2 s | 100-300 | Backend rapide, le proxy gère les connexions client | Trop court dans le cas de séquences de rafales rares |
| Page statique minimale | Désactivé ou 1 à 2 s | faible | Débit maximal par worker | Aucun avantage lié à la réutilisation |
Je me base sur ces valeurs comme première feuille de route et je les vérifie à l'aide d'indicateurs tels que les Connexions, la latence et le taux d’erreur. Si les chiffres révèlent des goulots d’étranglement, j’ajuste progressivement les paramètres « Timeout » et « MaxKeepAliveRequests ». Un ajustement effectué sans mesure conduit souvent dans la mauvaise direction. Il vaut mieux procéder à de petits changements tout en observant attentivement les résultats. Ainsi, les performances restent reproductibles et cohérent.
Tester la configuration : outils et procédure
Je valide chaque modification à l'aide de tests de charge synthétiques et de trafic réel, afin que la Valeurs mesurées sont capables de supporter la charge. Des outils tels que ab, wrk ou k6 me permettent de visualiser le débit et la répartition des erreurs sous charge. En parallèle, je surveille l'état du serveur et les journaux pour observer les temps d'inactivité, les nouvelles connexions et les temps de réponse. Après chaque modification, j’attends suffisamment longtemps pour que les chiffres soient significatifs. Pour l’ordre pratique des opérations, j’utilise volontiers un Processus d'optimisation. Cette discipline me permet de ne pas confondre les effets avec le hasard doit être.
HTTP/2 et HTTP/3 : ce qui change pour le Keep-Alive
Avec HTTP/2, un client regroupe plusieurs flux simultanés sur une seule connexion. Cela réduit considérablement le nombre de connexions TCP parallèles, et l'importance d'un KeepAliveTimeout bien configuré demeure : je maintiens la connexion ouverte suffisamment longtemps pour que les séquences de flux typiques (HTML, CSS, JS, polices, images) s’exécutent correctement sans nécessiter de nouvelles poignées de main. En même temps, je n’ai pas besoin d’un délai d’expiration excessivement long, car HTTP/2 regroupe plus efficacement les phases de rafales au sein d’une même session. Dans la pratique, mes valeurs de référence pour le Web (3 à 5 s) se sont révélées particulièrement efficaces sous HTTP/2. Certains modules intègrent leurs propres limites spécifiques à HTTP/2 pour les flux ou les sessions ; je m’assure que celles-ci ne soient pas en contradiction avec le paramètre KeepAliveTimeout. Avec HTTP/3 (QUIC), la surcharge liée à l’établissement de la connexion est encore réduite, mais le principe de base reste le même : je choisis une fenêtre temporelle qui reflète les groupes de requêtes typiques, sans bloquer excessivement les ressources.
HTTP Keep-Alive vs. TCP Keep-Alive : une distinction claire
Je fais une distinction stricte entre HTTP Keep-Alive (protocole d'application, réutilisation pour les requêtes suivantes) et TCP Keep-Alive (mécanisme du système d'exploitation qui détecte les connexions inactives). Les paramètres tels que net.ipv4.tcp_keepalive_time n’ont aucune incidence sur le temps pendant lequel Apache attend une nouvelle requête HTTP ; seul le paramètre KeepAliveTimeout est pertinent à cet égard. Les Keep-Alive du système d’exploitation aident à détecter les sockets orphelines (par exemple en cas de coupures réseau), mais ne constituent pas un moyen de contrôler les comportements HTTP. Ceux qui confondent ces niveaux tirent souvent des conclusions erronées à partir des mesures. Je vérifie donc séparément : les métriques HTTP pour la réutilisation et les latences, et les métriques du système d’exploitation pour l’état des sockets et la qualité de la connexion.
Planification des capacités : envisager conjointement le budget en main-d'œuvre et le délai d'expiration
Je planifie toujours le KeepAliveTimeout dans le cadre du budget global de concurrence (MaxRequestWorkers/ServerLimit). Une règle de pensée simple peut aider : plus les connexions restent inactives longtemps, plus la part de capacité mobilisée qui ne génère pas de débit est importante. Exemple : avec 400 requêtes par seconde et un KeepAliveTimeout de 3 s, on pourrait, dans le pire des cas, atteindre environ 1 200 secondes d'inactivité par seconde, réparties sur de nombreuses connexions. Le MPM Event atténue ce problème en découplant l'inactivité, mais un effet de plafonnement persiste néanmoins. Je surveille donc la courbe de charge : si le nombre de workers occupés augmente trop fortement lors des pics de charge, je réduis la fenêtre d’inactivité ou j’augmente prudemment le paramètre `MaxRequestWorkers` (en tenant compte de la mémoire RAM). L’objectif est que les workers backend soient principalement occupés par le traitement actif et que les temps d’inactivité ne se transforment pas en files d’attente.
Équilibrer de manière cohérente les délais d'attente dans la pile
Outre KeepAliveTimeout, je vérifie toujours les paramètres associés : la directive globale « timeout » définit des limites maximales strictes pour les opérations d'E/S et doit être nettement supérieure à la valeur Keep-Alive. Dans les configurations de proxy, je règle le paramètre `ProxyTimeout` ainsi que les options spécifiques `timeouts` et `connectiontimeout` pour chaque backend, afin qu’Apache ne coupe pas la connexion trop tôt ni ne la maintienne trop longtemps. Contre les attaques de type Slowloris, une configuration défensive de `RequestReadTimeout` s’avère utile, sans pour autant pénaliser inutilement les clients légitimes mais lents. Dans les environnements HTTP/2, je prête attention aux limites liées aux flux ou aux sessions, qui peuvent de fait imposer un plafond au-delà de la fenêtre Keep-Alive. Mon principe : des fenêtres d’inactivité courtes pour la réutilisation, des limites maximales plus généreuses mais raisonnables pour les véritables opérations de traitement – et des garde-fous clairs contre les abus.
Évaluer de manière réaliste les coûts liés au TLS
Même avec une cryptographie moderne, un nouveau handshake TLS reste plus coûteux qu’une réutilisation. La reprise de session et le protocole TLS 1.3 réduisent sensiblement cet effort, sans toutefois l’éliminer complètement. C’est justement avec les charges de travail gourmandes en ressources CPU ou sur des instances plus petites que je ressens chaque poignée de main inutile. C’est pourquoi un KeepAliveTimeout court, mais pas trop court, s’avère particulièrement avantageux : je réduis le nombre de handshakes dans les séquences serrées d’un chargement de page, sans pour autant laisser les connexions inactives pendant plusieurs minutes. Je me concentre sur les premières secondes suivant l’affichage du code HTML initial : c’est précisément là que la réutilisation apporte le plus grand bénéfice, car la plupart des ressources suivantes arrivent en rafale.
Réseaux mobiles, „ longues pauses “ et protection contre les abus
Sur les réseaux mobiles et à longue distance, le RTT et la perte de paquets varient davantage. Des délais d'expiration trop courts peuvent ici se déclencher plus tôt si les clients subissent de brefs ralentissements. J'évalue donc le profil réel des utilisateurs : une forte proportion de trafic mobile justifie souvent la limite supérieure de mes valeurs indicatives pour le Web (4 à 5 s), tandis que les API fonctionnant uniquement de centre de données à centre de données fonctionnent parfaitement avec 2 s. Dans le même temps, je me prémunis contre les abus : une stratégie RequestReadTimeout modérément restrictive et des limites sur le nombre de connexions simultanées par adresse IP empêchent que quelques clients, avec de nombreuses connexions inactives, ne ralentissent le système. Lorsqu’un proxy inverse est déployé en amont, je lui confie la gestion de la robustesse face aux réseaux instables et je maintiens le backend rigoureusement optimisé.
Apache, PHP-FPM et les processus en amont : une collaboration harmonieuse
Dans les piles PHP, je vérifie la cohérence entre MaxRequestWorkers (Apache) et pm.max_children (PHP-FPM). Si la valeur de KeepAliveTimeout est trop longue, les connexions front-end peuvent „ bloquer “ des workers, tandis qu’en arrière-plan, les requêtes attendent que des slots PHP se libèrent – ce qui est généralement la cause des pics de latence soudains. Je minimise ce risque en fixant des fenêtres d’inactivité plutôt courtes et en dimensionnant le goulot d’étranglement au niveau du maillon le plus lent (souvent PHP-FPM ou la base de données). Derrière un proxy inverse (par exemple un CDN, un proxy en périphérie ou un proxy L7 interne), je raccourcis délibérément la fenêtre du backend Apache, car le proxy gère des sessions persistantes vis-à-vis du client et l’origine n’est nécessaire que pour le traitement proprement dit.
Guide d'analyse pour les cas complexes
Lorsque les causes ne sont pas claires, je procède systématiquement de l'extérieur vers l'intérieur : d'abord le point de vue de l'utilisateur (temps de chargement, graphiques en cascade), puis Edge/Proxy, ensuite Apache (server-status, Scoreboard), et enfin l'application et la base de données. Des taux anormalement élevés de nouvelles connexions sont généralement liés à des délais d’expiration KeepAlive trop courts ou à des modèles de contenu qui provoquent de nombreuses requêtes courtes. À l’inverse, un nombre élevé de connexions inactives associé à une charge élevée du backend indique des fenêtres d’inactivité trop longues ou un nombre insuffisant de workers. J’isole les modifications, je ne teste qu’un seul paramètre à la fois et je laisse la mesure s’exécuter suffisamment longtemps pour que les phases de pic et la charge en arrière-plan soient représentatives. Cela permet de démêler de manière fiable même les interactions les plus subtiles entre les délais d’expiration, les caches et les backends.
Perspective économique : rapport coût-bénéfice au quotidien
Chaque seconde de KeepAliveTimeout „ coûte “ potentiellement des ressources de traitement et de mémoire, mais „ permet d’économiser “ la surcharge TCP/TLS et réduit la latence. Je considère cela comme un choix d’investissement : pour les API, j’opte pour une approche plutôt parcimonieuse afin que le débit reste élevé lors des pics de charge. Pour les sites web classiques, j’investis un petit budget « inactif » afin d’obtenir des chargements de pages nettement plus rapides. Pour les domaines d’actifs, je n’augmente ce budget que si la surveillance et les réserves le justifient clairement. Cet équilibre rationnel évite une sur-optimisation dans la mauvaise direction – et garantit que les améliorations sont reproductibles, au lieu de se contenter de briller dans les benchmarks.
Aperçu des environnements WordPress et d'hébergement
Les piles WordPress combinent la mise en cache, les requêtes PHP dynamiques et de nombreuses Actifs, c'est pourquoi un intervalle de timeout de 3 à 5 secondes constitue un bon point de départ. En cas de charge simultanée élevée, je passe à 2–3 secondes afin de libérer plus rapidement les workers. Si un CDN est également utilisé, le profil change : un nombre réduit de requêtes vers l'origine permet parfois d'utiliser des valeurs légèrement plus longues. Dans les configurations gérées, je veille à ce que les fournisseurs utilisent Event-MPM, des valeurs MaxKeepAliveRequests pertinentes et des délais d’expiration globaux adaptés. Les offres qui prennent ces subtilités au sérieux offrent une expérience utilisateur nettement meilleure. Pour de nombreux projets, webhoster.de est un choix approprié, car ici Performance- L'optimisation et une configuration soignée jouent un rôle essentiel.
En bref
Je laisse généralement KeepAlive activé et je définis un délai assez court Délai d'attente, afin de réutiliser les connexions de manière judicieuse. Pour les API, j’utilise 2 à 3 secondes, pour les sites web classiques 3 à 5 secondes, et pour les domaines de ressources 5 à 10 secondes lorsque les ressources sont suffisantes. Je dimensionne le paramètre `MaxKeepAliveRequests` en fonction du profil de trafic et j’en vérifie régulièrement les effets. L’Event-MPM, des délais d’expiration globaux bien définis et une surveillance systématique garantissent le résultat. De petits ajustements, des indicateurs clairs et des tests rigoureux conduisent de manière fiable à une amélioration Performance et une latence réduite. Je parviens ainsi à atteindre un haut niveau d'efficacité sans nuire à la stabilité ni à la consommation de ressources.
