event Une variante du MPM worker conçue pour ne mobiliser des threads que pour les connexions en cours de traitement MPM event.c mpm_event_module

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.

 Le MPM worker
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, 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 non seulement les sockets en écoute, mais aussi tous les sockets en état Keep Alive.

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.

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.

AcceptMutex CoreDumpDirectory EnableExceptionHook Group Listen ListenBacklog SendBufferSize LockFile MaxClients MaxMemFree MaxRequestsPerChild MaxSpareThreads MinSpareThreads PidFile ScoreBoardFile ServerLimit StartServers ThreadLimit ThreadsPerChild ThreadStackSize User