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>Amélioration des performances - 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>Amélioration des performances</h1>
26 <p><span>Langues Disponibles: </span><a href="../en/misc/perf-scaling.html" hreflang="en" rel="alternate" title="English"> en </a> |
27 <a href="../es/misc/perf-scaling.html" hreflang="es" rel="alternate" title="Español"> es </a> |
28 <a href="../fr/misc/perf-scaling.html" title="Français"> fr </a></p>
32 <p>Il est dit dans la documentation d'Apache 1.3
33 à propos de l'amélioration des performances :
36 "Apache est un serveur web à vocation générale, conçu pour
37 être non seulement efficace mais aussi rapide. Dans sa
38 configuration de base, ses performances sont déjà
39 relativement satisfaisantes. La plupart des sites possèdent
40 une bande passante en sortie inférieure à 10 Mbits que le
41 serveur Apache peut mettre pleinement à profit en utilisant un serveur à base
42 de processeur Pentium bas de gamme."</p>
44 <p>Cette phrase ayant été écrite il y a plusieurs années,
45 entre temps de nombreuses choses ont changé. D'une part, les
46 serveurs sont devenus beaucoup plus rapides. D'autre part, de
47 nombreux sites se voient maintenant allouée une bande passante
48 en sortie bien supérieure à 10 Mbits. En outre, les applications
49 web sont devenues beaucoup plus complexes. Les sites classiques
50 ne proposant que des pages du style brochure sont toujours
51 présents, mais le web a souvent évolué vers une plateforme
52 exécutant des traitements, et les webmasters peuvent maintenant
53 mettre en ligne des contenus dynamiques en Perl, PHP ou Java,
54 qui exigent un niveau de performances bien supérieur.
56 <p>C'est pourquoi en dépit des progrès en matière de bandes passantes
57 allouées et de rapidité des serveurs, les performances
58 des serveurs web et des applications web sont toujours un sujet
59 d'actualité. C'est dans ce cadre que cette documentation s'attache à
60 présenter de nombreux points concernant les performances des
65 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#what-will-and-will-not-be-discussed">Ce qui sera abordé et ce qui ne le sera pas</a></li>
66 <li><img alt="" src="../images/down.gif" /> <a href="#monitoring-your-server">Monitoring de votre serveur</a></li>
67 <li><img alt="" src="../images/down.gif" /> <a href="#configuring-for-performance">Configuration dans une optique de performances
69 <li><img alt="" src="../images/down.gif" /> <a href="#caching-content">Mise en cache des contenus
71 <li><img alt="" src="../images/down.gif" /> <a href="#further-considerations">Pour aller plus loin
73 </ul><h3>Voir aussi</h3><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
74 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
76 <h2><a name="what-will-and-will-not-be-discussed" id="what-will-and-will-not-be-discussed">Ce qui sera abordé et ce qui ne le sera pas</a> <a title="Lien permanent" href="#what-will-and-will-not-be-discussed" class="permalink">¶</a></h2>
78 <p>Ce document se concentre sur l'amélioration des performances
79 via des options facilement accessibles, ainsi que sur les outils
80 de monitoring. Les outils de monitoring vous permettront de
81 surveiller le fonctionnement de votre serveur web afin de
82 rassembler des informations à propos de ses performances et des
83 éventuels problèmes qui s'y rapportent. Nous supposerons
84 que votre budget n'est pas illimité ; c'est pourquoi les
85 améliorations apportées le seront sans modifier l'infrastructure
86 matérielle existante. Vous ne souhaitez probablement pas
87 compiler vous-même votre serveur Apache, ni recompiler le noyau
88 de votre système d'exploitation ; nous supposerons cependant que
89 vous possédez quelques notions à propos du fichier de
90 configuration du serveur HTTP Apache.
93 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
95 <h2><a name="monitoring-your-server" id="monitoring-your-server">Monitoring de votre serveur</a> <a title="Lien permanent" href="#monitoring-your-server" class="permalink">¶</a></h2>
97 <p>Si vous envisagez de redimensionner ou d'améliorer les performances
98 de votre serveur, vous devez tout d'abord observer la manière dont il
99 fonctionne. En observant son fonctionnement en conditions réelles ou
100 sous une charge créée artificiellement, vous serez en mesure
101 d'extrapoler son fonctionnement sous une charge accrue, par exemple dans
102 le cas où il serait mentionné sur Slashdot. </p>
105 <h3><a name="monitoring-tools" id="monitoring-tools">Outils de monitoring</a></h3>
108 <h4><a name="top" id="top">top
111 <p>L'outil top est fourni avec Linux et FreeBSD. Solaris
112 quant à lui, fournit <code>prstat(1)</code>. Cet outil
113 permet de rassembler de nombreuses données statistiques
114 à propos du système et de chaque processus en cours
115 d'exécution avant de les afficher de manière
116 interactive sur votre terminal. Les données affichées
117 sont rafraîchies toutes les secondes et varient en
118 fonction de la plateforme, mais elles comportent en
119 général la charge moyenne du système, le nombre de
120 processus et leur état courant, le pourcentage de temps
121 CPU(s) passé à exécuter le code système et utilisateur,
122 et l'état de la mémoire virtuelle système. Les données
123 affichées pour chaque processus sont en général
124 configurables et comprennent le nom et l'identifiant du
125 processus, sa priorité et la valeur définie par nice,
126 l'empreinte mémoire, et le pourcentage d'utilisation CPU.
127 L'exemple suivant montre plusieurs processus httpd (avec
128 les MPM worker et event) s'exécutant sur un système
132 <div class="example"><pre>top - 23:10:58 up 71 days, 6:14, 4 users, load average: 0.25, 0.53, 0.47
133 Tasks: 163 total, 1 running, 162 sleeping, 0 stopped, 0 zombie
134 Cpu(s): 11.6%us, 0.7%sy, 0.0%ni, 87.3%id, 0.4%wa, 0.0%hi, 0.0%si, 0.0%st
135 Mem: 2621656k total, 2178684k used, 442972k free, 100500k buffers
136 Swap: 4194296k total, 860584k used, 3333712k free, 1157552k cached
138 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
139 16687 example_ 20 0 1200m 547m 179m S 45 21.4 1:09.59 httpd-worker
140 15195 www 20 0 441m 33m 2468 S 0 1.3 0:41.41 httpd-worker
141 1 root 20 0 10312 328 308 S 0 0.0 0:33.17 init
142 2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
143 3 root RT -5 0 0 0 S 0 0.0 0:00.14 migration/0
144 4 root 15 -5 0 0 0 S 0 0.0 0:04.58 ksoftirqd/0
145 5 root RT -5 0 0 0 S 0 0.0 4:45.89 watchdog/0
146 6 root 15 -5 0 0 0 S 0 0.0 1:42.52 events/0
147 7 root 15 -5 0 0 0 S 0 0.0 0:00.00 khelper
148 19 root 15 -5 0 0 0 S 0 0.0 0:00.00 xenwatch
149 20 root 15 -5 0 0 0 S 0 0.0 0:00.00 xenbus
150 28 root RT -5 0 0 0 S 0 0.0 0:00.14 migration/1
151 29 root 15 -5 0 0 0 S 0 0.0 0:00.20 ksoftirqd/1
152 30 root RT -5 0 0 0 S 0 0.0 0:05.96 watchdog/1
153 31 root 15 -5 0 0 0 S 0 0.0 1:18.35 events/1
154 32 root RT -5 0 0 0 S 0 0.0 0:00.08 migration/2
155 33 root 15 -5 0 0 0 S 0 0.0 0:00.18 ksoftirqd/2
156 34 root RT -5 0 0 0 S 0 0.0 0:06.00 watchdog/2
157 35 root 15 -5 0 0 0 S 0 0.0 1:08.39 events/2
158 36 root RT -5 0 0 0 S 0 0.0 0:00.10 migration/3
159 37 root 15 -5 0 0 0 S 0 0.0 0:00.16 ksoftirqd/3
160 38 root RT -5 0 0 0 S 0 0.0 0:06.08 watchdog/3
161 39 root 15 -5 0 0 0 S 0 0.0 1:22.81 events/3
162 68 root 15 -5 0 0 0 S 0 0.0 0:06.28 kblockd/0
163 69 root 15 -5 0 0 0 S 0 0.0 0:00.04 kblockd/1
164 70 root 15 -5 0 0 0 S 0 0.0 0:00.04 kblockd/2</pre></div>
166 <p>Top est un merveilleux outil, même s'il est
167 relativement gourmand en ressources (lorsqu'il
168 s'exécute, son propre processus se trouve en général
169 dans le top dix des consommations CPU). Il est
170 indispensable pour déterminer la taille d'un processus
171 en cours d'exécution, information précieuse lorsque vous
172 voudrez déterminer combien de processus httpd vous
173 pourrez exécuter sur votre machine. La méthode pour
174 effectuer ce calcul est décrite ici : <a href="#sizing-maxClients">calculer MaxClients</a>. Top
175 est cependant un outil interactif, et l'exécuter de
176 manière continu présente peu ou pas d'avantage.
179 <h4><a name="free" id="free">free
182 <p>Cette commande n'est disponible que sous Linux. Elle
183 indique la mémoire vive et l'espace de swap utilisés.
184 Linux alloue la mémoire inutilisée en tant que cache du
185 système de fichiers. La commande free montre
186 l'utilisation de la mémoire avec et sans ce cache. On
187 peut utiliser la commande free pour déterminer la
188 quantité de mémoire utilisée par le système, comme
189 décrit dans le paragraphe <a href="#sizing-maxClients">calculer MaxClients</a>.
190 L'affichage de la sortie de la commande free ressemble à
194 <div class="example"><pre>sctemme@brutus:~$ free
195 total used free shared buffers cached
196 Mem: 4026028 3901892 124136 0 253144 841044
197 -/+ buffers/cache: 2807704 1218324
198 Swap: 3903784 12540 3891244</pre></div>
201 <h4><a name="vmstat" id="vmstat">vmstat
204 <p>Cette commande est disponible sur de nombreuses
205 plateformes de style Unix. Elle affiche un grand nombre
206 de données système. Lancée sans argument, elle affiche
207 une ligne d'état pour l'instant actuel. Lorsqu'on lui
208 ajoute un chiffre, la ligne d'état actuelle est ajoutée à
209 intervalles réguliers à l'affichage existant.
210 Par exemple, la commande
211 <code>vmstat 5</code> ajoute la ligne d'état actuelle
212 toutes les 5 secondes. La commande vmstat affiche la
213 quantité de mémoire virtuelle utilisée, la quantité de
214 mémoire échangée avec l'espace de swap en entrée et en
215 sortie à chaque seconde, le nombre de processus
216 actuellement en cours d'exécution ou inactifs, le nombre
217 d'interruptions et de changements de contexte par
218 seconde, et le pourcentage d'utilisation du CPU.
221 Voici la sortie de la commande <code>vmstat</code>
222 pour un serveur inactif :
226 <div class="example"><pre>[sctemme@GayDeceiver sctemme]$ vmstat 5 3
227 procs memory swap io system cpu
228 r b w swpd free buff cache si so bi bo in cs us sy id
229 0 0 0 0 186252 6688 37516 0 0 12 5 47 311 0 1 99
230 0 0 0 0 186244 6696 37516 0 0 0 16 41 314 0 0 100
231 0 0 0 0 186236 6704 37516 0 0 0 9 44 314 0 0 100</pre></div>
233 <p>Et voici cette même sortie pour un serveur en charge
234 de cent connexions simultanées pour du contenu statique :
237 <div class="example"><pre>[sctemme@GayDeceiver sctemme]$ vmstat 5 3
238 procs memory swap io system cpu
239 r b w swpd free buff cache si so bi bo in cs us sy id
240 1 0 1 0 162580 6848 40056 0 0 11 5 150 324 1 1 98
241 6 0 1 0 163280 6856 40248 0 0 0 66 6384 1117 42 25 32
242 11 0 0 0 162780 6864 40436 0 0 0 61 6309 1165 33 28 40</pre></div>
244 <p>La première ligne indique des valeurs moyennes depuis
245 le dernier redémarrage. Les lignes suivantes donnent des
246 informations d'état à intervalles de 5 secondes. Le
247 second argument demande à vmstat de générer 3 lignes
248 d'état, puis de s'arrêter.
252 <h4><a name="se-toolkit" id="se-toolkit">Boîte à outils SE
255 <p>La boîte à outils SE est une solution de supervision
256 pour Solaris. Son langage de programmation est basé sur
257 le préprocesseur C et est fourni avec de nombreux
258 exemples de scripts. Les informations fournies
259 peuvent être exploitées en mode console ou en mode
260 graphique. Cette boîte à outils peut aussi être programmée pour
261 appliquer des règles aux données système. Avec l'exemple
262 de script de la Figure 2, Zoom.se, des voyants verts,
263 oranges ou rouges s'allument lorsque certaines valeurs
264 du système dépassent un seuil spécifié. Un autre script
265 fourni, Virtual Adrian, permet d'affiner les
266 performances en tenant compte de ces valeurs.
268 <p>Depuis sa création, de nombreux propriétaires se sont
269 succédés à la tête de la boîte à outils SE, et elle a de
270 ce fait largement évolué. Il semble qu'elle ait
271 maintenant trouvé sa place chez Sunfreeware.com d'où
272 elle peut être téléchargée gratuitement. Il n'y a qu'un
273 seul paquet pour Solaris 8, 9 et 10 sur SPARC et x86, et
274 il inclut le code source. Le concepteur de la boîte à
275 outils SE, Richard Pettit, a fondé une nouvelle sociéte,
276 Captive Metrics4, et a l'intention de mettre sur le
277 marché un outil de supervision multiplateforme en Java basé sur
278 les mêmes principes que la boîte à outils SE.
283 <h4><a name="dtrace" id="dtrace">DTrace
286 <p>Etant donné que DTrace est disponible sous Solaris,
287 FreeBSD et OS X, il serait intéressant de l'étudier. Il
288 y a aussi le module mod_dtrace pour httpd.
293 <h4><a name="mod_status" id="mod_status">mod_status
296 <p>Le module mod_status donne un aperçu des performances
297 du serveur à un instant donné. Il génère une page HTML
298 comportant, entre autres, le nombre de processus Apache
299 en cours d'exécution avec la quantité de données qu'ils
300 ont servies, ainsi que la charge CPU induite par httpd
301 et le reste du système. L'Apache Software Foundation
302 utilise elle-même <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> pour son
303 propre <a href="http://apache.org/server-status">site
304 web</a>. Si vous ajoutez une directive
305 <code>ExtendedStatus On</code> à votre fichier
306 <code>httpd.conf</code>, la page de
307 <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> vous fournira d'avantage
308 d'informations, au prix d'une consommation de ressources
309 légèrement supérieure par requête.
315 <h3><a name="web-server-log-files" id="web-server-log-files">Les journaux du serveur web
318 <p>Le moyen le plus efficace pour vérifier la bonne santé et
319 le niveau de performance de votre serveur consiste à
320 surveiller et analyser les journaux écrits par httpd. La
321 surveillance du journal des erreurs vous permet de
322 déterminer les sources d'erreurs, de détecter des attaques
323 ou des problèmes de performance. L'analyse du journal des
324 accès vous indique le niveau de charge de votre serveur,
325 quelles sont les ressources les plus populaires, ainsi que
326 la provenance de vos utilisateurs. Une analyse historique des
327 données de journalisation peut vous fournir des informations
328 précieuses quant aux tendances d'utilisation de votre
329 serveur au cours du temps, ce qui vous permet de prévoir les
330 périodes où les besoins en performance risquent de dépasser
331 les capacités du serveur.
335 <h4><a name="ErrorLog" id="ErrorLog">Journal des erreurs
338 <p>Le journal des erreurs peut indiquer que le nombre
339 maximum de processus actifs ou de fichiers ouverts
340 simultanément a été atteint. Le journal des erreurs
341 signele aussi le lancement de processus supplémentaires selon un
342 taux supérieur à la normale en réponse à
343 une augmentation soudaine de la charge. Lorsque le
344 serveur démarre, le descripteur de fichier stderr est
345 redirigé vers le journal des erreurs, si bien que toute
346 erreur rencontrée par httpd après avoir ouvert ses
347 fichiers journaux apparaîtra dans ce journal. Consulter
348 fréquemment le journal des erreurs est donc une bonne
351 <p>Lorsque Apache httpd n'a pas encore ouvert ses
352 fichiers journaux, tout message d'erreur sera envoyé
353 vers la sortie d'erreur standard stderr. Si vous
354 démarrez httpd manuellement, ces messages d'erreur
355 apparaîtront sur votre terminal, et vous pourrez les
356 utiliser directement pour résoudre les problèmes de
357 votre serveur. Si httpd est lancé via un script de
358 démarrage, la destination de ces messages d'erreur
359 dépend de leur conception.
360 <code>/var/log/messages</code> est alors le premier fichier à
361 consulter. Sous Windows, ces messages d'erreur précoces
362 sont écrits dans le journal des évènements des
363 applications, qui peut être visualisé via l'observateur
364 d'évènements dans les outils d'administration.
367 Le journal des erreurs est configuré via les
368 directives de configuration <code class="directive"><a href="../mod/core.html#errorlog">ErrorLog</a></code> et <code class="directive"><a href="../mod/core.html#loglevel">LogLevel</a></code>. Le journal des
369 erreurs de la configuration du serveur principal de
370 httpd reçoit les messages d'erreur concernant
371 l'ensemble du serveur : démarrage, arrêt, crashes,
372 lancement de processus supplémentaires excessif,
373 etc... La directive <code class="directive"><a href="../mod/core.html#errorlog">ErrorLog</a></code> peut aussi être
374 utilisée dans les blocs de configuration des
375 serveurs virtuels. Le journal des erreurs d'un
376 serveur virtuel ne reçoit que les messages d'erreur
377 spécifiques à ce serveur virtuel, comme les erreurs
378 d'authentification et les erreurs du style 'File not
381 <p>Dans le cas d'un serveur accessible depuis Internet,
382 attendez-vous à voir de nombreuses tentatives
383 d'exploitation et attaques de vers dans le journal des
384 erreurs. La plupart d'entre elles ciblent des serveurs
385 autres qu'Apache, mais dans l'état actuel des choses,
386 les scripts se contentent d'envoyer leurs attaques vers
387 tout port ouvert, sans tenir compte du serveur web
388 effectivement en cours d'exécution ou du type
389 des applications installées. Vous pouvez bloquer ces
390 tentatives d'attaque en utilisant un pare-feu ou le
391 module <a href="http://www.modsecurity.org/">mod_security</a>,
392 mais ceci dépasse la portée de cette discussion.
395 La directive <code class="directive"><a href="../mod/core.html#loglevel">LogLevel</a></code> permet de définir
396 le niveau de détail des messages enregistrés dans
397 les journaux. Il existe huit niveaux de
403 <p><strong>Niveau</strong></p>
406 <p><strong>Description</strong></p>
414 <p>Urgence - le système est inutilisable.</p>
422 <p>Une action doit être entreprise
431 <p>Situations critiques.</p>
439 <p>Situations d'erreur.</p>
447 <p>Situations provoquant un avertissement.</p>
455 <p>Evènement normal, mais important.</p>
471 <p>Messages de débogage.</p>
475 <p>Le niveau de journalisation par défaut est warn. Un
476 serveur en production ne doit pas s'exécuter en mode
477 debug, mais augmenter le niveau de détail dans le
478 journal des erreurs peut s'avérer utile pour résoudre
479 certains problèmes. A partir de la
480 version 2.3.8, la directive <code class="directive"><a href="../mod/core.html#loglevel">LogLevel</a></code> peut être définie au
481 niveau de chaque module :
484 <pre class="prettyprint lang-config">LogLevel debug mod_ssl:warn</pre>
488 Dans cet exemple, l'ensemble du serveur est en mode
489 debug, sauf le module <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>
490 qui a tendance à être très bavard.
495 <h4><a name="AccessLog" id="AccessLog">Journal des accès
498 <p>Apache httpd garde la trace de toutes les requêtes
499 qu'il reçoit dans son journal des accès. En plus de
500 l'heure et de la nature d'une requête, httpd peut
501 enregistrer l'adresse IP du client, la date et l'heure
502 de la requête, le résultat et quantité d'autres
503 informations. Les différents formats de journaux sont
504 documentés dans le manuel. Le fichier concerne par
505 défaut le serveur principal, mais il peut être configuré
506 pour chaque serveur virtuel via les directives de
507 configuration <code class="directive"><a href="../mod/mod_log_config.html#transferlog">TransferLog</a></code> ou
508 <code class="directive"><a href="../mod/mod_log_config.html#customlog">CustomLog</a></code>.
510 <p>De nombreux programmes libres ou commerciaux
511 permettent d'analyser les journaux d'accès. Analog et
512 Webalyser sont des programmes d'analyse libres parmi les
513 plus populaires. L'analyse des journaux doit s'effectuer
514 hors ligne afin de ne pas surcharger le serveur web avec
515 le traitement des fichiers journaux. La plupart des
516 programmes d'analyse des journaux sont compatibles avec le format
517 de journal "Common". Voici une description des
518 différents champs présents dans une entrée du journal :
522 <div class="example"><pre>195.54.228.42 - - [24/Mar/2007:23:05:11 -0400] "GET /sander/feed/ HTTP/1.1" 200 9747
523 64.34.165.214 - - [24/Mar/2007:23:10:11 -0400] "GET /sander/feed/atom HTTP/1.1" 200 9068
524 60.28.164.72 - - [24/Mar/2007:23:11:41 -0400] "GET / HTTP/1.0" 200 618
525 85.140.155.56 - - [24/Mar/2007:23:14:12 -0400] "GET /sander/2006/09/27/44/ HTTP/1.1" 200 14172
526 85.140.155.56 - - [24/Mar/2007:23:14:15 -0400] "GET /sander/2006/09/21/gore-tax-pollution/ HTTP/1.1" 200 15147
527 74.6.72.187 - - [24/Mar/2007:23:18:11 -0400] "GET /sander/2006/09/27/44/ HTTP/1.0" 200 14172
528 74.6.72.229 - - [24/Mar/2007:23:24:22 -0400] "GET /sander/2006/11/21/os-java/ HTTP/1.0" 200 13457</pre></div>
533 <p><strong>Champ</strong></p>
536 <p><strong>Contenu</strong></p>
539 <p><strong>Explication</strong></p>
544 <p>Adresse IP client</p>
550 <p>Adresse IP d'où provient la requête</p>
555 <p>Identité RFC 1413</p>
561 <p>Identité de l'utilisateur distant renvoyée
562 par son démon identd</p>
567 <p>Nom utilisateur</p>
573 <p>Nom de l'utilisateur distant issu de
574 l'authentification Apache</p>
582 <p>[24/Mar/2007:23:05:11 -0400]</p>
585 <p>Date et heure de la requête</p>
593 <p>"GET /sander/feed/ HTTP/1.1"</p>
596 <p>La requête proprement dite</p>
607 <p>Code d'état renvoyé avec la réponse</p>
612 <p>Contenu en octets</p>
618 <p>Total des octets transférés sans les
625 <h4><a name="rotating-log-files" id="rotating-log-files">Rotation des fichiers journaux
628 <p>Il y a de nombreuses raisons pour mettre en oeuvre la
629 rotation des fichiers journaux. Même si pratiquement
630 plus aucun système d'exploitation n'impose une limite de
631 taille pour les fichiers de deux GigaOctets, avec le
632 temps, les fichiers journaux deviennent trop gros pour
633 pouvoir être traités. En outre, toute analyse de journal
634 ne doit pas être effectuée sur un fichier dans lequel le
635 serveur est en train d'écrire. Une rotation périodique
636 des fichiers journaux permet de faciliter leur analyse,
637 et de se faire une idée plus précise des habitudes
640 <p>Sur les systèmes unix, vous pouvez simplement
641 effectuer cette rotation en changeant le nom du fichier
642 journal via la commande mv. Le serveur continuera à
643 écrire dans le fichier ouvert même s'il a changé de nom.
644 Lorsque vous enverrez un signal de redémarrage
645 "Graceful" au serveur, il ouvrira un nouveau fichier
646 journal avec le nom configuré par défaut. Par exemple,
647 vous pouvez écrire un script de ce style pour cron :
651 <div class="example"><p><code>
652 APACHE=/usr/local/apache2<br />
653 HTTPD=$APACHE/bin/httpd<br />
654 mv $APACHE/logs/access_log
655 $APACHE/logarchive/access_log-`date +%F`<br />
659 <p>Cette approche fonctionne aussi sous Windows, mais
660 avec moins de souplesse. Alors que le processus httpd de
661 votre serveur sous Windows continuera à écrire dans le
662 fichier journal une fois ce dernier renommé, le service
663 Windows qui exécute Apache n'est pas en mesure
664 d'effectuer un redémarrage graceful. Sous Windows, le
665 redémarrage d'un service consiste simplement à l'arrêter
666 et à le démarrer à nouveau, alors qu'avec un redémarrage
667 graceful, les processus enfants terminent
668 le traitement des requêtes en cours avant de s'arrêter,
669 et le serveur httpd est alors immédiatement à
670 nouveau disponible pour traiter les nouvelles requêtes.
671 Sous Windows, le processus d'arrêt/redémarrage du
672 service interrompt les traitements de requêtes en cours,
673 et le serveur demeure indisponible jusqu'à ce qu'il ait
674 terminé son redémarrage. Vous devez donc tenir compte de
675 toutes ces contraintes lorsque vous planifiez un
679 Une seconde approche consiste à utiliser la
680 redirection des logs. Les directives <code class="directive"><a href="../mod/mod_log_config.html#customlog">CustomLog</a></code>,
681 <code class="directive"><a href="../mod/mod_log_config.html#transferlog">TransferLog</a></code> ou
682 <code class="directive"><a href="../mod/core.html#errorlog">ErrorLog</a></code>
683 permettent de rediriger les données de journalisation
684 vers tout programme via le caractère pipe
685 (<code>|</code>) comme dans cet exemple :
688 <div class="example"><p><code>CustomLog "|/usr/local/apache2/bin/rotatelogs
689 /var/log/access_log 86400" common
692 <p>Le programme cible de la redirection recevra alors les
693 données de journalisation d'Apache sur son entrée
694 standard stdin, et pourra en faire ce qu'il voudra. Le
695 programme rotatelogs fourni avec Apache effectue une
696 rotation des journaux de manière transparente en
697 fonction du temps ou de la quantité de données écrites,
698 et archive l'ancien fichier journal en ajoutant un
699 suffixe d'horodatage à son nom. Cependant, si cette
700 méthode fonctionne de manière satisfaisante sur les
701 plateformes de style unix, il n'en est pas de même sous
707 <h4><a name="logging-and-performance" id="logging-and-performance">Journalisation et performances
710 <p>L'écriture d'entrées dans les fichiers journaux est
711 consommatrice de ressources, mais l'importance de ces
712 données est telle qu'il est fortement déconseillé de
713 désactiver la journalisation. Pour optimiser les
714 performances, vous devez enregistrer vos journaux sur un
715 disque physique différent de celui où se situe votre
716 site web car les modes d'accès sont très différents. La
717 lecture de données sur un disque possède un caractère
718 essentiellement aléatoire, alors que l'écriture dans les
719 fichiers journaux s'effectue de manière séquentielle.
722 Ne définissez jamais la directive <code class="directive"><a href="../mod/core.html#loglevel">LogLevel</a></code> à debug pour un
723 serveur en production. En effet, lorsque ce niveau de
724 journalisation est défini, une grande quantité de
725 données est écrite dans le journal des erreurs, y
726 compris, dans le cas d'un accès SSL, toutes les
727 opérations de lecture/écriture de la négociation de la
728 connexion. Les implications en matière de performances
729 sont donc importantes et vous devez plutôt utiliser le
730 niveau de journalisation warn.
732 <p>Si votre serveur possède plus d'un serveur virtuel,
733 il est conseillé d'attribuer un journal des accès séparé à
734 chacun d'entre eux, ce qui a pour effet de faciliter son
735 exploitation ultérieure. Par contre, si votre serveur
736 possède un grand nombre de serveurs virtuels, le nombre
737 de fichiers journaux à ouvrir va représenter une
738 consommation de ressources importante pour votre
739 système, et il sera peut-être alors plus judicieux
740 d'utiliser un seul fichier journal avec l'aménagement
741 suivant : utiliser l'élément de format <code>%v</code>
742 en tête de votre directive <code class="directive"><a href="../mod/mod_log_config.html#logformat">LogFormat</a></code> (et de
743 votre directive <code class="directive"><a href="../mod/core.html#errorlog">ErrorLog</a></code> depuis la version
744 2.3.8) afin que httpd enregistre le nom du serveur
745 virtuel qui traite la requête ou l'erreur au début de
746 chaque entrée du journal. Un simple script Perl peut
747 alors éclater le journal en fichiers spécifiques à
748 chaque serveur virtuel après sa rotation ; Apache
749 fournit un tel script dans le répertoire
750 <code>support/split-logfile</code>.
753 Vous pouvez aussi utiliser la directive <code class="directive"><a href="../mod/mod_log_config.html#bufferedlogs">BufferedLogs</a></code>
754 pour qu'Apache conserve en mémoire plusieurs entrées
755 de journal avant de les écrire sur disque. Gardez
756 cependant à l'esprit que si les performances peuvent
757 s'en trouver améliorées, la chronologie des
758 évènements enregistrés peut quant à elle s'en
765 <h3><a name="generating-a-test-load" id="generating-a-test-load">Mise en oeuvre d'une charge de test
768 <p>Il est interessant de mettre en oeuvre une charge de test
769 afin d'évaluer les performances du système en conditions
770 réelles de fonctionnement. A cet effet, il existe des
771 paquets commerciaux comme <a href="http://learnloadrunner.com/">LoadRunner</a>, mais
772 aussi de nombreux outils libres permettant de générer une
773 charge de test pour votre serveur web.
776 <li>Apache est fourni avec un programme de test nommé ab
777 (initiales de Apache Bench). Ce dernier peut générer une
778 charge de serveur web consistant à demander le même
779 fichier de manière répétitive à un rythme rapide. Vous
780 pouvez spécifier le nombre de connexions simultanées, et
781 choisir entre une durée de fonctionnement ou un nombre
784 <li>http load11 est un autre exemple de générateur de
785 charge libre. Ce programme fonctionne avec un ficher
786 d'URLs et peut être compilé avec le support SSL.
788 <li>L'Apache Software Foundation propose un outil nommé
789 flood12. Flood est un programme assez sophistiqué que
790 l'on configure via un fichier XML.
792 <li>Pour finir, JMeter13, un sous-projet de Jakarta, est
793 un outil de test en charge entièrement en Java. Alors
794 que les premières versions de cette application étaient
795 lentes et difficiles d'utilisation, la version 2.1.1
796 actuelle semble être plus souple d'utilisation et
800 <p>Des projets externes à l'ASF et réputés
801 relativement corrects : grinder, httperf, tsung, <a href="http://funkload.nuxeo.org/">FunkLoad</a>.
805 <p>Lorsque vous appliquez une charge de test à votre serveur
806 web, gardez à l'esprit que si ce dernier est en production,
807 la charge de test peut en affecter négativement les
808 performances. En outre, le transfert de données
809 supplémentaires induit peut être comptabilisé dans le
810 quota mensuel qui vous a été éventuellement alloué.
815 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
816 <div class="section">
817 <h2><a name="configuring-for-performance" id="configuring-for-performance">Configuration dans une optique de performances
818 </a> <a title="Lien permanent" href="#configuring-for-performance" class="permalink">¶</a></h2>
822 <h3><a name="apache-configuration" id="apache-configuration">Configuration de httpd
825 <p>httpd version 2.2 est par défaut un serveur web avec des
826 processus enfants lancés au préalable. Au démarrage du
827 serveur, le processus parent lance un certain nombre de
828 processus enfants et ce sont eux qui seront chargés de traiter les
829 requêtes. Mais avec httpd version 2.0 est apparu le concept
830 de module multi-process (MPM). Les développeurs purent alors
831 écrire des MPMs qui pouvaient fonctionner avec l'architecture
832 à base de processus ou de threads de leur système
833 d'exploitation spécifique. Apache 2 est fourni avec des MPMs
834 spécifiques pour Windows, OS/2, Netware et BeOS. Pour les
835 plateformes de style unix, les deux MPMS les plus connus
836 sont Prefork et Worker. Le MPM Prefork offre le même modèle
837 de processus enfants prélancés que celui d'Apache 1.3. Le
838 MPM Worker quant à lui, lance un nombre de processus enfants
839 moins important, mais attribue à chacun d'entre eux un
840 certain nombre de threads pour traiter les requêtes. Avec la
841 version 2.4, le MPM n'est plus défini à la compilation,
842 mais peut être chargé à l'exécution via la directive
843 <code class="directive"><a href="../mod/core.html#loadmodule">LoadModule</a></code>. Le MPM par
844 défaut pour la version 2.4 est le MPM event.
846 <p>Le nombre maximum de process, à savoir le nombre de processus
847 enfants prélancés et/ou de threads, donne une approximation
848 du nombre de requêtes que votre serveur peut traiter
849 simultanément. Ce n'est cependant qu'une estimation car le
850 noyau peut mettre en file d'attente des tentatives de
851 connexion à votre serveur. Lorsque votre site approche de la
852 saturation et si le nombre maximum de process est atteint, la
853 machine n'impose pas de limite absolue au
854 delà de laquelle les clients se verront refuser l'accès.
855 Cependant, lorsque les requêtes commencent à être mises en
856 file d'attente, les performances du système se dégradent
859 <p>Enfin, si le serveur httpd en question n'exécute aucun
860 code tiers via <code>mod_php</code>, <code>mod_perl</code>,
861 etc..., nous recommandons l'utilisation de
862 <code class="module">mpm_event</code>. Ce MPM est idéal pour les
863 situations où httpd sert d'intermédiaire entre les clients
864 et des serveurs d'arrière-plan qui accomplissent le travail
865 proprement dit (par exemple en mode mandataire ou cache).
869 <h4><a name="MaxClients" id="MaxClients">MaxClients
872 <p>La directive <code>MaxClients</code> permet de
873 spécifier le nombre maximum de process que votre serveur
874 pourra créer. Deux autres directives lui sont associées
875 : <code>MinSpareServers</code> et
876 <code>MaxSpareServers</code>, qui permettent d'encadrer
877 le nombre de process que httpd garde en réserve pour
878 traiter les requêtes. Le nombre total de process que
879 httpd peut créer peut
880 être défini via la directive <code>ServerLimit</code>.
885 <h4><a name="spinning-threads" id="spinning-threads">Rotation des threads
888 <p>Les directives ci-dessus suffisent pour définir les
889 limites des nombres de process dans le cas du MPM Prefork.
890 Cependant, si vous utilisez un MPM à base de threads, la
891 situation est un peu plus compliquée. Les MPMs à base de
892 threads supportent la directive
893 <code>ThreadsPerChild</code>. httpd impose le fait que
894 <code>MaxClients</code> doit être divisible par
895 <code>ThreadsPerChild</code>. Si les valeurs que vous
896 attribuez à ces deux directives ne respectent pas cette
897 règle, httpd affichera un message d'erreur et corrigera
898 la valeur de la directive <code>ThreadsPerChild</code>
899 en la diminuant jusqu'à ce que la valeur de la directive
900 <code>MaxClients</code> soit divisible par elle.
905 <h4><a name="sizing-maxClients" id="sizing-maxClients">Choix de la valeur de MaxClients
908 <p>Idéalement, le nombre maximum de processus devrait
909 être choisi de façon à ce que toute la mémoire système
910 soit utilisée, sans la dépasser. En effet, si votre
911 système est surchargé au point de devoir faire appel de
912 manière intensive au swap (utilisation de la mémoire
913 disque), les performances vont se dégrader rapidement.
914 La formule permettant de déterminer la valeur de
915 <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxClients</a></code>
919 <div class="example"><p><code>
920 MaxClients = (RAM totale − RAM système − RAM pour
921 les programmes externes) divisé par la RAM nécessaire pour
922 chaque processus enfant.
925 <p>L'observation est la meilleure manière de déterminer
926 les différentes quantités de mémoire allouées au
927 système, aux programmes externes et aux processus httpd
928 : à cet effet, vous pouvez utiliser les commandes top et
929 free décrites plus haut pour étudier l'empreinte mémoire
930 du système lorsque le serveur web n'est pas en cours
931 d'exécution. Vous pouvez aussi étudier l'empreinte d'un
932 processus type du serveur web via la commande top ; en
933 effet, la plupart des implémentations de cette commande
934 présentent une colonne Mémoire résidente (RSS - Resident
935 Size) et Mémoire partagée (Shared Memory).
937 <p>La différence entre ces deux colonnes est la
938 quantité de mémoire par processus. Le segment de mémoire
939 partagée n'existe effectivement qu'une seule fois, et
940 est utilisé par le code et les bibliothèques chargées et
941 la concurrence inter-processus (ou tableau de résultat -
942 scoreboard) géré par Apache. La quantité de mémoire
943 utilisée par chaque processus dépend fortement du nombre
944 et du type de modules utilisés. La meilleure façon d'en
945 déterminer les besoins consiste à générer une charge
946 type pour votre site web et à observer l'importance que
947 prennent les processus httpd.
949 <p>La RAM pour les programmes externes comprend
950 principalement la mémoire utilisée pour les programmes
951 CGI et les scripts qui s'exécutent indépendamment des
952 processus httpd. Par contre, si vous utilisez une
953 machine virtuelle Java qui exécute Tomcat sur le même
954 serveur, cette dernière va aussi nécessiter une quantité
955 de mémoire significative. En conséquence, la formule
956 ci-dessus qui sert à calculer la valeur maximale de
957 <code>MaxClients</code> permet d'effectuer une première approche,
958 mais ne constitue en aucun cas une science exacte. En
959 cas de doute, soyez pragmatique et utilisez une valeur assez
960 basse pour <code>MaxClients</code>. Le noyau Linux
961 réserve une certaine quantité de mémoire pour la mise en
962 cache des accès disque. Sous Solaris par contre, il faut disposer
963 de suffisamment de mémoire RAM pour créer un processus,
964 et si ce n'est pas le cas, httpd va démarrer avec un
965 message d'erreur du style "No space left on device" dans
966 le journal des erreurs, et sera incapable de créer
967 d'autres processus httpd enfants ; une valeur trop
968 élevée pour <code>MaxClients</code> constituera alors
969 réellement un désavantage.
973 <h4><a name="selecting-your-mpm" id="selecting-your-mpm">Choisir votre MPM
976 <p>La commutation entre threads est plus
977 aisée pour le système, et ceux-ci consomment moins de
978 ressources que les processus ; c'est la raison
979 principale pour laquelle il est recommandé de choisir un
981 ceci est encore plus flagrant pour certains systèmes
982 d'exploitation que pour d'autres. Par exemple, sous
983 Solaris ou AIX, la manipulation des processus est assez
984 lourde en termes de ressources système ; l'utilisation
985 d'un MPM threadé est donc tout à fait indiquée pour ces
986 systèmes. Sous Linux en revanche, l'implémentation des
987 threads utilise en fait un processus par thread. Les
988 processus Linux sont assez légers, mais cela signifie qu'un
989 MPM threadé présentera ici un gain en performance
990 moindre que sous d'autres systèmes.
992 <p>Dans certaines situations cependant, l'utilisation
993 d'un MPM threadé peut induire des problèmes de
994 stabilité. Par exemple, si un processus enfant du MPM
995 prefork se crashe, au plus une connexion client sera
996 affectée ; par contre, si un processus enfant threadé se
997 crashe, ce sont tous les threads de ce processus qui
998 vont se crasher à leur tour, ce qui signifie que tous
999 les clients qui étaient servis par ce processus verront
1000 leur connexion interrompue. De plus, certains problèmes
1001 de sécurité des threads ("thread-safety")
1002 peuvent apparaître, particulièrement avec les
1003 bibliothèques tierces. Avec les applications threadées,
1004 les différents threads peuvent avoir accès aux mêmes
1005 variables sans distinction, sans savoir si une variable
1006 n'a pas été modifiée par un autre thread.
1008 <p>Ce problème a fait l'objet d'un point sensible au
1009 sein de la communauté PHP car Le processeur PHP repose
1010 fortement sur des bibliothèques tierces, et il n'est pas
1011 garanti que la totalité d'entre elles soient
1012 "thread-safe". Bonne nouvelle cependant : si vous
1013 exécutez Apache sous Linux, vous pouvez utiliser PHP
1014 avec le MPM prefork sans craindre une diminution de
1015 performance trop importante par rapport à une option
1021 <h4><a name="spinning-locks" id="spinning-locks">Verrous tournants</a></h4>
1023 <p>Apache httpd maintient un verrou inter-processus du
1024 point de vue de son écoute du réseau. Dans les faits,
1025 cela signifie qu'un seul processus httpd enfant à la
1026 fois peut recevoir une requête. Ainsi, soient les autres
1027 processus en profitent alors pour traiter les requêtes
1028 qu'ils ont déjà reçues, soient ils attendent de pouvoir
1029 à leur tour récupérer le verrou et ainsi écouter le
1030 réseau pour recevoir une nouvelle requête. Ceci peut se
1031 voir comme une porte tournante par laquelle un seul
1032 processus peut passer à la fois. Sur un serveur web
1033 fortement chargé où les requêtes arrivent constamment,
1034 la porte tourne rapidement et les requêtes sont
1035 acceptées à un rythme soutenu. Sur un serveur faiblement
1036 chargé en revanche, le processus qui "détient"
1037 le verrou est suceptible de garder sa porte ouverte un
1038 certain temps durant lequel tous les autres processus
1039 seront inactifs, attendant de pouvoir s'approprier le
1040 verrou. Dans une telle situation, le processus parent
1041 pourra décider d'arrêter quelques processus enfants en
1042 fonction de la valeur de la directive
1043 <code>MaxSpareServers</code>.</p>
1046 <h4><a name="the-thundering-herd" id="the-thundering-herd">L'assaut de la foule
1049 <p>La fonction de l'"accept mutex" (c'est le nom donné au
1050 verrou inter-processus) consiste à gérer la réception
1051 des requêtes de manière ordonnée. Si ce verrou est
1052 absent, le syndrome de l'"assaut de la foule" peut
1055 <p>Imaginez une équipe de football américain en attente
1056 devant la ligne de remise en jeu. Si les joueurs se
1057 comportaient comme des processus Apache, ils se
1058 précipiteraient tous à la fois pour récupérer la balle au
1059 signal de la reprise. Un seul d'entre eux y
1060 parviendrait, et tous les autres n'auraient plus qu'à se
1061 regrouper à nouveau sur la ligne jusqu'à la reprise
1062 suivante. Dans cette métaphore, c'est le quaterback qui
1063 va jouer le rôle d'"accept mutex" en donnant la balle
1064 au joueur approprié.
1066 <p>La transmission d'une telle quantité d'informations
1067 représente naturellement beaucoup de travail et, comme
1068 une personne intelligente, un serveur intelligent
1069 tentera d'éviter cette surcharge dans la mesure du
1070 possible, d'où l'idée de la porte tournante. Dans les
1071 dernières années, de nombreux systèmes d'exploitation,
1072 comme Linux et Solaris, ont développé du code pour
1073 éviter le syndrome de l'"assaut de la foule". Apache
1074 reconnaît ce code, et si vous n'effectuez qu'une seule
1075 écoute du réseau, autrement dit si vous n'utilisez que
1076 le serveur principal ou un seul serveur virtuel, Apache
1077 n'utilisera pas d'"accept mutex" ; par contre, si vous
1078 effectuez plusieurs écoutes du réseau (par exemple si
1079 un serveur virtuel sert les requêtes SSL), Apache
1080 utilisera un "accept mutex" afin d'éviter les conflits
1083 <p>Vous pouvez manipuler l'"accept mutex" via la
1084 directive <code>AcceptMutex</code>. Cette dernière
1085 permet en particulier de fermer l'"accept mutex", mais
1086 aussi de sélectionner le mécanisme de verrouillage. Les
1087 mécanismes de verrouillage courants comprennent fcntl,
1088 les sémaphores System V et le verrouillage par threads.
1089 Tous ne sont pas supportés par toutes les plateformes,
1090 et leur disponibilité dépend aussi des options de
1091 compilation. Les différents mécanismes de verrouillage
1092 peuvent avoir des exigences particulières en matière de
1093 ressources système ; il est donc recommandé de les
1094 utiliser avec précautions.
1096 <p>Il n'existe aucune raison particulière pour
1097 désactiver l'"accept mutex". Apache détermine
1098 automatiquement s'il doit utiliser ou non mutex sur
1099 votre plateforme en fonction du nombre d'écoutes réseau
1100 de votre serveur, comme décrit précédemment.
1105 <h3><a name="tuning-the-operating-system" id="tuning-the-operating-system">Optimisation du système d'exploitation
1108 <p>Souvent, les utilisateurs recherchent le paramètre magique qui va
1109 multiplier par quatre les performances de leur système. En
1110 fait, les systèmes de type Unix actuels sont déjà optimisés
1111 à l'origine, et il n'y a plus grand chose à faire pour
1112 améliorer leurs performances. L'administrateur peut
1113 cependant encore effectuer quelques modifications qui
1114 permettront de peaufiner la configuration.
1118 <h4><a name="ram-and-swap-space" id="ram-and-swap-space">RAM et swap
1121 <p>Le leitmotiv en matière de mémoire est souvent "plus
1122 on en a, mieux c'est". En effet, comme nous avons dit
1123 plus haut, la mémoire inutilisée peut être
1124 avantageusement utilisée comme cache du système de
1125 fichiers. Plus vous chargez de modules, plus les processus
1126 Apache grossissent, et ceci d'autant plus si vous
1127 utilisez des modules qui génèrent des contenus
1128 dynamiques comme PHP et mod_perl. Un gros fichier de
1129 configuration - avec de nombreux serveurs virtuels - a
1130 aussi tendance à augmenter l'empreinte mémoire des
1131 processus. Une quantité de mémoire importante vous
1132 permettra d'exécuter Apache avec plus de processus
1133 enfants, et donc de traiter d'avantage de requêtes
1136 <p>Même si les différentes plateformes traitent leur
1137 mémoire virtuelle de différentes manières, il est
1138 déconseillé de configurer un espace disque de swap
1139 inférieur à la mémoire RAM. En effet, le système de mémoire
1140 virtuelle a été conçu de manière à prendre le relai
1141 lorsque la mémoire RAM fait défaut, et lorsque l'espace
1142 disque, et donc l'espace de swap vient à manquer, votre
1143 serveur risque de s'arrêter. Vous devrez alors
1144 redémarrer physiquement votre serveur, et votre
1145 hébergeur pourra vous facturer le service.
1147 <p>Evidemment, ce genre problème survient au moment le
1148 plus défavorable : lorsque le monde vient découvrir votre
1149 site web et se présente avec insistance à votre porte.
1150 Si votre espace de swap est suffisant, même si la
1151 machine sera de plus en plus surchargée et deviendra
1152 très très lente car le système devra swapper les pages
1153 entre la mémoire et le disque, lorsque la charge diminuera à
1154 nouveau, le système reviendra dans son mode de
1155 fonctionnement normal. Rappelez-vous que vous disposez
1156 de la directive <code>MaxClients</code> pour garder le contrôle.
1158 <p>La plupart des systèmes de type Unix utilisent des
1159 partitions dédiées au swap. Au démarrage du système,
1160 celui-ci enregistre toutes les partitions de swap du ou
1161 des disques en fonction du type de la partition ou du
1162 contenu du fichier <code>/etc/fstab</code> et les
1163 active de manière automatique. Lorsque vous ajoutez un
1164 disque, ou lorsque vous installez le système
1165 d'exploitation, assurez-vous d'allouer suffisamment
1166 d'espace de swap afin de rester en adéquation avec une
1167 éventuelle augmentation de la mémoire RAM. La
1168 réallocation d'espace disque sur un système en
1169 production est en effet pénible et fastidieuse.
1171 <p>Prévoyez un espace de swap de deux fois la taille de
1172 votre mémoire RAM, et même jusqu'à quatre fois lorsque
1173 les surcharges peuvent s'avérer fréquentes. Assurez-vous
1174 de réajuster ces valeurs lorsque vous augmentez la
1175 quantité de mémoire RAM de votre système. En secours,
1176 vous pouvez aussi utilisez un fichier comme espace de
1177 swap. Pour ce faire, vous trouverez les instructions
1178 dans les pages de manuel de <code>mkswap</code> et
1179 <code>swapon</code>, ou dans celles des programmes de
1185 <h4><a name="ulimit-files-and-processes" id="ulimit-files-and-processes">ulimit: fichiers et processus
1188 <p>Supposons que vous disposiez d'une machine possédant
1189 une énorme quantité de mémoire RAM et un processeur aux
1190 performances astronomiques ; vous pourrez alors exécuter
1191 des centaines de processus Apache selon vos besoins,
1192 mais tout en restant en deçà des limites imposées par le
1193 noyau de votre système.
1195 <p>Considérez maintenant une situation où plusieurs
1196 centaines de serveurs web sont en cours d'exécution ; si
1197 certains d'entre eux doivent à leur tour lancer des
1198 processus CGI, le nombre maximum de processus autorisé
1199 par le noyau sera vite atteint.
1201 <p>Dans ce cas, vous pouvez modifier cette limite avec
1205 <div class="example"><p><code>
1206 ulimit [-H|-S] -u [nouvelle valeur]
1209 <p>Cette modification doit être effectuée avant le
1210 démarrage du serveur, car la nouvelle valeur ne sera
1211 prise en compte que dans le shell courant et pour les
1212 programmes lancés depuis ce dernier. Dans les derniers
1213 noyaux Linux, la valeur par défaut a été fixée à 2048.
1214 Sous FreeBSD, ce nombre semble être limité à la valeur
1215 inhabituelle de 513. Dans le shell par défaut de ce
1216 système, <code>csh</code>, la commande équivalente est
1217 <code>limit</code> et possède une syntaxe analogue à
1218 celle de la commande de style Bourne <code>ulimit</code> :
1221 <div class="example"><p><code>
1222 limit [-h] maxproc [newvalue]
1225 <p>En outre, le noyau peut limiter le nombre de fichiers
1226 ouverts par processus. Ce n'est généralement pas un
1227 problème pour les serveurs dont les processus sont lancés
1228 à l'avance, et où chacun de ceux-ci ne traite qu'une
1229 requête à la fois. Les processus des serveurs threadés,
1230 quant à eux, traitent plusieurs requêtes simultanément,
1231 et sont d'avantage susceptibles de dépasser la limite du
1232 nombre de descripteurs de fichiers. Vous pouvez alors
1233 augmenter cette valeur limite du nombre de fichiers
1234 ouverts avec la commande :
1237 <div class="example"><p><code>ulimit -n [newvalue]
1240 <p>Là encore, cette modification doit être effectuée
1241 avant le démarrage du serveur Apache.
1246 <h4><a name="setting-user-limits-on-system-startup" id="setting-user-limits-on-system-startup">Définition des limites en fonction de l'utilisateur ou du
1247 groupe au démarrage du système
1250 <p>Sous Linux, vous pouvez définir les paramètres de
1251 ulimit au démarrage en éditant le fichier
1252 <code>/etc/security/limits.conf</code>. Ce fichier vous
1253 permet de définir des limites "soft" et "hard"
1254 en fonction de l'utilisateur ou du groupe ;
1255 vous y trouverez aussi des commentaires explicatifs des
1256 différentes options. Pour que ce fichier soit pris en
1257 compte, le fichier <code>/etc/pam.d/login</code> doit
1261 <div class="example"><p><code>session required /lib/security/pam_limits.so
1264 <p>Chaque item peut posséder une valeur "soft" et
1265 "hard" : la première est la valeur
1266 par défaut, et la seconde la valeur maximale de cet
1269 <p>Dans le fichier <code>/etc/login.conf</code> de
1270 FreeBSD, ces valeurs peuvent être limitées ou étendues à
1271 tout le système de manière analogue au fichier
1272 <code>limits.conf</code>. Les limites "soft" sont
1273 spécifiées via le paramètre <code>-cur</code>, et les
1274 limites "hard" via le paramètre <code>-max</code>.
1276 <p>Solaris possède un mécanisme similaire pour manipuler
1277 les valeurs limites au démarrage du système : dans le
1278 fichier <code>/etc/system</code>, vous pouvez définir au
1279 démarrage des paramètres du noyau valables pour
1280 l'ensemble du système. Ce sont les mêmes paramètres que
1281 ceux définis à l'exécution par le débogueur de noyau
1282 <code>mdb</code>. Les commandes équivalentes à ulimit -u
1283 pour définir les limites hard et soft seront du style :
1286 <div class="example"><p><code>
1287 set rlim_fd_max=65536<br />
1288 set rlim_fd_cur=2048
1291 <p>Solaris calcule le nombre maximal de processus
1292 autorisé par utilisateur (<code>maxuprc</code>) en
1293 fonction de la mémoire système disponible
1294 (<code>maxusers</code>). Vous pouvez obtenir ces valeurs
1298 <div class="example"><p><code>sysdef -i | grep maximum
1301 <p>Il est cependant déconseillé de les modifier.
1306 <h4><a name="turn-off-unused-services-and-modules" id="turn-off-unused-services-and-modules">Désactiver les services et modules non utilisés
1309 <p>Dans la plupart des distributions Unix et Linux, de
1310 nombreux services sont activés par défaut, et vous n'
1311 avez probablement besoin que d'une minorité d'entre eux.
1312 Par exemple, votre serveur web n'a pas besoin de
1313 sendmail, de fournir le service NFS, etc... Désactivez
1314 les tout simplement.
1316 <p>Pour ce faire, sous RedHat Linux, vous
1317 disposez de l'utilitaire chkconfig en ligne de commande.
1318 Sous Solaris, les commandes <code>svcs</code> et
1319 <code>svcadm</code> vous permettent respectivement
1320 de lister les services activés et de désactiver ceux
1321 dont vous n'avez pas besoin.
1323 <p>Vous devez aussi prêter attention aux modules Apache
1324 chargés par défaut. La plupart des distributions binaires
1325 d'Apache httpd et des versions préinstallées fournies
1326 avec les distributions de Linux chargent les modules
1327 Apache via la directive
1328 <code class="directive">LoadModule</code>.
1330 <p>Les modules inutilisés peuvent être désactivés : si
1331 vous n'avez pas besoin de leurs fonctionnalités et des
1332 directives de configuration qu'ils implémentent,
1333 désactivez-les en commentant les lignes
1334 <code class="directive">LoadModule</code> correspondantes. Vous
1335 devez cependant lire la documentation relative à ces
1336 modules avant de les désactiver, et garder à l'esprit que
1337 la désactivation d'un module très peu gourmand en
1338 ressources n'est pas absolument nécessaire.
1344 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
1345 <div class="section">
1346 <h2><a name="caching-content" id="caching-content">Mise en cache des contenus
1347 </a> <a title="Lien permanent" href="#caching-content" class="permalink">¶</a></h2>
1349 <p>Les requêtes impliquant des contenus dynamiques nécessitent
1350 en général d'avantage de ressources que les
1351 requêtes pour des contenus statiques. Les contenus statiques
1352 consistent en simples pages issues de documents ou images
1353 sur disque, et sont servis très rapidement. En outre, de
1354 nombreux systèmes d'exploitation mettent automatiquement en
1355 cache en mémoire les contenus des fichiers fréquemment accédés.
1357 <p>Comme indiqué précédemment, le traitement des requêtes dynamiques peut
1358 nécessiter beaucoup plus de ressources. L'exécution de scripts
1359 CGI, le transfert de requêtes à un serveur d'applications
1360 externe, ou les accès à une base de données peuvent impliquer
1361 des temps d'attente et charges de travail significatifs pour un
1362 serveur web fortement sollicité. Dans de nombreuses
1363 circonstances, vous pourrez alors améliorer les performances en
1364 transformant les requêtes dynamiques courantes en requêtes
1365 statiques. Pour ce faire, deux approches seront discutées dans
1366 la suite de cette section.
1370 <h3><a name="making-popular-pages-static" id="making-popular-pages-static">Transformation des pages courantes en contenus
1374 <p>En générant à l'avance les réponses pour les requêtes les
1375 plus courantes de votre application, vous pouvez améliorer
1376 de manière significative les performances de votre serveur
1377 sans abandonner la flexibilité des contenus générés
1378 dynamiquement. Par exemple, si votre application est un
1379 service de livraison de fleurs, vous aurez tout intérêt à
1380 générer à l'avance les pages de votre catalogue concernant
1381 les roses rouges dans les semaines précédant le jour de la
1382 Saint Valentin. Lorsqu'un utilisateur cherchera des roses
1383 rouges, il téléchargera alors les pages générées à
1384 l'avance. Par contre, les recherches de roses jaunes seront
1385 quant à elles traitées directement via une requête vers la
1386 base de données. Pour effectuer ces aiguillages de requêtes,
1387 vous disposez d'un outil particulièrement approprié fourni
1388 avec Apache : le module mod_rewrite.
1392 <h4><a name="example-a-statically-rendered-blog" id="example-a-statically-rendered-blog">Exemple : un blog servi statiquement
1397 <p>Blosxom est un programme CGI de journalisation web
1398 léger. Il est écrit en Perl et utilise des fichiers
1399 texte pour ses entrées. Outre sa qualité de programme
1400 CGI, Blosxom peut être exécuté en ligne de commande pour
1401 générer à l'avance des pages de blog. Lorsque votre blog
1402 commence à être lu par un grand nombre de personnes, la
1403 génération à l'avance de pages en HTML satique peut
1404 améliorer de manière significative les performances de
1407 <p>Pour générer des pages statiques avec blosxom, éditez
1408 le script CGI selon la documentation. Définissez la
1409 variable $static dir à la valeur de
1410 <code class="directive">DocumentRoot</code> de votre serveur
1411 web, et exécutez le script en ligne de commande comme
1415 <div class="example"><p><code>$ perl blosxom.cgi -password='whateveryourpassword'
1418 <p>Vous pouvez exécuter ce script périodiquement via
1419 cron, à chaque fois que vous ajoutez un nouveau contenu. Pour
1420 faire en sorte qu'Apache substitue les pages
1421 statiques au contenu dynamique, nous
1422 utiliserons mod_rewrite. Ce module est fourni avec le
1423 code source d'Apache, mais n'est pas compilé par défaut.
1424 Pour le compiler avec la distribution d'Apache, vous
1425 pouvez utiliser l'option de la commande configure
1426 <code>--enable-rewrite[=shared]</code>. De nombreuses
1427 distributions binaires d'Apache sont fournies avec
1428 <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> inclus. Dans l'exemple
1429 suivant, un serveur virtuel Apache utilise les pages de
1430 blog générées à l'avance :
1433 <pre class="prettyprint lang-config">Listen *:8001
1434 <VirtualHost *:8001>
1435 ServerName blog.sandla.org:8001
1436 ServerAdmin sander@temme.net
1437 DocumentRoot "/home/sctemme/inst/blog/httpd/htdocs"
1438 <Directory "/home/sctemme/inst/blog/httpd/htdocs">
1442 RewriteCond "%{REQUEST_FILENAME}" "!-f"
1443 RewriteCond "%{REQUEST_FILENAME}" "!-d"
1444 RewriteRule "^(.*)$" "/cgi-bin/blosxom.cgi/$1" [L,QSA]
1446 RewriteLog "/home/sctemme/inst/blog/httpd/logs/rewrite_log"
1448 ErrorLog "/home/sctemme/inst/blog/httpd/logs/error_log"
1450 CustomLog "/home/sctemme/inst/blog/httpd/logs/access_log common"
1451 ScriptAlias "/cgi-bin/" "/home/sctemme/inst/blog/bin/"
1452 <Directory "/home/sctemme/inst/blog/bin">
1456 </VirtualHost></pre>
1460 Si les directives <code class="directive">RewriteCond</code>
1461 indiquent que la ressource demandée n'existe ni en tant que
1462 fichier, ni en tant que répertoire, son
1463 chemin sera redirigé par la directive
1464 <code class="directive">RewriteRule</code> vers le programme
1465 CGI Blosxom qui va générer la réponse. Blosxom
1466 utilise Path Info pour spécifier les entrées de blog
1467 en tant que pages d'index, et si un chemin dans
1468 Blosxom existe en tant que fichier statique dans le système de
1469 fichiers, c'est ce dernier qui sera par conséquent privilégié.
1470 Toute requête dont la réponse n'a pas été générée à
1471 l'avance sera traitée par le programme CGI. Cela
1472 signifie que les entrées individuelles comme les
1473 commentaires seront toujours servies par le
1474 programme CGI, et seront donc toujours visibles.
1475 Cette configuration permet aussi de ne pas faire
1476 apparaître le programme CGI Blosxom dans l'URL de la barre
1477 d'adresse. Enfin, mod_rewrite est un module extrêmement
1478 souple et puissant ; prenez le temps de bien
1479 l'étudier afin de parvenir à la configuration qui
1480 correspondra le mieux à votre situation.
1486 <h3><a name="caching-content-with-mod_cache" id="caching-content-with-mod_cache">Mise en cache du contenu avec mod_cache
1489 <p>Le module mod_cache implémente une mise en cache
1490 intelligente des réponses HTTP : il tient compte des délais
1491 de péremption et des contraintes en matière de contenu
1492 inhérentes à la spécification HTTP. Le module mod_cache met
1493 en cache les URL des contenus des réponses. Si un contenu envoyé au
1494 client peut être mis en cache, il est sauvegardé sur disque.
1495 Les requêtes ultérieures pour cette URL seront alors servies
1496 directement depuis le cache. Le module fournisseur pour
1497 mod_cache, mod_disk_cache, détermine la manière dont les
1498 contenus sont stockés sur disque. La plupart des systèmes de
1499 serveur possèdent plus d'espace disque que de mémoire, et il
1500 est bon de garder à l'esprit que certains noyaux système mettent en
1501 cache de manière transparente en mémoire les contenus sur
1502 disque fréquemment accédés ; il n'est donc pas très utile de
1503 répéter cette opération au niveau du serveur.
1505 <p>Pour mettre en oeuvre une mise en cache de contenu
1506 efficace et éviter de présenter à l'utilisateur un contenu
1507 invalide ou périmé, l'application qui génère le contenu à
1508 jour doit envoyer les en-têtes de réponse corrects. En
1509 effet, en l'absence d'en-têtes comme <code>Etag:</code>,
1510 <code>Last-Modified:</code> ou <code>Expires:</code>,
1511 <code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code> ne sera pas en mesure de décider
1512 de manière appropriée
1513 s'il doit mettre le contenu en cache, s'il doit le servir
1514 directement depuis ce dernier, ou s'il doit tout simplement
1515 ne rien faire. Lorsque vous testerez la mise en cache, vous
1516 devrez peut-être modifier votre application ou, en cas
1517 d'impossibilité, désactiver de manière sélective la mise en
1518 cache des URLs qui posent problème. Les modules mod_cache ne
1519 sont pas compilés par défaut ; pour ce faire, vous devez
1520 utiliser l'option <code>--enable-cache[=shared]</code> du
1521 script configure. Si vous utilisez une distribution binaire
1522 d'Apache httpd, ou si elle fait partie de votre portage ou
1523 de votre sélection de paquets, <code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code>
1524 sera probablement déjà inclus.
1528 <h4><a name="example-wiki" id="example-wiki">Exemple : wiki.apache.org
1533 Le Wiki de l'Apache Software Foundation est servi
1534 par MoinMoin. MoinMoin est écrit en Python et
1535 s'exécute en tant que programme CGI. A l'heure
1536 actuelle, toute tentative pour l'exécuter via
1537 mod_python s'est soldée par un échec. Le programme
1538 CGI induit une charge inacceptable sur le serveur,
1539 particulièrement lorsque le Wiki est indexé par des
1540 moteurs de recherche comme Google. Pour alléger la
1541 charge de la machine, l'équipe d'infrastructure
1542 d'Apache s'est tournée vers mod_cache. Il s'est
1543 avéré que <a href="/httpd/MoinMoin">MoinMoin</a>
1544 nécessitait un petit patch pour adopter un
1545 comportement approprié en aval du serveur de mise
1546 en cache : certaines requêtes ne pouvaient jamais
1547 être mises en cache, et les modules Python
1548 concernés ont été mis à jour pour pouvoir envoyer
1549 les en-têtes de réponse HTTP corrects. Après cette
1550 modification, la mise en cache en amont du Wiki a
1551 été activée via l'insertion des lignes suivantes
1552 dans le fichier de configuration
1553 <code>httpd.conf</code> :
1556 <pre class="prettyprint lang-config">CacheRoot /raid1/cacheroot
1558 # Une page modifiée il y a 100 minutes expirera dans 10 minutes
1559 CacheLastModifiedFactor .1
1560 # Dans tous les cas, vérifier la validité des pages après 6 heures
1561 CacheMaxExpire 21600</pre>
1564 <p>Cette configuration essaie de mettre en cache tout
1565 contenu de son serveur virtuel. Elle ne mettra jamais en
1566 cache un contenu plus vieux que 6 heures (voir la
1567 directive <code class="directive"><a href="../mod/mod_cache.html#cachemaxexpire">CacheMaxExpire</a></code>). Si
1568 l'en-tête <code>Expires:</code> est absent de la
1569 réponse, <code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code> va calculer une date
1570 d'expiration en fonction du contenu de l'en-tête
1571 <code>Last-Modified:</code>. Le principe de ce calcul
1572 qui utilise la directive <code class="directive"><a href="../mod/mod_cache.html#cachelastmodifiedfactor">CacheLastModifiedFactor</a></code>
1573 se base sur l'hypothèse que si une page a été modifiée
1574 récemment, il y a de fortes chances pour qu'elle le soit
1575 à nouveau dans un futur proche et devra donc être remise
1579 Notez qu'il peut s'avérer payant de
1580 <em>désactiver</em> l'en-tête <code>ETag:</code> :
1581 pour les fichiers inférieurs à 1 ko, le serveur
1582 doit calculer la somme de vérification checksum (en
1583 général MD5) et envoyer une réponse <code>304 Not
1584 Modified</code>, ce qui utilise des ressources CPU
1585 et réseau pour le transfert (1 paquet TCP). Pour les
1586 ressources supérieures à 1 ko, les ressources CPU
1587 consommées peuvent devenir importantes car l'en-tête
1588 est calculé à chaque requête. Malheureusement, il
1589 n'existe actuellement aucun moyen pour mettre en
1592 <pre class="prettyprint lang-config"><FilesMatch "\.(jpe?g|png|gif|js|css|x?html|xml)">
1594 </FilesMatch></pre>
1598 Dans l'exemple précédent: la génération d'un en-tête
1599 <code>ETag:</code> sera désactivée pour la plupart
1600 des ressources statiques. Le serveur ne génère pas
1601 ces en-têtes pour les ressources dynamiques.
1607 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
1608 <div class="section">
1609 <h2><a name="further-considerations" id="further-considerations">Pour aller plus loin
1610 </a> <a title="Lien permanent" href="#further-considerations" class="permalink">¶</a></h2>
1612 <p>Armés du savoir-faire pour personnaliser un système afin
1613 qu'il affiche les performances désirées, nous découvrirons vite
1614 qu'<em>1</em> sytème à lui seul peut constituer un goulot
1615 d'étranglement. A ce sujet, la page du Wiki <a href="http://wiki.apache.org/httpd/PerformanceScalingOut">PerformanceScalingOut</a>
1616 décrit comment adapter un système à mesure qu'il prend de
1617 l'ampleur, ou comment personnaliser plusieurs systèmes dans leur
1621 <div class="bottomlang">
1622 <p><span>Langues Disponibles: </span><a href="../en/misc/perf-scaling.html" hreflang="en" rel="alternate" title="English"> en </a> |
1623 <a href="../es/misc/perf-scaling.html" hreflang="es" rel="alternate" title="Español"> es </a> |
1624 <a href="../fr/misc/perf-scaling.html" title="Français"> fr </a></p>
1625 </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>
1626 <script type="text/javascript"><!--//--><![CDATA[//><!--
1627 var comments_shortname = 'httpd';
1628 var comments_identifier = 'http://httpd.apache.org/docs/trunk/misc/perf-scaling.html';
1630 if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
1631 d.write('<div id="comments_thread"><\/div>');
1632 var s = d.createElement('script');
1633 s.type = 'text/javascript';
1635 s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
1636 (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
1639 d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
1641 })(window, document);
1642 //--><!]]></script></div><div id="footer">
1643 <p class="apache">Copyright 2019 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
1644 <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