<-
Apache > Serveur HTTP > Documentation > Version 2.4 > Modules

Apache MPM event

Langues Disponibles:  en  |  fr 

Description:Une variante du MPM worker con´┐Żue pour ne mobiliser des threads que pour les connexions en cours de traitement
Statut:MPM
Identificateur´┐Żde´┐ŻModule:mpm_event_module
Fichier´┐ŻSource:event.c

Sommaire

Le module multi-processus (MPM) event est con´┐Żu pour permettre le traitement d'un nombre accru de requ´┐Żtes simultan´┐Żes en d´┐Żl´┐Żguant certaines t´┐Żches ´┐Ż des threads de support, lib´┐Żrant par l´┐Ż-m´┐Żme le thread principal et lui permettant de traiter les nouvelles requ´┐Żtes. Il s'inspire du MPM worker qui impl´┐Żmente un serveur hybride multi-processus/multi-threads. Les directives de configuration ´┐Ż l'ex´┐Żcution sont identiques ´┐Ż celles du MPM worker.

Pour utiliser le MPM event, ajoutez --with-mpm=event aux arguments du script configure lorsque vous compilez le programme httpd.

Directives

Sujets

Voir aussi

top

Comment tout cela fonctionne

Ce MPM essaie de r´┐Żsoudre le 'probl´┐Żme keep alive' de HTTP. Lorsqu'un client a soumis une premi´┐Żre requ´┐Żte, il peut garder la connexion ouverte, et envoyer les requ´┐Żtes suivantes en utilisant le m´┐Żme socket. Ceci permet de r´┐Żduire de mani´┐Żre significative la surcharge due ´┐Ż la cr´┐Żation de connexions TCP. Cependant, le serveur HTTP Apache mobilise en principe ´┐Ż cet effet un processus/thread enfant en attente des donn´┐Żes du client, ce qui am´┐Żne son propre lot d'inconv´┐Żnients. Pour r´┐Żsoudre ce probl´┐Żme, event utilise un thread d´┐Żdi´┐Ż qui g´┐Żre les sockets en ´┐Żcoute, tous les sockets en ´┐Żtat Keep Alive, et les sockets o´┐Ż les filtres gestionnaires et de protocole ont fait leur travail et pour lesquels la seule chose restant ´┐Ż faire consiste ´┐Ż envoyer les donn´┐Żes au client. La page d'´┐Żtat de mod_status montre les connexions qui se trouvent dans les situations mentionn´┐Żes.

Le gestionnaire de connexion am´┐Żlior´┐Ż peut ne pas fonctionner pour les filtres de connexion qui se d´┐Żclarent eux-m´┐Żmes comme incompatibles avec le MPM event. Dans ce cas, le MPM event adopte le comportement du MPM worker et r´┐Żserve un thread par connexion. Tous les modules fournis avec le serveur sont compatibles avec le MPM event.

Une restriction similaire existe pour les requ´┐Żtes qui utilisent un filtre en sortie qui doit lire et/ou modifier l'ensemble du corps de r´┐Żponse, comme dans le cas de mod_ssl, mod_deflate, ou mod_include. Si la connexion avec le client se bloque pendant que le filtre traite les donn´┐Żes, et si la quantit´┐Ż de donn´┐Żes g´┐Żn´┐Żr´┐Że par ce filtre est trop importante pour ´┐Żtre mise en tampon m´┐Żmoire, le thread utilis´┐Ż pour la requ´┐Żte n'est pas lib´┐Żr´┐Ż pendant que httpd attend que toutes les donn´┐Żes restantes aient ´┐Żt´┐Ż transmises au client.

Le MPM pr´┐Żsuppose que l'impl´┐Żmentation apr_pollset sous-jacente est raisonnablement s´┐Żre du point de vue des threads. Ceci permet au MPM d'´┐Żviter un verrouillage de haut niveau excessif, ou de devoir activer le thread en ´┐Żcoute afin de lui envoyer un socket keep alive. Tout ceci n'est actuellement compatible qu'avec KQueue et EPoll.

top

Pr´┐Żrequis

Ce MPM d´┐Żpend des op´┐Żrations atomiques compare-and-swap d'APR pour la synchronisation des threads. Si vous compilez pour une plate-forme x86 et n'avez pas besoin du support 386, ou si vous compilez pour une plate-forme SPARC et n'avez pas besoin du support pre-UltraSPARC, ajoutez --enable-nonportable-atomics=yes aux arguments du script configure. Ceci permettra ´┐Ż APR d'impl´┐Żmenter les op´┐Żrations atomiques en utilisant des instructions performantes indisponibles avec les processeurs plus anciens.

Ce MPM ne fonctionne pas de mani´┐Żre optimale sur les plates-formes plus anciennes qui ne g´┐Żrent pas correctement les threads, mais ce probl´┐Żme est sans objet du fait du pr´┐Żrequis concernant EPoll ou KQueue.

top

AsyncRequestWorkerFactor Directive

Description:Limite le nombre de connexions simultan´┐Żes par thread
Syntaxe:AsyncRequestWorkerFactor facteur
D´┐Żfaut:2
Contexte:configuration du serveur
Statut:MPM
Module:event
Compatibilit´┐Ż:Disponible depuis la version 2.3.13

Le MPM event g´┐Żre certaines connexions de mani´┐Żre asynchrone ; dans ce cas, les threads traitant la requ´┐Żte sont allou´┐Żs selon les besoins et pour de courtes p´┐Żriodes. Dans les autres cas, un thread est r´┐Żserv´┐Ż par connexion. Ceci peut conduire ´┐Ż des situations o´┐Ż tous les threads sont satur´┐Żs et o´┐Ż aucun thread n'est capable d'effectuer de nouvelles t´┐Żches pour les connexions asynchrones ´┐Żtablies.

Pour minimiser les effets de ce probl´┐Żme, le MPM event utilise deux m´┐Żthodes : tout d'abord, il limite le nombre de connexions simultan´┐Żes par thread en fonction du nombre de processus inactifs. Ensuite, si tous les processus sont occup´┐Żs, il ferme des connexions permanentes, m´┐Żme si la limite de dur´┐Że de la connexion n'a pas ´┐Żt´┐Ż atteinte. Ceci autorise les clients concern´┐Żs ´┐Ż se reconnecter ´┐Ż un autre processus poss´┐Żdant encore des threads disponibles.

Cette directive permet de personnaliser finement la limite du nombre de connexions par thread. Un processus n'acceptera de nouvelles connexions que si le nombre actuel de connexions (sans compter les connexions ´┐Ż l'´┐Żtat "closing") est inf´┐Żrieur ´┐Ż :

ThreadsPerChild + (AsyncRequestWorkerFactor * nombre de threads inactifs)

En d'autres termes, le nombre maximum de connexions simultan´┐Żes sera :

(AsyncRequestWorkerFactor + 1) * MaxRequestWorkers

La directive MaxRequestWorkers se nommait MaxClients avant la version 2.3.13. La valeur ci-dessus montre que cet ancien nom ne correspondait pas ´┐Ż sa signification exacte pour le MPM event.

La directive AsyncRequestWorkerFactor accepte des valeurs d'argument de type non entier, comme "1.5".

Langues Disponibles:  en  |  fr 

top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.