Améliorer les performances d'Apache en employant un serveur mandataire inverse

Gazette Linux n°132 — Novembre 2006

René Pfeiffer

Deny

Adaptation française

Joëlle Cornavin

Relecture de la version française

Article paru dans le n°132 de la Gazette Linux de novembre 2006.

Article publié sous Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.


Table des matières

1. Des caches où que vous alliez
2. En-têtes cache-control
3. Configuration du cache côté serveur
3.1. La directive mod_expires d'Apache
3.2. Le serveur mandataire inverse Squid
3.3. Statistiques
3.4. Activation du cache
4. Résumé
5. Liens utiles

Un jour, il n'y a pas si longtemps, un serveur web isolé était en détresse. D'innombrables navigateurs web avaient assiégé son port. La bande passante était exsangue ; les processeurs étaient occupés ; la base de données donnait des signes de faiblesse. La direction du département informatique nous a contactés, Pooz et moi, demandant une amélioration. Mettre à niveau soit le matériel, soit la connexion Internet n'étant pas une option, nous avons tenté de trouver ce que nous pourrions faire d'autre — utiliser des applications cache !

1. Des caches où que vous alliez

Chaque ordinateur utilise des caches. Votre processeur en a un, ainsi que votre lecteur de disque, système d'exploitation, carte graphique et naturellement votre navigateur web. Les caches sont conçus pour garder une copie des données souvent consultées. Les caches du processeur peuvent stocker des instructions et des données. Au lieu d'accéder à la mémoire du système pour obtenir l'instruction suivante ou un élément de données, il les récupère à partir du cache. Le navigateur web, cependant, se préoccupe plus de mettre en cache des fichiers tels que des images, feuilles de style en cascade, documents, etc. Ce comportement accélère la navigation web, car certains éléments de format apparaissent assez fréquemment dans les pages web. Plutôt que de télécharger répétitivement la même image ou le même fichier, le navigateur réutilise les éléments trouvés dans le cache. C'est particulièrement vrai si vous consultez les pages générées par un système de gestion de contenu (Content Management System, CMS). À présent, si nous pouvons trouver un moyen d'indiquer au navigateur web que sa copie dans le cache est valide, alors nous pourrions économiser une partie de la bande passante de notre serveur web. Dans le cas de notre CMS, qui est Typo3, nous pouvons également économiser à la fois du temps machine et des accès à la base de données, à condition de pouvoir également publier la période d'expiration des documents HTML générés. Vous pouvez également insérer un cache supplémentaire entre les navigateurs web et votre serveur, pour réduire encore plus les requêtes vers le serveur. Ce cache est nommé un serveur mandataire inverse, parfois appelé passerelle ou cache de substitution. Les serveurs mandataires classiques travaillent pour leurs clients, mais un serveur mandataire inverse travaille pour le serveur. Ce serveur mandataire possède également un disque et une mémoire cache, qui peuvent être utilisés pour délester le contenu statique depuis le serveur Apache. L'image suivante illustre où résident les caches et ce qu'ils font.

Les lignes vertes indiquent les réponses pertinentes du cache. Une réponse du cache est un contenu valide (c'est-à-dire, non expiré) qui est trouvé dans un cache et peut être copié depuis cet emplacement. Souvent les réponses ne parviennent pas jusqu'au serveur web. Quelques clients peuvent demander au serveur web si le contenu a déjà changé, mais cette brève requête ne génère pas beaucoup de trafic. Le serveur web répond simplement avec un en-tête HTTP/1.x 304 Not Modified sans données supplémentaires. Les lignes rouges indiquent des erreurs de cache. Une erreur survient quand le cache ne trouve pas l'objet demandé et le recherche sur le serveur cible. Il est ensuite copié sur le disque ou la mémoire et retransmis au client. Chaque fois qu'une autre requête est transférée vers le cache, une copie locale est employée aussi longtemps qu'elle est valide.

2. En-têtes cache-control

Comment un cache sait quand utiliser une copie en local et quand interroger le serveur ? Eh bien, cela dépend. Un cache de navigateur recherche des messages depuis le serveur web. Le serveur peut employer des en-têtes cache-control pour donner des recommandations. Examinons un exemple. La requête GET http://www.luchs.at/linuxgazette/index.html HTTP/1.1 utilise une page web dont les en-têtes HTTP ressemblent à ceci :


HTTP/1.x 200 OK
Date: Tue, 03 Oct 2006 10:24:35 GMT
Server: Apache
Last-Modified: Mon, 02 Oct 2006 02:04:36 GMT
Etag: "e324ac5-6d7d5500"
Accept-Ranges: bytes
Cache-Control: max-age=142800
Expires: Thu, 05 Oct 2006 02:04:36 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 3028
Content-Type: text/html; charset=ISO-8859-1
X-Cache: MISS from bazaar.office.lan
X-Cache-Lookup: MISS from bazaar.office.lan:3128
Via: 1.0 bazaar.office.lan:3128 (squid/2.6.STABLE1)
Proxy-Connection: keep-alive

Le serveur vous fournit le document HTTP. En outre, l'en-tête HTTP contient les champs suivants :

  • Last-Modified : indique quand le document a été dernièrement modifié.

  • Cache-Control : indique à chaque cache entre le serveur et le navigateur que le document peut être mis en cache pendant 14 2800 secondes.

  • Expires : indique à chaque cache quand le document est définitivement périmé.

Cache-Control : est meilleur que Expires : parce que ce dernier demande aux machines d'utiliser un source à temps synchronisé. Cache-Control : est plus prolixe mais fonctionne seulement avec HTTP 1.1. Quelques données incluses n'ont pas été envoyées par le serveur Apache. Les quatre derniers champs d'en-tête HTTP ont été insérés par le serveur mandataire local Squid sur notre bureau. Il nous indique que nous avons commis une erreur de cache.

3. Configuration du cache côté serveur

A présent, occupons-nous de nos serveurs et observons comment les configurer

3.1. La directive mod_expires d'Apache

Même si la directive Cache-Control est meilleure, examinons d'abord une façon de générer un en-tête Expires : c'est-à-dire un en-tête pour le contenu distribué. Le serveur web Apache comporte un module pour l'occasion nommé mod_expires. La plupart des distributions l'incluent dans leur version d'Apache. Vous pouvez également le compiler en tant que module et l'insérer après l'installation de votre propre serveur Apache. D'une façon l'autre, vous avez à présent la possibilité de créer des en-têtes Expires : l'un et l'autre dans la configuration globale ou par hôte virtuel. Un exemple de configuration pourrait ressembler à ceci (pour Apache 2.0.x) :

	
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "modification plus 3 days"
ExpiresByType text/xml  "modification plus 3 days"
ExpiresByType image/gif "access plus 4 weeks"
ExpiresByType image/jpg "access plus 4 weeks"
ExpiresByType image/png "access plus 4 weeks"
ExpiresByType video/quicktime "access plus 2 months"
ExpiresByType audio/mpeg "access plus 2 months"
ExpiresByType application/pdf "modification plus 2 months"
ExpiresByType application/ps "modification plus 2 months"
ExpiresByType application/xml "modification plus 2 weeks"
<IfModule>

La première ligne active le module. Si vous l'oubliez, mod_expires ne fera rien. Les lignes restantes fixent la période d'expiration par type de MIME. mod_expires automatiquement calcule et rajoute un cache-control approprié ,ce qui est agréable. Vous pouvez employer l'un et l'autre « modification plus » ... ou « access plus » .... « modification » fonctionne seulement avec des fichiers qu'Apache lit depuis le disque. Cela signifie que vous devez employer access si vous désirez fixer des en-têtes expires pour du contenu généré dynamiquement. Soyez prudent ! Bien que des scripts CGI soient requis pour fixer leur propre date d'expiration auparavant afin de garantir des rafraîchissements immédiats— quelques développeurs ne s'en soucient pas. mod_expires déréglera sévèrement des CGIs mal codés. Une fois, je passais une heure à étudier un code horrible afin de trouver pourquoi un script d'authentification ne fonctionnait plus. Le développeur avait oublié de fixer correctement le temps d'expiration, aussi j'ai adapté la configuration du serveur pour cet hôte virtuel particulier comme solution de rechange. En outre, assurez-vous de sélectionner des périodes d'expiration appropriées. Les valeurs ci-dessus sont des exemples. Vous pourriez avoir différentes exigences, selon la fréquence de changement de votre contenu.

3.2. Le serveur mandataire inverse Squid

Le serveur mandataire Squid comporte de nombreuses directives de configuration. Si vous n'avez pas d'expérience avec un serveur Squid, ceci peut sembler un peu déroutant, au premier abord. Cependant, je vous présente seulement un fichier de configuration minimal, qui fait ce que nous avons l'intention de faire. Les capacités de Squid méritent que l'on s'y attarde, cependant. Je supposerai que nous avons lancé un serveur mandataire Squid  2.6.x installé depuis le source et situé dans /usr/local/squid/.

Le serveur mandataire inverse prend la place du serveur web originel. Il doit intercepter chaque requête, afin de la comparer avec le contenu de son cache. Admettons que nous avons deux machines :

  • stingray.example.net serving http://www.example.net/ (172.16.23.42)

  • squid.example.net (172.16.23.43)

Le fichier local /usr/local/squid/etc/squid.conf définit ce que notre Squid devrait faire. Nous commençons avec les adresses IP et nous lui indiquons de détecter les requêtes entrantes sur le port  80.

http_port       172.16.23.43:80 vhost vport
http_port       127.0.0.1:80
icp_port        0
cache_peer      172.16.23.42 parent 80 0 originserver default

ICP désigne le protocole de communication inter-cache. Nous n'en avons pas besoin, et nous le désactivons en utilisant le port 0. cache_peer indique à notre serveur mandataire inverse de retransmettre chaque requête qu'il ne peut prendre en charge vers le serveur web. Ensuite, nous devons définir les règles d'accès. Contrairement à la situation des clients mandataires, un serveur mandataire inverse pour un serveur web public doit répondre aux requêtes de tous. Attention : c'est une bonne raison pour ne pas mélanger serveur mandataire et serveur mandataire inverse, où vous finirez avec un serveur mandataire ouvert, ce qui est une mauvaise idée.

acl         all src 0.0.0.0/0.0.0.0
acl         manager proto cache_object
acl         localhost src 127.0.0.1/255.255.255.255
acl         accel_hosts dst 172.16.23.42 172.16.23.43
http_access allow accel_hosts
http_access allow manager localhost
http_access deny manager
http_access deny all
deny_info   http://www.example.net/ all

Les lignes acl définissent des groupes. accel_hosts sont nos deux serveurs. http_access, allow accel_hosts autorisent à chacun d'accéder à ces serveurs. Les autres lignes font partie de la configuration par défaut de Squid, et elles désactivent l'adresse URL (Uniform Resource Locator) du cache manager. Nous n'en avons pas besoin pour l'instant. La dernière ligne est une sauvegarde contre les pages d'erreur indésirables. (Squid en possède un ensemble de son cru : elles différent des pages d'erreur d'Apache. Des utilisateurs sont envoyés sur notre page d'accueil, au cas où il y aurait des requêtes erronées. Il est possible de consulter le squid.conf complet séparément, parce que le reste prend « seulement » en charge la configuration et le réglage du cache. (Prenez garde : la configuration vient d'un serveur pourvu de 2 GO de mémoire vive et de plusieurs disques. Vous pourriez souhaiter réduire la taille du cache en mémoire.) Ainsi que je l'ai dit, Squid est capable de faire beaucoup de choses merveilleuses. Dés que Squid sera exécuté et fonctionnera, nous serons prêts à envoyer nos utilisateurs vers le serveur mandataire inverse.

3.3. Statistiques

Vous devez être prudent, si vous vous fiez aux statistiques courantes des fichiers journaux de votre serveur web. Beaucoup de requêtes HTTP seront interceptées par le serveur mandataire inverse Squid. Cela signifie que le serveur Apache voit peu de requêtes, et qu'elles proviennent de l'adresse IP de votre serveur mandataire. C'était l'idée-même de notre configuration. Vous pouvez rassembler des journaux semblables à ceux d'Apache avec Squid, si vous modifiez le format du journal.

logformat       combined %{Host}>h %>a %ui %un [%tl] "%rm %ru  HTTP/%rv" %Hs %<st "%{Referer}>h" "%{User-Agent}>h" %Ss:%Sh
logformat       vcombined %{Host}>h %>a %ui %un [%tl] "%rm %ru  HTTP/%rv" %Hs %<st "%{Referer}>h" "%{User-Agent}>h"
access_log      /var/log/squid/access.log combined
access_log      /var/log/squid/vaccess.log vcombined	

Pour les insérer dans votre analyse du journal, vous devez copier les journaux du serveur mandataire inverse et les fusionner avec vos journaux Apache. Dés que votre configuration web comprend un serveur mandataire ou même des techniques d'équilibrage de charge, maintenir des statistiques précises devient plutôt ardu.

3.4. Activation du cache

Après avoir configuré Apache et Squid, il est temps de tout vérifier. Commencez avec un seul hôte virtuel réservé pour l'essai. Modifiez les enregistrements DNS,(Domain Name System, système de noms de domaine) pour pointer sur la machine du serveur mandataire inverse. Vérifiez les fichiers journaux. Surfez aux alentours. Analysez les en-têtes. Quand vous êtes convaincu, déplacez les autres enregistrements DNS,(Domain Name System, système de noms de domaine). Voici une note complémentaire pour déboguer : vous pouvez provoquer un rafraîchissement « réel » dans Internet Explorer et dans Mozilla Firefox si vous appuyez sur la touche Maj tout en cliquant sur le bouton Actualisez. Un rafraîchissement ordinaire peut juste atteindre le cache local, à présent.

Vous n'aurez pas une idée convenable de ce qui est modifié juste en consultant les fichiers journaux. Je préconise un système de surveillance avec des statistiques, Munin, par exemple, de sorte que vous puissiez observer graphiquement ce que font vos serveurs. J'ai deux graphes provenant de serveurs de test, pris pendant une simulation de charge.

Dans le premier graphe, le rouge illustre les erreurs de cache ; le vert affiche les réponses pertinentes du cache. Ci-dessous, vous pouvez observer les réponses pertinentes sur le serveur Apache situé derrière le serveur mandataire inverse. La forme des graphes est similaire, mais gardez à l'esprit que chaque requête illustrée en vert sur le serveur mandataire Squid n'atteint jamais le serveur Apache, et réduit ainsi la charge. Si vous comparez les résultats, vous observerez que seulement une requête sur deux parvient jusqu'au serveur Apache.

4. Résumé

A présent, vous savez ce que vous pouvez réaliser en utilisant les ressources de Apache et Squid. Notre serveur web prend en charge correctement les pics de trafic, la charge du processeur a chuté de 50% et tous les surfeurs étaient de nouveau heureux. Vous pouvez faire beaucoup plus, si vous disposez de multiples connexions à Internet et d'un équilibrage de charge sur le pare-feu ou votre routeur. Heureusement, nous n'avons pas eu besoin de faire ceci dans notre cas.

5. Liens utiles

Aucun animal ou logiciel n'a été blessé pendant la préparation de cet article. Vous pourriez souhaiter jeter un coup d'oeil aux outils et articles suivants ; ils se pourraient qu'ils sauvent votre serveur web.

René est né l’année de la création d’Atari® et de la sortie du jeu Pong. Dès son plus jeune âge, il commençait à démonter les choses pour voir comment elles fonctionnent. Il ne pouvait même pas passer à proximité de chantiers de construction sans chercher des fils électriques qui pourraient sembler intéressants. Sa passion pour l’informatique débuta lorsque son grand-père lui offrit un micro-contrôleur sur 4 bits équipé de 256 octets de mémoire vive et d'un système d’exploitation de 4 096 octets, ce qui le força à apprendre l’assembleur avant tout autre langage.

Une fois sa scolarité terminée, il intègre l’université pour y étudier la physique. Il y accumule de l’expérience sur un C64®, un C128®, deux Amiga®, un Ultrix de DEC®, OpenVMS et finalement, GNU/Linux sur un PC en 1997. Depuis lors, il utilise Linux et aime toujours démonter les choses et les reconstituer. Son aisance à bricoler l'a rendu proche du mouvement du Logiciel libre (Free Software), où il place ses efforts dans le droit à comprendre comment fonctionnent les choses. Il est également impliqué dans des groupes de liberté civile se concentrant sur les droits numériques.

Depuis 1999, il offre ses services en tant qu’indépendant. Ses principales activités comprennent l’administration système/réseau, l'écriture de scripts et le consulting. En 2001, il a commencé à faire des conférences sur la sécurité informatique au Technikum Wien. À part sa curiosité pour les moniteurs informatiques, l'analyse du matériel et le dialogue avec les équipements réseau, c'est un adepte de la plongée en scaphandre autonome, de l’écriture ou de la photographie avec son appareil numérique. Il aimerait faire une expérience de récit oral et de jeu de rôle à nouveau dès qu’il trouvera plus de temps libre sur ses périphériques de sauvegarde.

pooz is a system administrator/Web application hacker working in Vienna, Austria. Free/Open Source software has been his tool of choice since early 90s.

Adaptation française de la Gazette Linux

L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux.

Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site : http://wiki.traduc.org/Gazette_Linux.

Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.