-
+
-
+
Le module mod_cache permet de tirer avantage du
- mécanisme de mise en cache en ligne faisant partie
- intégrante du protocole HTTP, et décrit dans la section
+ mécanisme de mise en cache en ligne faisant partie
+ intégrante du protocole HTTP, et décrit dans la section
13 de la RFC2616.
-
A la différence d'un cache simple clé/valeur à deux états où le
- contenu est supprimé lorsqu'il est périmé, un cache HTTP comporte un
- mécanisme permettant de conserver temporairement un contenu périmé,
- de demander au serveur original si ce contenu périmé a été modifié,
- et dans le cas contraire de le rendre à nouveau valide.
+
A la différence d'un cache simple clé/valeur à deux états où le
+ contenu est supprimé lorsqu'il est périmé, un cache HTTP comporte un
+ mécanisme permettant de conserver temporairement un contenu périmé,
+ de demander au serveur original si ce contenu périmé a été modifié,
+ et dans le cas contraire de le rendre à nouveau valide.
-
Une entrée d'un cache HTTP peut se présenter sous un de ces trois
- états :
+
Une entrée d'un cache HTTP peut se présenter sous un de ces trois
+ états :
- Frais
-
- Si un contenu est suffisamment récent (plus jeune que sa
- durée de fraîcheur), il est considéré comme
+ Si un contenu est suffisamment récent (plus jeune que sa
+ durée de fraîcheur), il est considéré comme
frais. Un cache HTTP peut servir un contenu
- frais sans avoir à demander quoi que ce soit au serveur
+ frais sans avoir à demander quoi que ce soit au serveur
d'origine.
- - Périmé
+ - Périmé
-
Si le contenu est trop ancien (plus vieux que sa
- durée de fraîcheur), il est considéré comme
- périmé. Un cache HTTP doit contacter le serveur
- original pour vérifier si le contenu, même s'il est périmé, est
- encore à jour avant de le servir au client. Soit le serveur
- original va répondre en envoyant un contenu de remplacement si
- le contenu périmé n'est plus à jour, soit dans le cas idéal il
+ durée de fraîcheur), il est considéré comme
+ périmé. Un cache HTTP doit contacter le serveur
+ original pour vérifier si le contenu, même s'il est périmé, est
+ encore à jour avant de le servir au client. Soit le serveur
+ original va répondre en envoyant un contenu de remplacement si
+ le contenu périmé n'est plus à jour, soit dans le cas idéal il
renverra un code pour signaler au cache que le contenu est
- encore à jour, et qu'il est inutile de le générer ou de
- l'envoyer à nouveau. Le contenu repasse à l'état "frais" et le
+ encore à jour, et qu'il est inutile de le générer ou de
+ l'envoyer à nouveau. Le contenu repasse à l'état "frais" et le
cycle continue.
- Le protocole HTTP permet au cache de servir des données
- périmées dans certaines circonstances, comme lorsqu'une
- tentative de rafraîchir une entrée depuis un serveur original
- se solde par un échec avec un code d'erreur 5xx, ou lorsqu'une
- autre requête est déjà en train d'essayer de rafraîchir la même
- entrée. Dans ces cas, un en-tête Warning est ajouté
- à la réponse.
+ Le protocole HTTP permet au cache de servir des données
+ périmées dans certaines circonstances, comme lorsqu'une
+ tentative de rafraîchir une entrée depuis un serveur original
+ se solde par un échec avec un code d'erreur 5xx, ou lorsqu'une
+ autre requête est déjà en train d'essayer de rafraîchir la même
+ entrée. Dans ces cas, un en-tête Warning est ajouté
+ à la réponse.
- Non Existent
-
- Si le cache est plein, il se réserve la possibilité de supprimer
- des entrées pour faire de la place. Une entrée peut être
- supprimée à tout moment, qu'elle soit fraîche ou périmée.
+ Si le cache est plein, il se réserve la possibilité de supprimer
+ des entrées pour faire de la place. Une entrée peut être
+ supprimée à tout moment, qu'elle soit fraîche ou périmée.
L'outil htcacheclean
- peut être utilisé à la demande, ou lancé en tant que démon afin
- de conserver la taille du cache ou le nombre d'inodes en deçà de
- valeurs spécifiées. Cet outil essaie cependant de
- supprimer les entrées périmées avant les entrées fraîches.
+ peut être utilisé à la demande, ou lancé en tant que démon afin
+ de conserver la taille du cache ou le nombre d'inodes en deçà de
+ valeurs spécifiées. Cet outil essaie cependant de
+ supprimer les entrées périmées avant les entrées fraîches.
-
Le fonctionnement détaillé d'un cache HTTP est décrit dans la Section
+ Le fonctionnement détaillé d'un cache HTTP est décrit dans la Section
13 de la RFC2616.
Interaction avec le serveur
Le module mod_cache interagit avec le serveur
- à deux niveaux possibles en fonction de la directive CacheQuickHandler :
+ à deux niveaux possibles en fonction de la directive CacheQuickHandler :
- Phase de gestion rapide
-
-
Cette phase se déroule très tôt au cours du traitement de
- la requête, juste après l'interprétation de cette dernière. Si
- le contenu se trouve dans le cache, il est servi immédiatement
- et pratiquement tout le reste du traitement de la requête est
- court-circuité.
-
- Dans ce scénario, le cache se comporte comme s'il avait
- été "boulonné" à l'entrée du serveur.
+ Cette phase se déroule très tôt au cours du traitement de
+ la requête, juste après l'interprétation de cette dernière. Si
+ le contenu se trouve dans le cache, il est servi immédiatement
+ et pratiquement tout le reste du traitement de la requête est
+ court-circuité.
+
+ Dans ce scénario, le cache se comporte comme s'il avait
+ été "boulonné" à l'entrée du serveur.
- Ce mode possède les meilleures performances car la
- majorité des traitements au niveau du serveur sont
- court-circuités. Cependant, il court-circuite aussi les
+
Ce mode possède les meilleures performances car la
+ majorité des traitements au niveau du serveur sont
+ court-circuités. Cependant, il court-circuite aussi les
phases d'authentification et d'autorisation du traitement
- au niveau du serveur, et il doit donc être utilisé avec
+ au niveau du serveur, et il doit donc être utilisé avec
prudence lorsque que ces phases sont importantes.
- Les requêtes comportant un en-tête "Authorization"
+
Les requêtes comportant un en-tête "Authorization"
(comme par exemple l'authentification HTTP basique) ne
- peuvent être ni mises en cache, ni servies depuis ce
- dernier lorsque mod_cache s'exécute dans
+ peuvent être ni mises en cache, ni servies depuis ce
+ dernier lorsque mod_cache s'exécute dans
cette phase.
- Phase de gestion normale
-
-
Cette phase se déroule très tard au cours du traitement
- de la requête, en fait après toutes les phases de ce
+
Cette phase se déroule très tard au cours du traitement
+ de la requête, en fait après toutes les phases de ce
traitement.
- Dans ce scénario, le cache se comporte comme s'il avait
- été "boulonné" à la sortie du serveur.
+ Dans ce scénario, le cache se comporte comme s'il avait
+ été "boulonné" à la sortie du serveur.
Ce mode offre la plus grande souplesse, car il permet
de faire intervenir la mise en cache en un point
- précisément spécifié de la chaîne de filtrage, et le
- contenu issu du cache peut être filtré ou personnalisé
- avant d'être servi au client.
+ précisément spécifié de la chaîne de filtrage, et le
+ contenu issu du cache peut être filtré ou personnalisé
+ avant d'être servi au client.
Si l'URL ne se trouve pas dans le cache,
- mod_cache ajoutera un filtre à la chaîne de filtrage afin
- d'enregistrer la réponse dans le cache, puis passera la main
- pour permettre le déroulement normal de la suite du traitement
- de la requête. Si la mise en cache du contenu est autorisée, il
- sera enregistré dans le cache pour pouvoir être servi à nouveau
- ; dans le cas contraire, le contenu sera ignoré.
-
-
Si le contenu trouvé dans le cache est périmé, le module
- mod_cache convertit la requête en
- requête conditionnelle. Si le serveur original
- renvoie une réponse normale, elle est enregistrée dans le cache
- en lieu et place du contenu périmé. Si le serveur original
- renvoie une réponse "304 Not Modified", le contenu repasse à
- l'état "frais" et est servi par le filtre au lieu d'être
- sauvegardé.
+
mod_cache ajoutera un
filtre à la chaîne de filtrage afin
+ d'enregistrer la réponse dans le cache, puis passera la main
+ pour permettre le déroulement normal de la suite du traitement
+ de la requête. Si la mise en cache du contenu est autorisée, il
+ sera enregistré dans le cache pour pouvoir être servi à nouveau
+ ; dans le cas contraire, le contenu sera ignoré.
+
+
Si le contenu trouvé dans le cache est périmé, le module
+ mod_cache convertit la requête en
+ requête conditionnelle. Si le serveur original
+ renvoie une réponse normale, elle est enregistrée dans le cache
+ en lieu et place du contenu périmé. Si le serveur original
+ renvoie une réponse "304 Not Modified", le contenu repasse à
+ l'état "frais" et est servi par le filtre au lieu d'être
+ sauvegardé.
-
Amélioration du taux de présence dans le cache
+
Amélioration du taux de présence dans le cache
Lorsqu'un serveur virtuel est connu sous la forme d'un des
- nombreux alias du serveur, la définition de la directive
- UseCanonicalName à
- On peut augmenter de manière significative le nombre
+ nombreux alias du serveur, la définition de la directive
+ UseCanonicalName à
+ On peut augmenter de manière significative le nombre
de correspondances positives dans le cache. Ceci est du au fait
- que la clé du cache contient le nom d'hôte du serveur virtuel.
- 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.
+ que la clé du cache contient le nom d'hôte du serveur virtuel.
+ 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.
-
Durée de fraîcheur
+
Durée de fraîcheur
-
Un contenu bien formé destiné à être mis en cache doit déclarer
- explicitement une durée de fraîcheur via les champs
- max-age ou s-maxage de l'en-tête
- Cache-Control, ou en incluant un en-tête
+
Un contenu bien formé destiné à être mis en cache doit déclarer
+ explicitement une durée de fraîcheur via les champs
+ max-age ou s-maxage de l'en-tête
+ Cache-Control, ou en incluant un en-tête
Expires.
-
De plus, un client peut passer outre la durée de fraîcheur
- définie pour le serveur original en ajoutant son propre en-tête
- Cache-Control à la requête. Dans ce cas, c'est la
- durée de fraîcheur la plus basse entre la requête et la réponse
+
De plus, un client peut passer outre la durée de fraîcheur
+ définie pour le serveur original en ajoutant son propre en-tête
+ Cache-Control à la requête. Dans ce cas, c'est la
+ durée de fraîcheur la plus basse entre la requête et la réponse
qui l'emporte.
-
Lorsque cette durée de fraîcheur est absente de la requête ou
- de la réponse, une durée de fraîcheur par défaut s'applique. La
- durée de fraîcheur par défaut des entrées du cache est d'une heure
- ; elle peut cependant être facilement modifiée à l'aide de
+
Lorsque cette durée de fraîcheur est absente de la requête ou
+ de la réponse, une durée de fraîcheur par défaut s'applique. La
+ durée de fraîcheur par défaut des entrées du cache est d'une heure
+ ; elle peut cependant être facilement modifiée à l'aide de
la directive CacheDefaultExpire.
-
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 durée de fraîcheur en se basant sur une
- heuristique, qui peut être contrôlée via la directive CacheLastModifiedFactor.
+
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 durée de fraîcheur en se basant sur une
+ heuristique, qui peut être contrôlée via la directive CacheLastModifiedFactor.
Pour les contenus locaux, ou les contenus distants qui ne
- spécifient pas leur propre en-tête Expires,
- mod_expires permet de régler finement la durée de
- fraîcheur via les paramètres max-age et
+ spécifient pas leur propre en-tête Expires,
+ mod_expires permet de régler finement la durée de
+ fraîcheur via les paramètres max-age et
Expires.
-
On peut aussi contrôler la durée de fraîcheur maximale en utilisant
+
On peut aussi contrôler la durée de fraîcheur maximale en utilisant
la directive CacheMaxExpire.
-
Guide succinct des requêtes conditionnelles
+
Guide succinct des requêtes conditionnelles
-
Lorsqu'un contenu du cache est périmé, httpd modifie la requête
- pour en faire une requête conditionnelle
+
Lorsqu'un contenu du cache est périmé, httpd modifie la requête
+ pour en faire une requête conditionnelle
-
Lorsque la réponse originale du cache contient un en-tête
- ETag, mod_cache ajoute un en-tête
- If-None-Match à la requête envoyée au serveur
- d'origine. Lorsque la réponse originale du cache contient un en-tête
- Last-Modified, mod_cache ajoute un en-tête
- If-Modified-Since à la requête envoyée au serveur
- d'origine. Dans ces deux cas, la requête devient une requête
+
Lorsque la réponse originale du cache contient un en-tête
+ ETag, mod_cache ajoute un en-tête
+ If-None-Match à la requête envoyée au serveur
+ d'origine. Lorsque la réponse originale du cache contient un en-tête
+ Last-Modified, mod_cache ajoute un en-tête
+ If-Modified-Since à la requête envoyée au serveur
+ d'origine. Dans ces deux cas, la requête devient une requête
conditionnelle.
-
Lorsqu'un serveur d'origine reçoit une requête conditionnelle,
- il vérifie si le paramètre Etag ou Last-Modified a été modifié en
- fonction des paramètres de la requête. Si ce n'est pas le cas, il
- répondra avec le message lapidaire "304 Not Modified". Ceci
- informe le cache que le contenu est périmé mais encore à jour, et
- peut être utilisé tel quel pour les prochaines requêtes jusqu'à ce
- qu'il atteigne à nouveau sa date de péremption.
-
-
Si le contenu a été modifié, il est servi comme s'il s'agissait
- d'une requête normale et non conditionnelle.
-
-
Les requêtes conditionnelles offrent deux avantages. D'une
- part, il est facile de déterminer si le contenu du serveur
- d'origine correspond à celui situé
- dans le cache, et ainsi d'économiser la consommation de ressources
- nécessaire au transfert du contenu dans son ensemble.
-
-
D'autre part, un serveur d'origine bien conçu sera configuré de
- telle manière que les requêtes conditionnelles nécessitent pour
- leur production bien moins de ressources qu'une réponse complète.
- Dans le cas des fichiers statiques, il suffit en général d'un
- appel système de type stat() ou similaire pour
- déterminer si la taille ou la date de modification du fichier a
- été modifiée. Ainsi, même un contenu local pourra être servi plus
- rapidement depuis le cache s'il n'a pas été modifié.
+
Lorsqu'un serveur d'origine reçoit une requête conditionnelle,
+ il vérifie si le paramètre Etag ou Last-Modified a été modifié en
+ fonction des paramètres de la requête. Si ce n'est pas le cas, il
+ répondra avec le message lapidaire "304 Not Modified". Ceci
+ informe le cache que le contenu est périmé mais encore à jour, et
+ peut être utilisé tel quel pour les prochaines requêtes jusqu'à ce
+ qu'il atteigne à nouveau sa date de péremption.
+
+
Si le contenu a été modifié, il est servi comme s'il s'agissait
+ d'une requête normale et non conditionnelle.
+
+
Les requêtes conditionnelles offrent deux avantages. D'une
+ part, il est facile de déterminer si le contenu du serveur
+ d'origine correspond à celui situé
+ dans le cache, et ainsi d'économiser la consommation de ressources
+ nécessaire au transfert du contenu dans son ensemble.
+
+
D'autre part, un serveur d'origine bien conçu sera configuré de
+ telle manière que les requêtes conditionnelles nécessitent pour
+ leur production bien moins de ressources qu'une réponse complète.
+ Dans le cas des fichiers statiques, il suffit en général d'un
+ appel système de type stat() ou similaire pour
+ déterminer si la taille ou la date de modification du fichier a
+ été modifiée. Ainsi, même un contenu local pourra être servi plus
+ rapidement depuis le cache s'il n'a pas été modifié.
Il serait souhaitable que tous les serveurs d'origine
- supportent les requêtes conditionnelles, car dans le cas
- contraire, ils répondent comme s'il s'agissait d'une requête
- normale, et le cache répond comme si le contenu avait été
- modifié et enregistre ce dernier. Le cache se comporte alors
- comme un simple cache à deux état, où le contenu est servi s'il
- est à jour, ou supprimé dans le cas contraire.
+ supportent les requêtes conditionnelles, car dans le cas
+ contraire, ils répondent comme s'il s'agissait d'une requête
+ normale, et le cache répond comme si le contenu avait été
+ modifié et enregistre ce dernier. Le cache se comporte alors
+ comme un simple cache à deux état, où le contenu est servi s'il
+ est à jour, ou supprimé dans le cas contraire.
Que peut-on mettre en cache ?
-
La liste complète des conditions nécessaires pour qu'une
- réponse puisse être enregistrée dans un cache HTTP est fournie
+
La liste complète des conditions nécessaires pour qu'une
+ réponse puisse être enregistrée dans un cache HTTP est fournie
dans la section
- 13.4 Response Cacheability de la RFC2616, et peut se résumer
+ 13.4 Response Cacheability de la RFC2616, et peut se résumer
ainsi :
- - La mise en cache doit être activée pour cette URL. Voir les
+
- La mise en cache doit être activée pour cette URL. Voir les
directives
CacheEnable et CacheDisable.
- - Si la reponse possède un code de statut HTTP autre que 200, 203, 300, 301
- ou 410, elle doit aussi comporter un en-tête "Expires" ou
+
- Si la reponse possède un code de statut HTTP autre que 200, 203, 300, 301
+ ou 410, elle doit aussi comporter un en-tête "Expires" ou
"Cache-Control".
- - La requête doit être de type HTTP GET.
+ - La requête doit être de type HTTP GET.
- - Si la réponse contient un en-tête "Authorization:", elle doit aussi
+
- 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:".
-
- - Si l'URL contient une chaîne de requête
- (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 explicitement un délai d'expiration via un
- en-tête "Expires:" ou une directive max-age ou s-maxage de
- l'en-tête "Cache-Control:" comme indiqué dans les
+ dans l'en-tête "Cache-Control:".
+
+ - Si l'URL contient une chaîne de requête
+ (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 explicitement un délai d'expiration via un
+ en-tête "Expires:" ou une directive max-age ou s-maxage de
+ l'en-tête "Cache-Control:" comme indiqué dans les
sections 13.2.1. et 13.9 de la RFC2616.
- - 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
+
- 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 une directive max-age ou s-maxage de
- l'en-tête "Cache-Control:", à moins que la directive
+ l'en-tête "Cache-Control:", à moins que la directive
CacheIgnoreNoLastMod
- ne précise d'autres contraintes.
+ ne précise d'autres contraintes.
- - 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
+
- 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.
+ ne précise d'autres contraintes.
- - 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
+
- 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.
+ n'ait été utilisée.
- - 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.
+ - 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 ?
+
Qu'est ce qui ne doit pas être mis en cache ?
-
Le client qui crée la requête ou le serveur d'origine qui
- génère la réponse doit être à même de déterminer si le contenu
- doit pouvoir être mis en cache ou non en définissant correctement
- l'en-tête Cache-Control, et
+
Le client qui crée la requête ou le serveur d'origine qui
+ génère la réponse doit être à même de déterminer si le contenu
+ doit pouvoir être mis en cache ou non en définissant correctement
+ l'en-tête Cache-Control, et
mod_cache sera alors en mesure de satisfaire les
- souhaits du client ou du serveur de manière appropriée.
+ souhaits du client ou du serveur de manière appropriée.
Les contenus qui varient au cours du temps, ou en fonction de
- particularités de la requête non prises en compte par la
- négociation HTTP ne doivent pas être mis en cache. Ce type de
- contenu doit se déclarer lui-même "à ne pas mettre en cache" via
- l'en-tête Cache-Control.
+ particularités de la requête non prises en compte par la
+ négociation HTTP ne doivent pas être mis en cache. Ce type de
+ contenu doit se déclarer lui-même "à ne pas mettre en cache" via
+ l'en-tête
Cache-Control.
-
Si le contenu change souvent, suite par exemple à une durée de
- fraîcheur de l'ordre de la minute ou de la seconde, il peut tout
- de même être mis en cache, mais il est alors fortement souhaitable
+
Si le contenu change souvent, suite par exemple à une durée de
+ fraîcheur de l'ordre de la minute ou de la seconde, il peut tout
+ de même être mis en cache, mais il est alors fortement souhaitable
que le serveur d'origine supporte correctement les
- requêtes conditionnelles afin que des réponses
- complètes ne soient pas systématiquement générées.
+
requêtes conditionnelles afin que des réponses
+ complètes ne soient pas systématiquement générées.
-
Un contenu qui varie en fonction d'en-têtes de requête fournis
- par le client peut être mis en cache, sous réserve d'une
- utilisation appropriée de l'en-tête de réponse Vary.
+
Un contenu qui varie en fonction d'en-têtes de requête fournis
+ par le client peut être mis en cache, sous réserve d'une
+ utilisation appropriée de l'en-tête de réponse Vary.
-
Contenu variable et/ou négocié
+
Contenu variable et/ou négocié
-
Lorsque le serveur d'origine est configuré pour servir des
- contenus différents en fonction de la valeur de certains en-têtes
- de la requête, par exemple pour servir une ressource en plusieurs
- langages à partir d'une seule URL, le mécanisme de mise en cache
- d'HTTP permet de mettre en cache plusieurs variantes de la même
- page à partir d'une seule URL.
+
Lorsque le serveur d'origine est configuré pour servir des
+ contenus différents en fonction de la valeur de certains en-têtes
+ de la requête, par exemple pour servir une ressource en plusieurs
+ langages à partir d'une seule URL, le mécanisme de mise en cache
+ d'HTTP permet de mettre en cache plusieurs variantes de la même
+ page à partir d'une seule URL.
-
Pour y parvenir, le serveur d'origine ajoute un en-tête
- Vary pour indiquer quels en-têtes doivent être pris
- en compte par un cache pour déterminer si deux variantes sont
- différentes l'une de l'autre.
+
Pour y parvenir, le serveur d'origine ajoute un en-tête
+ Vary pour indiquer quels en-têtes doivent être pris
+ en compte par un cache pour déterminer si deux variantes sont
+ différentes l'une de l'autre.
-
Si par exemple, une réponse est reçue avec l'en-tête Vary suivant,
+
Si par exemple, une réponse est reçue avec l'en-tête Vary suivant,
Vary: negotiate,accept-language,accept-charset
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.
-
-
Plusieurs variantes d'un contenu peuvent être mises en cache
- simultanément ; mod_cache utilise l'en-tête
- Vary et les valeurs correspondantes des en-têtes de
- la requête spécifiés dans ce dernier pour
- déterminer quelle variante doit être servie au client.
+ mis en cache qui correspond au contenu des en-têtes accept-language et
+ accept-charset de la requête originale.
+
+
Plusieurs variantes d'un contenu peuvent être mises en cache
+ simultanément ; mod_cache utilise l'en-tête
+ Vary et les valeurs correspondantes des en-têtes de
+ la requête spécifiés dans ce dernier pour
+ déterminer quelle variante doit être servie au client.
@@ -465,17 +465,17 @@ Vary: negotiate,accept-language,accept-charset
-
+
Le module mod_cache s'appuie sur des
- implémentations de stockage sous-jacentes spécifiques pour gérer
- le cache ; à ce titre, mod_cache_disk fournit le
+ implémentations de stockage sous-jacentes spécifiques pour gérer
+ le cache ; à ce titre, mod_cache_disk fournit le
support de la mise en cache sur disque.
-
En général, le module se configure comme suit :
+
En général, le module se configure comme suit :
CacheRoot "/var/cache/apache/"
CacheEnable disk /
@@ -483,135 +483,135 @@ 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.
+
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_cache_disk 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, ainsi que les éléments
- spécifiés dans l'en-tête Vary 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
+
Pour stocker des entités dans le cache,
+ le module mod_cache_disk 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, ainsi que les éléments
+ spécifiés dans l'en-tête Vary 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
+ 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
+ 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 à :
+ 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
+
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.
+ 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.
+ est recommandée.
-
Le paramétrage de la directive
+
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.
+ 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
Le module mod_cache_disk n'effectue aucune
- régulation de l'espace disque utilisé par le cache, mais s'il
- s'arrête en douceur en cas d'erreur disque et se comporte alors
- comme si le cache n'avait jamais existé.
+ régulation de l'espace disque utilisé par le cache, mais s'il
+ s'arrête en douceur en cas d'erreur disque et se comporte alors
+ comme si le cache n'avait jamais existé.
Par contre l'utilitaire
htcacheclean fourni avec
httpd
- vous permet 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
+ vous permet 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.
+
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.
-
Il est aussi conseillé d'attribuer un niveau de priorité "nice"
- approprié à htcacheclean de façon à ce qu'il n'effectue pas trop
- d'accès disque pendant le fonctionnement du serveur.
+
Il est aussi conseillé d'attribuer un niveau de priorité "nice"
+ approprié à htcacheclean de façon à ce qu'il n'effectue pas trop
+ d'accès disque pendant le fonctionnement du serveur.

Figure 1: Croissance
- typique du cache / séquence de nettoyage.
+ typique du cache / séquence de nettoyage.
Comme mod_cache_disk 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.
+ 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.
-
+
En utilisant le module mod_cache_socache,
- mod_cache peut mettre en cache des données à partir de
- diverses implémentations aussi nommées "fournisseurs". Par exemple, en
+ mod_cache peut mettre en cache des données à partir de
+ diverses implémentations aussi nommées "fournisseurs". Par exemple, en
utilisant le module mod_socache_memcache, on peut
- spécifier que c'est memcached qui doit
- être utilisé comme mécanisme de stockage sous-jacent.
+ spécifier que c'est
memcached qui doit
+ être utilisé comme mécanisme de stockage sous-jacent.
-
Typiquement, le module sera configuré comme suit :
+
Typiquement, le module sera configuré comme suit :
CacheEnable socache /
CacheSocache memcache:memcd.example.com:11211
-
En outre, il est possible de spécifier plusieurs serveurs
- memcached en les ajoutant à la fin de la ligne
- CacheSocache memcache: et en les séparant par des virgules :
+
En outre, il est possible de spécifier plusieurs serveurs
+ memcached en les ajoutant à la fin de la ligne
+ CacheSocache memcache: et en les séparant par des virgules :
CacheEnable socache /
CacheSocache memcache:mem1.example.com:11211,mem2.example.com:11212
@@ -632,46 +632,46 @@ CacheSocache dbm:/path/to/datafile
-
+
-
+
-
Sur les plateformes où le système de fichiers peut être lent, ou
+
Sur les plateformes où le système de fichiers peut être lent, ou
lorsque les descripteurs de fichiers sont gourmands en ressources,
- il est possible de précharger des fichiers en mémoire au démarrage
+ il est possible de précharger des fichiers en mémoire au démarrage
du serveur.
-
Sur les systèmes où l'ouverture des fichiers est lente, il est
- possible d'ouvrir le fichier au démarrage du serveur et de mettre en
+
Sur les systèmes où l'ouverture des fichiers est lente, il est
+ possible d'ouvrir le fichier au démarrage du serveur et de mettre en
cache le descripteur de fichier. Ces options peuvent vous aider sur
- les systèmes où l'accès aux fichiers statiques est lent.
+ les systèmes où l'accès aux fichiers statiques est lent.
-
Le processus d'ouverture d'un fichier peut être en soi une
- source de ralentissement, en particulier sur les systèmes de
- fichiers sur le réseau. httpd permet d'éviter ce ralentissement en
+
Le processus d'ouverture d'un fichier peut être en soi une
+ source de ralentissement, en particulier sur les systèmes de
+ fichiers sur le réseau. httpd permet d'éviter ce ralentissement en
maintenant un cache des descripteurs de fichiers ouverts pour les
fichiers souvent servis. Actuellement, httpd fournit une seule
- implémentation de mise en cache des descripteurs de fichiers.
+ implémentation de mise en cache des descripteurs de fichiers.
CacheFile
La forme la plus basique de mise en cache que propose httpd
est la mise en cache des descripteurs de fichiers fournie par le
- module mod_file_cache. Plutôt que de mettre en
+ 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 devant faire
- l'objet d'une mise en cache de ce type sont spécifiés dans le
+ l'objet d'une mise en cache de ce type sont spécifiés dans le
fichier de configuration via la directive CacheFile.
La directive CacheFile informe httpd
- qu'il doit ouvrir le fichier lors de son démarrage et qu'il doit
- réutiliser le descripteur de fichier mis en cache pour tous les
- accès futurs à ce fichier.
+ qu'il doit ouvrir le fichier lors de son démarrage et qu'il doit
+ réutiliser le descripteur de fichier mis en cache pour tous les
+ accès futurs à ce fichier.
CacheFile /usr/local/apache2/htdocs/index.html
-
Si vous désirez mettre en cache un grand nombre de fichiers
- de cette manière, vous devez vous assurer que le nombre maximal
- de fichiers ouverts pour votre système d'exploitation est défini
- à une valeur suffisante.
+
Si vous désirez mettre en cache un grand nombre de fichiers
+ de cette manière, vous devez vous assurer que le nombre maximal
+ de fichiers ouverts pour votre système d'exploitation est défini
+ à une valeur suffisante.
-
Bien que l'utilisation de la directive CacheFile n'entraîne pas de
+
Bien que l'utilisation de la directive CacheFile n'entraîne pas de
mise en cache du contenu du fichier proprement dit, elle
- implique que si le fichier est modifié pendant l'exécution du
+ implique que si le fichier est modifié pendant l'exécution du
serveur, ces modifications ne seront pas prises en compte. Le
- fichier sera toujours servi dans l'état où il se trouvait au
- moment du démarrage du serveur.
-
-
Si le fichier est supprimé pendant l'exécution du serveur, ce
- dernier conservera le descripteur de fichier ouvert associé et
- servira le fichier dans l'état où il se trouvait au
- moment du démarrage du serveur. Cela signifie aussi que même si
- le fichier a été supprimé, et n'apparaît donc plus dans le
- système de fichiers, l'espace disque libéré ne sera disponible
- qu'une fois le serveur httpd arrêté et donc le descripteur de
- fichier fermé.
+ fichier sera toujours servi dans l'état où il se trouvait au
+ moment du démarrage du serveur.
+
+
Si le fichier est supprimé pendant l'exécution du serveur, ce
+ dernier conservera le descripteur de fichier ouvert associé et
+ servira le fichier dans l'état où il se trouvait au
+ moment du démarrage du serveur. Cela signifie aussi que même si
+ le fichier a été supprimé, et n'apparaît donc plus dans le
+ système de fichiers, l'espace disque libéré ne sera disponible
+ qu'une fois le serveur httpd arrêté et donc le descripteur de
+ fichier fermé.
@@ -753,35 +753,35 @@ CacheSocache dbm:/path/to/datafile
-
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 à
- httpd, 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
+
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 à
+ httpd, 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
+
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
+
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;
+ 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
@@ -792,40 +792,40 @@ 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.
+
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
+
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
de httpd.
-
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
+
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
de httpd qui n'a
- aucune possibilité de savoir si un fichier a été modifié.
+ 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 httpd dans certaines
+
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 httpd dans certaines
circonstances.
-
Mise en cache à l'aide de la directive MMapFile
+
Mise en cache à l'aide de la directive MMapFile
La directive MMapFile
fournie par le module mod_file_cache vous permet de
- demander à httpd de charger un contenu de fichier statique en mémoire
- lors de son démarrage (à l'aide de l'appel
- système mmap). httpd
- utilisera le contenu chargé en mémoire pour satisfaire ultérieurement
- toutes les demandes d'accès à ce fichier.
+ demander à httpd de charger un contenu de fichier statique en mémoire
+ lors de son démarrage (à l'aide de l'appel
+ système mmap). httpd
+ 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
@@ -833,85 +833,85 @@ sys 0m0.000s
+ 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.