1 <?xml version="1.0" encoding="UTF-8"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head>
4 <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
7 This file is generated from xml source: DO NOT EDIT
8 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
10 <title>Optimisation des performances d'Apache - Serveur HTTP Apache Version 2.5</title>
11 <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
12 <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
13 <link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="../style/css/prettify.css" />
14 <script src="../style/scripts/prettify.min.js" type="text/javascript">
17 <link href="../images/favicon.ico" rel="shortcut icon" /></head>
18 <body id="manual-page"><div id="page-header">
19 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
20 <p class="apache">Serveur HTTP Apache Version 2.5</p>
21 <img alt="" src="../images/feather.png" /></div>
22 <div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
24 <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.5</a> > <a href="./">Documentations diverses</a></div><div id="page-content"><div id="preamble"><h1>Optimisation des performances d'Apache</h1>
26 <p><span>Langues Disponibles: </span><a href="../en/misc/perf-tuning.html" hreflang="en" rel="alternate" title="English"> en </a> |
27 <a href="../fr/misc/perf-tuning.html" title="Français"> fr </a> |
28 <a href="../ko/misc/perf-tuning.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
29 <a href="../tr/misc/perf-tuning.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
33 <div class="warning"><h3>Avertissement</h3>
34 <p>Ce document est en partie obsolète et son contenu peut s'avérer
38 <p>Apache 2.4 est un serveur web à usage général, conçu dans un but
39 d'équilibre entre souplesse, portabilité et performances. Bien que non
40 conçu dans le seul but d'établir une référence en la matière,
41 Apache 2.4 est capable de hautes performances dans de nombreuses situations
45 document décrit les options qu'un administrateur de serveur peut configurer
46 pour améliorer les performances d'une installation d'Apache 2.4. Certaines
47 de ces options de configuration permettent au démon httpd de mieux tirer
48 parti des possibilités du matériel et du système d'exploitation, tandis
49 que d'autres permettent à l'administrateur de privilégier la vitesse
50 par rapport aux fonctionnalités.</p>
53 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#hardware">Problèmes matériels et relatifs au système d'exploitation</a></li>
54 <li><img alt="" src="../images/down.gif" /> <a href="#runtime">Optimisation de la configuration à l'exécution</a></li>
55 <li><img alt="" src="../images/down.gif" /> <a href="#compiletime">Optimisation de la configuration à la compilation</a></li>
56 <li><img alt="" src="../images/down.gif" /> <a href="#trace">Appendice : Analyse détaillée d'une trace</a></li>
57 </ul><h3>Voir aussi</h3><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
58 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
60 <h2><a name="hardware" id="hardware">Problèmes matériels et relatifs au système d'exploitation</a><a title="Lien permanent" href="#hardware" class="permalink">¶</a></h2>
64 <p>Le principal problème matériel qui affecte les performances du serveur
65 web est la mémoire vive (RAM). Un serveur web ne devrait jamais avoir à
66 utiliser le swap, car le swapping augmente le temps de réponse de chaque
67 requête au delà du point que les utilisateurs considèrent comme
68 "trop lent". Ceci incite les utilisateurs à cliquer sur "Stop", puis
69 "Charger à nouveau", ce qui a pour effet d'augmenter encore la charge
70 du serveur. Vous pouvez, et même devez définir la valeur de la directive
71 <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> de façon à ce que
72 votre serveur ne lance pas un nombre de processus enfants tel qu'il
73 commence à faire du swapping. La méthode pour y parvenir est
74 simple : déterminez la taille de votre processus Apache standard en
75 consultant votre liste de processus à l'aide d'un outil tel que
76 <code>top</code>, et divisez votre quantité totale de mémoire disponible
77 par cette taille, tout en gardant un espace suffisant
78 pour les autres processus.</p>
80 <p>Hormis ce réglage relatif à la mémoire, le reste est trivial : le
81 processeur, la carte réseau et les disques doivent être suffisamment
82 rapides, où "suffisamment rapide" doit être déterminé par
85 <p>Le choix du système d'exploitation dépend principalement du
86 contexte local. Voici cependant quelques conseils qui se sont
87 généralement avérés utiles :</p>
91 <p>Exécutez la dernière version stable et le niveau de patches le
92 plus haut du système d'exploitation que vous avez choisi. De nombreux
93 éditeurs de systèmes d'exploitation ont amélioré de manière
94 significative les performances de leurs piles TCP et de leurs
95 bibliothèques de thread ces dernières années.</p>
99 <p>Si votre système d'exploitation possède un appel système
100 <code>sendfile(2)</code>, assurez-vous d'avoir installé la version
101 et/ou les patches nécessaires à son activation. (Pour Linux, par
102 exemple, cela se traduit par Linux 2.4 ou plus. Pour les versions
103 anciennes de Solaris 8, vous pouvez être amené à appliquer un patch.)
104 Sur les systèmes où il est disponible, <code>sendfile</code> permet
105 à Apache de servir les contenus statiques plus rapidement, tout en
106 induisant une charge CPU inférieure.</p>
110 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
111 <div class="section">
112 <h2><a name="runtime" id="runtime">Optimisation de la configuration à l'exécution</a><a title="Lien permanent" href="#runtime" class="permalink">¶</a></h2>
116 <table class="related"><tr><th>Modules Apparentés</th><th>Directives Apparentées</th></tr><tr><td><ul><li><code class="module"><a href="../mod/mod_dir.html">mod_dir</a></code></li><li><code class="module"><a href="../mod/mpm_common.html">mpm_common</a></code></li><li><code class="module"><a href="../mod/mod_status.html">mod_status</a></code></li></ul></td><td><ul><li><code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code></li><li><code class="directive"><a href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a></code></li><li><code class="directive"><a href="../mod/core.html#hostnamelookups">HostnameLookups</a></code></li><li><code class="directive"><a href="../mod/core.html#enablemmap">EnableMMAP</a></code></li><li><code class="directive"><a href="../mod/core.html#enablesendfile">EnableSendfile</a></code></li><li><code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code></li><li><code class="directive"><a href="../mod/prefork.html#maxspareservers">MaxSpareServers</a></code></li><li><code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code></li><li><code class="directive"><a href="../mod/core.html#options">Options</a></code></li><li><code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code></li></ul></td></tr></table>
118 <h3><a name="dns" id="dns">HostnameLookups et autres considérations à propos du DNS</a></h3>
122 <p>Avant Apache 1.3, la directive
123 <code class="directive"><a href="../mod/core.html#hostnamelookups">HostnameLookups</a></code> était positionnée
124 par défaut à <code>On</code>, ce qui impliquait une recherche DNS et donc un temps d'attente
125 supplémentaire pour chaque requête. Avec Apache 2.4, <code class="directive"><a href="../mod/core.html#hostnamelookups">HostnameLookups</a></code> est positionnée par défaut à
126 <code>Off</code>. Si vous avez besoin de convertir des adresses IP en noms
127 d'hôtes dans vos fichiers journaux, il est préférable d'effectuer un
128 traitement à postériori plutôt que de forcer Apache à le faire en temps
129 réel. Il est recommandé d'effectuer ce genre de traitement a posteriori
130 de vos fichiers journaux sur une autre machine que celle qui héberge le
131 serveur web en production, afin que cette activité n'affecte pas les
132 performances du serveur.</p>
134 <p>Si vous utilisez une directive
135 <code><code class="directive"><a href="../mod/mod_access_compat.html#allow">Allow</a></code>from domain</code>
137 <code><code class="directive"><a href="../mod/mod_access_compat.html#deny">Deny</a></code> from domain</code>
138 (ce qui signifie que vous utilisez un nom d'hôte ou un nom de domaine à
139 la place d'une adresse IP), vous devrez compter avec deux recherches
140 DNS (une recherche inverse suivie d'une recherche directe pour
141 s'assurer que l'adresse IP n'a pas été usurpée). C'est pourquoi il est
142 préférable, pour améliorer les performances, et chaque fois que c'est
143 possible, d'utiliser des adresses IP plutôt que des noms de domaines.</p>
145 <div class="warning"><h3>Avertissement :</h3>
146 <p>Veuillez utiliser la directive <code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code> avec Apache 2.4 ; pour plus de
147 détails, reportez-vous au <a href="../upgrading.html">guide de mise à
148 jour</a> correspondant.</p>
151 <p>Notez qu'il est possible de modifier la portée des directives, en les
152 plaçant par exemple à l'intérieur d'une section
153 <code><Location "/server-status"></code>. Les recherches DNS ne
154 seront alors effectuées que pour les requêtes qui satisfont aux critères.
155 Voici un exemple qui désactive les recherches DNS sauf pour les fichiers
156 <code>.html</code> et <code>.cgi</code> :</p>
158 <pre class="prettyprint lang-config"><Files ~ "\.(html|cgi)$">
163 <p>Mais même dans ce cas, si vous n'avez besoin de noms DNS que dans
164 certains CGIs, vous pouvez effectuer l'appel à <code>gethostbyname</code>
165 dans les CGIs spécifiques qui en ont besoin.</p>
169 <h3><a name="symlinks" id="symlinks">FollowSymLinks et SymLinksIfOwnerMatch</a></h3>
173 <p>Chaque fois que la ligne <code>Options FollowSymLinks</code> sera
174 absente, ou que la ligne <code>Options SymLinksIfOwnerMatch</code> sera
175 présente dans votre espace d'adressage, Apache devra effectuer des
176 appels système supplémentaires pour vérifier la présence de liens
177 symboliques. Un appel supplémentaire par élément du chemin du fichier.
178 Par exemple, si vous avez :</p>
180 <pre class="prettyprint lang-config">DocumentRoot "/www/htdocs"
181 <Directory "/">
182 Options SymLinksIfOwnerMatch
183 </Directory></pre>
186 <p>et si une requête demande l'URI <code>/index.html</code>, Apache
187 effectuera un appel à <code>lstat(2)</code> pour
188 <code>/www</code>, <code>/www/htdocs</code>, et
189 <code>/www/htdocs/index.html</code>. Les résultats de ces appels à
190 <code>lstat</code> ne sont jamais mis en cache, ils devront donc être
191 générés à nouveau pour chaque nouvelle requête. Si vous voulez absolument
192 vérifier la sécurité des liens symboliques, vous pouvez utiliser une
193 configuration du style :</p>
195 <pre class="prettyprint lang-config">DocumentRoot "/www/htdocs"
196 <Directory "/">
197 Options FollowSymLinks
200 <Directory "/www/htdocs">
201 Options -FollowSymLinks +SymLinksIfOwnerMatch
202 </Directory></pre>
205 <p>Ceci évite au moins les vérifications supplémentaires pour le chemin
206 défini par <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code>. Notez que
207 vous devrez ajouter des sections similaires si vous avez des chemins
208 définis par les directives
209 <code class="directive"><a href="../mod/mod_alias.html#alias">Alias</a></code> ou
210 <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> en dehors de
211 la racine de vos documents. Pour améliorer les performances, et supprimer
212 toute protection des liens symboliques, ajoutez l'option
213 <code>FollowSymLinks</code> partout, et n'utilisez jamais l'option
214 <code>SymLinksIfOwnerMatch</code>.</p>
218 <h3><a name="htaccess" id="htaccess">AllowOverride</a></h3>
222 <p>Dans toute partie de votre espace d'adressage où vous autoriserez
223 la surcharge de la configuration (en général à l'aide de fichiers
224 <code>.htaccess</code>), Apache va tenter d'ouvrir <code>.htaccess</code>
225 pour chaque élément du chemin du fichier demandé. Par exemple, si vous
228 <pre class="prettyprint lang-config">DocumentRoot "/www/htdocs"
229 <Directory "/">
231 </Directory></pre>
234 <p>et qu'une requête demande l'URI <code>/index.html</code>, Apache
235 tentera d'ouvrir <code>/.htaccess</code>, <code>/www/.htaccess</code>,
236 et <code>/www/htdocs/.htaccess</code>. Les solutions sont similaires à
237 celles évoquées précédemment pour <code>Options FollowSymLinks</code>.
238 Pour améliorer les performances, utilisez <code>AllowOverride None</code>
239 pour tous les niveaux de votre espace d'adressage.</p>
243 <h3><a name="negotiation" id="negotiation">Négociation</a></h3>
247 <p>Dans la mesure du possible, évitez toute négociation de contenu si
248 vous tenez au moindre gain en performances. En pratique toutefois,
249 les bénéfices de la négociation l'emportent souvent sur la diminution
251 Il y a cependant un cas dans lequel vous pouvez accélérer le serveur.
252 Au lieu d'utiliser une directive générique comme :</p>
254 <pre class="prettyprint lang-config">DirectoryIndex index</pre>
257 <p>utilisez une liste explicite d'options :</p>
259 <pre class="prettyprint lang-config">DirectoryIndex index.cgi index.pl index.shtml index.html</pre>
262 <p>où vous placez le choix courant en première position.</p>
264 <p>Notez aussi que créer explicitement un fichier de
265 <code>correspondances de type</code> fournit de meilleures performances
266 que l'utilisation des <code>MultiViews</code>, car les informations
267 nécessaires peuvent être simplement obtenues en lisant ce fichier, sans
268 avoir à parcourir le répertoire à la recherche de types de fichiers.</p>
270 <p>Par conséquent, si la négociation de contenu est nécessaire pour votre
271 site, préférez les fichiers de <code>correspondances de type</code> aux
272 directives <code>Options MultiViews</code> pour mener à bien cette
273 négociation. Se référer au document sur la
274 <a href="../content-negotiation.html">Négociation de contenu</a> pour une
275 description complète des méthodes de négociation, et les instructions
276 permettant de créer des fichiers de <code>correspondances de type</code>.</p>
280 <h3>Transfert en mémoire</h3>
284 <p>Dans les situations où Apache 2.x doit consulter le contenu d'un
285 fichier en train d'être servi - par exemple à l'occasion du traitement
286 d'une inclusion côté serveur - il transfère en général le fichier en
287 mémoire si le système d'exploitation supporte une forme quelconque
288 de <code>mmap(2)</code>.</p>
290 <p>Sur certains systèmes, ce transfert en mémoire améliore les
291 performances. Dans certains cas, ce transfert peut toutefois les dégrader
292 et même diminuer la stabilité du démon httpd :</p>
296 <p>Dans certains systèmes d'exploitation, <code>mmap</code> devient
297 moins efficace que <code>read(2)</code> quand le nombre de
298 processeurs augmente. Sur les serveurs multiprocesseurs sous Solaris,
299 par exemple, Apache 2.x sert parfois les fichiers consultés par le
300 serveur plus rapidement quand <code>mmap</code> est désactivé.</p>
304 <p>Si vous transférez en mémoire un fichier localisé dans un système
305 de fichiers monté par NFS, et si un processus sur
306 une autre machine cliente NFS supprime ou tronque le fichier, votre
307 processus peut rencontrer une erreur de bus la prochaine fois qu'il
308 essaiera d'accéder au contenu du fichier en mémoire.</p>
312 <p>Pour les installations où une de ces situations peut se produire,
313 vous devez utiliser <code>EnableMMAP off</code> afin de désactiver le
314 transfert en mémoire des fichiers servis. (Note : il est possible de
315 passer outre cette directive au niveau de chaque répertoire.)</p>
323 <p>Dans les cas où Apache peut se permettre d'ignorer le contenu du
324 fichier à servir - par exemple, lorsqu'il sert un contenu de fichier
325 statique - il utilise en général le support sendfile du noyau si le
326 système d'exploitation supporte l'opération <code>sendfile(2)</code>.</p>
328 <p>Sur la plupart des plateformes, l'utilisation de sendfile améliore
329 les performances en éliminant les mécanismes de lecture et envoi séparés.
330 Dans certains cas cependant, l'utilisation de sendfile peut nuire à la
331 stabilité du démon httpd :</p>
335 <p>Certaines plateformes peuvent présenter un support de sendfile
336 défaillant que la construction du système n'a pas détecté, en
337 particulier si les binaires ont été construits sur une autre machine
338 et transférés sur la machine où le support de sendfile est
342 <p>Dans le cas d'un système de fichiers monté
343 sous NFS, le noyau peut s'avérer incapable de servir
344 les fichiers réseau de manière fiable depuis
345 son propre cache.</p>
349 <p>Pour les installations où une de ces situations peut se produire,
350 vous devez utiliser <code>EnableSendfile off</code> afin de désactiver
351 la mise à disposition de contenus de fichiers par sendfile. (Note : il
352 est possible de passer outre cette directive au niveau de chaque
357 <h3><a name="process" id="process">Recyclage des processus enfants</a></h3>
361 <p>La directive <code class="directive"><a href="../mod/mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></code> permet de limiter le
362 nombre de connexions qu'un processus enfant peut gérer au cours de sa vie
363 (par défaut, la valeur est <code>0</code>, soit aucune limite). Tous les <a href="../mpm.html#defaults">MPMs</a> sont concernés, même ceux qui utilisent
364 des threads. Par exemple, chaque processus créé par le MPM
365 <code class="module"><a href="../mod/worker.html">worker</a></code> lance plusieurs threads qui gèrent les connexions,
366 mais cette directive n'en affecte pas le nombre total. Cela signifie
367 seulement que la valeur de la directive <code class="directive"><a href="../mod/mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></code> ne limitera que le
368 nombre de requêtes traitées par les threads lancés par un seul processus
371 <p>Dans des conditions d'utilisation optimales, la directive <code class="directive"><a href="../mod/mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></code> ne devrait imposer
372 aucune limite, car il n'y a à priori aucune raison de tuer un processus, si
373 ce n'est suite à un bug logiciel causant des fuites de mémoire ou un usage
376 <p>Lorsque le mode "keep-alive" est activé, un processus (ou un thread lancé
377 par un processus) est
378 maintenu et ne fait rien sinon attendre la prochaine requête sur la
379 connexion déjà ouverte. La valeur par défaut de <code>5</code> de la
380 directive <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> tend à
381 minimiser cet effet. Il faut trouver le bon compromis entre la bande
382 passante réseau et les ressources du serveur.</p>
386 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
387 <div class="section">
388 <h2><a name="compiletime" id="compiletime">Optimisation de la configuration à la compilation</a><a title="Lien permanent" href="#compiletime" class="permalink">¶</a></h2>
392 <h3>Choisir un Module Multi-Processus (MPM)</h3>
396 <p>Apache 2.x supporte les modèles simultanés enfichables, appelés
397 <a href="../mpm.html">Modules Multi-Processus</a> (MPMs). Vous devez
398 choisir un MPM au moment de la construction d'Apache. Certaines
399 plateformes ont des modules MPM spécifiques :
400 <code class="module"><a href="../mod/mpm_netware.html">mpm_netware</a></code>, <code class="module"><a href="../mod/mpmt_os2.html">mpmt_os2</a></code> et
401 <code class="module"><a href="../mod/mpm_winnt.html">mpm_winnt</a></code>. Sur les systèmes de type Unix, vous avez le
402 choix entre un grand nombre de modules MPM. Le choix du MPM peut affecter
403 la vitesse et l'évolutivité du démon httpd :</p>
407 <li>Le MPM <code class="module"><a href="../mod/worker.html">worker</a></code> utilise plusieurs processus
408 enfants possédant chacun de nombreux threads. Chaque thread gère une
409 seule connexion à la fois. Worker est en général un bon choix pour les
410 serveurs présentant un traffic important car il possède une empreinte
411 mémoire plus petite que le MPM prefork.</li>
413 <li>Comme le MPM Worker, le MPM <code class="module"><a href="../mod/event.html">event</a></code> utilise
414 les threads, mais il a été conçu pour traiter davantage de
415 requêtes simultanément en confiant une partie du travail à des
416 threads de support, ce qui permet aux threads principaux de
417 traiter de nouvelles requêtes.</li>
419 <li>Le MPM <code class="module"><a href="../mod/prefork.html">prefork</a></code> utilise plusieurs processus enfants
420 possédant chacun un seul thread. Chaque processus gère une seule
421 connexion à la fois. Sur de nombreux systèmes, prefork est comparable
422 en matière de vitesse à worker, mais il utilise plus de mémoire. De par
423 sa conception sans thread, prefork présente des avantages par rapport à
424 worker dans certaines situations : il peut être utilisé avec les
425 modules tiers qui ne supportent pas le threading, et son débogage est plus
426 aisé sur les platesformes présentant un support du débogage des threads
431 <p>Pour plus d'informations sur ces deux MPMs et les autres, veuillez
432 vous référer à la <a href="../mpm.html">documentation sur les
437 <h3><a name="modules" id="modules">Modules</a></h3>
441 <p>Comme le contrôle de l'utilisation de la mémoire est très important
442 en matière de performance, il est conseillé d'éliminer les modules que
443 vous n'utilisez pas vraiment. Si vous avez construit ces modules en
444 tant que <a href="../dso.html">DSOs</a>, leur élimination consiste
445 simplement à commenter la directive
446 <code class="directive"><a href="../mod/mod_so.html#loadmodule">LoadModule</a></code> associée à ce
447 module. Ceci vous permet de vérifier si votre site fonctionne toujours
448 après la suppression de tel ou tel module.</p>
450 <p>Par contre, si les modules que vous voulez supprimer sont liés
451 statiquement à votre binaire Apache, vous devrez recompiler ce dernier
452 afin de pouvoir les éliminer.</p>
454 <p>La question qui découle de ce qui précède est évidemment de
455 savoir de quels modules vous avez besoin et desquels vous pouvez vous
456 passer. La réponse sera bien entendu différente d'un site web à
457 l'autre. Cependant, la liste <em>minimale</em> de modules nécessaire à
458 la survie de votre site contiendra certainement
459 <code class="module"><a href="../mod/mod_mime.html">mod_mime</a></code>, <code class="module"><a href="../mod/mod_dir.html">mod_dir</a></code> et
460 <code class="module"><a href="../mod/mod_log_config.html">mod_log_config</a></code>. <code>mod_log_config</code> est bien
461 entendu optionnel puisque vous pouvez faire fonctionner un site web
462 en se passant de fichiers journaux ; ceci est cependant
467 <h3>Opérations atomiques</h3>
471 <p>Certains modules, à l'instar de <code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code> et des
472 versions de développement récentes du MPM worker, utilisent l'API
473 atomique d'APR. Cette API propose des opérations atomiques que l'on
474 peut utiliser pour alléger la synchronisation des threads.</p>
476 <p>Par défaut, APR implémente ces opérations en utilisant les
477 mécanismes les plus efficaces disponibles sur chaque plateforme cible
478 (Système d'exploitation et processeur). De nombreux processeurs modernes,
479 par exemple, possèdent une instruction qui effectue une opération
480 atomique de type comparaison et échange ou compare-and-swap (CAS) au
481 niveau matériel. Sur certaines platesformes cependant, APR utilise par
482 défaut une implémentation de l'API atomique plus lente, basée sur les
483 mutex, afin d'assurer la compatibilité avec les anciens modèles de
484 processeurs qui ne possèdent pas ce genre d'instruction. Si vous
485 construisez Apache pour une de ces platesformes, et ne prévoyez de
486 l'exécuter que sur des processeurs récents, vous pouvez sélectionner une
487 implémentation atomique plus rapide à la compilation en utilisant
488 l'option <code>--enable-nonportable-atomics</code> du
489 script configure :</p>
491 <div class="example"><p><code>
493 ./configure --with-mpm=worker --enable-nonportable-atomics=yes
496 <p>L'option <code>--enable-nonportable-atomics</code> concerne les
497 platesformes suivantes :</p>
501 <li>Solaris sur SPARC<br />
502 Sur Solaris/SPARC, APR utilise par défaut les opérations
503 atomiques basées sur les mutex. Cependant, si vous ajoutez l'option
504 <code>--enable-nonportable-atomics</code> au script configure, APR
505 génère un code qui utilise le code opération SPARC v8plus pour des
506 opérations de compare-and-swap matériel plus rapides. Si vous
507 utilisez cette option de configure avec Apache, les opérations
508 atomiques seront plus efficaces (permettant d'alléger la charge du
509 processeur et un plus haut niveau de simultanéité), mais
510 l'exécutable produit ne fonctionnera que sur les processeurs
514 <li>Linux sur x86<br />
515 Sous Linux, APR utilise par défaut les opérations atomiques basées
516 sur les mutex. Cependant, si vous ajoutez l'option
517 <code>--enable-nonportable-atomics</code> au script configure,
518 APR générera un code qui utilise un code d'opération du 486
519 pour des opérations de compare-and-swap matériel plus rapides. Le
520 code résultant est plus efficace en matière d'opérations atomiques,
521 mais l'exécutable produit ne fonctionnera que sur des processeurs
522 486 et supérieurs (et non sur des 386).
529 <h3>Module mod_status et ExtendedStatus On</h3>
533 <p>Si vous incluez le module <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> à la
534 construction d'Apache et ajoutez <code>ExtendedStatus On</code> à sa
535 configuration, Apache va effectuer pour chaque requête deux appels à
536 <code>gettimeofday(2)</code> (ou <code>times(2)</code> selon votre
537 système d'exploitation), et (pour les versions antérieures à 1.3) de
538 nombreux appels supplémentaires à <code>time(2)</code>. Tous ces
539 appels sont effectués afin que le rapport de statut puisse contenir
540 des indications temporelles. Pour améliorer les performances, utilisez
541 <code>ExtendedStatus off</code> (qui est le réglage par défaut).</p>
545 <h3>accept Serialization - points de connexion à un programme (sockets) multiples</h3>
549 <div class="warning"><h3>Mise en garde :</h3>
550 <p>Cette section n'a pas été totalement mise à jour car elle ne tient pas
551 compte des changements intervenus dans la version 2.x du Serveur HTTP
552 Apache. Certaines informations sont encore pertinentes, il vous est
553 cependant conseillé de les utiliser avec prudence.</p>
556 <p>Ce qui suit est une brève discussion à propos de l'API des sockets
557 Unix. Supposons que votre serveur web utilise plusieurs directives
558 <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> afin d'écouter
559 plusieurs ports ou de multiples adresses. Afin de tester chaque socket
560 pour voir s'il a une connexion en attente, Apache utilise
561 <code>select(2)</code>. <code>select(2)</code> indique si un socket a
562 <em>zéro</em> ou <em>au moins une</em> connexion en attente. Le modèle
563 d'Apache comporte plusieurs processus enfants, et tous ceux qui sont
564 inactifs testent la présence de nouvelles connexions au même moment.
565 Une implémentation rudimentaire de ceci pourrait ressembler à
567 (ces exemples ne sont pas extraits du code d'Apache, ils ne sont
568 proposés qu'à des fins pédagogiques) :</p>
570 <pre class="prettyprint lang-c"> for (;;) {
574 FD_ZERO (&accept_fds);
575 for (i = first_socket; i <= last_socket; ++i) {
576 FD_SET (i, &accept_fds);
578 rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
579 if (rc < 1) continue;
581 for (i = first_socket; i <= last_socket; ++i) {
582 if (FD_ISSET (i, &accept_fds)) {
583 new_connection = accept (i, NULL, NULL);
584 if (new_connection != -1) break;
587 if (new_connection != -1) break;
589 process_the(new_connection);
593 <p>Mais cette implémentation rudimentaire présente une sérieuse lacune.
594 Rappelez-vous que les processus enfants exécutent cette boucle au même
595 moment ; ils vont ainsi bloquer sur <code>select</code> s'ils se trouvent
596 entre deux requêtes. Tous ces processus bloqués vont se réactiver et
597 sortir de <code>select</code> quand une requête va apparaître sur un des
598 sockets (le nombre de processus enfants qui se réactivent varie en
599 fonction du système d'exploitation et des réglages de synchronisation).
600 Ils vont alors tous entrer dans la boucle et tenter un
601 <code>"accept"</code> de la connexion. Mais seulement un d'entre eux y
602 parviendra (en supposant qu'il ne reste q'une seule connexion en
603 attente), les autres vont se bloquer au niveau de <code>accept</code>.
604 Ceci verrouille vraiment ces processus de telle sorte qu'ils ne peuvent
605 plus servir de requêtes que par cet unique socket, et il en sera ainsi
606 jusqu'à ce que suffisamment de nouvelles requêtes apparaissent sur ce
607 socket pour les réactiver tous. Cette lacune a été documentée pour la
609 <a href="http://bugs.apache.org/index/full/467">PR#467</a>. Il existe
610 au moins deux solutions.</p>
612 <p>La première consiste à rendre les sockets non blocants. Dans ce cas,
613 <code>accept</code> ne bloquera pas les processus enfants, et ils
614 pourront continuer à s'exécuter immédiatement. Mais ceci consomme des
615 ressources processeur. Supposons que vous ayez dix processus enfants
616 inactifs dans <code>select</code>, et qu'une connexion arrive.
617 Neuf des dix processus vont se réactiver, tenter un <code>accept</code>
618 de la connexion, échouer, et boucler dans <code>select</code>, tout en
619 n'ayant finalement rien accompli. Pendant ce temps, aucun de ces processus
620 ne traite les requêtes qui arrivent sur d'autres sockets jusqu'à ce
621 qu'ils retournent dans <code>select</code>. Finalement, cette solution
622 ne semble pas très efficace, à moins que vous ne disposiez d'autant de
623 processeurs inactifs (dans un serveur multiprocesseur) que de processus
624 enfants inactifs, ce qui n'est pas une situation très courante.</p>
626 <p>Une autre solution, celle qu'utilise Apache, consiste à sérialiser les
627 entrées dans la boucle interne. La boucle ressemble à ceci (les
628 différences sont mises en surbrillance) :</p>
630 <pre class="prettyprint lang-c"> for (;;) {
631 <strong>accept_mutex_on ();</strong>
635 FD_ZERO (&accept_fds);
636 for (i = first_socket; i <= last_socket; ++i) {
637 FD_SET (i, &accept_fds);
639 rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
640 if (rc < 1) continue;
642 for (i = first_socket; i <= last_socket; ++i) {
643 if (FD_ISSET (i, &accept_fds)) {
644 new_connection = accept (i, NULL, NULL);
645 if (new_connection != -1) break;
648 if (new_connection != -1) break;
650 <strong>accept_mutex_off ();</strong>
651 process the new_connection;
655 <p><a id="serialize" name="serialize">Les fonctions</a>
656 <code>accept_mutex_on</code> et <code>accept_mutex_off</code>
657 implémentent un sémaphore permettant une exclusion mutuelle. Un seul
658 processus enfant à la fois peut posséder le mutex. Plusieurs choix se
659 présentent pour implémenter ces mutex. Ce choix est défini dans
660 <code>src/conf.h</code> (versions antérieures à 1.3) ou
661 <code>src/include/ap_config.h</code> (versions 1.3 ou supérieures).
662 Certaines architectures ne font pas ce choix du mode de verrouillage ;
663 l'utilisation de directives
664 <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> multiples sur ces
665 architectures est donc peu sûr.</p>
667 <p>La directive <code class="directive"><a href="../mod/core.html#mutex">Mutex</a></code> permet
668 de modifier l'implémentation du mutex <code>mpm-accept</code> à
669 l'exécution. Des considérations spécifiques aux différentes
670 implémentations de mutex sont documentées avec cette directive.</p>
672 <p>Une autre solution qui a été imaginée mais jamais implémentée, consiste
673 à sérialiser partiellement la boucle -- c'est à dire y faire entrer un
674 certain nombre de processus. Ceci ne présenterait un intérêt que sur les
675 machines multiprocesseurs où plusieurs processus enfants peuvent
676 s'exécuter simultanément, et encore, la sérialisation ne tire pas
677 vraiment parti de toute la bande passante. C'est une possibilité
678 d'investigation future, mais demeure de priorité basse car les serveurs
679 web à architecture hautement parallèle ne sont pas la norme.</p>
681 <p>Pour bien faire, vous devriez faire fonctionner votre serveur sans
682 directives <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> multiples
683 si vous visez les performances les plus élevées.
684 Mais lisez ce qui suit.</p>
688 <h3>accept Serialization - point de connexion à un programme (sockets) unique</h3>
692 <p>Ce qui précède convient pour les serveurs à sockets multiples, mais
693 qu'en est-il des serveurs à socket unique ? En théorie, ils ne
694 devraient pas rencontrer les mêmes problèmes car tous les processus
695 enfants peuvent se bloquer dans <code>accept(2)</code> jusqu'à ce qu'une
696 connexion arrive, et ils ne sont pas utilisés à ne rien faire. En
697 pratique, ceci dissimule un même comportement de bouclage
698 discuté plus haut dans la solution non-blocante. De la manière dont
699 sont implémentées les piles TCP, le noyau réactive véritablement tous les
700 processus bloqués dans <code>accept</code> quand une seule connexion
701 arrive. Un de ces processus prend la connexion en compte et retourne
702 dans l'espace utilisateur, les autres bouclant dans l'espace du
703 noyau et se désactivant quand ils s'aperçoivent qu'il n'y a pas de
704 connexion pour eux. Ce bouclage est invisible depuis le code de l'espace
705 utilisateur, mais il est quand-même présent. Ceci peut conduire à la
706 même augmentation de charge à perte que la solution non blocante au cas
707 des sockets multiples peut induire.</p>
709 <p>Pour cette raison, il apparaît que de nombreuses architectures se
710 comportent plus "proprement" si on sérialise même dans le cas d'une socket
711 unique. Il s'agit en fait du comportement par défaut dans la plupart des
712 cas. Des expériences poussées sous Linux (noyau 2.0.30 sur un
713 biprocesseur Pentium pro 166 avec 128 Mo de RAM) ont montré que la
714 sérialisation d'une socket unique provoque une diminution inférieure à 3%
715 du nombre de requêtes par secondes par rapport au traitement non
716 sérialisé. Mais le traitement non sérialisé des sockets uniques induit
717 un temps de réponse supplémentaire de 100 ms pour chaque requête. Ce
718 temps de réponse est probablement provoqué par une limitation sur les
719 lignes à haute charge, et ne constitue un problème que sur les réseaux
720 locaux. Si vous voulez vous passer de la sérialisation des sockets
721 uniques, vous pouvez définir
722 <code>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</code> et les
723 serveurs à socket unique ne pratiqueront plus du tout la
728 <h3>Fermeture en prenant son temps (Lingering close)</h3>
732 <p>Comme discuté dans <a href="http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt">
733 draft-ietf-http-connection-00.txt</a> section 8, pour implémenter de
734 manière <strong>fiable</strong> le protocole, un serveur HTTP doit fermer
735 les deux directions d'une communication indépendamment (rappelez-vous
736 qu'une connexion TCP est bidirectionnelle, chaque direction étant
737 indépendante de l'autre).</p>
739 <p>Quand cette fonctionnalité fut ajoutée à Apache, elle causa une
740 avalanche de problèmes sur plusieurs versions d'Unix à cause d'une
741 implémentation à courte vue. La spécification TCP ne précise pas que
742 l'état <code>FIN_WAIT_2</code> possède un temps de réponse mais elle ne
743 l'exclut pas. Sur les systèmes qui n'introduisent pas ce temps de
744 réponse, Apache 1.2 induit de nombreux blocages définitifs de socket
745 dans l'état <code>FIN_WAIT_2</code>. On peut eviter ceci dans de nombreux
746 cas tout simplement en mettant à jour TCP/IP avec le dernier patch mis à
747 disposition par le fournisseur. Dans les cas où le fournisseur n'a
748 jamais fourni de patch (par exemple, SunOS4 -- bien que les utilisateurs
749 possédant une license source puissent le patcher eux-mêmes), nous avons
750 décidé de désactiver cette fonctionnalité.</p>
752 <p>Il y a deux méthodes pour arriver à ce résultat. La première est
753 l'option de socket <code>SO_LINGER</code>. Mais le sort a voulu que cette
754 solution ne soit jamais implémentée correctement dans la plupart des
755 piles TCP/IP. Et même dans les rares cas où cette solution a été
756 implémentée correctement (par exemple Linux 2.0.31), elle se
757 montre beaucoup plus gourmande (en temps processeur) que la solution
760 <p>Pour la plus grande partie, Apache implémente cette solution à l'aide
761 d'une fonction appelée <code>lingering_close</code> (définie dans
762 <code>http_main.c</code>). La fonction ressemble approximativement à
765 <pre class="prettyprint lang-c"> void lingering_close (int s)
767 char junk_buffer[2048];
769 /* shutdown the sending side */
772 signal (SIGALRM, lingering_death);
776 select (s for reading, 2 second timeout);
778 if (s is ready for reading) {
779 if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
782 /* just toss away whatever is here */
790 <p>Ceci ajoute naturellement un peu de charge à la fin d'une connexion,
791 mais s'avère nécessaire pour une implémentation fiable. Comme HTTP/1.1
792 est de plus en plus présent et que toutes les connexions sont
793 persistentes, la charge sera amortie par la multiplicité des requêtes.
794 Si vous voulez jouer avec le feu en désactivant cette fonctionnalité,
795 vous pouvez définir <code>NO_LINGCLOSE</code>, mais c'est fortement
796 déconseillé. En particulier, comme les connexions persistantes en
797 pipeline de HTTP/1.1 commencent à être utilisées,
798 <code>lingering_close</code> devient une absolue nécessité (et les
799 <a href="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html">
800 connexions en pipeline sont plus rapides</a> ; vous avez donc tout
801 intérêt à les supporter).</p>
805 <h3>Fichier tableau de bord (Scoreboard file)</h3>
809 <p>Les processus parent et enfants d'Apache communiquent entre eux à
810 l'aide d'un objet appelé "Tableau de bord" (Scoreboard). Idéalement, cet
811 échange devrait s'effectuer en mémoire partagée. Pour les systèmes
812 d'exploitation auxquels nous avons eu accès, ou pour lesquels nous avons
813 obtenu des informations suffisamment détaillées pour effectuer un
814 portage, cet échange est en général implémenté en utilisant la mémoire
815 partagée. Pour les autres, on utilise par défaut un fichier d'échange sur
816 disque. Le fichier d'échange sur disque est non seulement lent, mais
817 aussi peu fiable (et propose moins de fonctionnalités). Recherchez dans
818 le fichier <code>src/main/conf.h</code> correspondant à votre
819 architecture soit <code>USE_MMAP_SCOREBOARD</code>, soit
820 <code>USE_SHMGET_SCOREBOARD</code>. La définition de l'un des deux
821 (ainsi que leurs compagnons respectifs <code>HAVE_MMAP</code> et
822 <code>HAVE_SHMGET</code>), active le code fourni pour la mémoire
823 partagée. Si votre système propose une autre solution pour la gestion de
824 la mémoire partagée, éditez le fichier <code>src/main/http_main.c</code>
825 et ajoutez la portion de code nécessaire pour pouvoir l'utiliser dans
826 Apache (Merci de nous envoyer aussi le patch correspondant).</p>
828 <div class="note">Note à caractère historique : le portage d'Apache sous Linux
829 n'utilisait pas la mémoire partagée avant la version 1.2. Ceci entraînait
830 un comportement très rudimentaire et peu fiable des versions antérieures
831 d'Apache sous Linux.</div>
835 <h3>DYNAMIC_MODULE_LIMIT</h3>
839 <p>Si vous n'avez pas l'intention d'utiliser les modules chargés
840 dynamiquement (ce qui est probablement le cas si vous êtes en train de
841 lire ce document afin de personnaliser votre serveur en recherchant le
842 moindre des gains en performances), vous pouvez ajouter la définition
843 <code>-DDYNAMIC_MODULE_LIMIT=0</code> à la construction de votre serveur.
844 Ceci aura pour effet de libérer la mémoire RAM allouée pour le
845 chargement dynamique des modules.</p>
849 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
850 <div class="section">
851 <h2><a name="trace" id="trace">Appendice : Analyse détaillée d'une trace</a><a title="Lien permanent" href="#trace" class="permalink">¶</a></h2>
855 <p>Voici la trace d'un appel système d'Apache 2.0.38 avec le MPM worker
856 sous Solaris 8. Cette trace a été collectée à l'aide de la commande :</p>
858 <div class="example"><p><code>
859 truss -l -p <var>httpd_child_pid</var>.
862 <p>L'option <code>-l</code> demande à truss de tracer l'ID du LWP
863 (lightweight process--la version de Solaris des threads niveau noyau) qui
864 invoque chaque appel système.</p>
866 <p>Les autres systèmes peuvent proposer des utilitaires de traçage
867 des appels système différents comme <code>strace</code>,
868 <code>ktrace</code>, ou <code>par</code>. Ils produisent cependant tous une
871 <p>Dans cette trace, un client a demandé un fichier statique de 10 ko au
872 démon httpd. Le traçage des requêtes pour des contenus non statiques
873 ou comportant une négociation de contenu a une présentation
874 différente (et même assez laide dans certains cas).</p>
876 <div class="example"><pre>/67: accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...)
877 /67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9</pre></div>
879 <p>Dans cette trace, le thread à l'écoute s'exécute à l'intérieur de
882 <div class="note">Notez l'absence de la sérialisation d'<code>accept(2)</code>. Sur
883 cette plateforme spécifique, le MPM worker utilise un accept non sérialisé
884 par défaut sauf s'il est en écoute sur des ports multiples.</div>
886 <div class="example"><pre>/65: lwp_park(0x00000000, 0) = 0
887 /67: lwp_unpark(65, 1) = 0</pre></div>
889 <p>Après avoir accepté la connexion, le thread à l'écoute réactive un
890 thread du worker pour effectuer le traitement de la requête. Dans cette
891 trace, le thread du worker qui traite la requête est associé à
894 <div class="example"><pre>/65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0</pre></div>
896 <p>Afin de pouvoir implémenter les hôtes virtuels, Apache doit connaître
897 l'adresse du socket local utilisé pour accepter la connexion. On pourrait
898 supprimer cet appel dans de nombreuses situations (par exemple dans le cas
899 où il n'y a pas d'hôte virtuel ou dans le cas où les directives
900 <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> contiennent des adresses
901 sans caractères de substitution). Mais aucun effort n'a été accompli à ce
902 jour pour effectuer ces optimisations.</p>
904 <div class="example"><pre>/65: brk(0x002170E8) = 0
905 /65: brk(0x002190E8) = 0</pre></div>
907 <p>L'appel <code>brk(2)</code> alloue de la mémoire dans le tas. Ceci est
908 rarement visible dans une trace d'appel système, car le démon httpd
909 utilise des allocateurs mémoire de son cru (<code>apr_pool</code> et
910 <code>apr_bucket_alloc</code>) pour la plupart des traitements de requêtes.
911 Dans cette trace, le démon httpd vient juste de démarrer, et il doit
912 appeler <code>malloc(3)</code> pour réserver les blocs de mémoire
913 nécessaires à la création de ses propres allocateurs de mémoire.</p>
915 <div class="example"><pre>/65: fcntl(9, F_GETFL, 0x00000000) = 2
916 /65: fstat64(9, 0xFAF7B818) = 0
917 /65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0
918 /65: fstat64(9, 0xFAF7B818) = 0
919 /65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0
920 /65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0
921 /65: fcntl(9, F_SETFL, 0x00000082) = 0</pre></div>
923 <p>Ensuite, le thread de worker passe la connexion du client (descripteur
924 de fichier 9) en mode non blocant. Les appels <code>setsockopt(2)</code>
925 et <code>getsockopt(2)</code> constituent un effet de bord de la manière
926 dont la libc de Solaris utilise <code>fcntl(2)</code> pour les sockets.</p>
928 <div class="example"><pre>/65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97</pre></div>
930 <p>Le thread de worker lit la requête du client.</p>
932 <div class="example"><pre>/65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0
933 /65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10</pre></div>
935 <p>Ce démon httpd a été configuré avec les options
936 <code>Options FollowSymLinks</code> et <code>AllowOverride None</code>. Il
937 n'a donc ni besoin d'appeler <code>lstat(2)</code> pour chaque répertoire
938 du chemin du fichier demandé, ni besoin de vérifier la présence de fichiers
939 <code>.htaccess</code>. Il appelle simplement <code>stat(2)</code> pour
940 vérifier d'une part que le fichier existe, et d'autre part que c'est un
941 fichier régulier, et non un répertoire.</p>
943 <div class="example"><pre>/65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269</pre></div>
945 <p>Dans cet exemple, le démon httpd peut envoyer l'en-tête de la réponse
946 HTTP et le fichier demandé à l'aide d'un seul appel système
947 <code>sendfilev(2)</code>. La sémantique de sendfile varie en fonction des
948 systèmes d'exploitation. Sur certains autres systèmes, il faut faire un
949 appel à <code>write(2)</code> ou <code>writev(2)</code> pour envoyer les
950 en-têtes avant d'appeler <code>sendfile(2)</code>.</p>
952 <div class="example"><pre>/65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78</pre></div>
954 <p>Cet appel à <code>write(2)</code> enregistre la requête dans le journal
955 des accès. Notez qu'une des choses manquant à cette trace est un appel à
956 <code>time(2)</code>. A la différence d'Apache 1.3, Apache 2.x utilise
957 <code>gettimeofday(3)</code> pour consulter l'heure. Sur certains systèmes
958 d'exploitation, comme Linux ou Solaris, <code>gettimeofday</code> est
959 implémenté de manière optimisée de telle sorte qu'il consomme moins de
960 ressources qu'un appel système habituel.</p>
962 <div class="example"><pre>/65: shutdown(9, 1, 1) = 0
963 /65: poll(0xFAF7B980, 1, 2000) = 1
964 /65: read(9, 0xFAF7BC20, 512) = 0
965 /65: close(9) = 0</pre></div>
967 <p>Le thread de worker effectue une fermeture "en prenant son temps"
968 (lingering close) de la connexion.</p>
970 <div class="example"><pre>/65: close(10) = 0
971 /65: lwp_park(0x00000000, 0) (sleeping...)</pre></div>
973 <p>Enfin, le thread de worker ferme le fichier qu'il vient de délivrer et
974 se bloque jusqu'à ce que le thread en écoute lui assigne une autre
977 <div class="example"><pre>/67: accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)</pre></div>
979 <p>Pendant ce temps, le thread à l'écoute peut accepter une autre connexion
980 à partir du moment où il a assigné la connexion présente à un thread de
981 worker (selon une certaine logique de contrôle de flux dans le MPM worker
982 qui impose des limites au thread à l'écoute si tous les threads de worker
983 sont occupés). Bien que cela n'apparaisse pas dans cette trace,
984 l'<code>accept(2)</code> suivant peut (et le fait en général, en situation
985 de charge élevée) s'exécuter en parallèle avec le traitement de la
986 connexion qui vient d'être acceptée par le thread de worker.</p>
989 <div class="bottomlang">
990 <p><span>Langues Disponibles: </span><a href="../en/misc/perf-tuning.html" hreflang="en" rel="alternate" title="English"> en </a> |
991 <a href="../fr/misc/perf-tuning.html" title="Français"> fr </a> |
992 <a href="../ko/misc/perf-tuning.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
993 <a href="../tr/misc/perf-tuning.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
994 </div><div class="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Commentaires</a></h2><div class="warning"><strong>Notice:</strong><br />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 <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
995 <script type="text/javascript"><!--//--><![CDATA[//><!--
996 var comments_shortname = 'httpd';
997 var comments_identifier = 'http://httpd.apache.org/docs/trunk/misc/perf-tuning.html';
999 if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
1000 d.write('<div id="comments_thread"><\/div>');
1001 var s = d.createElement('script');
1002 s.type = 'text/javascript';
1004 s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
1005 (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
1008 d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
1010 })(window, document);
1011 //--><!]]></script></div><div id="footer">
1012 <p class="apache">Copyright 2018 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
1013 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div><script type="text/javascript"><!--//--><
projects / apache / blob