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

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.

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 :

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.

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.

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.