Tuning des performances d’Apache : Modules MPM

  1. Apache Performance Tuning : Mémoire swap
  2. Apache Performance Tuning : Modules MPM
  3. Apache Performance Tuning : Directives MPM
  4. Ajustement des performances d’Apache : Configuration des directives MPM
  5. Comment activer la journalisation pipée dans Apache

Temps de lecture : 3 minutes

La clé de voûte pour comprendre les performances des serveurs Apache est de loin les modules multiprocesseurs (MPM). Ces modules déterminent la base de la façon dont Apache aborde le multiprocessing. Le multiprocessing signifie l’exécution de plusieurs opérations simultanément dans un système avec plusieurs unités centrales de traitement (CPU Cores).

Il existe de nombreux MPMs parmi lesquels choisir ; cependant, cet article se concentre sur les modules les plus couramment utilisés que l’on trouve dans les serveurs VPS basés sur Liquid Web Linux. Ces modules sont :

  • MPM Prefork
  • MPM Worker
  • MPM Event
  • Autres MPM
  • Quel MPM est le meilleur ?

MPM Prefork

Le MPM autorégulateur Prefork tire son homonyme de la façon dont il bifurque ou se copie dans de nouveaux processus identiques de façon préemptive pour attendre les demandes entrantes. Une approche du multiprocessing basée sur des processus non threadés, MPM Prefork exécute Apache dans un seul processus serveur parent maître. Ce processus parent est responsable de la gestion de tous les serveurs enfants supplémentaires qui composent son pool de serveurs. Avec MPM Prefork, chaque serveur enfant ne traite qu’une seule requête. Cette focalisation assure une isolation complète des autres demandes traitées sur le serveur. MPM Prefork est généralement utilisé pour des raisons de compatibilité lorsque des bibliothèques/logiciels non threadés, comme mod_php (DSO), sont nécessaires. Du point de vue de l’optimisation, MPM Prefork peut présenter des lacunes importantes par rapport aux solutions multithreads, car il nécessite beaucoup plus de ressources pour atteindre des niveaux de trafic similaires à ceux d’un MPM threadé. Il est gourmand en ressources en raison de son besoin de spawn des copies complètes d’Apache pour chaque requête.

Note:
Évitez d’utiliser MPM Prefork autant que possible. Son incapacité à bien s’échelonner avec l’augmentation du trafic dépassera rapidement le matériel disponible sur la plupart des configurations de système.

MPM Worker

Un serveur web hybride pré-forking, multi threads et multiprocesseurs. De la même manière que MPM Prefork, MPM Worker utilise la même approche avec un seul processus parent maître régissant tous les enfants de son pool de serveurs. Cependant, contrairement à MPM Prefork, ces enfants sont des processus multithreads qui peuvent gérer des dizaines de threads (demandes) simultanément. MPM Worker a jeté les bases du multitraitement multithreadé dans les serveurs Apache, qui est devenu stable dans Apache 2.2. La configuration threadée permet à Apache de traiter des centaines de requêtes avec facilité tout en ne conservant en mémoire qu’une douzaine de processus enfants. Le MPM Worker fait à la fois une solution de haute capacité et de faible ressource pour le service web.

Note
La directive KeepAliveTimeOut définit actuellement la durée d’attente des requêtes par Apache. Lorsque vous utilisez KeepAlive avec MPM Worker, utilisez le plus petit KeepAliveTimeout possible (1 seconde de préférence).

MPM Event

Basé sur le code source de MPM Worker, MPM Event partage les directives de configuration avec MPM Worker. Son fonctionnement est presque identique à celui de MPM Worker, sauf en ce qui concerne la gestion des requêtes KeepAlive. MPM Event utilise un thread Listener dédié dans chaque processus enfant. Ce fil d’écoute est chargé de diriger les demandes entrantes vers un fil de travail disponible. Le thread Listening résout le problème rencontré par MPM Worker qui bloque des threads entiers dans l’attente du KeepAliveTimeout. L’approche d’écoute de MPM Event garantit que les threads de travail ne sont pas « bloqués » en attendant l’expiration du KeepAliveTimeout. Cette méthode permet de garder le maximum de threads travailleurs traitant autant de requêtes que possible.

Informations sur les limites du serveur

Conseil:
MPM Event est stable dans Apache 2.4, les versions plus anciennes peuvent utiliser MPM Worker comme alternative.

Autres MPM

Il existe un assortiment de MPM supplémentaires disponibles. Ceux-ci font généralement partie de l’intégration d’Apache dans les systèmes d’exploitation autres que ceux basés sur Unix. Ils ont des MPMs spécifiques qui sont des exigences ou qui utilisent Apache sur leurs types de systèmes respectifs. Ces types de MPMs ne sont pas du ressort de cet article. Vous pouvez trouver plus d’informations sur les MPM spécifiques dans la section MPM Defaults de la documentation officielle d’Apache.

Note:
Nous recommandons de rester loin des MPM expérimentaux et instables. La nature peu fiable de ces types de logiciels les rend non supportables.

Quel MPM est le meilleur ?

Lorsqu’on envisage une optimisation, il est essentiel de comprendre qu’il n’existe pas de configuration Apache universelle. Choisir correctement un MPM nécessite l’analyse de nombreuses variables mobiles comme le trafic, le code du site, le type de serveur, le gestionnaire PHP et le matériel disponible. Chaque serveur est unique, ce qui fait du meilleur MPM un choix entièrement subjectif.

Si le code de votre application ne supporte pas le multithreading, alors votre choix se portera inévitablement sur MPM Prefork purement sur une base de compatibilité. MPM Prefork comprend des modules logiciels comme mod_php (DSO). MPM Worker sans KeepAlive fonctionne très bien si votre application est un système d’API à haute performance et à charge équilibrée. L’évolutivité et la flexibilité de MPM Event constituent un choix solide pour l’hébergement de plusieurs sites de petite à moyenne taille dans une configuration d’hébergement partagé.

La plupart des configurations de serveurs simples fonctionnent bien sous la configuration autonome par défaut de MPM Event, ce qui en fait un point de départ idéal pour le réglage de l’optimisation. Une fois choisi, un MPM peut ensuite passer aux directives de configuration pour examiner les paramètres relatifs aux performances et à l’optimisation du serveur. Vous pouvez également consulter l’article précédent de cette série, Apache Performance Tuning : Swap Memory.

Série Navigation << Article précédentArticle suivant >>

  • .

Laisser un commentaire