Serveur HTTP Apache Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4 > Modules

# Apache MPM worker

Langues Disponibles: de | en | fr | ja | tr

Description: | Module multi-processus implémentant un serveur web hybride multi-processus multi-thread
Statut: | MPM
Identificateur de Module: | mpm_worker_module
Fichier Source: | worker.c

### Sommaire

Ce module multi-processus (MPM) implémente un serveur hybride multi-processus multi-thread. En utilisant les threads pour servir les requêtes, il peut en traiter un grand nombre tout en consommant moins de ressources qu'un serveur à base de processus. Cependant, il conserve une grande partie de la stabilité d'un serveur à base de processus en maintenant plusieurs processus disponibles, chacun de ces derniers possédant de nombreux threads.

Les directives les plus importantes qui permettent de contrôler ce MPM sont `ThreadsPerChild`, qui définit le nombre de threads lancés par chaque processus enfant et `MaxRequestWorkers`, qui définit le nombre global maximum de threads qui peuvent être lancés.

### Sujets

- Comment ça marche

### Directives

### Traitement des bugs

- Journal des modifications de httpd
- Problèmes connus
- Signaler un bug

### Voir aussi

- Définition des adresses et ports qu'utilise le serveur HTTP Apache

## Comment ça marche ¶

Un processus de contrôle unique (le parent) a pour tâche de lancer les processus enfants. Chaque processus enfant crée un nombre fixe de threads serveurs selon la valeur de la directive `ThreadsPerChild`, ainsi qu'un thread chargé d'attendre les connexions et de les passer à un thread serveur pour traitement au fur et à mesure de leur arrivée.

Le serveur HTTP Apache essaie toujours de maintenir un jeu de threads serveurs inactifs ou en réserve, qui se tiennent prêts à traiter les requêtes entrantes. De cette façon, les clients n'ont pas besoin d'attendre la création d'un nouveau thread ou d'un nouveau processus pour que leurs requêtes puissent être traitées. Le nombre de processus lancés initialement est défini par la directive `StartServers`. En cours de fonctionnement, le serveur évalue le nombre total de threads inactifs dans tous les processus, et en crée ou en arrête de façon à maintenir ce nombre à l'intérieur des limites définies par les directives `MinSpareThreads` et `MaxSpareThreads`. Comme ce module s'auto-contrôle de manière efficace, on peut en général conserver les valeurs par défaut. Le nombre maximum de clients pouvant être servis simultanément (c'est à dire le nombre global maximum de threads pour tous les processus) est défini par la directive `MaxRequestWorkers`. Le nombre maximum de processus enfants actifs est défini par la valeur de la directive `MaxRequestWorkers` divisée par la valeur de la directive `ThreadsPerChild`.

Deux directives permettent de fixer des limites absolues pour le nombre de processus enfants actifs et le nombre de threads serveurs par processus enfant, et ne peuvent être modifiées qu'en arrêtant complètement le serveur et en le démarrant à nouveau. La valeur de la directive `ServerLimit` constitue une limite absolue pour le nombre de processus enfants actifs, et doit être supérieure ou égale à la valeur de la directive `MaxRequestWorkers` divisée par la valeur de la directive `ThreadsPerChild`. La valeur de la directive `ThreadLimit` constitue une limite absolue pour le nombre de threads par processus enfant, et doit être supérieure ou égale à la valeur de la directive `ThreadsPerChild`.

En plus du jeu de processus enfants actifs, il peut exister quelques processus enfants en cours d'arrêt, mais dont au moins un thread serveur est encore en train de traiter une connexion client existante. Il peut subsister en théorie jusqu'à `MaxRequestWorkers` processus en cours d'arrêt, bien qu'en réalité, ce nombre sera en général beaucoup plus petit. Ce comportement peut être évité en désactivant l'arrêt de processus enfants individuels de la manière suivante :

- définir la valeur de `MaxConnectionsPerChild` à zéro
- Définir la valeur de `MaxSpareThreads` à la même valeur que `MaxRequestWorkers`

Voici un exemple typique de configuration du contrôle processus-thread pour le MPM `worker` :

    ServerLimit         16
    StartServers         2
    MaxRequestWorkers  150
    MinSpareThreads     25
    MaxSpareThreads     75
    ThreadsPerChild     25

Alors que le processus parent est en général démarré en tant que `root` sous Unix afin de se mettre en écoute du port 80, les processus enfants et les threads sont lancés par le serveur sous un utilisateur avec privilèges restreints. On peut utiliser les directives `User` et `Group` pour définir les privilèges des processus enfants. Les processus enfants doivent pouvoir être en mesure de lire tous les contenus destinés à être servis, mais doivent avoir des privilèges aussi bas que possible. De plus, ces directives définissent également les privilèges dont vont hériter les scripts CGI (sauf si on utilise `suexec`).

La directive `MaxConnectionsPerChild` permet de définir la fréquence à laquelle le serveur recycle ses processus en arrêtant les plus anciens et en en lançant de nouveaux.

Ce module MPM utilise le mutex `mpm-accept` pour sérialiser l'accès aux connexions entrantes lorsqu'un problème d'afflux de requêtes peut survenir (en général, lorsqu'il y a plusieurs sockets en écoute). Les différents aspects de l'implémentation de ce mutex peuvent être configurés via la directive `Mutex`. Vous trouverez des informations plus détaillées à propos de ce mutex dans la documentation sur les conseils en matière de performances.

Langues Disponibles: de | en | fr | ja | tr