Serveur Apache HTTP Version 2.4

| 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 | 
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.
 CoreDumpDirectory
 CoreDumpDirectory EnableExceptionHook
 EnableExceptionHook Group
 Group Listen
 Listen ListenBacklog
 ListenBacklog MaxConnectionsPerChild
 MaxConnectionsPerChild MaxMemFree
 MaxMemFree MaxRequestWorkers
 MaxRequestWorkers MaxSpareThreads
 MaxSpareThreads MinSpareThreads
 MinSpareThreads PidFile
 PidFile ReceiveBufferSize
 ReceiveBufferSize ScoreBoardFile
 ScoreBoardFile SendBufferSize
 SendBufferSize ServerLimit
 ServerLimit StartServers
 StartServers ThreadLimit
 ThreadLimit ThreadsPerChild
 ThreadsPerChild ThreadStackSize
 ThreadStackSize User
 UserUn 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 :
      MaxConnectionsPerChild � z�ro
      MaxSpareThreads � la m�me valeur que MaxRequestWorkersVoici 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.