Modules multi-processus (MPMs) - Serveur HTTP Apache Version 2.4

Serveur HTTP Apache Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4

# Modules multi-processus (MPMs)

Langues Disponibles: de | en | es | fr | ja | ko | tr | zh-cn

Ce document décrit ce qu'est un Module Multi-Processus, ainsi que la manière dont ces modules sont utilisés par le serveur HTTP Apache.

### Voir aussi

- Commentaires

## Introduction

La conception du serveur HTTP Apache en fait un serveur web puissant et flexible pouvant fonctionner sur une très grande variété de plateformes et toute une gamme d'environnements différents. Plateformes différentes et environnements différents signifient souvent fonctionnalités différentes, ou utilisation de différentes méthodes pour implémenter la même fonctionnalité le plus efficacement possible. Apache httpd s'est toujours accomodé d'une grande variété d'environnements grâce à sa conception modulaire. Cette conception autorise le webmaster à choisir quelles fonctionnalités seront incluses dans le serveur en sélectionnant les modules à charger soit à la compilation, soit à l'exécution.

Le serveur HTTP Apache 2.0 a étendu cette conception modulaire aux fonctions les plus élémentaires d'un serveur web. Le serveur est fourni avec une variété de Modules Multi-Processus (MPMs) qui sont responsables de l'association aux ports réseau de la machine, acceptent les requêtes, et se chargent de répartir ces dernières entre les différents processus enfants.

L'extension de la conception modulaire à ce niveau du serveur comporte deux avantages importants :

- Apache httpd peut supporter plus proprement et efficacement une grande variété de systèmes d'exploitation. En particulier, la version Windows du serveur est maintenant beaucoup plus efficace, depuis que `mpm_winnt` peut utiliser les fonctionnalités réseau natives à la place de la couche POSIX utilisée par Apache httpd 1.3. Cet avantage s'étend aussi aux systèmes d'exploitation qui implémentent des MPMs spécialisés.
- le serveur est plus à même de répondre aux besoins d'un site particulier. Par exemple, les sites qui sont très sollicités peuvent utiliser un MPM threadé comme `worker` ou `event`, tandis que les sites qui privilégient la stabilité ou la compatibilité avec des logiciels plus anciens peuvent utiliser un module comme `prefork`.

Du point de vue de l'utilisateur, les MPMs ne sont pas différents des autres modules Apache httpd. La principale différence réside dans le fait qu'un et un seul MPM à la fois doit être chargé lorsque le serveur s'exécute. La liste des MPMs disponibles est fournie dans l'index des modules.

## MPM par défaut

La table suivante fournit la liste des MPMs par défaut pour divers systèmes d'exploitation. Il s'agit du MPM qui sera utilisé si vous n'en spécifiez pas un autre à la compilation.

Netware | `mpm_netware`
OS/2 | `mpmt_os2`
Unix | `prefork`, `worker`, ou `event`, selon les possibilités de la plate-forme
Windows | `mpm_winnt`

Ici, 'Unix' sous-entend les systèmes d'exploitation de type Unix, comme Linux, BSD, Solaris, Mac OS X, etc...

Dans le cas des systèmes d'exploitation de type Unix, le choix du MPM à installer est orienté par deux questions :

1. Est-ce que le système supporte les threads ?

2. Est-ce que le système supporte le polling thread-safe (et en particulier les fonctions kqueue et epoll) ?

Si la réponse aux deux questions est 'oui', le MPM par défaut sera `event`.

Si la réponse à la première question est 'oui', et la réponse à la deuxième 'non', le MPM par défaut sera `worker`.

Si la réponse aux deux questions est 'non', le MPM par défaut sera `prefork`.

En pratique, cela signifie que le MPM par défaut sera presque toujours `event` car tous les systèmes d'exploitation modernes satisfont aux deux conditions.

## Compiler un module MPM en tant que module statique

Les modules MPM peuvent être compilés en tant que modules statiques sur toutes les plates-formes. A la compilation d'Apache, un seul module MPM doit être choisi pour être compilé et lié avec le serveur. La recompilation du serveur sera donc nécessaire si vous souhaitez changer de module MPM.

Pour choisir un module MPM autre que le MPM par défaut, utiliser l'argument `--with-mpm=NOM` du script `configure`. NOM est le nom du MPM désiré.

Une fois le serveur compilé, il est possible de savoir quel MPM a été choisi à l'aide de la commande `./httpd -l`. Cette commande fournit la liste de tous les modules compilés avec le serveur, y compris le MPM.

## Compiler un module MPM en tant que module DSO (Dynamic Shared Object)

Sous Unix et les plates-formes similaires, les modules MPM peuvent être compilés en tant que modules DSO et chargés dynamiquement dans le serveur comme tout module DSO. Compiler les modules MPM en tant que modules DSO permet de changer de MPM en modifiant la directive `LoadModule` concernée, sans avoir à recompiler le serveur.

    LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

Toute tentative de charger plusieurs modules MPM via la directive `LoadModule` empêchera le serveur de démarrer et affichera l'erreur suivante :

`AH00534: httpd: Configuration error: More than one MPM loaded.`

Cette fonctionnalité est activée via l'option `--enable-mpms-shared` du script `configure`. Si on ajoute l'argument `all`, tous les modules MPM disponibles sur la plate-forme considérée seront installés. Cet argument peut aussi contenir une liste de modules MPM à installer.

Le module MPM par défaut, sélectionné automatiquement ou spécifié via l'option `--with-mpm` du script `configure`, sera chargé via une directive `LoadModule` du fichier de configuration du serveur généré. Pour choisir un autre module MPM, vous devrez donc modifier cette directive

Langues Disponibles: de | en | es | fr | ja | ko | tr | zh-cn