From 1db4bed81e878af298cee3d1996b274aa863a227 Mon Sep 17 00:00:00 2001 From: Lucien Gentis Date: Sat, 27 Feb 2016 17:48:49 +0000 Subject: [PATCH] XML updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1732658 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/event.xml.fr | 351 ++++++++++++++++++------- docs/manual/sections.xml.fr | 495 ++++++++++++++++++++--------------- 2 files changed, 544 insertions(+), 302 deletions(-) diff --git a/docs/manual/mod/event.xml.fr b/docs/manual/mod/event.xml.fr index cc115eb9ba..53311c24de 100644 --- a/docs/manual/mod/event.xml.fr +++ b/docs/manual/mod/event.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -24,22 +24,18 @@ event -Une variante du MPM worker conçue pour ne +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.

+

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 + aux threads d'écoute, libérant par là-même les + threads de travail et leur permettant de traiter les nouvelles requêtes.

Pour utiliser le MPM event, ajoutez --with-mpm=event aux arguments du script @@ -50,78 +46,189 @@ mobiliser des threads que pour les connexions en cours de traitementLe 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, 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.

+
Relations avec le MPM Worker +

Le MPM event s'inspire du MPM worker qui +implémente un serveur hybride multi-processus et multi-threads. Un processus de +contrôle unique (le parent) est chargé de lancer des processus enfants. Chaque +processus enfant crée un nombre de threads serveurs défini via la directive +ThreadsPerChild, ainsi qu'un thread +d'écoute qui surveille les requêtes entrantes et les distribue aux threads de +travail pour traitement au fur et à mesure de leur arrivée.

+ +

Les directives de configuration à l'exécution sont identiques à celles que +propose le MPM worker, avec l'unique addition de la directive +AsyncRequestWorkerFactor.

-
Prérequis -

Ce MPM dépend des opérations atomiques compare-and-swap + +

Comment tout cela fonctionne + +

Ce module MPM tente de résoudre le "problème keep + alive" de HTTP. Lorsqu'un client a effectué une première requête, il peut + garder la connexion ouverte et envoyer les requêtes suivante en utilisant le + même socket, ce qui diminue considérablement la charge qui aurait été + induite par la création de nouvelles connexions TCP. Cependant, le + fonctionnement du serveur HTTP Apache impose de réserver un couple processus + enfant/thread pour attendre les données en provenance du client, ce qui + présente certains inconvénients. + Pour résoudre ce problème, le MPM Event utilise un thread d'écoute dédié + pour chaque processus pour gérer les sockets d'écoute, tous les sockets qui + sont dans un état de connexion persistante, les sockets où les + filtres de gestionnaire et de protocole ont fait leur travail, et ceux pour + lesquels la seule chose restant à faire est l'envoi des données au client. +

+ +

La directive AsyncRequestWorkerFactor permet de + définir le nombre total de connexions qu'un bloc processus/thread peut + gérer.

+ +
Connexions asynchrones +

Avec les MPM précédents, les connexions asynchrones nécessitaient + un thread de travail dédié, mais ce n'est plus le cas avec le MPM Event. + La page d'état de mod_status montre de nouvelles + colonnes dans la section "Async connections" :

+
+
Writing
+
Lors de l'envoi de la réponse au client, il peut arriver que le + tampon d'écriture TCP soit plein si la connexion est trop lente. Si + cela se produit, une instruction write() vers le socket + renvoie en général EWOULDBLOCK ou EAGAIN + pour que l'on puisse y écrire à nouveau après un certain temps + d'inactivité. Le thread de travail qui utilise le socket doit alors + être en mesure de récupérer la tâche en attente et la restituer au + thread d'écoute qui, à son tour, la réattribuera au premier thread + de travail disponible, lorsqu'un évènement sera généré pour le socket + (par exemple, "il est maintenant possible d'écrire dans le socket"). + Veuillez vous reporter à la section à propos des limitations pour + plus de détails. +
+ +
Keep-alive
+
La gestion des connexions persistantes constitue la principale + amélioration par rapport au MPM Worker. Lorsqu'un thread de travail + a terminé l'envoi d'une réponse à un client, il peut restituer la + gestion du socket au thread d'écoute, qui à son tour va attendre un + évènement en provenance du système d'exploitation comme "le socket + est lisible". Si une nouvelle requête arrive en provenance du + client, le thread d'écoute l'attribuera au premier thread de travail + disponible. Inversement, si le délai KeepAliveTimeout est atteint, le socket + sera fermé par le thread d'écoute. Les threads de travail n'ont + donc plus à s'occuper des sockets inactifs et ils peuvent être + réutilisés pour traiter d'autres requêtes.
+ +
Closing
+
Parfois, le MPM doit effectuer une fermeture progressive, c'est + à dire envoyer au client une erreur survenue précédemment alors que + ce dernier est en train de transmettre des données à httpd. Envoyer la réponse et + fermer immédiatement la connexion n'est pas une bonne solution car + le client (qui est encore en train d'envoyer le reste de la requête) + verrait sa connexion réinitialisée et ne pourrait pas lire la + réponse de httpd. Si cela se produit, httpd essaie donc de lire le + reste de la requête afin de permettre au client de lire la réponse + entièrement. La fermeture progressive est limitée dans le temps, + mais elle peut tout de même être assez longue, si bien qu'il est + intéressant qu'un thread de travail puisse se décharger de cette + tâche sur le thread d'écoute.
+
+ +

Ces améliorations sont disponible pour les connexions HTTP ou HTTPS.

+ +
+ +
Limitations +

La gestion améliorée des connexions peut ne pas fonctionner pour + certains filtres de connexion qui se sont déclarés eux-mêmes + incompatibles avec le MPM Event. Dans ce cas, le MPM Event réadoptera le + comportement du MPM worker et réservera un thread de + travail par connexion. Notez que tous les modules inclus dans la + distribution du serveur httpd sont compatibles avec le MPM Event.

+ +

Une restriction similaire apparaît lorsqu'une requête utilise un + filtre en sortie qui doit pouvoir lire et/ou modifier la totalité du + corps de la réponse. Si la connexion avec le client se bloque pendant + que le filtre traite les données, et si la quantité de données produites + par le filtre est trop importante pour être stockée en mémoire, le + thread utilisé pour la requête n'est pas libéré pendant que httpd attend + que les données soient transmises au client.
+ Pour illustrer ce cas de figure, nous pouvons envisager les deux + situations suivantes : servir une ressource statique (comme un fichier + CSS) ou servir un contenu issu d'un programme FCGI/CGI ou d'un serveur + mandaté. La première situation est prévisible ; en effet, le MPM Event a + une parfaite visibilité sur la fin du contenu, et il peut utiliser les + évènements : le thread de travail qui sert la réponse peut envoyer les + premiers octets jusqu'à ce que EWOULDBLOCK ou + EAGAIN soit renvoyé, et déléguer le reste de la réponse au thread + d'écoute. Ce dernier en retour attend un évènement sur le socket, et + délègue le reste de la réponse au premier + thread de travail disponible. Dans la deuxième situation par contre + (FCGI/CGI/contenu mandaté), le MPM n'a pas de visibilité sur la fin de + la réponse, et le thread de travail doit terminer sa tâche avant de + rendre le contrôle au thread d'écoute. La seule solution consisterait + alors à stocker la réponse en mémoire, mais ce ne serait pas l'option la + plus sure en matière de stabilité du serveur et d'empreinte mémoire. +

+ +
+ +
Matériel d'arrière-plan +

Le modèle event a été rendu possible par l'introduction de nouvelles + APIs dans les systèmes d'exploitation supportés :

+
    +
  • epoll (Linux)
    • +
  • kqueue (BSD)
    • +
  • event ports (Solaris)
    • +
+

Avant que ces APIs soient mises à disposition, les APIs + traditionnelles select et poll devaient être + utilisées. Ces APIs deviennent lentes si on les utilise pour gérer de + nombreuses connexions ou si le jeu de connexions possède un taux de + renouvellement élevé. Les nouvelles APIs permettent de gérer beaucoup + plus de connexions et leur performances sont meilleures lorsque le jeu + de connexions à gérer change fréquemment. Ces APIs ont donc rendu + possible l'écriture le MPM Event qui est mieux adapté à la situation + HTTP typique où de nombreuses connexions sont inactives.

+ +

Le MPM Event suppose que l'implémentation de apr_pollset + sous-jacente est raisonnablement sure avec l'utilisation des threads + (threadsafe). Ceci évite au MPM de devoir effectuer trop verrouillages + de haut niveau, ou d'avoir à réveiller le thread d'écoute pour lui + envoyer un socket keep-alive. Ceci n'est possible 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 + 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 +

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.

  • Pour utiliser ce MPM sous FreeBSD, la version 5.3 ou - supérieure de ce système est recommandée. Il est cependant - possible d'exécuter ce MPM sous FreeBSD 5.2.1 si vous utilisez + supérieure de ce système est recommandée. Il est cependant + possible d'exécuter ce MPM sous FreeBSD 5.2.1 si vous utilisez libkse (voir man libmap.conf).
  • Pour NetBSD, il est recommander d'utiliser la version 2.0 ou - supérieure.
    • + supérieure. -
  • Pour Linux, un noyau 2.6 est recommandé. Il faut aussi - s'assurer que votre version de glibc a été compilée +
  • Pour Linux, un noyau 2.6 est recommandé. Il faut aussi + s'assurer que votre version de glibc a été compilée avec le support pour EPoll.
@@ -168,35 +275,39 @@ mobiliser des threads que pour les connexions en cours de traitement AsyncRequestWorkerFactor -Limite le nombre de connexions simultanées par thread +Limite le nombre de connexions simultanées par thread AsyncRequestWorkerFactor facteur 2 server config 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.

+

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 :

+
    +
  • il limite le nombre de connexions + simultanées par thread en fonction du nombre de processus + inactifs;
    • +
  • 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 + 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 à :

+ compter les connexions à l'état "closing") est + inférieur à :

ThreadsPerChild + @@ -204,18 +315,82 @@ mobiliser des threads que pour les connexions en cours de traitementnombre de threads inactifs)

-

En d'autres termes, le nombre maximum de connexions simultanées - sera :

+

Il est possible d'effectuer une estimation du nombre maximum de + connexions simultanées pour tous les processus et pour un nombre donné moyen + de threads de travail inactifs comme suit : +

+ + +

+ (ThreadsPerChild + + (AsyncRequestWorkerFactor * + number of idle workers)) * + ServerLimit +

+ + Exemple + + +ThreadsPerChild = 10 +ServerLimit = 4 +AsyncRequestWorkerFactor = 2 +MaxRequestWorkers = 40 + +idle_workers = 4 (moyenne pour tous les processus pour faire simple) + +max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit + = (10 + (2 * 4)) * 4 = 72 + + + + +

Lorsque tous les threads de travail sont inactifs, le nombre maximum + absolu de connexions simultanées peut être calculé de manière plus simple :

(AsyncRequestWorkerFactor + 1) * MaxRequestWorkers

+ Exemple + + +ThreadsPerChild = 10 +ServerLimit = 4 +MaxRequestWorkers = 40 +AsyncRequestWorkerFactor = 2 + + + +

Si tous les threads de tous les processus sont inactifs, alors :

+ + idle_workers = 10 + +

Nous pouvons calculer le nombre maximum absolu de connexions simultanées + de deux manières :

+ + + +max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit + = (10 + (2 * 10)) * 4 = 120 + +max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers + = (2 + 1) * 40 = 120 + + + + +

Le réglage de la directive + AsyncRequestWorkerFactor nécessite de connaître le + trafic géré par httpd pour chaque style d'utilisation spécifique ; si vous + modifiez la valeur par défaut, vous devrez par conséquent effectuer des + tests approfondis en vous appuyant étroitement sur les données fournies par + mod_status.

+

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 + ci-dessus montre que cet ancien nom ne correspondait pas à sa signification exacte pour le MPM event.

La directive AsyncRequestWorkerFactor diff --git a/docs/manual/sections.xml.fr b/docs/manual/sections.xml.fr index fd0a5ff5b6..288174d54d 100644 --- a/docs/manual/sections.xml.fr +++ b/docs/manual/sections.xml.fr @@ -1,9 +1,9 @@ - + - +