Apache MPM motorz

Comment cela fonctionne-t-il ¶

motorz utilise prefork comme cadre pour la gestion des processus et un cœur à base d’évènements pour la gestion des connexions. Un seul processus de contrôle (le parent) lance un nombre fixe de processus enfants, ce nombre étant défini par la directive StartServers. À la différence des MPM worker et event, le nombre de processus enfants ne varie pas avec la charge : motorz maintient un jeu de processus statique en les remplaçant nombre pour nombre lorsqu’ils quittent. Le parallélisme de traitement au sein d’un hôte est mis en œuvre en ajoutant des threads de travail (ThreadsPerChild) et, lorsque le cheminement du processus de sondage/répartition constitue un goulot d’étranglement, des threads sondeurs (PollersPerChild), au lieu de lancer davantage de processus.

Chaque processus enfant exécute :

• Un ou plusieurs threads sondeurs. Chaque sondeur possède ses propres domaine de sondage, sonnerie de chronomètre (avec un mutex de protection) et liste de recyclage du jeu de transactions non bloquante, de sorte que les sondeurs n’interfèrent pas les uns avec les autres. Un thread sondeur sonde, répartit les évènements d’entrée/sortie prêts et les délais expirés au sein du jeu de threads de travail, et (en ce qui concerne le thread sondeur qui possède le socket d’écoute) accepte de nouvelles connexions. Le nombre de threads sondeurs est contrôlé par la directive PollersPerChild.
• Un jeu de threads de travail partagé (ThreadsPerChild) qui gère la connexion proprement dite et traite les requêtes qui lui sont envoyées. Les threads de travail ne sondent jamais.
• Un superviseur (le thread principal de l’enfant) qui surveille MaxConnectionsPerChild et la "pipe-of-death / generation", enjoint les threads sondeurs de ralentir et les rejoint lorsqu’ils quittent.

Une connexion est attribuée à un thread sondeur au moment de l'acceptation (round-robin) et le reste pendant toute sa durée de vie : elle réinitialise et fait passer à l’état expiré le domaine de sondage et la sonnerie du chronomètre de ce thread sondeur. Utiliser plusieurs threads sondeurs augmente le plafond de débit par rapport à celui d’un sondage par thread unique ; ainsi l’acceptation, la répartition des évènements et l’expiration du délai sont réglées par PollersPerChild au lieu d’être sérialisées sur un seul thread.

Alors que le processus parent est en général démarré en tant que root sous Unix de façon à se lier au port 80, les processus enfants et les threads sont lancés par le serveur sous un utilisateur moins privilégié. Les directives User et Group permettent de définir les privilèges des processus enfants du serveur HTTP Apache. Les processus enfants doivent pouvoir lire tout le contenu destiné à être servi, mais cela mis à part, doivent posséder le moins de privilèges possible.

La directive MaxConnectionsPerChild permet de contrôler la fréquence à laquelle le serveur recycle les processus en retirant les anciens et en en lançant de nouveaux.

Gestion des connexions asynchrones ¶

motorz se définit lui-même comme un MPM asynchrone. Lorsqu’un thread de travail termine la phase active d’une connexion (par exemple, une connexion persistante HTTP entre les requêtes ou une connexion attendant une entrée/sortie), il confie le socket à son thread sondeur au lieu de maintenir un thread de travail inactif. Le thread sondeur attend le prochain évènement sur ce socket (dans les limites du délai défini par la directive Timeout) et n’attribue la connexion à un thread de travail que s’il y a quelque chose à faire. Cela libère les threads de travail des connexions persistantes inactives et permet une gestion efficace de HTTP/2 où la connexion principale est reprise par le MPM entre les requêtes.

La fermeture avec délai (lingering close) n’est, elle non plus, pas bloquante : plutôt que de bloquer un thread de travail pendant la durée du délai de fermeture, le socket en cours de vidage est confié à la boucle de sondage avec un délai d’inaction limité ; ainsi, le thread de travail est replacé dans le pool immédiatement.

Les modules qui acceptent une connexion totalement asynchrone (la suspendant et la réactivant plus tard) sont pris en charge ; une connexion suspendue est parquée et réarmée sur son propre thread sondeur lorsqu’elle est réactivée.

Contrôle d’admission ¶

Pour qu’un processus enfant reste fiable en cas de surcharge, motorz applique une pression en retour (backpressure) à l’écouteur. Lorsque le pool de threads de travail sature, le thread sondeur qui possède les sockets d’écoute les enlève de son domaine de sondage et arrête d’accepter ; il les réajoute lorsque la liste de demandes se vide. Cela a pour effet de limiter la taille de la file d’attente de travaux et la mémoire consommée par connexion, au lieu de les laisser grandir sans limite. La décision se base sur le décompte des threads inactifs, en attente et actifs dans le pool de threads de travail, avec hystérèse pour éviter un basculement excessif des écouteurs entre « on » et « off ».

Liens de parenté avec les autres MPMs ¶

motorz utilise prefork pour la gestion des processus et un pool de threads de travail APR, avec des threads sondeurs qui répartissent le travail au sein du pool de threads de travail. Cette approche est différente de la conception écouteur,thread de travail/fdqueue du MPM event dans laquelle les threads de travail réarment eux-mêmes un domaine de sondage partagé et sûr en ce qui concerne les threads.

La charge de travail détermine si l’ajout de threads sondeurs peut aider. Si les threads de travail constituent le goulot d’étranglement du CPU#8212;c’est en général le cas pour le traitement réel des requêtes#8212;les threads sondeurs ne sont pas le facteur de limitation et une valeur de la directive PollersPerChild au delà de 1 ou 2 sera de peu d’effet. La conception à plusieurs threads sondeurs supprime le plafond structurel de la conception à thread sondeur unique, mais le débit par hôte reste tout de même gouverné par le CPU de travail.

StartServers       2
ThreadsPerChild   64
ThreadLimit       64
PollersPerChild    2