mirror of
https://github.com/apache/httpd.git
synced 2025-08-10 02:56:11 +00:00
12745a93ae
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1836023 13f79535-47bb-0310-9956-ffa450edef68
1649 lines
86 KiB
Plaintext
1649 lines
86 KiB
Plaintext
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head>
|
|
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
|
|
<!--
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
This file is generated from xml source: DO NOT EDIT
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
-->
|
|
<title>Amélioration des performances - Serveur HTTP Apache Version 2.5</title>
|
|
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
|
|
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
|
|
<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" />
|
|
<script src="../style/scripts/prettify.min.js" type="text/javascript">
|
|
</script>
|
|
|
|
<link href="../images/favicon.ico" rel="shortcut icon" /></head>
|
|
<body id="manual-page"><div id="page-header">
|
|
<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>
|
|
<p class="apache">Serveur HTTP Apache Version 2.5</p>
|
|
<img alt="" src="../images/feather.png" /></div>
|
|
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
|
|
<div id="path">
|
|
<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>
|
|
<div class="toplang">
|
|
<p><span>Langues Disponibles: </span><a href="../en/misc/perf-scaling.html" hreflang="en" rel="alternate" title="English"> en </a> |
|
|
<a href="../es/misc/perf-scaling.html" hreflang="es" rel="alternate" title="Español"> es </a> |
|
|
<a href="../fr/misc/perf-scaling.html" title="Français"> fr </a></p>
|
|
</div>
|
|
|
|
|
|
<p>Il est dit dans la documentation d'Apache 1.3
|
|
à propos de l'amélioration des performances :
|
|
</p>
|
|
<blockquote><p>
|
|
"Apache est un serveur web à vocation générale, conçu pour
|
|
être non seulement efficace mais aussi rapide. Dans sa
|
|
configuration de base, ses performances sont déjà
|
|
relativement satisfaisantes. La plupart des sites possèdent
|
|
une bande passante en sortie inférieure à 10 Mbits que le
|
|
serveur Apache peut mettre pleinement à profit en utilisant un serveur à base
|
|
de processeur Pentium bas de gamme."</p>
|
|
</blockquote>
|
|
<p>Cette phrase ayant été écrite il y a plusieurs années,
|
|
entre temps de nombreuses choses ont changé. D'une part, les
|
|
serveurs sont devenus beaucoup plus rapides. D'autre part, de
|
|
nombreux sites se voient maintenant allouée une bande passante
|
|
en sortie bien supérieure à 10 Mbits. En outre, les applications
|
|
web sont devenues beaucoup plus complexes. Les sites classiques
|
|
ne proposant que des pages du style brochure sont toujours
|
|
présents, mais le web a souvent évolué vers une plateforme
|
|
exécutant des traitements, et les webmasters peuvent maintenant
|
|
mettre en ligne des contenus dynamiques en Perl, PHP ou Java,
|
|
qui exigent un niveau de performances bien supérieur.
|
|
</p>
|
|
<p>C'est pourquoi en dépit des progrès en matière de bandes passantes
|
|
allouées et de rapidité des serveurs, les performances
|
|
des serveurs web et des applications web sont toujours un sujet
|
|
d'actualité. C'est dans ce cadre que cette documentation s'attache à
|
|
présenter de nombreux points concernant les performances des
|
|
serveurs web.
|
|
</p>
|
|
|
|
</div>
|
|
<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>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#monitoring-your-server">Monitoring de votre serveur</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#configuring-for-performance">Configuration dans une optique de performances
|
|
</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#caching-content">Mise en cache des contenus
|
|
</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#further-considerations">Pour aller plus loin
|
|
</a></li>
|
|
</ul><h3>Voir aussi</h3><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
|
|
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<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>
|
|
|
|
<p>Ce document se concentre sur l'amélioration des performances
|
|
via des options facilement accessibles, ainsi que sur les outils
|
|
de monitoring. Les outils de monitoring vous permettront de
|
|
surveiller le fonctionnement de votre serveur web afin de
|
|
rassembler des informations à propos de ses performances et des
|
|
éventuels problèmes qui s'y rapportent. Nous supposerons
|
|
que votre budget n'est pas illimité ; c'est pourquoi les
|
|
améliorations apportées le seront sans modifier l'infrastructure
|
|
matérielle existante. Vous ne souhaitez probablement pas
|
|
compiler vous-même votre serveur Apache, ni recompiler le noyau
|
|
de votre système d'exploitation ; nous supposerons cependant que
|
|
vous possédez quelques notions à propos du fichier de
|
|
configuration du serveur HTTP Apache.
|
|
</p>
|
|
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<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>
|
|
|
|
<p>Si vous envisagez de redimensionner ou d'améliorer les performances
|
|
de votre serveur, vous devez tout d'abord observer la manière dont il
|
|
fonctionne. En observant son fonctionnement en conditions réelles ou
|
|
sous une charge créée artificiellement, vous serez en mesure
|
|
d'extrapoler son fonctionnement sous une charge accrue, par exemple dans
|
|
le cas où il serait mentionné sur Slashdot. </p>
|
|
|
|
|
|
<h3><a name="monitoring-tools" id="monitoring-tools">Outils de monitoring</a></h3>
|
|
|
|
|
|
<h4><a name="top" id="top">top
|
|
</a></h4>
|
|
|
|
<p>L'outil top est fourni avec Linux et FreeBSD. Solaris
|
|
quant à lui, fournit <code>prstat(1)</code>. Cet outil
|
|
permet de rassembler de nombreuses données statistiques
|
|
à propos du système et de chaque processus en cours
|
|
d'exécution avant de les afficher de manière
|
|
interactive sur votre terminal. Les données affichées
|
|
sont rafraîchies toutes les secondes et varient en
|
|
fonction de la plateforme, mais elles comportent en
|
|
général la charge moyenne du système, le nombre de
|
|
processus et leur état courant, le pourcentage de temps
|
|
CPU(s) passé à exécuter le code système et utilisateur,
|
|
et l'état de la mémoire virtuelle système. Les données
|
|
affichées pour chaque processus sont en général
|
|
configurables et comprennent le nom et l'identifiant du
|
|
processus, sa priorité et la valeur définie par nice,
|
|
l'empreinte mémoire, et le pourcentage d'utilisation CPU.
|
|
L'exemple suivant montre plusieurs processus httpd (avec
|
|
les MPM worker et event) s'exécutant sur un système
|
|
Linux (Xen) :
|
|
</p>
|
|
|
|
<div class="example"><pre>top - 23:10:58 up 71 days, 6:14, 4 users, load average: 0.25, 0.53, 0.47
|
|
Tasks: 163 total, 1 running, 162 sleeping, 0 stopped, 0 zombie
|
|
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
|
|
Mem: 2621656k total, 2178684k used, 442972k free, 100500k buffers
|
|
Swap: 4194296k total, 860584k used, 3333712k free, 1157552k cached
|
|
|
|
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
|
|
16687 example_ 20 0 1200m 547m 179m S 45 21.4 1:09.59 httpd-worker
|
|
15195 www 20 0 441m 33m 2468 S 0 1.3 0:41.41 httpd-worker
|
|
1 root 20 0 10312 328 308 S 0 0.0 0:33.17 init
|
|
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
|
|
3 root RT -5 0 0 0 S 0 0.0 0:00.14 migration/0
|
|
4 root 15 -5 0 0 0 S 0 0.0 0:04.58 ksoftirqd/0
|
|
5 root RT -5 0 0 0 S 0 0.0 4:45.89 watchdog/0
|
|
6 root 15 -5 0 0 0 S 0 0.0 1:42.52 events/0
|
|
7 root 15 -5 0 0 0 S 0 0.0 0:00.00 khelper
|
|
19 root 15 -5 0 0 0 S 0 0.0 0:00.00 xenwatch
|
|
20 root 15 -5 0 0 0 S 0 0.0 0:00.00 xenbus
|
|
28 root RT -5 0 0 0 S 0 0.0 0:00.14 migration/1
|
|
29 root 15 -5 0 0 0 S 0 0.0 0:00.20 ksoftirqd/1
|
|
30 root RT -5 0 0 0 S 0 0.0 0:05.96 watchdog/1
|
|
31 root 15 -5 0 0 0 S 0 0.0 1:18.35 events/1
|
|
32 root RT -5 0 0 0 S 0 0.0 0:00.08 migration/2
|
|
33 root 15 -5 0 0 0 S 0 0.0 0:00.18 ksoftirqd/2
|
|
34 root RT -5 0 0 0 S 0 0.0 0:06.00 watchdog/2
|
|
35 root 15 -5 0 0 0 S 0 0.0 1:08.39 events/2
|
|
36 root RT -5 0 0 0 S 0 0.0 0:00.10 migration/3
|
|
37 root 15 -5 0 0 0 S 0 0.0 0:00.16 ksoftirqd/3
|
|
38 root RT -5 0 0 0 S 0 0.0 0:06.08 watchdog/3
|
|
39 root 15 -5 0 0 0 S 0 0.0 1:22.81 events/3
|
|
68 root 15 -5 0 0 0 S 0 0.0 0:06.28 kblockd/0
|
|
69 root 15 -5 0 0 0 S 0 0.0 0:00.04 kblockd/1
|
|
70 root 15 -5 0 0 0 S 0 0.0 0:00.04 kblockd/2</pre></div>
|
|
|
|
<p>Top est un merveilleux outil, même s'il est
|
|
relativement gourmand en ressources (lorsqu'il
|
|
s'exécute, son propre processus se trouve en général
|
|
dans le top dix des consommations CPU). Il est
|
|
indispensable pour déterminer la taille d'un processus
|
|
en cours d'exécution, information précieuse lorsque vous
|
|
voudrez déterminer combien de processus httpd vous
|
|
pourrez exécuter sur votre machine. La méthode pour
|
|
effectuer ce calcul est décrite ici : <a href="#sizing-maxClients">calculer MaxClients</a>. Top
|
|
est cependant un outil interactif, et l'exécuter de
|
|
manière continu présente peu ou pas d'avantage.
|
|
</p>
|
|
|
|
<h4><a name="free" id="free">free
|
|
</a></h4>
|
|
|
|
<p>Cette commande n'est disponible que sous Linux. Elle
|
|
indique la mémoire vive et l'espace de swap utilisés.
|
|
Linux alloue la mémoire inutilisée en tant que cache du
|
|
système de fichiers. La commande free montre
|
|
l'utilisation de la mémoire avec et sans ce cache. On
|
|
peut utiliser la commande free pour déterminer la
|
|
quantité de mémoire utilisée par le système, comme
|
|
décrit dans le paragraphe <a href="#sizing-maxClients">calculer MaxClients</a>.
|
|
L'affichage de la sortie de la commande free ressemble à
|
|
ceci :
|
|
</p>
|
|
|
|
<div class="example"><pre>sctemme@brutus:~$ free
|
|
total used free shared buffers cached
|
|
Mem: 4026028 3901892 124136 0 253144 841044
|
|
-/+ buffers/cache: 2807704 1218324
|
|
Swap: 3903784 12540 3891244</pre></div>
|
|
|
|
|
|
<h4><a name="vmstat" id="vmstat">vmstat
|
|
</a></h4>
|
|
|
|
<p>Cette commande est disponible sur de nombreuses
|
|
plateformes de style Unix. Elle affiche un grand nombre
|
|
de données système. Lancée sans argument, elle affiche
|
|
une ligne d'état pour l'instant actuel. Lorsqu'on lui
|
|
ajoute un chiffre, la ligne d'état actuelle est ajoutée à
|
|
intervalles réguliers à l'affichage existant.
|
|
Par exemple, la commande
|
|
<code>vmstat 5</code> ajoute la ligne d'état actuelle
|
|
toutes les 5 secondes. La commande vmstat affiche la
|
|
quantité de mémoire virtuelle utilisée, la quantité de
|
|
mémoire échangée avec l'espace de swap en entrée et en
|
|
sortie à chaque seconde, le nombre de processus
|
|
actuellement en cours d'exécution ou inactifs, le nombre
|
|
d'interruptions et de changements de contexte par
|
|
seconde, et le pourcentage d'utilisation du CPU.
|
|
</p>
|
|
<p>
|
|
Voici la sortie de la commande <code>vmstat</code>
|
|
pour un serveur inactif :
|
|
</p>
|
|
|
|
|
|
<div class="example"><pre>[sctemme@GayDeceiver sctemme]$ vmstat 5 3
|
|
procs memory swap io system cpu
|
|
r b w swpd free buff cache si so bi bo in cs us sy id
|
|
0 0 0 0 186252 6688 37516 0 0 12 5 47 311 0 1 99
|
|
0 0 0 0 186244 6696 37516 0 0 0 16 41 314 0 0 100
|
|
0 0 0 0 186236 6704 37516 0 0 0 9 44 314 0 0 100</pre></div>
|
|
|
|
<p>Et voici cette même sortie pour un serveur en charge
|
|
de cent connexions simultanées pour du contenu statique :
|
|
</p>
|
|
|
|
<div class="example"><pre>[sctemme@GayDeceiver sctemme]$ vmstat 5 3
|
|
procs memory swap io system cpu
|
|
r b w swpd free buff cache si so bi bo in cs us sy id
|
|
1 0 1 0 162580 6848 40056 0 0 11 5 150 324 1 1 98
|
|
6 0 1 0 163280 6856 40248 0 0 0 66 6384 1117 42 25 32
|
|
11 0 0 0 162780 6864 40436 0 0 0 61 6309 1165 33 28 40</pre></div>
|
|
|
|
<p>La première ligne indique des valeurs moyennes depuis
|
|
le dernier redémarrage. Les lignes suivantes donnent des
|
|
informations d'état à intervalles de 5 secondes. Le
|
|
second argument demande à vmstat de générer 3 lignes
|
|
d'état, puis de s'arrêter.
|
|
</p>
|
|
|
|
|
|
<h4><a name="se-toolkit" id="se-toolkit">Boîte à outils SE
|
|
</a></h4>
|
|
|
|
<p>La boîte à outils SE est une solution de supervision
|
|
pour Solaris. Son langage de programmation est basé sur
|
|
le préprocesseur C et est fourni avec de nombreux
|
|
exemples de scripts. Les informations fournies
|
|
peuvent être exploitées en mode console ou en mode
|
|
graphique. Cette boîte à outils peut aussi être programmée pour
|
|
appliquer des règles aux données système. Avec l'exemple
|
|
de script de la Figure 2, Zoom.se, des voyants verts,
|
|
oranges ou rouges s'allument lorsque certaines valeurs
|
|
du système dépassent un seuil spécifié. Un autre script
|
|
fourni, Virtual Adrian, permet d'affiner les
|
|
performances en tenant compte de ces valeurs.
|
|
</p>
|
|
<p>Depuis sa création, de nombreux propriétaires se sont
|
|
succédés à la tête de la boîte à outils SE, et elle a de
|
|
ce fait largement évolué. Il semble qu'elle ait
|
|
maintenant trouvé sa place chez Sunfreeware.com d'où
|
|
elle peut être téléchargée gratuitement. Il n'y a qu'un
|
|
seul paquet pour Solaris 8, 9 et 10 sur SPARC et x86, et
|
|
il inclut le code source. Le concepteur de la boîte à
|
|
outils SE, Richard Pettit, a fondé une nouvelle sociéte,
|
|
Captive Metrics4, et a l'intention de mettre sur le
|
|
marché un outil de supervision multiplateforme en Java basé sur
|
|
les mêmes principes que la boîte à outils SE.
|
|
</p>
|
|
|
|
|
|
|
|
<h4><a name="dtrace" id="dtrace">DTrace
|
|
</a></h4>
|
|
|
|
<p>Etant donné que DTrace est disponible sous Solaris,
|
|
FreeBSD et OS X, il serait intéressant de l'étudier. Il
|
|
y a aussi le module mod_dtrace pour httpd.
|
|
</p>
|
|
|
|
|
|
|
|
<h4><a name="mod_status" id="mod_status">mod_status
|
|
</a></h4>
|
|
|
|
<p>Le module mod_status donne un aperçu des performances
|
|
du serveur à un instant donné. Il génère une page HTML
|
|
comportant, entre autres, le nombre de processus Apache
|
|
en cours d'exécution avec la quantité de données qu'ils
|
|
ont servies, ainsi que la charge CPU induite par httpd
|
|
et le reste du système. L'Apache Software Foundation
|
|
utilise elle-même <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> pour son
|
|
propre <a href="http://apache.org/server-status">site
|
|
web</a>. Si vous ajoutez une directive
|
|
<code>ExtendedStatus On</code> à votre fichier
|
|
<code>httpd.conf</code>, la page de
|
|
<code class="module"><a href="../mod/mod_status.html">mod_status</a></code> vous fournira d'avantage
|
|
d'informations, au prix d'une consommation de ressources
|
|
légèrement supérieure par requête.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="web-server-log-files" id="web-server-log-files">Les journaux du serveur web
|
|
</a></h3>
|
|
|
|
<p>Le moyen le plus efficace pour vérifier la bonne santé et
|
|
le niveau de performance de votre serveur consiste à
|
|
surveiller et analyser les journaux écrits par httpd. La
|
|
surveillance du journal des erreurs vous permet de
|
|
déterminer les sources d'erreurs, de détecter des attaques
|
|
ou des problèmes de performance. L'analyse du journal des
|
|
accès vous indique le niveau de charge de votre serveur,
|
|
quelles sont les ressources les plus populaires, ainsi que
|
|
la provenance de vos utilisateurs. Une analyse historique des
|
|
données de journalisation peut vous fournir des informations
|
|
précieuses quant aux tendances d'utilisation de votre
|
|
serveur au cours du temps, ce qui vous permet de prévoir les
|
|
périodes où les besoins en performance risquent de dépasser
|
|
les capacités du serveur.
|
|
</p>
|
|
|
|
|
|
<h4><a name="ErrorLog" id="ErrorLog">Journal des erreurs
|
|
</a></h4>
|
|
|
|
<p>Le journal des erreurs peut indiquer que le nombre
|
|
maximum de processus actifs ou de fichiers ouverts
|
|
simultanément a été atteint. Le journal des erreurs
|
|
signele aussi le lancement de processus supplémentaires selon un
|
|
taux supérieur à la normale en réponse à
|
|
une augmentation soudaine de la charge. Lorsque le
|
|
serveur démarre, le descripteur de fichier stderr est
|
|
redirigé vers le journal des erreurs, si bien que toute
|
|
erreur rencontrée par httpd après avoir ouvert ses
|
|
fichiers journaux apparaîtra dans ce journal. Consulter
|
|
fréquemment le journal des erreurs est donc une bonne
|
|
habitude.
|
|
</p>
|
|
<p>Lorsque Apache httpd n'a pas encore ouvert ses
|
|
fichiers journaux, tout message d'erreur sera envoyé
|
|
vers la sortie d'erreur standard stderr. Si vous
|
|
démarrez httpd manuellement, ces messages d'erreur
|
|
apparaîtront sur votre terminal, et vous pourrez les
|
|
utiliser directement pour résoudre les problèmes de
|
|
votre serveur. Si httpd est lancé via un script de
|
|
démarrage, la destination de ces messages d'erreur
|
|
dépend de leur conception.
|
|
<code>/var/log/messages</code> est alors le premier fichier à
|
|
consulter. Sous Windows, ces messages d'erreur précoces
|
|
sont écrits dans le journal des évènements des
|
|
applications, qui peut être visualisé via l'observateur
|
|
d'évènements dans les outils d'administration.
|
|
</p>
|
|
<p>
|
|
Le journal des erreurs est configuré via les
|
|
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
|
|
erreurs de la configuration du serveur principal de
|
|
httpd reçoit les messages d'erreur concernant
|
|
l'ensemble du serveur : démarrage, arrêt, crashes,
|
|
lancement de processus supplémentaires excessif,
|
|
etc... La directive <code class="directive"><a href="../mod/core.html#errorlog">ErrorLog</a></code> peut aussi être
|
|
utilisée dans les blocs de configuration des
|
|
serveurs virtuels. Le journal des erreurs d'un
|
|
serveur virtuel ne reçoit que les messages d'erreur
|
|
spécifiques à ce serveur virtuel, comme les erreurs
|
|
d'authentification et les erreurs du style 'File not
|
|
Found'.
|
|
</p>
|
|
<p>Dans le cas d'un serveur accessible depuis Internet,
|
|
attendez-vous à voir de nombreuses tentatives
|
|
d'exploitation et attaques de vers dans le journal des
|
|
erreurs. La plupart d'entre elles ciblent des serveurs
|
|
autres qu'Apache, mais dans l'état actuel des choses,
|
|
les scripts se contentent d'envoyer leurs attaques vers
|
|
tout port ouvert, sans tenir compte du serveur web
|
|
effectivement en cours d'exécution ou du type
|
|
des applications installées. Vous pouvez bloquer ces
|
|
tentatives d'attaque en utilisant un pare-feu ou le
|
|
module <a href="http://www.modsecurity.org/">mod_security</a>,
|
|
mais ceci dépasse la portée de cette discussion.
|
|
</p>
|
|
<p>
|
|
La directive <code class="directive"><a href="../mod/core.html#loglevel">LogLevel</a></code> permet de définir
|
|
le niveau de détail des messages enregistrés dans
|
|
les journaux. Il existe huit niveaux de
|
|
journalisation :
|
|
</p>
|
|
<table>
|
|
<tr>
|
|
<td>
|
|
<p><strong>Niveau</strong></p>
|
|
</td>
|
|
<td>
|
|
<p><strong>Description</strong></p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>emerg</p>
|
|
</td>
|
|
<td>
|
|
<p>Urgence - le système est inutilisable.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>alert</p>
|
|
</td>
|
|
<td>
|
|
<p>Une action doit être entreprise
|
|
immédiatement.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>crit</p>
|
|
</td>
|
|
<td>
|
|
<p>Situations critiques.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>error</p>
|
|
</td>
|
|
<td>
|
|
<p>Situations d'erreur.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>warn</p>
|
|
</td>
|
|
<td>
|
|
<p>Situations provoquant un avertissement.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>notice</p>
|
|
</td>
|
|
<td>
|
|
<p>Evènement normal, mais important.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>info</p>
|
|
</td>
|
|
<td>
|
|
<p>Informations.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>debug</p>
|
|
</td>
|
|
<td>
|
|
<p>Messages de débogage.</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<p>Le niveau de journalisation par défaut est warn. Un
|
|
serveur en production ne doit pas s'exécuter en mode
|
|
debug, mais augmenter le niveau de détail dans le
|
|
journal des erreurs peut s'avérer utile pour résoudre
|
|
certains problèmes. A partir de la
|
|
version 2.3.8, la directive <code class="directive"><a href="../mod/core.html#loglevel">LogLevel</a></code> peut être définie au
|
|
niveau de chaque module :
|
|
</p>
|
|
|
|
<pre class="prettyprint lang-config">LogLevel debug mod_ssl:warn</pre>
|
|
|
|
|
|
<p>
|
|
Dans cet exemple, l'ensemble du serveur est en mode
|
|
debug, sauf le module <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>
|
|
qui a tendance à être très bavard.
|
|
</p>
|
|
|
|
|
|
|
|
<h4><a name="AccessLog" id="AccessLog">Journal des accès
|
|
</a></h4>
|
|
|
|
<p>Apache httpd garde la trace de toutes les requêtes
|
|
qu'il reçoit dans son journal des accès. En plus de
|
|
l'heure et de la nature d'une requête, httpd peut
|
|
enregistrer l'adresse IP du client, la date et l'heure
|
|
de la requête, le résultat et quantité d'autres
|
|
informations. Les différents formats de journaux sont
|
|
documentés dans le manuel. Le fichier concerne par
|
|
défaut le serveur principal, mais il peut être configuré
|
|
pour chaque serveur virtuel via les directives de
|
|
configuration <code class="directive"><a href="../mod/mod_log_config.html#transferlog">TransferLog</a></code> ou
|
|
<code class="directive"><a href="../mod/mod_log_config.html#customlog">CustomLog</a></code>.
|
|
</p>
|
|
<p>De nombreux programmes libres ou commerciaux
|
|
permettent d'analyser les journaux d'accès. Analog et
|
|
Webalyser sont des programmes d'analyse libres parmi les
|
|
plus populaires. L'analyse des journaux doit s'effectuer
|
|
hors ligne afin de ne pas surcharger le serveur web avec
|
|
le traitement des fichiers journaux. La plupart des
|
|
programmes d'analyse des journaux sont compatibles avec le format
|
|
de journal "Common". Voici une description des
|
|
différents champs présents dans une entrée du journal :
|
|
</p>
|
|
|
|
|
|
<div class="example"><pre>195.54.228.42 - - [24/Mar/2007:23:05:11 -0400] "GET /sander/feed/ HTTP/1.1" 200 9747
|
|
64.34.165.214 - - [24/Mar/2007:23:10:11 -0400] "GET /sander/feed/atom HTTP/1.1" 200 9068
|
|
60.28.164.72 - - [24/Mar/2007:23:11:41 -0400] "GET / HTTP/1.0" 200 618
|
|
85.140.155.56 - - [24/Mar/2007:23:14:12 -0400] "GET /sander/2006/09/27/44/ HTTP/1.1" 200 14172
|
|
85.140.155.56 - - [24/Mar/2007:23:14:15 -0400] "GET /sander/2006/09/21/gore-tax-pollution/ HTTP/1.1" 200 15147
|
|
74.6.72.187 - - [24/Mar/2007:23:18:11 -0400] "GET /sander/2006/09/27/44/ HTTP/1.0" 200 14172
|
|
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>
|
|
|
|
<table>
|
|
<tr>
|
|
<td>
|
|
<p><strong>Champ</strong></p>
|
|
</td>
|
|
<td>
|
|
<p><strong>Contenu</strong></p>
|
|
</td>
|
|
<td>
|
|
<p><strong>Explication</strong></p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>Adresse IP client</p>
|
|
</td>
|
|
<td>
|
|
<p>195.54.228.42</p>
|
|
</td>
|
|
<td>
|
|
<p>Adresse IP d'où provient la requête</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>Identité RFC 1413</p>
|
|
</td>
|
|
<td>
|
|
<p>-</p>
|
|
</td>
|
|
<td>
|
|
<p>Identité de l'utilisateur distant renvoyée
|
|
par son démon identd</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>Nom utilisateur</p>
|
|
</td>
|
|
<td>
|
|
<p>-</p>
|
|
</td>
|
|
<td>
|
|
<p>Nom de l'utilisateur distant issu de
|
|
l'authentification Apache</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>Horodatage</p>
|
|
</td>
|
|
<td>
|
|
<p>[24/Mar/2007:23:05:11 -0400]</p>
|
|
</td>
|
|
<td>
|
|
<p>Date et heure de la requête</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>Requête</p>
|
|
</td>
|
|
<td>
|
|
<p>"GET /sander/feed/ HTTP/1.1"</p>
|
|
</td>
|
|
<td>
|
|
<p>La requête proprement dite</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>Code d'état</p>
|
|
</td>
|
|
<td>
|
|
<p>200</p>
|
|
</td>
|
|
<td>
|
|
<p>Code d'état renvoyé avec la réponse</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<p>Contenu en octets</p>
|
|
</td>
|
|
<td>
|
|
<p>9747</p>
|
|
</td>
|
|
<td>
|
|
<p>Total des octets transférés sans les
|
|
en-têtes</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
|
|
<h4><a name="rotating-log-files" id="rotating-log-files">Rotation des fichiers journaux
|
|
</a></h4>
|
|
|
|
<p>Il y a de nombreuses raisons pour mettre en oeuvre la
|
|
rotation des fichiers journaux. Même si pratiquement
|
|
plus aucun système d'exploitation n'impose une limite de
|
|
taille pour les fichiers de deux GigaOctets, avec le
|
|
temps, les fichiers journaux deviennent trop gros pour
|
|
pouvoir être traités. En outre, toute analyse de journal
|
|
ne doit pas être effectuée sur un fichier dans lequel le
|
|
serveur est en train d'écrire. Une rotation périodique
|
|
des fichiers journaux permet de faciliter leur analyse,
|
|
et de se faire une idée plus précise des habitudes
|
|
d'utilisation.
|
|
</p>
|
|
<p>Sur les systèmes unix, vous pouvez simplement
|
|
effectuer cette rotation en changeant le nom du fichier
|
|
journal via la commande mv. Le serveur continuera à
|
|
écrire dans le fichier ouvert même s'il a changé de nom.
|
|
Lorsque vous enverrez un signal de redémarrage
|
|
"Graceful" au serveur, il ouvrira un nouveau fichier
|
|
journal avec le nom configuré par défaut. Par exemple,
|
|
vous pouvez écrire un script de ce style pour cron :
|
|
</p>
|
|
|
|
|
|
<div class="example"><p><code>
|
|
APACHE=/usr/local/apache2<br />
|
|
HTTPD=$APACHE/bin/httpd<br />
|
|
mv $APACHE/logs/access_log
|
|
$APACHE/logarchive/access_log-`date +%F`<br />
|
|
$HTTPD -k graceful
|
|
</code></p></div>
|
|
|
|
<p>Cette approche fonctionne aussi sous Windows, mais
|
|
avec moins de souplesse. Alors que le processus httpd de
|
|
votre serveur sous Windows continuera à écrire dans le
|
|
fichier journal une fois ce dernier renommé, le service
|
|
Windows qui exécute Apache n'est pas en mesure
|
|
d'effectuer un redémarrage graceful. Sous Windows, le
|
|
redémarrage d'un service consiste simplement à l'arrêter
|
|
et à le démarrer à nouveau, alors qu'avec un redémarrage
|
|
graceful, les processus enfants terminent
|
|
le traitement des requêtes en cours avant de s'arrêter,
|
|
et le serveur httpd est alors immédiatement à
|
|
nouveau disponible pour traiter les nouvelles requêtes.
|
|
Sous Windows, le processus d'arrêt/redémarrage du
|
|
service interrompt les traitements de requêtes en cours,
|
|
et le serveur demeure indisponible jusqu'à ce qu'il ait
|
|
terminé son redémarrage. Vous devez donc tenir compte de
|
|
toutes ces contraintes lorsque vous planifiez un
|
|
redémarrage.
|
|
</p>
|
|
<p>
|
|
Une seconde approche consiste à utiliser la
|
|
redirection des logs. Les directives <code class="directive"><a href="../mod/mod_log_config.html#customlog">CustomLog</a></code>,
|
|
<code class="directive"><a href="../mod/mod_log_config.html#transferlog">TransferLog</a></code> ou
|
|
<code class="directive"><a href="../mod/core.html#errorlog">ErrorLog</a></code>
|
|
permettent de rediriger les données de journalisation
|
|
vers tout programme via le caractère pipe
|
|
(<code>|</code>) comme dans cet exemple :
|
|
</p>
|
|
|
|
<div class="example"><p><code>CustomLog "|/usr/local/apache2/bin/rotatelogs
|
|
/var/log/access_log 86400" common
|
|
</code></p></div>
|
|
|
|
<p>Le programme cible de la redirection recevra alors les
|
|
données de journalisation d'Apache sur son entrée
|
|
standard stdin, et pourra en faire ce qu'il voudra. Le
|
|
programme rotatelogs fourni avec Apache effectue une
|
|
rotation des journaux de manière transparente en
|
|
fonction du temps ou de la quantité de données écrites,
|
|
et archive l'ancien fichier journal en ajoutant un
|
|
suffixe d'horodatage à son nom. Cependant, si cette
|
|
méthode fonctionne de manière satisfaisante sur les
|
|
plateformes de style unix, il n'en est pas de même sous
|
|
Windows.
|
|
</p>
|
|
|
|
|
|
|
|
<h4><a name="logging-and-performance" id="logging-and-performance">Journalisation et performances
|
|
</a></h4>
|
|
|
|
<p>L'écriture d'entrées dans les fichiers journaux est
|
|
consommatrice de ressources, mais l'importance de ces
|
|
données est telle qu'il est fortement déconseillé de
|
|
désactiver la journalisation. Pour optimiser les
|
|
performances, vous devez enregistrer vos journaux sur un
|
|
disque physique différent de celui où se situe votre
|
|
site web car les modes d'accès sont très différents. La
|
|
lecture de données sur un disque possède un caractère
|
|
essentiellement aléatoire, alors que l'écriture dans les
|
|
fichiers journaux s'effectue de manière séquentielle.
|
|
</p>
|
|
<p>
|
|
Ne définissez jamais la directive <code class="directive"><a href="../mod/core.html#loglevel">LogLevel</a></code> à debug pour un
|
|
serveur en production. En effet, lorsque ce niveau de
|
|
journalisation est défini, une grande quantité de
|
|
données est écrite dans le journal des erreurs, y
|
|
compris, dans le cas d'un accès SSL, toutes les
|
|
opérations de lecture/écriture de la négociation de la
|
|
connexion. Les implications en matière de performances
|
|
sont donc importantes et vous devez plutôt utiliser le
|
|
niveau de journalisation warn.
|
|
</p>
|
|
<p>Si votre serveur possède plus d'un serveur virtuel,
|
|
il est conseillé d'attribuer un journal des accès séparé à
|
|
chacun d'entre eux, ce qui a pour effet de faciliter son
|
|
exploitation ultérieure. Par contre, si votre serveur
|
|
possède un grand nombre de serveurs virtuels, le nombre
|
|
de fichiers journaux à ouvrir va représenter une
|
|
consommation de ressources importante pour votre
|
|
système, et il sera peut-être alors plus judicieux
|
|
d'utiliser un seul fichier journal avec l'aménagement
|
|
suivant : utiliser l'élément de format <code>%v</code>
|
|
en tête de votre directive <code class="directive"><a href="../mod/mod_log_config.html#logformat">LogFormat</a></code> (et de
|
|
votre directive <code class="directive"><a href="../mod/core.html#errorlog">ErrorLog</a></code> depuis la version
|
|
2.3.8) afin que httpd enregistre le nom du serveur
|
|
virtuel qui traite la requête ou l'erreur au début de
|
|
chaque entrée du journal. Un simple script Perl peut
|
|
alors éclater le journal en fichiers spécifiques à
|
|
chaque serveur virtuel après sa rotation ; Apache
|
|
fournit un tel script dans le répertoire
|
|
<code>support/split-logfile</code>.
|
|
</p>
|
|
<p>
|
|
Vous pouvez aussi utiliser la directive <code class="directive"><a href="../mod/mod_log_config.html#bufferedlogs">BufferedLogs</a></code>
|
|
pour qu'Apache conserve en mémoire plusieurs entrées
|
|
de journal avant de les écrire sur disque. Gardez
|
|
cependant à l'esprit que si les performances peuvent
|
|
s'en trouver améliorées, la chronologie des
|
|
évènements enregistrés peut quant à elle s'en
|
|
trouver affectée.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="generating-a-test-load" id="generating-a-test-load">Mise en oeuvre d'une charge de test
|
|
</a></h3>
|
|
|
|
<p>Il est interessant de mettre en oeuvre une charge de test
|
|
afin d'évaluer les performances du système en conditions
|
|
réelles de fonctionnement. A cet effet, il existe des
|
|
paquets commerciaux comme <a href="http://learnloadrunner.com/">LoadRunner</a>, mais
|
|
aussi de nombreux outils libres permettant de générer une
|
|
charge de test pour votre serveur web.
|
|
</p>
|
|
<ul>
|
|
<li>Apache est fourni avec un programme de test nommé ab
|
|
(initiales de Apache Bench). Ce dernier peut générer une
|
|
charge de serveur web consistant à demander le même
|
|
fichier de manière répétitive à un rythme rapide. Vous
|
|
pouvez spécifier le nombre de connexions simultanées, et
|
|
choisir entre une durée de fonctionnement ou un nombre
|
|
de requêtes.
|
|
</li>
|
|
<li>http load11 est un autre exemple de générateur de
|
|
charge libre. Ce programme fonctionne avec un ficher
|
|
d'URLs et peut être compilé avec le support SSL.
|
|
</li>
|
|
<li>L'Apache Software Foundation propose un outil nommé
|
|
flood12. Flood est un programme assez sophistiqué que
|
|
l'on configure via un fichier XML.
|
|
</li>
|
|
<li>Pour finir, JMeter13, un sous-projet de Jakarta, est
|
|
un outil de test en charge entièrement en Java. Alors
|
|
que les premières versions de cette application étaient
|
|
lentes et difficiles d'utilisation, la version 2.1.1
|
|
actuelle semble être plus souple d'utilisation et
|
|
efficace.
|
|
</li>
|
|
<li>
|
|
<p>Des projets externes à l'ASF et réputés
|
|
relativement corrects : grinder, httperf, tsung, <a href="http://funkload.nuxeo.org/">FunkLoad</a>.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<p>Lorsque vous appliquez une charge de test à votre serveur
|
|
web, gardez à l'esprit que si ce dernier est en production,
|
|
la charge de test peut en affecter négativement les
|
|
performances. En outre, le transfert de données
|
|
supplémentaires induit peut être comptabilisé dans le
|
|
quota mensuel qui vous a été éventuellement alloué.
|
|
</p>
|
|
|
|
|
|
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="configuring-for-performance" id="configuring-for-performance">Configuration dans une optique de performances
|
|
</a><a title="Lien permanent" href="#configuring-for-performance" class="permalink">¶</a></h2>
|
|
|
|
|
|
|
|
<h3><a name="apache-configuration" id="apache-configuration">Configuration de httpd
|
|
</a></h3>
|
|
|
|
<p>httpd version 2.2 est par défaut un serveur web avec des
|
|
processus enfants lancés au préalable. Au démarrage du
|
|
serveur, le processus parent lance un certain nombre de
|
|
processus enfants et ce sont eux qui seront chargés de traiter les
|
|
requêtes. Mais avec httpd version 2.0 est apparu le concept
|
|
de module multi-process (MPM). Les développeurs purent alors
|
|
écrire des MPMs qui pouvaient fonctionner avec l'architecture
|
|
à base de processus ou de threads de leur système
|
|
d'exploitation spécifique. Apache 2 est fourni avec des MPMs
|
|
spécifiques pour Windows, OS/2, Netware et BeOS. Pour les
|
|
plateformes de style unix, les deux MPMS les plus connus
|
|
sont Prefork et Worker. Le MPM Prefork offre le même modèle
|
|
de processus enfants prélancés que celui d'Apache 1.3. Le
|
|
MPM Worker quant à lui, lance un nombre de processus enfants
|
|
moins important, mais attribue à chacun d'entre eux un
|
|
certain nombre de threads pour traiter les requêtes. Avec la
|
|
version 2.4, le MPM n'est plus défini à la compilation,
|
|
mais peut être chargé à l'exécution via la directive
|
|
<code class="directive"><a href="../mod/core.html#loadmodule">LoadModule</a></code>. Le MPM par
|
|
défaut pour la version 2.4 est le MPM event.
|
|
</p>
|
|
<p>Le nombre maximum de process, à savoir le nombre de processus
|
|
enfants prélancés et/ou de threads, donne une approximation
|
|
du nombre de requêtes que votre serveur peut traiter
|
|
simultanément. Ce n'est cependant qu'une estimation car le
|
|
noyau peut mettre en file d'attente des tentatives de
|
|
connexion à votre serveur. Lorsque votre site approche de la
|
|
saturation et si le nombre maximum de process est atteint, la
|
|
machine n'impose pas de limite absolue au
|
|
delà de laquelle les clients se verront refuser l'accès.
|
|
Cependant, lorsque les requêtes commencent à être mises en
|
|
file d'attente, les performances du système se dégradent
|
|
rapidement.
|
|
</p>
|
|
<p>Enfin, si le serveur httpd en question n'exécute aucun
|
|
code tiers via <code>mod_php</code>, <code>mod_perl</code>,
|
|
etc..., nous recommandons l'utilisation de
|
|
<code class="module">mpm_event</code>. Ce MPM est idéal pour les
|
|
situations où httpd sert d'intermédiaire entre les clients
|
|
et des serveurs d'arrière-plan qui accomplissent le travail
|
|
proprement dit (par exemple en mode mandataire ou cache).
|
|
</p>
|
|
|
|
|
|
<h4><a name="MaxClients" id="MaxClients">MaxClients
|
|
</a></h4>
|
|
|
|
<p>La directive <code>MaxClients</code> permet de
|
|
spécifier le nombre maximum de process que votre serveur
|
|
pourra créer. Deux autres directives lui sont associées
|
|
: <code>MinSpareServers</code> et
|
|
<code>MaxSpareServers</code>, qui permettent d'encadrer
|
|
le nombre de process que httpd garde en réserve pour
|
|
traiter les requêtes. Le nombre total de process que
|
|
httpd peut créer peut
|
|
être défini via la directive <code>ServerLimit</code>.
|
|
</p>
|
|
|
|
|
|
|
|
<h4><a name="spinning-threads" id="spinning-threads">Rotation des threads
|
|
</a></h4>
|
|
|
|
<p>Les directives ci-dessus suffisent pour définir les
|
|
limites des nombres de process dans le cas du MPM Prefork.
|
|
Cependant, si vous utilisez un MPM à base de threads, la
|
|
situation est un peu plus compliquée. Les MPMs à base de
|
|
threads supportent la directive
|
|
<code>ThreadsPerChild</code>. httpd impose le fait que
|
|
<code>MaxClients</code> doit être divisible par
|
|
<code>ThreadsPerChild</code>. Si les valeurs que vous
|
|
attribuez à ces deux directives ne respectent pas cette
|
|
règle, httpd affichera un message d'erreur et corrigera
|
|
la valeur de la directive <code>ThreadsPerChild</code>
|
|
en la diminuant jusqu'à ce que la valeur de la directive
|
|
<code>MaxClients</code> soit divisible par elle.
|
|
</p>
|
|
|
|
|
|
|
|
<h4><a name="sizing-maxClients" id="sizing-maxClients">Choix de la valeur de MaxClients
|
|
</a></h4>
|
|
|
|
<p>Idéalement, le nombre maximum de processus devrait
|
|
être choisi de façon à ce que toute la mémoire système
|
|
soit utilisée, sans la dépasser. En effet, si votre
|
|
système est surchargé au point de devoir faire appel de
|
|
manière intensive au swap (utilisation de la mémoire
|
|
disque), les performances vont se dégrader rapidement.
|
|
La formule permettant de déterminer la valeur de
|
|
<code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxClients</a></code>
|
|
est assez simple :
|
|
</p>
|
|
|
|
<div class="example"><p><code>
|
|
MaxClients = (RAM totale − RAM système − RAM pour
|
|
les programmes externes) divisé par la RAM nécessaire pour
|
|
chaque processus enfant.
|
|
</code></p></div>
|
|
|
|
<p>L'observation est la meilleure manière de déterminer
|
|
les différentes quantités de mémoire allouées au
|
|
système, aux programmes externes et aux processus httpd
|
|
: à cet effet, vous pouvez utiliser les commandes top et
|
|
free décrites plus haut pour étudier l'empreinte mémoire
|
|
du système lorsque le serveur web n'est pas en cours
|
|
d'exécution. Vous pouvez aussi étudier l'empreinte d'un
|
|
processus type du serveur web via la commande top ; en
|
|
effet, la plupart des implémentations de cette commande
|
|
présentent une colonne Mémoire résidente (RSS - Resident
|
|
Size) et Mémoire partagée (Shared Memory).
|
|
</p>
|
|
<p>La différence entre ces deux colonnes est la
|
|
quantité de mémoire par processus. Le segment de mémoire
|
|
partagée n'existe effectivement qu'une seule fois, et
|
|
est utilisé par le code et les bibliothèques chargées et
|
|
la concurrence inter-processus (ou tableau de résultat -
|
|
scoreboard) géré par Apache. La quantité de mémoire
|
|
utilisée par chaque processus dépend fortement du nombre
|
|
et du type de modules utilisés. La meilleure façon d'en
|
|
déterminer les besoins consiste à générer une charge
|
|
type pour votre site web et à observer l'importance que
|
|
prennent les processus httpd.
|
|
</p>
|
|
<p>La RAM pour les programmes externes comprend
|
|
principalement la mémoire utilisée pour les programmes
|
|
CGI et les scripts qui s'exécutent indépendamment des
|
|
processus httpd. Par contre, si vous utilisez une
|
|
machine virtuelle Java qui exécute Tomcat sur le même
|
|
serveur, cette dernière va aussi nécessiter une quantité
|
|
de mémoire significative. En conséquence, la formule
|
|
ci-dessus qui sert à calculer la valeur maximale de
|
|
<code>MaxClients</code> permet d'effectuer une première approche,
|
|
mais ne constitue en aucun cas une science exacte. En
|
|
cas de doute, soyez pragmatique et utilisez une valeur assez
|
|
basse pour <code>MaxClients</code>. Le noyau Linux
|
|
réserve une certaine quantité de mémoire pour la mise en
|
|
cache des accès disque. Sous Solaris par contre, il faut disposer
|
|
de suffisamment de mémoire RAM pour créer un processus,
|
|
et si ce n'est pas le cas, httpd va démarrer avec un
|
|
message d'erreur du style "No space left on device" dans
|
|
le journal des erreurs, et sera incapable de créer
|
|
d'autres processus httpd enfants ; une valeur trop
|
|
élevée pour <code>MaxClients</code> constituera alors
|
|
réellement un désavantage.
|
|
</p>
|
|
|
|
|
|
<h4><a name="selecting-your-mpm" id="selecting-your-mpm">Choisir votre MPM
|
|
</a></h4>
|
|
|
|
<p>La commutation entre threads est plus
|
|
aisée pour le système, et ceux-ci consomment moins de
|
|
ressources que les processus ; c'est la raison
|
|
principale pour laquelle il est recommandé de choisir un
|
|
MPM threadé. Et
|
|
ceci est encore plus flagrant pour certains systèmes
|
|
d'exploitation que pour d'autres. Par exemple, sous
|
|
Solaris ou AIX, la manipulation des processus est assez
|
|
lourde en termes de ressources système ; l'utilisation
|
|
d'un MPM threadé est donc tout à fait indiquée pour ces
|
|
systèmes. Sous Linux en revanche, l'implémentation des
|
|
threads utilise en fait un processus par thread. Les
|
|
processus Linux sont assez légers, mais cela signifie qu'un
|
|
MPM threadé présentera ici un gain en performance
|
|
moindre que sous d'autres systèmes.
|
|
</p>
|
|
<p>Dans certaines situations cependant, l'utilisation
|
|
d'un MPM threadé peut induire des problèmes de
|
|
stabilité. Par exemple, si un processus enfant du MPM
|
|
prefork se crashe, au plus une connexion client sera
|
|
affectée ; par contre, si un processus enfant threadé se
|
|
crashe, ce sont tous les threads de ce processus qui
|
|
vont se crasher à leur tour, ce qui signifie que tous
|
|
les clients qui étaient servis par ce processus verront
|
|
leur connexion interrompue. De plus, certains problèmes
|
|
de sécurité des threads ("thread-safety")
|
|
peuvent apparaître, particulièrement avec les
|
|
bibliothèques tierces. Avec les applications threadées,
|
|
les différents threads peuvent avoir accès aux mêmes
|
|
variables sans distinction, sans savoir si une variable
|
|
n'a pas été modifiée par un autre thread.
|
|
</p>
|
|
<p>Ce problème a fait l'objet d'un point sensible au
|
|
sein de la communauté PHP car Le processeur PHP repose
|
|
fortement sur des bibliothèques tierces, et il n'est pas
|
|
garanti que la totalité d'entre elles soient
|
|
"thread-safe". Bonne nouvelle cependant : si vous
|
|
exécutez Apache sous Linux, vous pouvez utiliser PHP
|
|
avec le MPM prefork sans craindre une diminution de
|
|
performance trop importante par rapport à une option
|
|
threadée.
|
|
</p>
|
|
|
|
|
|
|
|
<h4><a name="spinning-locks" id="spinning-locks">Verrous tournants</a></h4>
|
|
|
|
<p>Apache httpd maintient un verrou inter-processus du
|
|
point de vue de son écoute du réseau. Dans les faits,
|
|
cela signifie qu'un seul processus httpd enfant à la
|
|
fois peut recevoir une requête. Ainsi, soient les autres
|
|
processus en profitent alors pour traiter les requêtes
|
|
qu'ils ont déjà reçues, soient ils attendent de pouvoir
|
|
à leur tour récupérer le verrou et ainsi écouter le
|
|
réseau pour recevoir une nouvelle requête. Ceci peut se
|
|
voir comme une porte tournante par laquelle un seul
|
|
processus peut passer à la fois. Sur un serveur web
|
|
fortement chargé où les requêtes arrivent constamment,
|
|
la porte tourne rapidement et les requêtes sont
|
|
acceptées à un rythme soutenu. Sur un serveur faiblement
|
|
chargé en revanche, le processus qui "détient"
|
|
le verrou est suceptible de garder sa porte ouverte un
|
|
certain temps durant lequel tous les autres processus
|
|
seront inactifs, attendant de pouvoir s'approprier le
|
|
verrou. Dans une telle situation, le processus parent
|
|
pourra décider d'arrêter quelques processus enfants en
|
|
fonction de la valeur de la directive
|
|
<code>MaxSpareServers</code>.</p>
|
|
|
|
|
|
<h4><a name="the-thundering-herd" id="the-thundering-herd">L'assaut de la foule
|
|
</a></h4>
|
|
|
|
<p>La fonction de l'"accept mutex" (c'est le nom donné au
|
|
verrou inter-processus) consiste à gérer la réception
|
|
des requêtes de manière ordonnée. Si ce verrou est
|
|
absent, le syndrome de l'"assaut de la foule" peut
|
|
apparaître.
|
|
</p>
|
|
<p>Imaginez une équipe de football américain en attente
|
|
devant la ligne de remise en jeu. Si les joueurs se
|
|
comportaient comme des processus Apache, ils se
|
|
précipiteraient tous à la fois pour récupérer la balle au
|
|
signal de la reprise. Un seul d'entre eux y
|
|
parviendrait, et tous les autres n'auraient plus qu'à se
|
|
regrouper à nouveau sur la ligne jusqu'à la reprise
|
|
suivante. Dans cette métaphore, c'est le quaterback qui
|
|
va jouer le rôle d'"accept mutex" en donnant la balle
|
|
au joueur approprié.
|
|
</p>
|
|
<p>La transmission d'une telle quantité d'informations
|
|
représente naturellement beaucoup de travail et, comme
|
|
une personne intelligente, un serveur intelligent
|
|
tentera d'éviter cette surcharge dans la mesure du
|
|
possible, d'où l'idée de la porte tournante. Dans les
|
|
dernières années, de nombreux systèmes d'exploitation,
|
|
comme Linux et Solaris, ont développé du code pour
|
|
éviter le syndrome de l'"assaut de la foule". Apache
|
|
reconnaît ce code, et si vous n'effectuez qu'une seule
|
|
écoute du réseau, autrement dit si vous n'utilisez que
|
|
le serveur principal ou un seul serveur virtuel, Apache
|
|
n'utilisera pas d'"accept mutex" ; par contre, si vous
|
|
effectuez plusieurs écoutes du réseau (par exemple si
|
|
un serveur virtuel sert les requêtes SSL), Apache
|
|
utilisera un "accept mutex" afin d'éviter les conflits
|
|
internes.
|
|
</p>
|
|
<p>Vous pouvez manipuler l'"accept mutex" via la
|
|
directive <code>AcceptMutex</code>. Cette dernière
|
|
permet en particulier de fermer l'"accept mutex", mais
|
|
aussi de sélectionner le mécanisme de verrouillage. Les
|
|
mécanismes de verrouillage courants comprennent fcntl,
|
|
les sémaphores System V et le verrouillage par threads.
|
|
Tous ne sont pas supportés par toutes les plateformes,
|
|
et leur disponibilité dépend aussi des options de
|
|
compilation. Les différents mécanismes de verrouillage
|
|
peuvent avoir des exigences particulières en matière de
|
|
ressources système ; il est donc recommandé de les
|
|
utiliser avec précautions.
|
|
</p>
|
|
<p>Il n'existe aucune raison particulière pour
|
|
désactiver l'"accept mutex". Apache détermine
|
|
automatiquement s'il doit utiliser ou non mutex sur
|
|
votre plateforme en fonction du nombre d'écoutes réseau
|
|
de votre serveur, comme décrit précédemment.
|
|
</p>
|
|
|
|
|
|
|
|
<h3><a name="tuning-the-operating-system" id="tuning-the-operating-system">Optimisation du système d'exploitation
|
|
</a></h3>
|
|
|
|
<p>Souvent, les utilisateurs recherchent le paramètre magique qui va
|
|
multiplier par quatre les performances de leur système. En
|
|
fait, les systèmes de type Unix actuels sont déjà optimisés
|
|
à l'origine, et il n'y a plus grand chose à faire pour
|
|
améliorer leurs performances. L'administrateur peut
|
|
cependant encore effectuer quelques modifications qui
|
|
permettront de peaufiner la configuration.
|
|
</p>
|
|
|
|
|
|
<h4><a name="ram-and-swap-space" id="ram-and-swap-space">RAM et swap
|
|
</a></h4>
|
|
|
|
<p>Le leitmotiv en matière de mémoire est souvent "plus
|
|
on en a, mieux c'est". En effet, comme nous avons dit
|
|
plus haut, la mémoire inutilisée peut être
|
|
avantageusement utilisée comme cache du système de
|
|
fichiers. Plus vous chargez de modules, plus les processus
|
|
Apache grossissent, et ceci d'autant plus si vous
|
|
utilisez des modules qui génèrent des contenus
|
|
dynamiques comme PHP et mod_perl. Un gros fichier de
|
|
configuration - avec de nombreux serveurs virtuels - a
|
|
aussi tendance à augmenter l'empreinte mémoire des
|
|
processus. Une quantité de mémoire importante vous
|
|
permettra d'exécuter Apache avec plus de processus
|
|
enfants, et donc de traiter d'avantage de requêtes
|
|
simultanément.
|
|
</p>
|
|
<p>Même si les différentes plateformes traitent leur
|
|
mémoire virtuelle de différentes manières, il est
|
|
déconseillé de configurer un espace disque de swap
|
|
inférieur à la mémoire RAM. En effet, le système de mémoire
|
|
virtuelle a été conçu de manière à prendre le relai
|
|
lorsque la mémoire RAM fait défaut, et lorsque l'espace
|
|
disque, et donc l'espace de swap vient à manquer, votre
|
|
serveur risque de s'arrêter. Vous devrez alors
|
|
redémarrer physiquement votre serveur, et votre
|
|
hébergeur pourra vous facturer le service.
|
|
</p>
|
|
<p>Evidemment, ce genre problème survient au moment le
|
|
plus défavorable : lorsque le monde vient découvrir votre
|
|
site web et se présente avec insistance à votre porte.
|
|
Si votre espace de swap est suffisant, même si la
|
|
machine sera de plus en plus surchargée et deviendra
|
|
très très lente car le système devra swapper les pages
|
|
entre la mémoire et le disque, lorsque la charge diminuera à
|
|
nouveau, le système reviendra dans son mode de
|
|
fonctionnement normal. Rappelez-vous que vous disposez
|
|
de la directive <code>MaxClients</code> pour garder le contrôle.
|
|
</p>
|
|
<p>La plupart des systèmes de type Unix utilisent des
|
|
partitions dédiées au swap. Au démarrage du système,
|
|
celui-ci enregistre toutes les partitions de swap du ou
|
|
des disques en fonction du type de la partition ou du
|
|
contenu du fichier <code>/etc/fstab</code> et les
|
|
active de manière automatique. Lorsque vous ajoutez un
|
|
disque, ou lorsque vous installez le système
|
|
d'exploitation, assurez-vous d'allouer suffisamment
|
|
d'espace de swap afin de rester en adéquation avec une
|
|
éventuelle augmentation de la mémoire RAM. La
|
|
réallocation d'espace disque sur un système en
|
|
production est en effet pénible et fastidieuse.
|
|
</p>
|
|
<p>Prévoyez un espace de swap de deux fois la taille de
|
|
votre mémoire RAM, et même jusqu'à quatre fois lorsque
|
|
les surcharges peuvent s'avérer fréquentes. Assurez-vous
|
|
de réajuster ces valeurs lorsque vous augmentez la
|
|
quantité de mémoire RAM de votre système. En secours,
|
|
vous pouvez aussi utilisez un fichier comme espace de
|
|
swap. Pour ce faire, vous trouverez les instructions
|
|
dans les pages de manuel de <code>mkswap</code> et
|
|
<code>swapon</code>, ou dans celles des programmes de
|
|
<code>swap</code>.
|
|
</p>
|
|
|
|
|
|
|
|
<h4><a name="ulimit-files-and-processes" id="ulimit-files-and-processes">ulimit: fichiers et processus
|
|
</a></h4>
|
|
|
|
<p>Supposons que vous disposiez d'une machine possédant
|
|
une énorme quantité de mémoire RAM et un processeur aux
|
|
performances astronomiques ; vous pourrez alors exécuter
|
|
des centaines de processus Apache selon vos besoins,
|
|
mais tout en restant en deçà des limites imposées par le
|
|
noyau de votre système.
|
|
</p>
|
|
<p>Considérez maintenant une situation où plusieurs
|
|
centaines de serveurs web sont en cours d'exécution ; si
|
|
certains d'entre eux doivent à leur tour lancer des
|
|
processus CGI, le nombre maximum de processus autorisé
|
|
par le noyau sera vite atteint.
|
|
</p>
|
|
<p>Dans ce cas, vous pouvez modifier cette limite avec
|
|
la commande :
|
|
</p>
|
|
|
|
<div class="example"><p><code>
|
|
ulimit [-H|-S] -u [nouvelle valeur]
|
|
</code></p></div>
|
|
|
|
<p>Cette modification doit être effectuée avant le
|
|
démarrage du serveur, car la nouvelle valeur ne sera
|
|
prise en compte que dans le shell courant et pour les
|
|
programmes lancés depuis ce dernier. Dans les derniers
|
|
noyaux Linux, la valeur par défaut a été fixée à 2048.
|
|
Sous FreeBSD, ce nombre semble être limité à la valeur
|
|
inhabituelle de 513. Dans le shell par défaut de ce
|
|
système, <code>csh</code>, la commande équivalente est
|
|
<code>limit</code> et possède une syntaxe analogue à
|
|
celle de la commande de style Bourne <code>ulimit</code> :
|
|
</p>
|
|
|
|
<div class="example"><p><code>
|
|
limit [-h] maxproc [newvalue]
|
|
</code></p></div>
|
|
|
|
<p>En outre, le noyau peut limiter le nombre de fichiers
|
|
ouverts par processus. Ce n'est généralement pas un
|
|
problème pour les serveurs dont les processus sont lancés
|
|
à l'avance, et où chacun de ceux-ci ne traite qu'une
|
|
requête à la fois. Les processus des serveurs threadés,
|
|
quant à eux, traitent plusieurs requêtes simultanément,
|
|
et sont d'avantage susceptibles de dépasser la limite du
|
|
nombre de descripteurs de fichiers. Vous pouvez alors
|
|
augmenter cette valeur limite du nombre de fichiers
|
|
ouverts avec la commande :
|
|
</p>
|
|
|
|
<div class="example"><p><code>ulimit -n [newvalue]
|
|
</code></p></div>
|
|
|
|
<p>Là encore, cette modification doit être effectuée
|
|
avant le démarrage du serveur Apache.
|
|
</p>
|
|
|
|
|
|
|
|
<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
|
|
groupe au démarrage du système
|
|
</a></h4>
|
|
|
|
<p>Sous Linux, vous pouvez définir les paramètres de
|
|
ulimit au démarrage en éditant le fichier
|
|
<code>/etc/security/limits.conf</code>. Ce fichier vous
|
|
permet de définir des limites "soft" et "hard"
|
|
en fonction de l'utilisateur ou du groupe ;
|
|
vous y trouverez aussi des commentaires explicatifs des
|
|
différentes options. Pour que ce fichier soit pris en
|
|
compte, le fichier <code>/etc/pam.d/login</code> doit
|
|
contenir la ligne :
|
|
</p>
|
|
|
|
<div class="example"><p><code>session required /lib/security/pam_limits.so
|
|
</code></p></div>
|
|
|
|
<p>Chaque item peut posséder une valeur "soft" et
|
|
"hard" : la première est la valeur
|
|
par défaut, et la seconde la valeur maximale de cet
|
|
item.
|
|
</p>
|
|
<p>Dans le fichier <code>/etc/login.conf</code> de
|
|
FreeBSD, ces valeurs peuvent être limitées ou étendues à
|
|
tout le système de manière analogue au fichier
|
|
<code>limits.conf</code>. Les limites "soft" sont
|
|
spécifiées via le paramètre <code>-cur</code>, et les
|
|
limites "hard" via le paramètre <code>-max</code>.
|
|
</p>
|
|
<p>Solaris possède un mécanisme similaire pour manipuler
|
|
les valeurs limites au démarrage du système : dans le
|
|
fichier <code>/etc/system</code>, vous pouvez définir au
|
|
démarrage des paramètres du noyau valables pour
|
|
l'ensemble du système. Ce sont les mêmes paramètres que
|
|
ceux définis à l'exécution par le débogueur de noyau
|
|
<code>mdb</code>. Les commandes équivalentes à ulimit -u
|
|
pour définir les limites hard et soft seront du style :
|
|
</p>
|
|
|
|
<div class="example"><p><code>
|
|
set rlim_fd_max=65536<br />
|
|
set rlim_fd_cur=2048
|
|
</code></p></div>
|
|
|
|
<p>Solaris calcule le nombre maximal de processus
|
|
autorisé par utilisateur (<code>maxuprc</code>) en
|
|
fonction de la mémoire système disponible
|
|
(<code>maxusers</code>). Vous pouvez obtenir ces valeurs
|
|
avec la commande :
|
|
</p>
|
|
|
|
<div class="example"><p><code>sysdef -i | grep maximum
|
|
</code></p></div>
|
|
|
|
<p>Il est cependant déconseillé de les modifier.
|
|
</p>
|
|
|
|
|
|
|
|
<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
|
|
</a></h4>
|
|
|
|
<p>Dans la plupart des distributions Unix et Linux, de
|
|
nombreux services sont activés par défaut, et vous n'
|
|
avez probablement besoin que d'une minorité d'entre eux.
|
|
Par exemple, votre serveur web n'a pas besoin de
|
|
sendmail, de fournir le service NFS, etc... Désactivez
|
|
les tout simplement.
|
|
</p>
|
|
<p>Pour ce faire, sous RedHat Linux, vous
|
|
disposez de l'utilitaire chkconfig en ligne de commande.
|
|
Sous Solaris, les commandes <code>svcs</code> et
|
|
<code>svcadm</code> vous permettent respectivement
|
|
de lister les services activés et de désactiver ceux
|
|
dont vous n'avez pas besoin.
|
|
</p>
|
|
<p>Vous devez aussi prêter attention aux modules Apache
|
|
chargés par défaut. La plupart des distributions binaires
|
|
d'Apache httpd et des versions préinstallées fournies
|
|
avec les distributions de Linux chargent les modules
|
|
Apache via la directive
|
|
<code class="directive">LoadModule</code>.
|
|
</p>
|
|
<p>Les modules inutilisés peuvent être désactivés : si
|
|
vous n'avez pas besoin de leurs fonctionnalités et des
|
|
directives de configuration qu'ils implémentent,
|
|
désactivez-les en commentant les lignes
|
|
<code class="directive">LoadModule</code> correspondantes. Vous
|
|
devez cependant lire la documentation relative à ces
|
|
modules avant de les désactiver, et garder à l'esprit que
|
|
la désactivation d'un module très peu gourmand en
|
|
ressources n'est pas absolument nécessaire.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="caching-content" id="caching-content">Mise en cache des contenus
|
|
</a><a title="Lien permanent" href="#caching-content" class="permalink">¶</a></h2>
|
|
|
|
<p>Les requêtes impliquant des contenus dynamiques nécessitent
|
|
en général d'avantage de ressources que les
|
|
requêtes pour des contenus statiques. Les contenus statiques
|
|
consistent en simples pages issues de documents ou images
|
|
sur disque, et sont servis très rapidement. En outre, de
|
|
nombreux systèmes d'exploitation mettent automatiquement en
|
|
cache en mémoire les contenus des fichiers fréquemment accédés.
|
|
</p>
|
|
<p>Comme indiqué précédemment, le traitement des requêtes dynamiques peut
|
|
nécessiter beaucoup plus de ressources. L'exécution de scripts
|
|
CGI, le transfert de requêtes à un serveur d'applications
|
|
externe, ou les accès à une base de données peuvent impliquer
|
|
des temps d'attente et charges de travail significatifs pour un
|
|
serveur web fortement sollicité. Dans de nombreuses
|
|
circonstances, vous pourrez alors améliorer les performances en
|
|
transformant les requêtes dynamiques courantes en requêtes
|
|
statiques. Pour ce faire, deux approches seront discutées dans
|
|
la suite de cette section.
|
|
</p>
|
|
|
|
|
|
<h3><a name="making-popular-pages-static" id="making-popular-pages-static">Transformation des pages courantes en contenus
|
|
statiques
|
|
</a></h3>
|
|
|
|
<p>En générant à l'avance les réponses pour les requêtes les
|
|
plus courantes de votre application, vous pouvez améliorer
|
|
de manière significative les performances de votre serveur
|
|
sans abandonner la flexibilité des contenus générés
|
|
dynamiquement. Par exemple, si votre application est un
|
|
service de livraison de fleurs, vous aurez tout intérêt à
|
|
générer à l'avance les pages de votre catalogue concernant
|
|
les roses rouges dans les semaines précédant le jour de la
|
|
Saint Valentin. Lorsqu'un utilisateur cherchera des roses
|
|
rouges, il téléchargera alors les pages générées à
|
|
l'avance. Par contre, les recherches de roses jaunes seront
|
|
quant à elles traitées directement via une requête vers la
|
|
base de données. Pour effectuer ces aiguillages de requêtes,
|
|
vous disposez d'un outil particulièrement approprié fourni
|
|
avec Apache : le module mod_rewrite.
|
|
</p>
|
|
|
|
|
|
<h4><a name="example-a-statically-rendered-blog" id="example-a-statically-rendered-blog">Exemple : un blog servi statiquement
|
|
</a></h4>
|
|
|
|
|
|
|
|
<p>Blosxom est un programme CGI de journalisation web
|
|
léger. Il est écrit en Perl et utilise des fichiers
|
|
texte pour ses entrées. Outre sa qualité de programme
|
|
CGI, Blosxom peut être exécuté en ligne de commande pour
|
|
générer à l'avance des pages de blog. Lorsque votre blog
|
|
commence à être lu par un grand nombre de personnes, la
|
|
génération à l'avance de pages en HTML satique peut
|
|
améliorer de manière significative les performances de
|
|
votre serveur.
|
|
</p>
|
|
<p>Pour générer des pages statiques avec blosxom, éditez
|
|
le script CGI selon la documentation. Définissez la
|
|
variable $static dir à la valeur de
|
|
<code class="directive">DocumentRoot</code> de votre serveur
|
|
web, et exécutez le script en ligne de commande comme
|
|
suit :
|
|
</p>
|
|
|
|
<div class="example"><p><code>$ perl blosxom.cgi -password='whateveryourpassword'
|
|
</code></p></div>
|
|
|
|
<p>Vous pouvez exécuter ce script périodiquement via
|
|
cron, à chaque fois que vous ajoutez un nouveau contenu. Pour
|
|
faire en sorte qu'Apache substitue les pages
|
|
statiques au contenu dynamique, nous
|
|
utiliserons mod_rewrite. Ce module est fourni avec le
|
|
code source d'Apache, mais n'est pas compilé par défaut.
|
|
Pour le compiler avec la distribution d'Apache, vous
|
|
pouvez utiliser l'option de la commande configure
|
|
<code>--enable-rewrite[=shared]</code>. De nombreuses
|
|
distributions binaires d'Apache sont fournies avec
|
|
<code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> inclus. Dans l'exemple
|
|
suivant, un serveur virtuel Apache utilise les pages de
|
|
blog générées à l'avance :
|
|
</p>
|
|
|
|
<pre class="prettyprint lang-config">Listen *:8001
|
|
<VirtualHost *:8001>
|
|
ServerName blog.sandla.org:8001
|
|
ServerAdmin sander@temme.net
|
|
DocumentRoot "/home/sctemme/inst/blog/httpd/htdocs"
|
|
<Directory "/home/sctemme/inst/blog/httpd/htdocs">
|
|
Options +Indexes
|
|
Require all granted
|
|
RewriteEngine on
|
|
RewriteCond "%{REQUEST_FILENAME}" "!-f"
|
|
RewriteCond "%{REQUEST_FILENAME}" "!-d"
|
|
RewriteRule "^(.*)$" "/cgi-bin/blosxom.cgi/$1" [L,QSA]
|
|
</Directory>
|
|
RewriteLog "/home/sctemme/inst/blog/httpd/logs/rewrite_log"
|
|
RewriteLogLevel 9
|
|
ErrorLog "/home/sctemme/inst/blog/httpd/logs/error_log"
|
|
LogLevel debug
|
|
CustomLog "/home/sctemme/inst/blog/httpd/logs/access_log common"
|
|
ScriptAlias "/cgi-bin/" "/home/sctemme/inst/blog/bin/"
|
|
<Directory "/home/sctemme/inst/blog/bin">
|
|
Options +ExecCGI
|
|
Require all granted
|
|
</Directory>
|
|
</VirtualHost></pre>
|
|
|
|
|
|
<p>
|
|
Si les directives <code class="directive">RewriteCond</code>
|
|
indiquent que la ressource demandée n'existe ni en tant que
|
|
fichier, ni en tant que répertoire, son
|
|
chemin sera redirigé par la directive
|
|
<code class="directive">RewriteRule</code> vers le programme
|
|
CGI Blosxom qui va générer la réponse. Blosxom
|
|
utilise Path Info pour spécifier les entrées de blog
|
|
en tant que pages d'index, et si un chemin dans
|
|
Blosxom existe en tant que fichier statique dans le système de
|
|
fichiers, c'est ce dernier qui sera par conséquent privilégié.
|
|
Toute requête dont la réponse n'a pas été générée à
|
|
l'avance sera traitée par le programme CGI. Cela
|
|
signifie que les entrées individuelles comme les
|
|
commentaires seront toujours servies par le
|
|
programme CGI, et seront donc toujours visibles.
|
|
Cette configuration permet aussi de ne pas faire
|
|
apparaître le programme CGI Blosxom dans l'URL de la barre
|
|
d'adresse. Enfin, mod_rewrite est un module extrêmement
|
|
souple et puissant ; prenez le temps de bien
|
|
l'étudier afin de parvenir à la configuration qui
|
|
correspondra le mieux à votre situation.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="caching-content-with-mod_cache" id="caching-content-with-mod_cache">Mise en cache du contenu avec mod_cache
|
|
</a></h3>
|
|
|
|
<p>Le module mod_cache implémente une mise en cache
|
|
intelligente des réponses HTTP : il tient compte des délais
|
|
de péremption et des contraintes en matière de contenu
|
|
inhérentes à la spécification HTTP. Le module mod_cache met
|
|
en cache les URL des contenus des réponses. Si un contenu envoyé au
|
|
client peut être mis en cache, il est sauvegardé sur disque.
|
|
Les requêtes ultérieures pour cette URL seront alors servies
|
|
directement depuis le cache. Le module fournisseur pour
|
|
mod_cache, mod_disk_cache, détermine la manière dont les
|
|
contenus sont stockés sur disque. La plupart des systèmes de
|
|
serveur possèdent plus d'espace disque que de mémoire, et il
|
|
est bon de garder à l'esprit que certains noyaux système mettent en
|
|
cache de manière transparente en mémoire les contenus sur
|
|
disque fréquemment accédés ; il n'est donc pas très utile de
|
|
répéter cette opération au niveau du serveur.
|
|
</p>
|
|
<p>Pour mettre en oeuvre une mise en cache de contenu
|
|
efficace et éviter de présenter à l'utilisateur un contenu
|
|
invalide ou périmé, l'application qui génère le contenu à
|
|
jour doit envoyer les en-têtes de réponse corrects. En
|
|
effet, en l'absence d'en-têtes comme <code>Etag:</code>,
|
|
<code>Last-Modified:</code> ou <code>Expires:</code>,
|
|
<code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code> ne sera pas en mesure de décider
|
|
de manière appropriée
|
|
s'il doit mettre le contenu en cache, s'il doit le servir
|
|
directement depuis ce dernier, ou s'il doit tout simplement
|
|
ne rien faire. Lorsque vous testerez la mise en cache, vous
|
|
devrez peut-être modifier votre application ou, en cas
|
|
d'impossibilité, désactiver de manière sélective la mise en
|
|
cache des URLs qui posent problème. Les modules mod_cache ne
|
|
sont pas compilés par défaut ; pour ce faire, vous devez
|
|
utiliser l'option <code>--enable-cache[=shared]</code> du
|
|
script configure. Si vous utilisez une distribution binaire
|
|
d'Apache httpd, ou si elle fait partie de votre portage ou
|
|
de votre sélection de paquets, <code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code>
|
|
sera probablement déjà inclus.
|
|
</p>
|
|
|
|
|
|
<h4><a name="example-wiki" id="example-wiki">Exemple : wiki.apache.org
|
|
</a></h4>
|
|
|
|
|
|
<p>
|
|
Le Wiki de l'Apache Software Foundation est servi
|
|
par MoinMoin. MoinMoin est écrit en Python et
|
|
s'exécute en tant que programme CGI. A l'heure
|
|
actuelle, toute tentative pour l'exécuter via
|
|
mod_python s'est soldée par un échec. Le programme
|
|
CGI induit une charge inacceptable sur le serveur,
|
|
particulièrement lorsque le Wiki est indexé par des
|
|
moteurs de recherche comme Google. Pour alléger la
|
|
charge de la machine, l'équipe d'infrastructure
|
|
d'Apache s'est tournée vers mod_cache. Il s'est
|
|
avéré que <a href="/httpd/MoinMoin">MoinMoin</a>
|
|
nécessitait un petit patch pour adopter un
|
|
comportement approprié en aval du serveur de mise
|
|
en cache : certaines requêtes ne pouvaient jamais
|
|
être mises en cache, et les modules Python
|
|
concernés ont été mis à jour pour pouvoir envoyer
|
|
les en-têtes de réponse HTTP corrects. Après cette
|
|
modification, la mise en cache en amont du Wiki a
|
|
été activée via l'insertion des lignes suivantes
|
|
dans le fichier de configuration
|
|
<code>httpd.conf</code> :
|
|
</p>
|
|
|
|
<pre class="prettyprint lang-config">CacheRoot /raid1/cacheroot
|
|
CacheEnable disk /
|
|
# Une page modifiée il y a 100 minutes expirera dans 10 minutes
|
|
CacheLastModifiedFactor .1
|
|
# Dans tous les cas, vérifier la validité des pages après 6 heures
|
|
CacheMaxExpire 21600</pre>
|
|
|
|
|
|
<p>Cette configuration essaie de mettre en cache tout
|
|
contenu de son serveur virtuel. Elle ne mettra jamais en
|
|
cache un contenu plus vieux que 6 heures (voir la
|
|
directive <code class="directive"><a href="../mod/mod_cache.html#cachemaxexpire">CacheMaxExpire</a></code>). Si
|
|
l'en-tête <code>Expires:</code> est absent de la
|
|
réponse, <code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code> va calculer une date
|
|
d'expiration en fonction du contenu de l'en-tête
|
|
<code>Last-Modified:</code>. Le principe de ce calcul
|
|
qui utilise la directive <code class="directive"><a href="../mod/mod_cache.html#cachelastmodifiedfactor">CacheLastModifiedFactor</a></code>
|
|
se base sur l'hypothèse que si une page a été modifiée
|
|
récemment, il y a de fortes chances pour qu'elle le soit
|
|
à nouveau dans un futur proche et devra donc être remise
|
|
en cache.
|
|
</p>
|
|
<p>
|
|
Notez qu'il peut s'avérer payant de
|
|
<em>désactiver</em> l'en-tête <code>ETag:</code> :
|
|
pour les fichiers inférieurs à 1 ko, le serveur
|
|
doit calculer la somme de vérification checksum (en
|
|
général MD5) et envoyer une réponse <code>304 Not
|
|
Modified</code>, ce qui utilise des ressources CPU
|
|
et réseau pour le transfert (1 paquet TCP). Pour les
|
|
ressources supérieures à 1 ko, les ressources CPU
|
|
consommées peuvent devenir importantes car l'en-tête
|
|
est calculé à chaque requête. Malheureusement, il
|
|
n'existe actuellement aucun moyen pour mettre en
|
|
cache ces en-têtes.
|
|
</p>
|
|
<pre class="prettyprint lang-config"><FilesMatch "\.(jpe?g|png|gif|js|css|x?html|xml)">
|
|
FileETag None
|
|
</FilesMatch></pre>
|
|
|
|
|
|
<p>
|
|
Dans l'exemple précédent: la génération d'un en-tête
|
|
<code>ETag:</code> sera désactivée pour la plupart
|
|
des ressources statiques. Le serveur ne génère pas
|
|
ces en-têtes pour les ressources dynamiques.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="further-considerations" id="further-considerations">Pour aller plus loin
|
|
</a><a title="Lien permanent" href="#further-considerations" class="permalink">¶</a></h2>
|
|
|
|
<p>Armés du savoir-faire pour personnaliser un système afin
|
|
qu'il affiche les performances désirées, nous découvrirons vite
|
|
qu'<em>1</em> sytème à lui seul peut constituer un goulot
|
|
d'étranglement. A ce sujet, la page du Wiki <a href="http://wiki.apache.org/httpd/PerformanceScalingOut">PerformanceScalingOut</a>
|
|
décrit comment adapter un système à mesure qu'il prend de
|
|
l'ampleur, ou comment personnaliser plusieurs systèmes dans leur
|
|
ensemble.
|
|
</p>
|
|
</div></div>
|
|
<div class="bottomlang">
|
|
<p><span>Langues Disponibles: </span><a href="../en/misc/perf-scaling.html" hreflang="en" rel="alternate" title="English"> en </a> |
|
|
<a href="../es/misc/perf-scaling.html" hreflang="es" rel="alternate" title="Español"> es </a> |
|
|
<a href="../fr/misc/perf-scaling.html" title="Français"> fr </a></p>
|
|
</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>
|
|
<script type="text/javascript"><!--//--><![CDATA[//><!--
|
|
var comments_shortname = 'httpd';
|
|
var comments_identifier = 'http://httpd.apache.org/docs/trunk/misc/perf-scaling.html';
|
|
(function(w, d) {
|
|
if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
|
|
d.write('<div id="comments_thread"><\/div>');
|
|
var s = d.createElement('script');
|
|
s.type = 'text/javascript';
|
|
s.async = true;
|
|
s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
|
|
(d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
|
|
}
|
|
else {
|
|
d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
|
|
}
|
|
})(window, document);
|
|
//--><!]]></script></div><div id="footer">
|
|
<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>
|
|
<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"><!--//--><![CDATA[//><!--
|
|
if (typeof(prettyPrint) !== 'undefined') {
|
|
prettyPrint();
|
|
}
|
|
//--><!]]></script>
|
|
</body></html> |