You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by gr...@apache.org on 2017/12/18 18:03:03 UTC
svn commit: r1818598 - in /httpd/httpd/trunk/docs/manual/misc:
perf-scaling.xml.fr perf-scaling.xml.meta
Author: gryzor
Date: Mon Dec 18 18:03:03 2017
New Revision: 1818598
URL: http://svn.apache.org/viewvc?rev=1818598&view=rev
Log:
Introducing .fr translation for perf-scaling howto
Added:
httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.fr
Modified:
httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.meta
Added: httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.fr?rev=1818598&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.fr (added)
+++ httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.fr [utf-8] Mon Dec 18 18:03:03 2017
@@ -0,0 +1,1645 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision : 1690137 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<manualpage metafile="perf-scaling.xml.meta">
+
+ <parentdocument href="./">Documentations diverses</parentdocument>
+
+ <title>Amélioration des performances</title>
+
+ <summary>
+
+ <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>
+
+ </summary>
+
+ <section id="what-will-and-will-not-be-discussed">
+ <title>Ce qui sera abordé et ce qui ne le sera pas</title>
+ <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>
+
+ </section>
+
+ <section id="monitoring-your-server">
+ <title>Monitoring de votre serveur</title>
+ <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>
+
+
+ <section id="monitoring-tools">
+ <title>Outils de monitoring</title>
+
+ <section id="top">
+ <title>top
+ </title>
+ <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>
+
+ <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></example>
+
+ <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>
+ </section>
+ <section id="free">
+ <title>free
+ </title>
+ <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>
+
+ <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></example>
+ </section>
+
+ <section id="vmstat">
+ <title>vmstat
+ </title>
+ <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>
+
+
+ <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></example>
+
+ <p>Et voici cette même sortie pour un serveur en charge
+ de cent connexions simultanées pour du contenu statique :
+ </p>
+
+ <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></example>
+
+ <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>
+
+ </section>
+ <section id="se-toolkit">
+ <title>Boîte à outils SE
+ </title>
+ <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>
+
+
+ </section>
+ <section id="dtrace">
+ <title>DTrace
+ </title>
+ <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>
+
+
+ </section>
+ <section id="mod_status">
+ <title>mod_status
+ </title>
+ <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 <module>mod_status</module> 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
+ <module>mod_status</module> vous fournira d'avantage
+ d'informations, au prix d'une consommation de ressources
+ légèrement supérieure par requête.
+ </p>
+
+
+ </section>
+ </section>
+ <section id="web-server-log-files">
+ <title>Les journaux du serveur web
+ </title>
+ <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>
+
+
+ <section id="ErrorLog">
+ <title>Journal des erreurs
+ </title>
+ <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 <directive
+ module="core">ErrorLog</directive> et <directive
+ module="core">LogLevel</directive>. 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 <directive
+ module="core">ErrorLog</directive> 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 <directive
+ module="core">LogLevel</directive> 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 <directive
+ module="core">LogLevel</directive> peut être définie au
+ niveau de chaque module :
+ </p>
+
+ <highlight language="config">
+ LogLevel debug mod_ssl:warn
+ </highlight>
+
+ <p>
+ Dans cet exemple, l'ensemble du serveur est en mode
+ debug, sauf le module <module>mod_ssl</module>
+ qui a tendance à être très bavard.
+ </p>
+
+
+ </section>
+ <section id="AccessLog">
+ <title>Journal des accès
+ </title>
+ <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 <directive
+ module="mod_log_config">TransferLog</directive> ou
+ <directive
+ module="mod_log_config">CustomLog</directive>.
+ </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>
+
+
+ <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></example>
+
+ <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>
+
+ </section>
+ <section id="rotating-log-files">
+ <title>Rotation des fichiers journaux
+ </title>
+ <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>
+
+
+ <example>
+ 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
+ </example>
+
+ <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 <directive
+ module="mod_log_config">CustomLog</directive>,
+ <directive
+ module="mod_log_config">TransferLog</directive> ou
+ <directive module="core">ErrorLog</directive>
+ permettent de rediriger les données de journalisation
+ vers tout programme via le caractère pipe
+ (<code>|</code>) comme dans cet exemple :
+ </p>
+
+ <example>CustomLog "|/usr/local/apache2/bin/rotatelogs
+ /var/log/access_log 86400" common
+ </example>
+
+ <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>
+
+
+ </section>
+ <section id="logging-and-performance">
+ <title>Journalisation et performances
+ </title>
+ <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 <directive
+ module="core">LogLevel</directive> à 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 <directive
+ module="mod_log_config">LogFormat</directive> (et de
+ votre directive <directive
+ module="core">ErrorLog</directive> 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 <directive
+ module="mod_log_config">BufferedLogs</directive>
+ 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>
+
+
+ </section>
+ </section>
+ <section id="generating-a-test-load">
+ <title>Mise en oeuvre d'une charge de test
+ </title>
+ <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>
+
+
+ </section>
+ </section>
+ <section id="configuring-for-performance">
+ <title>Configuration dans une optique de performances
+ </title>
+
+
+ <section id="apache-configuration">
+ <title>Configuration de httpd
+ </title>
+ <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
+ <directive module="core">LoadModule</directive>. 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
+ <module outdated="true">mpm_event</module>. 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>
+
+
+ <section id="MaxClients">
+ <title>MaxClients
+ </title>
+ <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>
+
+
+ </section>
+ <section id="spinning-threads">
+ <title>Rotation des threads
+ </title>
+ <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>
+
+
+ </section>
+ <section id="sizing-maxClients">
+ <title>Choix de la valeur de MaxClients
+ </title>
+ <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
+ <directive module="mpm_common"
+ name="MaxRequestWorkers">MaxClients</directive>
+ est assez simple :
+ </p>
+
+ <example>
+ MaxClients = (RAM totale − RAM système − RAM pour
+ les programmes externes) divisé par la RAM nécessaire pour
+ chaque processus enfant.
+ </example>
+
+ <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>
+
+ </section>
+ <section id="selecting-your-mpm">
+ <title>Choisir votre MPM
+ </title>
+ <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>
+
+
+ </section>
+ <section id="spinning-locks">
+ <title>Verrous tournants</title>
+ <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>
+
+ </section>
+ <section id="the-thundering-herd">
+ <title>L'assaut de la foule
+ </title>
+ <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>
+
+ </section>
+ </section>
+ <section id="tuning-the-operating-system">
+ <title>Optimisation du système d'exploitation
+ </title>
+ <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>
+
+
+ <section id="ram-and-swap-space">
+ <title>RAM et swap
+ </title>
+ <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>
+
+
+ </section>
+ <section id="ulimit-files-and-processes">
+ <title>ulimit: fichiers et processus
+ </title>
+ <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>
+
+ <example>
+ ulimit [-H|-S] -u [nouvelle valeur]
+ </example>
+
+ <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>
+
+ <example>
+ limit [-h] maxproc [newvalue]
+ </example>
+
+ <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>
+
+ <example>ulimit -n [newvalue]
+ </example>
+
+ <p>Là encore, cette modification doit être effectuée
+ avant le démarrage du serveur Apache.
+ </p>
+
+
+ </section>
+ <section id="setting-user-limits-on-system-startup">
+ <title>Définition des limites en fonction de l'utilisateur ou du
+ groupe au démarrage du système
+ </title>
+ <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>
+
+ <example>session required /lib/security/pam_limits.so
+ </example>
+
+ <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>
+
+ <example>
+ set rlim_fd_max=65536<br />
+ set rlim_fd_cur=2048
+ </example>
+
+ <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>
+
+ <example>sysdef -i | grep maximum
+ </example>
+
+ <p>Il est cependant déconseillé de les modifier.
+ </p>
+
+
+ </section>
+ <section id="turn-off-unused-services-and-modules">
+ <title>Désactiver les services et modules non utilisés
+ </title>
+ <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
+ <directive>LoadModule</directive>.
+ </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
+ <directive>LoadModule</directive> 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>
+
+
+ </section>
+ </section>
+ </section>
+ <section id="caching-content">
+ <title>Mise en cache des contenus
+ </title>
+ <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>
+
+
+ <section id="making-popular-pages-static">
+ <title>Transformation des pages courantes en contenus
+ statiques
+ </title>
+ <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>
+
+
+ <section id="example-a-statically-rendered-blog">
+ <title>Exemple : un blog servi statiquement
+ </title>
+ <!--we should provide a more useful example here.
+ One showing how to make Wordpress or Drupal suck less. -->
+
+ <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
+ <directive>DocumentRoot</directive> de votre serveur
+ web, et exécutez le script en ligne de commande comme
+ suit :
+ </p>
+
+ <example>$ perl blosxom.cgi -password='whateveryourpassword'
+ </example>
+
+ <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
+ <module>mod_rewrite</module> inclus. Dans l'exemple
+ suivant, un serveur virtuel Apache utilise les pages de
+ blog générées à l'avance :
+ </p>
+
+<highlight language="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>
+</highlight>
+
+ <p>
+ Si les directives <directive>RewriteCond</directive>
+ 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
+ <directive>RewriteRule</directive> 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>
+
+
+ </section>
+ </section>
+ <section id="caching-content-with-mod_cache">
+ <title>Mise en cache du contenu avec mod_cache
+ </title>
+ <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>,
+ <module>mod_cache</module> 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, <module>mod_cache</module>
+ sera probablement déjà inclus.
+ </p>
+
+
+ <section id="example-wiki">
+ <title>Exemple : wiki.apache.org
+ </title>
+ <!-- Is this still the case? Maybe we should give
+ a better example here too.-->
+ <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>
+
+<highlight language="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
+</highlight>
+
+ <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 <directive
+ module="mod_cache">CacheMaxExpire</directive>). Si
+ l'en-tête <code>Expires:</code> est absent de la
+ réponse, <module>mod_cache</module> 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 <directive
+ module="mod_cache">CacheLastModifiedFactor</directive>
+ 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>
+<highlight language="config">
+<FilesMatch "\.(jpe?g|png|gif|js|css|x?html|xml)">
+ FileETag None
+</FilesMatch>
+</highlight>
+
+ <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>
+
+
+ </section>
+ </section>
+ </section>
+ <section id="further-considerations">
+ <title>Pour aller plus loin
+ </title>
+ <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>
+ </section>
+</manualpage>
Modified: httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.meta
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.meta?rev=1818598&r1=1818597&r2=1818598&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.meta (original)
+++ httpd/httpd/trunk/docs/manual/misc/perf-scaling.xml.meta Mon Dec 18 18:03:03 2017
@@ -9,5 +9,6 @@
<variants>
<variant>en</variant>
<variant>es</variant>
+ <variant>fr</variant>
</variants>
</metafile>