{"id":20730,"date":"2026-08-17T11:52:23","date_gmt":"2026-08-17T09:52:23","guid":{"rendered":"https:\/\/webhosting.de\/apache-event-mpm-vs-worker-mpm-webserver-tuning-optimierung\/"},"modified":"2026-08-17T11:52:23","modified_gmt":"2026-08-17T09:52:23","slug":"mpm-event-apache-vs-mpm-worker-optimisation-du-serveur-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/apache-event-mpm-vs-worker-mpm-webserver-tuning-optimierung\/","title":{"rendered":"MPM Apache Event vs MPM Worker : un \u00ab turbo \u00bb moderne pour les serveurs web soumis \u00e0 des charges \u00e9lev\u00e9es"},"content":{"rendered":"<p>Je vais expliquer en deux phrases pourquoi le choix du <strong>MPM Apache<\/strong> qui influence de mani\u00e8re visible le d\u00e9bit, la latence et la stabilit\u00e9 en cas de charge \u00e9lev\u00e9e. Je compare ici concr\u00e8tement les modes Event MPM et Worker MPM pour les connexions Keep-Alive de longue dur\u00e9e, HTTP\/2 et un haut niveau de parall\u00e9lisme, et j'en d\u00e9duis des recommandations claires en mati\u00e8re d'optimisation.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<p>Pour que tu puisses saisir imm\u00e9diatement l'essentiel, je r\u00e9sume bri\u00e8vement les points cl\u00e9s et je mets en gras les mots-cl\u00e9s d\u00e9cisifs. \u00c0 partir de ces points, je d\u00e9duis ci-dessous des \u00e9tapes concr\u00e8tes et des configurations que j'explique de mani\u00e8re pratique. J'\u00e9value syst\u00e9matiquement les deux MPM selon des profils de charge r\u00e9alistes comportant de nombreuses connexions. Tu peux ainsi identifier sans d\u00e9tour quel module se d\u00e9marque dans ta pile. Cette liste te permet de prendre des d\u00e9cisions \u00e9clair\u00e9es dans le cadre de ton exploitation quotidienne.<\/p>\n<ul>\n  <li><strong>\u00e9v\u00e9nement<\/strong> dissocie le \u00ab Idle-Keep-Alive \u00bb des threads de requ\u00eates et s'adapte \u00e0 un grand nombre de connexions.<\/li>\n  <li><strong>Travailleur<\/strong> Il est performant pour les requ\u00eates courtes, mais monopolise des threads en cas de Keep-Alive prolong\u00e9.<\/li>\n  <li><strong>HTTP\/2<\/strong> b\u00e9n\u00e9ficie de mani\u00e8re tangible de l'\u00e9v\u00e9nement gr\u00e2ce \u00e0 une gestion efficace du multiplexage.<\/li>\n  <li><strong>Ressources<\/strong>: L'\u00e9v\u00e9nement permet de r\u00e9duire l'utilisation de la RAM et du processeur par requ\u00eate active.<\/li>\n  <li><strong>Compatibilit\u00e9<\/strong>: Les modules compatibles avec les threads sont obligatoires ; mod_php reste r\u00e9serv\u00e9 au mode Prefork.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-webserverturbo-4837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pourquoi \u00ab Worker \u00bb et \u00ab Event \u00bb ont la cote<\/h2>\n\n<p>Dans une entreprise moderne, je mise clairement sur <strong>Fils de discussion<\/strong>, car ils occupent moins de m\u00e9moire vive par connexion que les processus. Prefork offrait autrefois une s\u00e9curit\u00e9 avec des modules non thread-safe, mais il est difficile \u00e0 faire \u00e9voluer lorsque le nombre de connexions est \u00e9lev\u00e9. Aujourd\u2019hui, les modes \u00ab Worker \u00bb et \u00ab Event \u00bb dominent, car ils g\u00e8rent efficacement un grand nombre d\u2019utilisateurs simultan\u00e9s. Cela s\u2019av\u00e8re particuli\u00e8rement avantageux avec le Keep-Alive actif et HTTP\/2, o\u00f9 les connexions restent ouvertes longtemps. C\u2019est pr\u00e9cis\u00e9ment l\u00e0 que <strong>\u00e9v\u00e9nement<\/strong> ses atouts, car il n'accapare pas les threads de requ\u00eate pr\u00e9cieux avec des connexions inactives.<\/p>\n\n<h2>MPM Apache Worker : architecture et limites<\/h2>\n\n<p>Je d\u00e9finis les \u00ab workers \u00bb comme un hybride entre les processus et <strong>Fils de discussion<\/strong>, dans lequel chaque processus fils dispose d'un thread d'\u00e9coute et de nombreux threads de serveur. Une requ\u00eate est trait\u00e9e par un thread, re\u00e7oit une r\u00e9ponse, puis lib\u00e8re le thread. Si la connexion reste ouverte, ce m\u00eame thread reste li\u00e9 \u00e0 cette connexion. Cela entra\u00eene une inactivit\u00e9 lorsque de nombreux clients attendent longtemps ou n'envoient que sporadiquement de petites requ\u00eates. Les utilisateurs de Worker doivent donc dimensionner judicieusement les pools de threads et les limites ; pour cela, vous pouvez consulter mon bref <a href=\"https:\/\/webhosting.de\/fr\/thread-pool-serveur-optimisation-workerhosting-threadpool\/\">Optimisation du pool de threads<\/a> utiliser comme point de d\u00e9part.<\/p>\n\n<h2>MPM Event d'Apache : explication de la boucle d'\u00e9v\u00e9nements<\/h2>\n\n<p>Je d\u00e9finis un \u00e9v\u00e9nement comme un \u00ab worker \u00bb associ\u00e9 \u00e0 une \u00ab boucle d'\u00e9v\u00e9nements \u00bb, c'est-\u00e0-dire <strong>auditeur<\/strong>- Des threads qui mettent en attente les connexions inactives. L'\u00e9couteur accepte les nouvelles connexions, transmet les requ\u00eates actives aux threads de travail disponibles, puis r\u00e9cup\u00e8re la connexion. De cette mani\u00e8re, les threads de requ\u00eate ne fonctionnent que lorsque des donn\u00e9es circulent. Des centaines, voire des milliers de clients peuvent ainsi rester ouverts sans bloquer les threads. C'est pr\u00e9cis\u00e9ment ce <strong>Stationnement<\/strong> c'est ce qui rend Event si efficace pour les charges de travail typiques HTTP\/1.1 et HTTP\/2.<\/p>\n\n<h2>\u00c9v\u00e9nement vs. Worker : diff\u00e9rences sous charge<\/h2>\n\n<p>J'\u00e9value toujours ces deux MPM dans des conditions r\u00e9elles <strong>Dernier<\/strong> avec des dur\u00e9es de keep-alive longues. Le worker atteint rapidement sa limite, car les connexions inactives occupent des threads qui ne sont alors plus disponibles pour les nouvelles requ\u00eates. L'\u00e9v\u00e9nement lib\u00e8re les pools de threads et transf\u00e8re les connexions inactives vers la boucle d'\u00e9v\u00e9nements. Ainsi, le nombre d'utilisateurs pouvant \u00eatre servis simultan\u00e9ment augmente consid\u00e9rablement, tandis que les latences restent stables. Si vous avez besoin d'\u00e9l\u00e9ments pour prendre une d\u00e9cision, le mieux est de comparer des cas concrets <a href=\"https:\/\/webhosting.de\/fr\/threading-server-model-event-driven-hosting-comparer-serverperf\/\">mod\u00e8les de serveurs orient\u00e9s \u00e9v\u00e9nements<\/a> avec des pools de threads dans les tests de charge.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/ApacheWebserverMeeting2573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compatibilit\u00e9 : modules et configurations types<\/h2>\n\n<p>Je v\u00e9rifie d'abord les <strong>Modules<\/strong>, car les modes \u00ab Worker \u00bb et \u00ab Event \u00bb exigent la s\u00e9curit\u00e9 des threads. Les piles mod_php classiques ne conviennent pas, c\u2019est pourquoi le mode \u00ab Prefork \u00bb reste ici pertinent. En revanche, si PHP fonctionne via PHP-FPM ou FastCGI, j\u2019opte clairement pour le mode \u00ab Event \u00bb. Cela vaut \u00e9galement pour les proxys invers\u00e9s vers des serveurs d\u2019applications, des microservices ou des backends Go\/Node. Dans de telles configurations, les modes \u00ab Worker \u00bb et surtout <strong>\u00e9v\u00e9nement<\/strong> ses atouts sans compromis en mati\u00e8re de compatibilit\u00e9.<\/p>\n\n<h2>Configuration : les directives principales<\/h2>\n\n<p>Je te pr\u00e9sente bri\u00e8vement les principes cl\u00e9s afin que tu puisses bien les situer et <strong>adapte<\/strong>. MaxRequestWorkers limite le nombre de requ\u00eates trait\u00e9es simultan\u00e9ment ; avec Event, tu peux souvent aller plus haut, car les connexions inactives ne bloquent pas le syst\u00e8me. ThreadsPerChild d\u00e9finit le nombre de threads par processus ; un nombre trop faible r\u00e9duit le d\u00e9bit, tandis qu'un nombre trop \u00e9lev\u00e9 sollicite excessivement le processeur. ServerLimit fixe la limite du nombre de processus et donc le plafond des requ\u00eates parall\u00e8les au sein du cluster. KeepAliveTimeout vous permet de contr\u00f4ler la dur\u00e9e pendant laquelle les connexions restent ouvertes ; plus la valeur est \u00e9lev\u00e9e, plus le syst\u00e8me en tire profit <strong>\u00e9v\u00e9nement<\/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\/08\/webserver-turbo-mpm-comparison-8394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparaison sous forme de tableau : \u00ab Worker \u00bb vs \u00ab Event \u00bb<\/h2>\n\n<p>Je r\u00e9sume les principales caract\u00e9ristiques dans un format concis <strong>Tableau<\/strong> ensemble, afin que tu puisses rep\u00e9rer imm\u00e9diatement les diff\u00e9rences. Elle ne remplace pas un test de charge, mais elle structure ton analyse des caract\u00e9ristiques essentielles. Lis les points de gauche \u00e0 droite et associe-les \u00e0 ton profil de trafic. Tu trouveras ainsi rapidement le MPM adapt\u00e9 \u00e0 ton architecture. L'accent est clairement mis sur l'\u00e9volutivit\u00e9, les besoins en ressources et le comportement avec <strong>Keep-Alive<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Crit\u00e8re<\/th>\n      <th>Worker MPM<\/th>\n      <th>\u00c9v\u00e9nement MPM<\/th>\n      <th>impact<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Gestion du Keep-Alive<\/td>\n      <td>Le thread reste li\u00e9 \u00e0 la connexion<\/td>\n      <td>Les connexions inactives sont mises en attente par la boucle d'\u00e9v\u00e9nements<\/td>\n      <td>L'\u00e9v\u00e9nement lib\u00e8re les threads de requ\u00eate<\/td>\n    <\/tr>\n    <tr>\n      <td>Utilisation des ressources<\/td>\n      <td>Davantage de threads li\u00e9s en mode veille<\/td>\n      <td>Moins de threads bloqu\u00e9s en mode veille<\/td>\n      <td>Moins de m\u00e9moire vive et de ressources processeur par requ\u00eate active<\/td>\n    <\/tr>\n    <tr>\n      <td>Latence en charge<\/td>\n      <td>Part plus t\u00f4t<\/td>\n      <td>Reste stable plus longtemps<\/td>\n      <td>Meilleure r\u00e9activit\u00e9<\/td>\n    <\/tr>\n    <tr>\n      <td>Compatibilit\u00e9 HTTP\/2<\/td>\n      <td>Bien rang\u00e9<\/td>\n      <td>Tr\u00e8s efficace<\/td>\n      <td>Avantages du multiplexage<\/td>\n    <\/tr>\n    <tr>\n      <td>Configuration<\/td>\n      <td>MaxRequestWorkers, ThreadsPerChild, ServerLimit<\/td>\n      <td>\u00ab Gleich \u00bb, plus l'optimisation de la boucle d'\u00e9v\u00e9nements<\/td>\n      <td>Cet \u00e9v\u00e9nement permet d'augmenter le taux d'occupation<\/td>\n    <\/tr>\n    <tr>\n      <td>Compatibilit\u00e9<\/td>\n      <td>Modules compatibles avec les threads requis<\/td>\n      <td>De m\u00eame, de pr\u00e9f\u00e9rence avec PHP-FPM<\/td>\n      <td>Prefork reste une option de mod_php<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>En pratique : processus de r\u00e9glage et mesures<\/h2>\n\n<p>Je pars toujours d'une base vierge <strong>Suivi<\/strong> et les donn\u00e9es de journalisation. Ensuite, je fais varier progressivement les param\u00e8tres `MaxRequestWorkers` et `ThreadsPerChild` et je mesure la latence, le taux d'erreur et la charge CPU. Je teste le param\u00e8tre `KeepAliveTimeout` par paliers, car la dur\u00e9e id\u00e9ale d\u00e9pend fortement du comportement du client. \u00c0 partir de l\u00e0, il est int\u00e9ressant de comparer les \u00e9v\u00e9nements (Event) et les workers \u00e0 l\u2019aide d\u2019outils tels que ab, wrk ou JMeter. Ce n\u2019est que lorsque les m\u00e9triques semblent correctes que je fixe les <strong>Profils<\/strong> et je consigne les indicateurs cl\u00e9s.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/apache_mpm_techoffice_4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quand le \u00ab prefork \u00bb reste pertinent<\/h2>\n\n<p>J'utilise Prefork lorsque le code n'est absolument pas compatible avec les threads <strong>Modules<\/strong> doivent fonctionner. Dans ce cas, l'isolation par processus prime sur l'\u00e9volutivit\u00e9. En contrepartie, j'accepte une consommation de RAM nettement plus \u00e9lev\u00e9e par connexion. Pour les applications h\u00e9rit\u00e9es impossibles \u00e0 adapter, cela reste souvent la solution la plus r\u00e9aliste. Cependant, d\u00e8s que j'utilise PHP-FPM ou d'autres serveurs d'applications externes, je pr\u00e9f\u00e8re <strong>\u00e9v\u00e9nement<\/strong> clairement.<\/p>\n\n<h2>Contexte de l'h\u00e9bergement web et choix du fournisseur<\/h2>\n\n<p>Dans le domaine de l'h\u00e9bergement, je fais attention aux profils MPM, car une machine h\u00e9berge souvent de nombreux h\u00e9bergements virtuels <strong>courir<\/strong>. Event permet ici une utilisation optimale des ressources, notamment gr\u00e2ce \u00e0 HTTP\/2 et TLS. Si ma pile n\u00e9cessite PHP-FPM, je choisis Event par d\u00e9faut. Pour mieux situer les choses et v\u00e9rifier les aspects techniques, voici un bref <a href=\"https:\/\/webhosting.de\/fr\/serveur-web-worker-modeles-prefork-worker-event-mpm-serverperf\/\">Comparaison entre Prefork, Worker et Event<\/a> avant le choix final. Ceux qui font ces exercices obtiennent des r\u00e9sultats nettement meilleurs <strong>Temps de r\u00e9ponse<\/strong> par euro.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/entwickler_apachempm_9821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Meilleures pratiques compactes<\/h2>\n\n<p>Je m'en sers syst\u00e9matiquement <strong>PHP-FPM<\/strong> ou d'autres serveurs d'applications externes, afin qu'Event puisse exploiter pleinement son potentiel. Ensuite, j'ajuste les param\u00e8tres `MaxRequestWorkers` et `ThreadsPerChild` en fonction des c\u0153urs de processeur et de la m\u00e9moire vive, puis je v\u00e9rifie les limites strictes du syst\u00e8me. En cas de nombreux clients inactifs, j\u2019opte pour Event, je r\u00e8gle d\u00e9lib\u00e9r\u00e9ment KeepAliveTimeout sur une valeur plus \u00e9lev\u00e9e et je surveille les latences. Pour les charges de travail comportant des requ\u00eates tr\u00e8s courtes et un Keep-Alive mod\u00e9r\u00e9, Worker suffit, \u00e0 condition que les modules restent thread-safe. Sans surveillance continue de l\u2019utilisation des threads, des erreurs et <strong>Latence<\/strong> je ne prends aucune d\u00e9cision d\u00e9finitive.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-performance-4096.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemples concrets de configuration pour Event et Worker<\/h2>\n<p>Je fournis deux profils minimalistes que j'utilise comme point de d\u00e9part et que j'affine ensuite \u00e0 l'aide de mesures. Point essentiel : <strong>MaxRequestWorkers = ServerLimit \u00d7 ThreadsPerChild<\/strong>. Je pars du budget de m\u00e9moire vive et des besoins par thread (modules, TLS et tampons compris) pour augmenter progressivement la m\u00e9moire.<\/p>\n<pre><code>Exemple # : Event MPM (HTTP\/2, PHP-FPM)\nServerLimit 16\nThreadLimit 256\nThreadsPerChild 64\nMaxRequestWorkers     1024\nStartServers 4\nMaxConnectionsPerChild 10000\n\nKeepAlive On\nMaxKeepAliveRequests  100\nKeepAliveTimeout 15\n\n# Facultatif : \u00e0 ajuster uniquement apr\u00e8s mesure :\n# ListenBacklog 1024\n# ThreadStackSize     1048576   # 1 Mo, uniquement si les modules le permettent\n# AsyncRequestWorkerFactor 2    # R\u00e9glage fin de la boucle d'\u00e9v\u00e9nements, g\u00e9n\u00e9ralement laisser la valeur par d\u00e9faut\n\n# HTTP\/2\nProtocoles h2 http\/1.1\n# H2MaxSessionStreams  100-200  # ajuster avec pr\u00e9cision en fonction de la capacit\u00e9 du backend\n<\/code><\/pre>\n<pre><code>Exemple # : Worker MPM (requ\u00eates courtes, Keep-Alive mod\u00e9r\u00e9)\nServerLimit 8\nThreadLimit 256\nThreadsPerChild 50\nMaxRequestWorkers     400\nStartServers 4\nMaxConnectionsPerChild 5000\n\nKeepAlive On\nMaxKeepAliveRequests  100\nKeepAliveTimeout 3\nProtocols http\/1.1\n<\/code><\/pre>\n<p>Je tiens <strong>MaxConnectionsPerChild<\/strong> (alias : MaxRequestsPerChild) diff\u00e9rent de 0, afin de d\u00e9tecter les fuites insidieuses. <strong>KeepAliveTimeout<\/strong> Je le r\u00e8gle d\u00e9lib\u00e9r\u00e9ment \u00e0 une valeur plus \u00e9lev\u00e9e pour les \u00e9v\u00e9nements, car les connexions inactives ne co\u00fbtent pas cher ; pour les workers, je le maintiens \u00e0 un niveau bas afin de ne pas bloquer les threads.<\/p>\n\n<h2>Optimisation de HTTP\/2 avec Event<\/h2>\n<p>Je tiens compte de <strong>HTTP\/2<\/strong>, que les navigateurs ouvrent peu de connexions et en \u00e9tablissent beaucoup <strong>flux<\/strong> multiplexer. Le goulot d'\u00e9tranglement ne r\u00e9side donc plus dans le nombre de connexions, mais dans la r\u00e9partition \u00e9quitable des threads et la capacit\u00e9 du backend. Avec Event, les threads restent libres tant qu'un flux est en attente, ce qui permet de lisser les pics de latence. Leviers pratiques :<\/p>\n<ul>\n  <li><strong>H2MaxSessionStreams<\/strong>: Je me situe g\u00e9n\u00e9ralement entre 50 et 200. Une valeur trop \u00e9lev\u00e9e provoque des effets \u00ab head-of-line \u00bb dans le backend, tandis qu'une valeur trop faible ne permet pas d'exploiter pleinement le parall\u00e9lisme.<\/li>\n  <li><strong>MaxRequestWorkers<\/strong>: Avec Event, je peux augmenter le niveau, \u00e0 condition que la m\u00e9moire vive et le processeur le permettent. Je surveille les 95e et 99e centiles de latence \u00e0 mesure que le parall\u00e9lisme augmente.<\/li>\n  <li><strong>TLS<\/strong>: Gr\u00e2ce \u00e0 ALPN et \u00e0 des suites de chiffrement modernes, je r\u00e9duis les co\u00fbts li\u00e9s \u00e0 la phase d'\u00e9tablissement de la connexion ; Event en tire \u00e9galement profit, car les phases d'inactivit\u00e9 entre les rafales de flux sont g\u00e9r\u00e9es de mani\u00e8re efficace.<\/li>\n<\/ul>\n\n<h2>Limites du syst\u00e8me d'exploitation et files d'attente de sockets<\/h2>\n<p>Avant chaque test de charge, je v\u00e9rifie les limites du syst\u00e8me, sinon ce n'est pas le MPM qui impose des limites, mais le noyau. Pour un nombre \u00e9lev\u00e9 de connexions, je fais notamment \u00e9voluer :<\/p>\n<ul>\n  <li><strong>Descripteurs de fichiers<\/strong>: ulimit -n et systemd <code>LimitNOFILE<\/code> Je l'augmente, par exemple, \u00e0 65 536 ou plus ; Apache a besoin d'un FD par socket, journal et canal.<\/li>\n  <li><strong>arri\u00e9r\u00e9<\/strong>: <code>net.core.somaxconn<\/code> et <code>tcp_max_syn_backlog<\/code> Je d\u00e9finis une valeur appropri\u00e9e (par exemple 1024\u20134096) afin d'\u00e9viter que la file d'attente d'acceptation ne d\u00e9borde.<\/li>\n  <li><strong>plage de ports<\/strong> (en cas de proxy inverse) : <code>ip_local_port_range<\/code> Je l'\u00e9largis (par exemple de 10 000 \u00e0 65 000) lorsqu'il existe de nombreuses connexions sortantes simultan\u00e9es vers les serveurs backend.<\/li>\n  <li><strong>FIN\/Temps morts<\/strong>: Attention \u00e0 <code>tcp_fin_timeout<\/code>: un r\u00e9glage trop agressif peut entra\u00eener des coupures de connexion ; je ne modifie les param\u00e8tres qu'en me basant sur les mesures.<\/li>\n<\/ul>\n<p>Je consigne chaque modification apport\u00e9e au noyau, en pr\u00e9cisant la justification, et je la v\u00e9rifie en effectuant une nouvelle mesure de la charge. En l'absence de preuve, le r\u00e9glage par d\u00e9faut reste g\u00e9n\u00e9ralement le bon.<\/p>\n\n<h2>Surveillance et d\u00e9pannage au quotidien<\/h2>\n<p>J'active <strong>ExtendedStatus<\/strong> et utilise \u00ab server-status \u00bb pour afficher la <strong>Tableau d'affichage<\/strong>- \u00c9tats. Dans la section \u201e Event \u00bb, je constate la pr\u00e9sence de nombreuses sockets inactives ou de type \u00ab keep-alive \u00bb, sans que les threads de travail soient satur\u00e9s. Le message \u00ab server reached \u00bb appara\u00eet dans le journal d'erreurs <strong>MaxRequestWorkers<\/strong> \u201c setting, consider raising the MaxRequestWorkers setting \u00bb, le serveur atteint d\u00e9j\u00e0 ses limites ; j'augmente prudemment cette valeur et surveille l'utilisation de la RAM et du processeur ainsi que le taux d'erreurs.<\/p>\n<ul>\n  <li><strong>Champs de mesure<\/strong>: Dans les fichiers journaux d'acc\u00e8s, j'enregistre les temps de r\u00e9ponse (par exemple %D\/%T), les codes d'\u00e9tat et le nombre d'octets ; je mets en corr\u00e9lation les pics avec l'activit\u00e9 du processeur et des E\/S.<\/li>\n  <li><strong>Sympt\u00f4mes chez Worker<\/strong>: Nombreuses connexions Keep-Alive inactives, threads occup\u00e9s \u00e0 100 %, latence en hausse, 503\/504 \u2013 signe de threads bloqu\u00e9s.<\/li>\n  <li><strong>Sympt\u00f4mes lors d'un \u00e9v\u00e9nement<\/strong>: Les threads d'\u00e9coute sont tr\u00e8s sollicit\u00e9s, mais les threads de travail sont libres \u2013 il s'agit g\u00e9n\u00e9ralement d'une limite li\u00e9e au r\u00e9seau ou au backend, et non au MPM.<\/li>\n  <li><strong>Rechargement en douceur<\/strong>: J'int\u00e8gre les modifications avec <code>apachectl -k graceful<\/code> afin que les liquides pr\u00e9sents s'\u00e9coulent correctement.<\/li>\n<\/ul>\n\n<h2>Planification des capacit\u00e9s : des c\u0153urs et de la m\u00e9moire vive (RAM) \u00e0 MaxRequestWorkers<\/h2>\n<p>Je proc\u00e8de de mani\u00e8re pragmatique : quelle quantit\u00e9 de m\u00e9moire vive par thread, plus la m\u00e9moire tampon, est-ce que je souhaite allouer ? Pour le TLS, les filtres et les modules courants, je table, par mesure de prudence, sur quelques Mo par thread. Ensuite, je d\u00e9finis <strong>MaxRequestWorkers<\/strong> de mani\u00e8re \u00e0 ce que les pics de charge situ\u00e9s dans les 95e et 99e centiles soient g\u00e9r\u00e9s sans swap. Au niveau du processeur, le principe suivant s'applique : les threads suppl\u00e9mentaires par rapport au nombre de c\u0153urs ne sont utiles que s'ils ne sont pas constamment gourmands en temps d'ex\u00e9cution. Avec Event, j'ose des valeurs plus \u00e9lev\u00e9es, car les phases d'inactivit\u00e9 ne co\u00fbtent pratiquement rien.<\/p>\n<ul>\n  <li><strong>R\u00e8gles empiriques<\/strong>: D\u00e9marrer avec 32 \u00e0 64 threads par processus, 4 \u00e0 16 processus ; puis proc\u00e9der \u00e0 des mesures et \u00e0 des ajustements.<\/li>\n  <li><strong>ThreadStackSize<\/strong>: Si la m\u00e9moire vive est insuffisante et que les modules le permettent, je r\u00e9duis la taille de la pile (avec prudence, en effectuant un test de charge).<\/li>\n  <li><strong>MaxKeepAliveRequests<\/strong>: Je conserve g\u00e9n\u00e9ralement la valeur par d\u00e9faut ; avec des clients \u00ab bavards \u00bb, une valeur plus \u00e9lev\u00e9e peut r\u00e9duire la surcharge.<\/li>\n<\/ul>\n\n<h2>Sc\u00e9narios de proxy inverse et connexions au backend<\/h2>\n<p>J'aime particuli\u00e8rement utiliser Event avec les back-ends d'applications, car il <strong>Prises avant<\/strong> se gare efficacement, tandis que le v\u00e9ritable travail s'effectue en arri\u00e8re-plan. Ce qui est alors d\u00e9terminant, c'est la mise en commun des <strong>Connexions au backend<\/strong> (mod_proxy) :<\/p>\n<ul>\n  <li><strong>Keep-Alive vers le backend<\/strong>: Laisser cette option activ\u00e9e pour \u00e9conomiser des handshakes ; taille des pools (<em>max<\/em> (par cible) en fonction de la capacit\u00e9 du backend.<\/li>\n  <li><strong>D\u00e9lais d'expiration des proxys<\/strong>: D\u00e9finir clairement les d\u00e9lais d'expiration afin que les backends bloqu\u00e9s ne monopolisent pas les threads du frontend.<\/li>\n  <li><strong>HTTP\/2 vers le backend<\/strong>: Dans la mesure du possible, j'utilise H2 (par exemple, h2c en interne) pour r\u00e9duire le nombre de connexions tout en augmentant le nombre de flux \u2013 Event s'adapte bien \u00e0 cette configuration.<\/li>\n<\/ul>\n<p>Je surveille tout particuli\u00e8rement les temps de latence entre le front-end et le back-end ; si seul le temps du back-end augmente, le r\u00e9glage du MPM ne suffit pas \u00e0 lui seul : je dois alors ajuster la taille des pools, les d\u00e9lais d'expiration ou les ressources du back-end.<\/p>\n\n<h2>Strat\u00e9gie de d\u00e9ploiement et migration de \u00ab Worker \u00bb vers \u00ab Event \u00bb<\/h2>\n<p>Je proc\u00e8de \u00e0 la migration en plusieurs \u00e9tapes claires : je commence par v\u00e9rifier les <strong>Liste des modules<\/strong> (apachectl -M) pour v\u00e9rifier la s\u00e9curit\u00e9 des threads. Tout ce qui n'est pas \u00ab thread-safe \u00bb (comme mod_php) doit \u00eatre supprim\u00e9 ou isol\u00e9. Ensuite, j'active les \u00e9v\u00e9nements, je d\u00e9finis des valeurs de d\u00e9part prudentes et je lance des tests de charge sur l'environnement de pr\u00e9production. Lors du d\u00e9ploiement, je commence par une partie du trafic (Canary), je compare les m\u00e9triques, puis je proc\u00e8de au d\u00e9ploiement \u00e0 grande \u00e9chelle.<\/p>\n<ul>\n  <li><strong>commandes<\/strong>: Comme d'habitude dans cette distribution, activez\/d\u00e9sactivez les modules MPM (par exemple avec a2dismod\/a2enmod) puis red\u00e9marrez correctement le syst\u00e8me.<\/li>\n  <li><strong>plan de secours<\/strong>: Je garde un profil de worker \u00e0 disposition au cas o\u00f9 un module du module \u00ab Event \u00bb pr\u00e9senterait un comportement anormal.<\/li>\n  <li><strong>Documentation<\/strong>: Je documente chaque modification apport\u00e9e aux limites, aux param\u00e8tres HTTP\/2 et aux valeurs du noyau \u00e0 l'aide de mesures \u00ab avant\/apr\u00e8s \u00bb.<\/li>\n<\/ul>\n\n<h2>La s\u00e9curit\u00e9 et les performances TLS sous la loupe<\/h2>\n<p>Je constate, en ce qui concerne le protocole TLS, que les proc\u00e9dures d'\u00e9tablissement de connexion sollicitent fortement le processeur et peuvent augmenter la latence en cas de charge importante. Avec <strong>R\u00e9somption de session<\/strong> Gr\u00e2ce \u00e0 un choix de algorithmes de chiffrement modernes, je r\u00e9duis les co\u00fbts tout en g\u00e9rant efficacement les phases d'inactivit\u00e9. En combinaison avec HTTP\/2 et ALPN, j'\u00e9vite les allers-retours suppl\u00e9mentaires. Important : les tampons TLS et les param\u00e8tres OpenSSL font partie de l\u2019empreinte m\u00e9moire (RAM) par thread ; j\u2019en tiens compte dans la planification des capacit\u00e9s.<\/p>\n\n<h2>Tol\u00e9rance aux pannes et d\u00e9gradation en douceur<\/h2>\n<p>Je pr\u00e9vois une surcharge : le processeur est-il satur\u00e9 ou Apache atteint-il <strong>MaxRequestWorkers<\/strong>, je ne veux pas d'une avalanche de tentatives de reconnexion. Je d\u00e9finis des d\u00e9lais d'expiration clairs, des pages d'erreur explicites et des limites de d\u00e9bit sur les proxys en amont. Avec Event, on reste plus performant sous pression <strong>Fils de discussion<\/strong> disponibles pour le travail effectif, tandis que les connexions inactives sont mises en attente \u2013 c'est pr\u00e9cis\u00e9ment cette r\u00e9serve qui permet au syst\u00e8me de rester op\u00e9rationnel plus longtemps, jusqu'\u00e0 ce que la charge diminue \u00e0 nouveau ou que la mise \u00e0 l'\u00e9chelle automatique se d\u00e9clenche.<\/p>\n\n<h2>En bref<\/h2>\n\n<p>Dans le cadre de mon activit\u00e9 actuelle, je mise sur <strong>\u00e9v\u00e9nement<\/strong>, d\u00e8s que mon stack utilise des modules thread-safe et PHP-FPM. Cette approche r\u00e9duit le nombre de threads li\u00e9s aux connexions inactives, maintient un temps de r\u00e9ponse stable et augmente le nombre d'utilisateurs servis en parall\u00e8le. Le mode \u00ab Worker \u00bb reste une option solide pour les requ\u00eates courtes avec un \u00ab keep-alive \u00bb mod\u00e9r\u00e9, lorsque le mode \u00ab Event \u00bb ne convient pas pour des raisons organisationnelles. Je r\u00e9serve le mode \u00ab Prefork \u00bb aux configurations utilisant des modules non thread-safe ou du code ancien. Avec des tests de charge clairs, un r\u00e9glage pr\u00e9cis des directives et une <strong>Suivi<\/strong> je fais tourner Apache \u00e0 plein r\u00e9gime de mani\u00e8re reproductible.<\/p>","protected":false},"excerpt":{"rendered":"<p>MPM Event d'Apache vs MPM Worker : d\u00e9couvrez quel MPM offre les meilleures performances pour l'optimisation des serveurs web modernes et dans quels cas il est pr\u00e9f\u00e9rable d'opter pour le module Event.<\/p>","protected":false},"author":1,"featured_media":20723,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20730","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":"104","_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":"Apache MPM","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":"20723","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20730","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=20730"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20723"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}