Guide de la mise en cache

Introduction

Depuis la version 2.2 du serveur HTTP Apache, les modules mod_cache et mod_file_cache ne sont plus jug�s exp�rimentaux et on consid�re qu'ils peuvent �tre utilis�s en production. Ces architectures de mise en cache constituent un puissant concept d'acc�l�ration de la gestion HTTP, tant comme serveur web originel que comme mandataire.

Le module mod_cache et ses modules de soutien mod_mem_cache et mod_disk_cache permettent une mise en cache intelligente du point de vue HTTP. Le contenu proprement dit est stock� dans le cache, et mod_cache tente d'honorer tous les en-t�tes HTTP et les options qui d�finissent la possibilit� de mise en cache du contenu. Il g�re non seulement le contenu local, mais aussi le contenu mandat�. mod_cache est con�u pour des configurations de mise en cache simples ou complexes, dans lesquels vous traitez de contenu mandat�, de contenu local dynamique ou avez besoin d'acc�l�rer l'acc�s � des fichiers locaux qui sont modifi�s au cours du temps.

Le module mod_file_cache quant � lui, constitue une forme de mise en cache plus basique, mais quelques fois int�ressante. Plut�t que de g�rer la complexit� de s'assurer de mani�re active de la possibilit� de mise en cache d'URLs, mod_file_cache fournit des m�thodes pour la gestion et l'�dition de fichiers en m�moire afin de maintenir un cache de fichiers dans l'�tat o� ils �taient la derni�re fois qu'Apache a d�marr�. En tant que tel, mod_file_cache a �t� con�u pour am�liorer le temps d'acc�s � des fichiers locaux statiques qui ne sont modifi�s que rarement.

Etant donn� que mod_file_cache constitue une impl�mentation de mise en cache relativement simple, mises � part les sections sp�cifiques sur les directives CacheFile et MMapFile, les explications fournies dans ce guide concernent l'architecture de mise en cache du module mod_cache.

Pour tirer parti efficacement de ce document, les bases de HTTP doivent vous �tre famili�res, et vous devez avoir lu les sections Mise en correspondance des URLs avec le syst�me de fichiers et N�gociation sur le contenu du guide de l'utilisateur.

Vue d'ensemble de la mise en cache

mod_cache peut faire intervenir deux phases principales pendant la dur�e de vie d'une requ�te. En premier lieu, mod_cache est un module de mise en correspondance d'URLs, ce qui signifie que si une URL a �t� mise en cache, et que la version du cache de cette URL n'est pas arriv�e � expiration, la requ�te sera trait�e directement par mod_cache.

Ceci entra�ne que toutes autres actions qui se d�rouleraient normalement au cours du processus de traitement d'une requ�te -- par exemple un traitement effectu� par mod_proxy, ou mod_rewrite -- ne seront pas effectu�es. Mais c'est justement l'int�r�t de la mise en cache pr�alable du contenu.

Si l'URL ne se trouve pas dans le cache, mod_cache va ajouter un filtre au traitement de la requ�te. Une fois le contenu de la r�ponse HTTP trouv� par Apache de mani�re classique, le filtre sera ex�cut� en m�me temps que le contenu sera transmis au client. S'il est d�termin� que le contenu peut �tre mis en cache, il sera sauvegard� dans le cache pour une utilisation future.

Si l'URL se trouve dans le cache, mais est arriv�e � expiration, le filtre est quand-m�me ajout�, mais mod_cache va cr�er une requ�te conditionnelle en arri�re-plan, pour d�terminer si la version du cache est encore � jour. Si la version du cache est encore � jour, ses meta-informations seront mises � jour et la requ�te sera servie � partir du cache. Si la version du contenu n'est plus � jour, elle sera supprim�e et le filtre va sauvegarder le contenu mis � jour dans le cache au moment o� il sera servi.

Am�lioration du taux de pr�sence dans le cache

Lors de la mise en cache de contenu g�n�r� localement, le positionnement de la directive UseCanonicalName � On peut am�liorer de mani�re spectaculaire le taux de pr�sence dans le cache. Ceci est du au fait que le nom d'h�te de l'h�te virtuel qui sert le contenu constitue une partie de la cl� de cache. Avec UseCanonicalName positionn�e � On, les h�tes virtuels poss�dant plusieurs noms de serveur ou alias ne g�n�reront pas d'entit�s de cache diff�rentes, et le contenu sera mis en cache en faisant r�f�rence au nom d'h�te canonique.

Les documents mis en cache ne seront servis qu'en r�ponse � des requ�tes de type URL, car la mise en cache est effectu�e lors de la phase de traduction de l'URL en nom de fichier. En g�n�ral, cela n'a que peu d'effet, � moins que vous n'utilisiez les Inclusions C�t� Serveur (SSI);

<!-- L'inclusion suivante peut �tre mise en cache -->
<!--#include virtual="/footer.html" -->

<!-- L'inclusion suivante ne peut pas �tre mise en cache -->
<!--#include file="/path/to/footer.html" -->

Si vous utilisez les SSI, et voulez b�n�ficier de la vitesse de service depuis le cache, vous devez utiliser des inclusions de type virtual.

P�riodes d'expiration

La p�riode d'expiration par d�faut pour les entit�s du cache est d'une heure; elle peut cependant �tre facilement modifi�e � l'aide de la directive CacheDefaultExpire. Cette valeur par d�faut n'est utilis�e que lorsque la source originale du contenu ne pr�cise pas de p�riode d'expiration ou d'heure de derni�re modification.

Si une r�ponse ne contient pas d'en-t�te Expires mais inclut un en-t�te Last-Modified, mod_cache peut d�duire une p�riode d'expiration en se basant sur la valeur de la directive CacheLastModifiedFactor.

La p�riode d'expiration des contenus locaux peut �tre ajust�e finement en utilisant le module mod_expires.

On peut aussi contr�ler la p�riode d'expiration maximale en utilisant la directive CacheMaxExpire.

Guide succinct des requ�tes conditionnelles

Lorsqu'un contenu est arriv� � expiration dans le cache et fait l'objet d'une nouvelle demande d'acc�s, plut�t que traiter directement la requ�te originale, Apache pr�f�re utiliser une requ�te conditionnelle.

HTTP propose toute une panoplie d'en-t�tes qui permettent � un client, ou au cache de distinguer les diff�rentes versions d'un m�me contenu. Par exemple, si une ressource a �t� servie avec un en-t�te "Etag:", il est possible de cr�er une requ�te conditionnelle contenant un en-t�te "If-None-Match:". Si une ressource a �t� servie avec un en-t�te "Last-Modified:", il est possible de cr�er une requ�te conditionnelle contenant un en-t�te "If-Modified-Since:", etc....

Lorsqu'une telle requ�te conditionnelle est cr��e, la reponse diff�re selon que le contenu satisfait ou non aux conditions. Si une requ�te est cr��e avec un en-t�te "If-Modified-Since:", et le contenu n'a pas �t� modifi� depuis le moment indiqu� dans la requ�te, alors un laconique "304 Not Modified" est retourn�.

Si le contenu a �t� modifi�, il est servi comme si la requ�te n'avait pas �t� conditionnelle � l'origine.

Les b�n�fices des requ�tes conditionnelles pour ce qui concerne la mise en cache sont de deux sortes. Premi�rement, quand une telle requ�te est envoy�e au processus en arri�re-plan, il sera ais� de d�terminer si le contenu que devra servir le processus en arri�re-plan correspond au contenu stock� dans le cache, sans �tre oblig� de transmettre la totalit� de la ressource.

Deuxi�mement, les requ�tes conditionnelles sont en g�n�ral moins co�teuses en ressources pour le processus en arri�re-plan. Pour ce qui est des fichiers statiques, l'action type est un appel � stat() ou un appel syst�me similaire, pour d�terminer si la taille du fichier ou sa date de modification ont chang�. Ainsi, m�me si Apache met en cache le contenu local, un contenu arriv� � expiration pourra �tre servi plus rapidement depuis le cache s'il n'a pas �t� modifi�, parce que la lecture depuis le cache est plus rapide que la lecture depuis le processus en arri�re-plan (� comparer � la diff�rence de vitesse entre la lecture depuis un cache en m�moire et la lecture depuis un disque).

Que peut-on mettre en cache ?

Comme mentionn� plus haut, les deux styles de mise en cache d'Apache fonctionnent diff�remment; la mise en cache de mod_file_cache conserve les contenus des fichiers tels qu'ils �taient au d�marrage d'Apache. Quand une requ�te pour un fichier mis en cache par ce module est envoy�e, elle est intercept�e et le fichier mis en cache est servi.

La mise en cache de mod_cache, quant � elle, est plus complexe. Lors du traitement d'une requ�te, le module de mise en cache d�terminera si le contenu peut �tre mis en cache, s'il ne l'a pas d�j� �t� auparavant. Les conditions qui permettent de d�terminer la possibilit� de mise en cache d'une r�ponse sont :

1. La mise en cache doit �tre activ�e pour cette URL. Voir les directives CacheEnable et CacheDisable.
2. La reponse doit avoir un code de statut HTTP de 200, 203, 300, 301 ou 410.
3. La requ�te doit �tre de type HTTP GET.
4. Si la requ�te contient un en-t�te "Authorization:", la r�ponse ne sera pas mise en cache.
5. Si la r�ponse contient un en-t�te "Authorization:", elle doit aussi contenir une option "s-maxage", "must-revalidate" ou "public" dans l'en-t�te "Cache-Control:".
6. Si l'URL contient une cha�ne de param�tres (provenant par exemple d'une m�thode GET de formulaire HTML), elle ne sera pas mise en cache � moins que la r�ponse ne sp�cifie une condition d'expiration explicite via un en-t�te "Expires:" ou la directive max-age ou s-maxage de l'en-t�te "Cache-Control:", comme pr�conis� dans la RFC2616, sections 13.9 et 13.2.1.
7. Si la r�ponse a un statut de 200 (OK), elle doit aussi contenir au moins un des en-t�tes "Etag", "Last-Modified" ou "Expires", ou la directive max-age ou s-maxage de l'en-t�te "Cache-Control:", � moins que la directive CacheIgnoreNoLastMod ne pr�cise d'autres contraintes.
8. Si la r�ponse contient l'option "private" dans un en-t�te "Cache-Control:", elle ne sera pas mise en cache � moins que la directive CacheStorePrivate ne pr�cise d'autres contraintes.
9. De m�me, si la r�ponse contient l'option "no-store" dans un en-t�te "Cache-Control:", elle ne sera pas mise en cache � moins que la directive CacheStoreNoStore n'ait �t� utilis�e.
10. Une r�ponse ne sera pas mise en cache si elle comporte un en-t�te "Vary:" contenant le caract�re "*" qui correspond � toute cha�ne de caract�res.

Qu'est ce qui ne doit pas �tre mis en cache ?

En bref, tout contenu qui varie beaucoup avec le temps, ou en fonction de particularit�s de la requ�te qui ne sont pas couvertes par la n�gociation HTTP, ne doit pas �tre mis en cache.

Un contenu dynamique qui varie en fonction de l'adresse IP du demandeur, ou qui est modifi� toutes les 5 minutes, ne devra en g�n�ral pas �tre mis en cache.

Si par contre le contenu servi diff�re en fonction de la valeur de divers en-t�tes HTTP, il se peut que l'on puisse le mettre en cache intelligemment en utilisant un en-t�te "Vary".

Contenu variable et/ou n�goci�

Si mod_cache re�oit une r�ponse contenant un en-t�te "Vary", lorsqu'un contenu a �t� demand� par un processus d'arri�re-plan, il va s'efforcer de la traiter intelligemment. Si possible, mod_cache va d�tecter les en-t�tes attribu�s dans la r�ponse "Vary" � l'occasion des futures demandes, et servir une r�ponse correcte � partir du cache.

Si par exemple, une r�ponse est re�ue avec l'en-t�te Vary suivant,

mod_cache ne servira aux demandeurs que le contenu mis en cache qui correspond au contenu des en-t�tes accept-language et accept-charset de la requ�te originale.

Consid�rations sur la s�curit�

Autorisation et contr�le d'acc�s

Utiliser mod_cache revient sensiblement � la m�me chose qu'avoir un mandataire inverse int�gr� (reverse-proxy). Les requ�tes seront servies par le module de mise en cache sauf si ce dernier d�termine qu'un processus d'arri�re-plan doit �tre appel�. La mise en cache de ressources locales modifie consid�rablement le mod�le de s�curit� d'Apache.

Comme le parcours de la hi�rarchie d'un syst�me de fichiers pour examiner le contenu d'�ventuels fichiers .htaccess serait une op�ration tr�s co�teuse en ressources, annulant partiellement de ce fait l'int�r�t de la mise en cache (acc�l�rer le traitement des requ�tes), mod_cache ne se pr�occupe pas de savoir s'il a l'autorisation de servir une entit� mise en cache. En d'autres termes, si mod_cache a mis en cache un certain contenu, ce dernier sera servi � partir du cache tant qu'il ne sera pas arriv� � expiration.

Si par exemple, votre configuration autorise l'acc�s � une ressource en fonction de l'adresse IP, vous devez vous assurer que ce contenu n'est pas mis en cache. Ceci est possible en utilisant la directive CacheDisable, ou le module mod_expires. Livr� � lui-m�me, mod_cache - pratiquement comme un mandataire inverse - mettrait en cache le contenu lors de son service, et le servirait ensuite � tout client, vers n'importe quelle adresse IP.

Piratages locaux

Etant donn� que les requ�tes des utilisateurs finaux peuvent �tre servies depuis le cache, ce dernier est une cible potentielle pour ceux qui veulent d�figurer un contenu ou interf�rer avec lui. Il est important de garder � l'esprit que l'utilisateur sous lequel tourne Apache doit toujours avoir l'acc�s en �criture dans le cache. Ceci est en contraste total avec la recommandation usuelle d'interdire � l'utilisateur sous lequel tourne Apache l'acc�s en �criture � tout contenu.

Si l'utilisateur sous lequel tourne Apache est compromis, par exemple � cause d'une faille de s�curit� dans un processus CGI, il est possible que le cache fasse l'objet d'une attaque. Il est relativement ais� d'ins�rer ou de modifier une entit� dans le cache en utilisant le module mod_disk_cache.

Cela repr�sente un risque relativement �l�v� par rapport aux autres types d'attaques qu'il est possible de mener sous l'utilisateur apache. Si vous utilisez mod_disk_cache, vous devez garder ceci � l'esprit : effectuez toujours les mises � jour d'Apache quand des correctifs de s�curit� sont annonc�s et ex�cutez les processus CGI sous un utilisateur autre qu'apache en utilisant suEXEC dans la mesure du possible.

Empoisonnement du cache (Cache Poisoning)

Si vous utilisez Apache comme serveur mandataire avec mise en cache, vous vous exposez aussi � un �ventuel "Empoisonnement du cache" (Cache poisoning). L'empoisonnement du cache est un terme g�n�ral pour d�signer les attaques au cours desquelles l'attaquant fait en sorte que le serveur mandataire renvoie un contenu incorrect (et souvent ind�sirable) en provenance du serveur d'arri�re plan.

Par exemple, si les serveur DNS qu'utilise votre syst�me o� tourne Apache sont vuln�rables � l'empoisonnement du cache des DNS, un attaquant pourra contr�ler vers o� Apache se connecte lorsqu'il demande un contenu depuis le serveur d'origine. Un autre exemple est constitu� par les attaques ainsi nomm�es "Dissimulation de requ�tes HTTP" (HTTP request-smuggling).

Ce document n'est pas le bon endroit pour une discussion approfondie � propos de la Dissimulation de requ�tes HTTP (utilisez plut�t votre moteur de recherche favori); il est cependant important de savoir qu'il est possible d'�laborer une s�rie de requ�tes, et d'exploiter une vuln�rabilit� d'un serveur web d'origine de telle fa�on que l'attaquant puisse contr�ler enti�rement le contenu renvoy� par le mandataire.

Mise en cache de la gestion de fichier

Le fait d'ouvrir un fichier peut en lui-m�me introduire un d�lai, en particulier dans les syst�mes de fichiers r�partis sur le r�seau. Apache peut s'affranchir de ce d�lai en maintenant un cache des descripteurs de fichiers ouverts pour ce qui concerne les fichiers souvent acc�d�s. Apache propose actuellement deux impl�mentations diff�rentes de mise en cache de la gestion de fichier.

Directive CacheFile

La forme la plus �l�mentaire de mise en cache que propose Apache est fournie par le module mod_file_cache. Plut�t que de mettre en cache le contenu des fichiers, ce cache maintient une table des descripteurs de fichiers ouverts. Les fichiers � mettre en cache de cette mani�re sont sp�cifi�s dans le fichier de configuration en utilisant la directive CacheFile.

La directive CacheFile demande � Apache d'ouvrir le fichier lors de son d�marrage et de r�utiliser le descripteur de fichier �labor� � cette occasion pour tous les acc�s ult�rieurs � ce fichier.

CacheFile /usr/local/apache2/htdocs/index.html

Si vous avez l'intention de mettre en cache un grand nombre de fichiers de cette mani�re, vous devez vous assurer que le nombre maximum de fichiers ouverts par votre syst�me d'exploitation est correctement d�fini.

Bien que l'utilisation de la directive CacheFile n'entra�ne pas la mise en cache du contenu du fichier, cela ne signifie pas qu'en cas de modification du fichier pendant l'ex�cution d'Apache, ces changements seront pris en compte. Le fichier sera toujours servi dans l'�tat o� il �tait quand Apache a d�marr�.

Si le fichier est supprim� pendant l'ex�cution d'Apache, ce dernier continuera � maintenir un descripteur de fichier ouvert et � servir le fichier dans l'�tat o� il �tait quand Apache a d�marr�. Cela signifie aussi habituellement que malgr� le fait que le fichier ait �t� supprim�, et ne soit plus accessible par le syst�me de fichiers, l'espace lib�r� ne sera restitu� qu'� l'arr�t d'Apache quand le descripteur de fichier sera ferm�.

Directive CacheEnable

Le module mod_mem_cache propose aussi son propre sch�ma de mise en cache de la gestion de fichier, qui peut �tre activ� � l'aide de la directive CacheEnable.

CacheEnable fd /

A l'instar de tout ce qui concerne le module mod_cache, ce mode de mise en cache de la gestion de fichier est intelligent, et les descripteurs ne seront plus maintenus lorsque le contenu mis en cache sera arriv� � expiration.

Mise en cache en m�moire

Servir un contenu directement depuis la m�moire syst�me est universellement reconnu comme la m�thode la plus rapide. Lire des fichiers depuis un contr�leur de disque ou pire, depuis un r�seau distant est plus lent de plusieurs ordres de grandeur. Les contr�leurs de disque r�alisent en g�n�ral des op�rations m�caniques, et l'acc�s au r�seau est limit� par la bande passante dont vous disposez. Par contre, les temps d'acc�s � la m�moire sont de l'ordre de la nano-seconde.

Cependant la m�moire syst�me n'est pas bon march�; � capacit� �gale, c'est de loin le type de stockage le plus co�teux et il est important de s'assurer qu'elle est utilis�e efficacement. Le fait de mettre en cache des fichiers en m�moire diminue d'autant la quantit� de m�moire syst�me disponible. Comme nous le verrons plus loin, ce n'est pas un probl�me en soi dans le cas de la mise en cache par l'interm�diaire du syst�me d'exploitation, mais si l'on utilise la mise en cache en m�moire propre � Apache, il faut prendre garde � ne pas allouer trop de m�moire au cache. Sinon le syst�me sera contraint d'utiliser le swap, ce qui d�gradera sensiblement les performances.

Mise en cache par l'interm�diaire du syst�me d'exploitation

Dans la plupart des syst�mes d'exploitation modernes, c'est le noyau qui g�re directement la mise en cache en m�moire des donn�es relatives aux fichiers. C'est une fonctionnalit� puissante, et les syst�mes d'exploitation s'en acquittent fort bien pour la plus grande partie. Consid�rons par exemple, dans le cas de Linux, la diff�rence entre le temps n�cessaire � la premi�re lecture d'un fichier et le temps n�cessaire � sa deuxi�me lecture;

colm@coroebus:~$ time cat testfile > /dev/null
real    0m0.065s
user    0m0.000s
sys     0m0.001s
colm@coroebus:~$ time cat testfile > /dev/null
real    0m0.003s
user    0m0.003s
sys     0m0.000s

M�me pour ce petit fichier, il y a une grande diff�rence entre les temps n�cessaires pour lire le fichier. Ceci est du au fait que le noyau a mis en cache le contenu du fichier en m�moire.

Du fait de toujours pouvoir disposer de m�moire syst�me, vous pouvez �tre assur� qu'il y aura de plus en plus de contenus de fichiers stock�s dans ce cache. Ceci peut s'av�rer une m�thode de mise en cache en m�moire tr�s efficace, et ne n�cessite aucune configuration suppl�mentaire d'Apache.

De plus, comme le syst�me d'exploitation sait si des fichiers ont �t� supprim�s ou modifi�s, il peut effacer automatiquement des contenus de fichiers du cache lorsque cela s'av�re n�cessaire. Ceci constitue un gros avantage par rapport � la mise en cache en m�moire d'Apache qui n'a aucune possibilit� de savoir si un fichier a �t� modifi�.

En d�pit des performances et des avantages de la mise en cache automatique par le syst�me d'exploitation, la mise en cache en m�moire peut �tre effectu�e plus efficacement par Apache dans certaines circonstances.

En premier lieu, un syst�me d'exploitation ne peut mettre en cache que les fichiers dont il a connaissance. Si vous ex�cutez Apache en tant que serveur mandataire, les fichiers que vous mettez en cache ne sont pas stock�s en local mais sur un serveur distant. Si vous voulez tout de m�me b�n�ficier de la vitesse incomparable procur�e par la mise en cache en m�moire, la mise en cache propre � Apache sera n�cessaire.

Mise en cache � l'aide de la directive MMapFile

La directive MMapFile fournie par le module mod_file_cache vous permet de demander � Apache de charger un contenu de fichier statique en m�moire lors de son d�marrage (� l'aide de l'appel syst�me mmap). Apache utilisera le contenu charg� en m�moire pour satisfaire ult�rieurement toutes les demandes d'acc�s � ce fichier.

MMapFile /usr/local/apache2/htdocs/index.html

Comme dans le cas de la directive CacheFile, toute modification du fichier ne sera plus prise en compte par Apache une fois ce dernier d�marr�.

La directive MMapFile ne gardant pas la trace de la quantit� de m�moire qu'elle alloue, vous devez prendre garde de ne pas en abuser. Chaque processus enfant d'Apache utilisant sa propre r�plique de la m�moire allou�e, il est donc d'une importance critique de s'assurer que les fichiers charg�s ne sont pas d'une taille trop importante afin d'�pargner au syst�me l'utilisation du swap.

Mise en cache � l'aide du module mod_mem_cache

Le module mod_mem_cache propose une mise en cache en m�moire intelligente du point de vue du protocole HTTP. Il utilise aussi directement le "tas" de la m�moire, ce qui signifie que m�me si MMap n'est pas support� par votre syst�me, mod_mem_cache pourra quand-m�me effectuer la mise en cache.

La mise en cache selon cette m�thode est activ�e comme suit :

# Activation de la mise en cache en m�moire
CacheEnable mem /

# Limite la taille du cache � 1 M�gaoctet
MCacheSize 1024

Mise en cache sur disque

Le module mod_disk_cache fournit un m�canisme de mise en cache sur disque au module mod_cache. Comme dans le cas du module mod_mem_cache, cette mise en cache est intelligente et le contenu ne sera servi qu'� partir du cache tant qu'il sera consid�r� comme valide.

Typiquement, le module sera configur� comme suit :

CacheRoot   /var/cache/apache/
CacheEnable disk /
CacheDirLevels 2
CacheDirLength 1

Il est important de savoir que, les fichiers mis en cache �tant stock�s localement, la mise en cache par l'interm�diaire du syst�me d'exploitation sera en g�n�ral aussi appliqu�e � leurs acc�s. Si bien que m�me si les fichiers sont stock�s sur disque, s'il font l'objet d'acc�s fr�quents, il est probable que le syst�me d'exploitation s'appliquera � ce qu'ils soient servis � partir de la m�moire.

Comprendre le stockage dans le cache

Pour stocker des entit�s dans le cache, le module mod_disk_cache cr�e une empreinte (hash) de 22 caract�res de l'URL qui a fait l'objet d'une requ�te. Cette empreinte comprend le nom d'h�te, le protocole, le port, le chemin et tout argument de type CGI associ� � l'URL, afin d'�tre sur que plusieurs URLs n'interf�rent pas entre elles.

Chaque position de l'empreinte peut contenir un caract�re choisi parmi 64 caract�res diff�rents, il y a donc 64^22 possibilit�s pour une empreinte. Par exemple, une URL peut poss�der l'empreinte xyTGxSMO2b68mBCykqkp1w. Cette empreinte est utilis�e pour pr�fixer les noms de fichiers sp�cifiques � cette URL � l'int�rieur du cache; cependant, elle est tout d'abord plac�e dans les r�pertoires du cache selon les directives CacheDirLevels et CacheDirLength.

La directive CacheDirLevels d�finit le nombre de niveaux de sous-r�pertoires, et CacheDirLength le nombre de caract�res composant le nom des sous-r�pertoires. Dans l'exemple donn� plus haut, l'empreinte se trouvera � : /var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w.

Cette technique a pour but principal de r�duire le nombre de sous-r�pertoires ou de fichiers contenus dans un r�pertoire particulier, car le fonctionnement de la plupart des syst�mes de fichiers est ralenti quand ce nombre augmente. Avec la valeur "1" pour la directive CacheDirLength, il peut y avoir au plus 64 sous-r�pertoires � un niveau quelconque. Avec la valeur "2", il peut y en avoir 64 * 64, etc... A moins d'avoir une bonne raison pour ne pas le faire, l'utilisation de la valeur "1" pour la directive CacheDirLength est recommand�e.

Le param�trage de la directive CacheDirLevels d�pend du nombre de fichiers que vous pensez stocker dans le cache. Avec une valeur de "2" comme dans l'exemple donn� plus haut, 4096 sous-r�pertoires peuvent �tre cr��s au total. Avec 1 million de fichiers dans le cache, cela �quivaut � environ 245 URLs mises en cache dans chaque r�pertoire.

Chaque URL n�cessite au moins deux fichiers dans le cache. Ce sont en g�n�ral un fichier ".header", qui contient des meta-informations � propos de l'URL, comme la date de son arriv�e � expiration, et un fichier ".data" qui est la copie exacte du contenu � servir.

Dans le cas d'un contenu n�goci� via l'en-t�te "Vary", un r�pertoire ".vary" sera cr�� pour l'URL en question. Ce r�pertoire contiendra de multiples fichiers ".data" correspondant aux diff�rents contenus n�goci�s.

Maintenance du cache sur disque

Bien que le module mod_disk_cache supprime un contenu du cache lorsqu'il est arriv� � expiration, il ne maintient aucune information � propos de la taille totale du cache ou de l'espace restant disponible.

Par contre l'utilitaire htcacheclean fourni avec Apache vous permet, comme son nom l'indique, de nettoyer le cache p�riodiquement. D�terminer la fr�quence � laquelle lancer htcacheclean et la taille souhait�e pour le cache est une t�che relativement complexe et il vous faudra de nombreux essais et erreurs pour arriver � s�lectionner des valeurs optimales.

htcacheclean op�re selon deux modes. Il peut s'ex�cuter comme d�mon r�sident, ou �tre lanc� p�riodiquement par cron. htcacheclean peut mettre une heure ou plus pour traiter de tr�s grands caches (plusieurs dizaines de Gigaoctets) et si vous l'ex�cutez � partir de cron, il vous est conseill� de d�terminer la dur�e typique d'un traitement, afin d'�viter d'ex�cuter plusieurs instances � la fois.

Figure 1: Croissance typique du cache / s�quence de nettoyage.

Comme mod_disk_cache ne tient pas compte de l'espace utilis� dans le cache, vous devez vous assurer que htcacheclean est configur� de fa�on � laisser suffisamment d'"espace de croissance" � la suite d'un nettoyage.