Comment configurer la mise en cache du contenu d’Apache sur Ubuntu 14.04

Qu’est-ce que la mise en cache ?

La mise en cache est une méthode d’amélioration des performances du serveur en permettant au contenu couramment demandé d’être stocké temporairement d’une manière qui permet un accès plus rapide. Cela accélère le traitement et la livraison en supprimant certaines opérations gourmandes en ressources.

En créant des règles de mise en cache efficaces, le contenu qui convient à la mise en cache sera stocké pour améliorer les temps de réponse, conserver les ressources et minimiser la charge. Apache fournit une variété de caches adaptés à l’accélération de différents types d’opérations. Dans ce guide, nous allons aborder la façon de configurer Apache 2.4 sur Ubuntu 14.04 en utilisant ses différents modules de mise en cache.

Pour en savoir plus sur le développement de stratégies générales de mise en cache, consultez cet article.

Une introduction à la mise en cache dans Apache

Apache peut mettre en cache du contenu avec différents niveaux de sophistication et d’évolutivité. Il les divise en trois groupes en fonction de la méthode de mise en cache du contenu. La répartition générale est la suivante :

• Mise en cache des fichiers : La stratégie de mise en cache la plus basique, cela ouvre simplement les fichiers ou les descripteurs de fichiers lorsque le serveur démarre et les garde disponibles pour accélérer l’accès.
• Mise en cache clé-valeur : Principalement utilisée pour la mise en cache SSL et l’authentification, la mise en cache clé-valeur utilise un modèle d’objet partagé qui peut stocker des éléments dont le calcul répété est coûteux.
• Mise en cache HTTP standard : Le mécanisme de mise en cache le plus flexible et généralement utile, ce système à trois états peut stocker les réponses et les valider lorsqu’elles expirent. Cela peut être configuré pour la performance ou la flexibilité en fonction de vos besoins spécifiques.

Un coup d’œil rapide aux descriptions ci-dessus peut révéler que les méthodes ci-dessus ont un certain chevauchement, mais aussi qu’il peut être utile d’utiliser plus d’une stratégie en même temps. Par exemple, l’utilisation d’un key-value store pour vos sessions SSL et l’activation d’un cache HTTP standard pour les réponses pourraient vous permettre de soulager considérablement vos sources de données et d’accélérer de nombreuses opérations de diffusion de contenu pour vos clients.

Maintenant que vous avez une compréhension générale de chacun des mécanismes de mise en cache d’Apache, examinons ces systèmes plus en détail.

Mise en cache des fichiers

Vue d’ensemble

• Modules primaires impliqués : mod_file_cache
• Principaux cas d’utilisation : stockage soit du contenu des fichiers, soit des descripteurs de fichiers au démarrage du serveur. Il s’agit de représentations statiques qui ne peuvent pas être modifiées de manière fiable jusqu’à ce que le serveur soit redémarré.
• Caractéristiques : simple, améliore les performances des systèmes de fichiers lents
• Inconvénients : fonctionnalité expérimentale, ne répond pas aux mises à jour du système de fichiers, doit être utilisé avec parcimonie pour s’adapter aux limites du système d’exploitation, ne peut être utilisé que sur des fichiers statiques

Les détails

Le module mod_file_cache est principalement utilisé pour accélérer l’accès aux fichiers sur les serveurs avec des systèmes de fichiers lents. Il offre un choix de deux directives de configuration, qui visent toutes deux à accélérer le processus de service des fichiers statiques en effectuant une partie du travail au démarrage du serveur plutôt que lorsque les fichiers sont demandés.

La directive CacheFile est utilisée pour spécifier le chemin d’accès aux fichiers sur le disque dont vous souhaitez accélérer l’accès. Au démarrage d’Apache, ce dernier ouvrira les fichiers statiques spécifiés et mettra en cache le handle du fichier, évitant ainsi d’avoir à ouvrir le fichier lorsqu’il est demandé. Le nombre de fichiers qui peuvent être ouverts de cette manière est soumis aux limitations fixées par votre système d’exploitation.

La directive MMapFile ouvre également les fichiers au premier démarrage d’Apache. Cependant, MMapFile met en cache le contenu du fichier en mémoire plutôt que le seul gestionnaire de fichiers. Cela permet d’obtenir des performances plus rapides pour ces pages, mais présente de sérieuses limitations. Il ne conserve aucun enregistrement de la quantité de mémoire qu’il a utilisée, il est donc possible de manquer de mémoire. Notez également que les processus enfants copieront toute la mémoire allouée, ce qui peut entraîner un épuisement plus rapide des ressources que vous ne l’aviez initialement prévu. N’utilisez cette directive qu’avec parcimonie.

Ces directives sont évaluées uniquement au démarrage d’Apache. Cela signifie que vous ne pouvez pas compter sur Apache pour récupérer les modifications apportées après son démarrage. Utilisez-les uniquement sur des fichiers statiques qui ne seront pas modifiés pendant la durée de vie de la session Apache. Selon la façon dont les fichiers sont modifiés, le serveur peut être informé des changements, mais ce n’est pas le comportement attendu et cela ne fonctionnera pas toujours correctement. Si des modifications doivent être apportées aux fichiers passés à ces directives, redémarrez Apache après que les modifications ont été effectuées.

Comment activer la mise en cache des fichiers

La mise en cache des fichiers est fournie par le module mod_file_cache. Pour utiliser cette fonctionnalité, vous devez activer le module.

Lorsque vous utilisez Ubuntu 14.04, le module sera installé mais désactivé lorsque vous installez Apache. Vous pouvez activer le module en tapant:

sudo a2enmod file_cache

Après cela, vous devez modifier le fichier de configuration principal pour mettre en place vos directives de mise en cache des fichiers. Ouvrez le fichier en tapant:

sudo nano /etc/apache2/apache2.conf

Pour configurer la mise en cache du gestionnaire de fichiers, utilisez la directive CacheFile. Cette directive prend une liste de chemins de fichiers, séparés par des espaces, comme ceci:

CacheFile /var/www/html/index.html /var/www/html/somefile.index

Lorsque le serveur sera redémarré, Apache ouvrira les fichiers listés et stockera leurs poignées de fichiers dans le cache pour un accès plus rapide.

Si, au lieu de cela, vous souhaitez mapper quelques fichiers directement en mémoire, vous pouvez utiliser la directive MMapFile. Sa syntaxe est fondamentalement la même que celle de la dernière directive, en ce sens qu’elle prend simplement une liste de chemins de fichiers :

MMapFile /var/www/html/index.html /var/www/html/somefile.index

En pratique, il n’y aurait aucune raison de configurer à la fois CacheFile et MMapFile pour le même ensemble de fichiers, mais vous pourriez les utiliser sur différents ensembles de fichiers.

Quand vous avez terminé, vous pouvez enregistrer et fermer les fichiers. Vérifiez la syntaxe du fichier de configuration en tapant :

sudo apachectl configtest

Si la dernière ligne indique Syntax OK, vous pouvez redémarrer en toute sécurité votre instance d’Apache :

sudo service apache2 restart

Apache redémarre, en mettant en cache le contenu des fichiers ou les gestionnaires en fonction des directives que vous avez utilisées.

Mise en cache des valeurs clés

Vue d’ensemble

• Modules primaires impliqués : mod_socache_dbm, mod_socache_dc, mod_socache_memcache, mod_socache_shmcb
• Modules de soutien concernés : mod_authn_socache, mod_ssl
• Principaux cas d’utilisation : stockage des sessions SSL ou des détails d’authentification, agrafage SSL
• Caractéristiques : cache d’objet partagé pour stocker des ressources complexes, peut aider à la mise en cache et à l’agrafage des sessions SSL, backends flexibles
• Inconvénients : n’a pas de mécanismes de validation, nécessité de configurer un logiciel séparé pour des backends plus performants/flexibles, quelques bugs dans le code

Les détails

Le cache à valeur clé est plus complexe que le cache à fichier et présente des avantages plus ciblés. Également connu sous le nom de cache d’objets partagés, le cache clé-valeur d’Apache est principalement utilisé pour éviter de répéter les opérations coûteuses liées à la configuration de l’accès d’un client au contenu, par opposition au contenu lui-même. Plus précisément, il peut être utilisé pour mettre en cache les détails d’authentification, les sessions SSL et pour fournir l’agrafage SSL.

Actuellement, il existe certains problèmes avec chaque fournisseur de cache d’objets partagés. Les références à ces problèmes seront décrites ci-dessous. Prenez-les en considération lorsque vous évaluez si vous devez activer cette fonctionnalité.

La mise en cache réelle est accomplie par l’utilisation d’un des modules de fournisseur de cache d’objets partagés. Ce sont :

• mod_socache_dbm : Ce backend utilise le moteur de base de données simple dbm, qui est un magasin clé-valeur basé sur des fichiers qui utilise le hachage et des buckets de taille fixe. Ce fournisseur souffre de quelques fuites de mémoire, donc pour la plupart des cas, il est recommandé d’utiliser mod_socache_shmcb à la place.
• mod_socache_dc : Ce fournisseur utilise le logiciel de mise en cache de session distcache. Ce projet n’a pas été mis à jour depuis 2004 et n’est même pas packagé pour certaines distributions, donc à utiliser avec une bonne dose de prudence.
• mod_socache_memcache : Ce fournisseur utilise le cache objet à mémoire distribuée memcache pour stocker les éléments. C’est la meilleure option pour un cache distribué entre plusieurs serveurs. Actuellement, il n’expire pas correctement les entrées, mais un correctif a été commis dans le tronc du contrôle de version d’Apache qui corrige le problème.
• mod_socache_shmcb : Actuellement, c’est la meilleure option pour la mise en cache des valeurs de clés. Cela cache dans un tampon cyclique en mémoire partagée, qui supprimera les entrées à mesure qu’il sera plein. Il s’étouffe actuellement sur les entrées de plus de 11k en taille.

A côté des modules fournisseurs ci-dessus, des modules supplémentaires seront nécessaires en fonction des objets mis en cache. Par exemple, pour mettre en cache les sessions SSL ou pour configurer l’agrafage SSL, mod_ssl doit être activé, ce qui fournira respectivement les directives SSLSessionCache et SSLStaplingCache. De même, pour configurer la mise en cache de l’authentification, le module mod_authn_socache doit être activé afin que la directive AuthnCacheSOCache puisse être définie.

Comment activer la mise en cache de la valeur des clés

Avec les bogues et les avertissements ci-dessus à l’esprit, si vous souhaitez toujours configurer ce type de mise en cache dans Apache, suivez la procédure ci-dessous.

La méthode utilisée pour configurer le cache de la valeur des clés dépendra de ce à quoi il sera utilisé et du fournisseur que vous utilisez. Nous passerons en revue les bases du cache d’authentification et du cache de session SSL ci-dessous.

En ce moment, il y a un bogue avec le cache d’authentification qui empêche de passer des arguments au fournisseur de cache. Ainsi, tous les fournisseurs qui ne fournissent pas de paramètres par défaut sur lesquels se rabattre auront des problèmes.

Mise en cache de l’authentification

La mise en cache de l’authentification est utile si vous utilisez une méthode d’authentification coûteuse, telle que l’authentification LDAP ou de base de données. Ces types d’opérations peuvent avoir un impact significatif sur les performances si le backend doit être frappé à chaque fois qu’une demande d’authentification est effectuée.

La mise en place de la mise en cache implique de modifier votre configuration d’authentification existante (nous ne couvrirons pas la façon de configurer l’authentification dans ce guide). Les modifications elles-mêmes seront sensiblement les mêmes quelle que soit la méthode d’authentification backend. Nous utiliserons mod_socache_shmcb pour notre démonstration.

Premièrement, activez le module authn_socache et le module fournisseur mod_socache_shmcb en tapant :

 
sudo a2enmod authn_socache
 
sudo a2enmod socache_shmcb
 

Ouvrez votre fichier de configuration principal d’Apache afin de pouvoir spécifier ce backend de cache partagé à utiliser avec l’authentification :

sudo nano /etc/apache2/apache2.conf

À l’intérieur, vers le haut du fichier, ajoutez la directive AuthnCacheSOCache. Spécifiez que shmcb doit être utilisé comme fournisseur. Si le bogue discuté précédemment empêchant le passage des options est corrigé au moment où vous lisez ceci, vous pouvez spécifier un emplacement et une taille pour le cache. Le nombre est en octets, donc l’exemple commenté résultera en un cache de 512 kilobytes:

AuthnCacheSOCache shmcb# If the bug preventing passed arguments to the provider gets fixed,# you can customize the location and size like this#AuthnCacheSOCache shmcb:${APACHE_RUN_DIR}/auth_cache(512000)

Enregistrez et fermez le fichier lorsque vous avez terminé.

Puis, ouvrez votre page de configuration d’hôte virtuel qui a l’authentification configurée. Nous supposerons que vous utilisez la configuration d’hôte virtuel 000-default.conf, mais vous devriez la modifier pour refléter votre environnement :

sudo nano /etc/apache2/sites-enabled/000-default.conf

À l’endroit où vous avez configuré l’authentification, modifiez le bloc pour ajouter la mise en cache. Plus précisément, vous devez ajouter le AuthnCacheProvideFor pour lui indiquer quelles sources d’authentification mettre en cache, ajouter un timeout de cache avec AuthnCacheTimeout, et ajouter socache à la liste AuthBasicProvider devant votre méthode d’authentification conventionnelle. Les résultats ressembleront à quelque chose comme ceci:

<VirtualHost *:80> . . . <Directory /var/www/html/private> AuthType Basic AuthName "Restricted Files" AuthBasicProvider socache file AuthUserFile /etc/apache2/.htpasswd AuthnCacheProvideFor file AuthnCacheTimeout 300 Require valid-user </Directory></VirtualHost>

L’exemple ci-dessus concerne l’authentification par fichier, qui ne bénéficiera probablement pas beaucoup de la mise en cache. Cependant, l’implémentation devrait être très similaire lors de l’utilisation d’autres méthodes d’authentification. La seule différence substantielle serait où la spécification « file » est dans l’exemple ci-dessus, l’autre méthode d’authentification serait utilisée à la place.

Enregistrer et fermer le fichier. Redémarrez Apache pour mettre en œuvre vos modifications de mise en cache :

sudo service apache2 restart

Mise en cache de la session SSL

La poignée de main qui doit être effectuée pour établir une connexion SSL entraîne une surcharge importante. En tant que tel, la mise en cache des données de session pour éviter cette étape d’initialisation pour les demandes ultérieures peut potentiellement contourner cette pénalité. Le cache d’objet partagé est un endroit parfait pour cela.

Si vous avez SSL déjà configuré pour votre serveur Apache, mod_ssl sera activé. Sur Ubuntu, cela signifie qu’un fichier ssl.conf a été déplacé vers le répertoire /etc/apache2/mods-enabled. En fait, cela configure déjà la mise en cache. A l’intérieur, vous verrez quelques lignes comme ceci:

. . .SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)SSLSessionCacheTimeout 300. . .

Ceci est en fait suffisant pour configurer la mise en cache des sessions. Pour tester cela, vous pouvez utiliser le client de connexion d’OpenSSL. Tapez :

openssl s_client -connect 127.0.0.1:443 -reconnect -no_ticket | grep Session-ID

Si l’ID de session est le même dans tous les résultats, votre cache de session fonctionne correctement. Appuyez sur CTRL-C pour revenir au terminal.

Mise en cache HTTP standard

Vue d’ensemble

• Modules primaires concernés : mod_cache
• Modules de soutien impliqués : mod_cache_disk, mod_cache_socache
• Principaux cas d’utilisation : Mise en cache du contenu général
• Caractéristiques : Peut interpréter correctement les en-têtes de mise en cache HTTP, peut revalider les entrées périmées, peut être déployé pour une vitesse ou une flexibilité maximale en fonction de vos besoins
• Inconvénients : Peut fuir des données sensibles s’il est mal configuré, doit utiliser des modules supplémentaires pour définir correctement la politique de mise en cache

Les détails

Le protocole HTTP encourage et fournit les mécanismes de mise en cache des réponses tout au long du chemin de livraison du contenu. Tout ordinateur qui touche le contenu peut potentiellement mettre en cache chaque élément pendant un certain temps en fonction des politiques de mise en cache énoncées aux origines du contenu et des règles de mise en cache propres à l’ordinateur.

Le mécanisme de mise en cache HTTP d’Apache met en cache les réponses en fonction des politiques de mise en cache HTTP qu’il voit. Il s’agit d’un système de mise en cache à usage général qui adhère aux mêmes règles que suivrait tout serveur intermédiaire ayant un rôle dans la livraison. Cela rend ce système très flexible et puissant et vous permet de tirer parti des en-têtes que vous devriez déjà définir sur votre contenu (nous couvrirons comment le faire ci-dessous).

Le cache HTTP d’Apache est également connu comme un cache à « trois états ». C’est parce que le contenu qu’il a stocké peut être dans l’un des trois états suivants. Il peut être frais, ce qui signifie qu’il est autorisé à être servi aux clients sans autre vérification, il peut être périmé, ce qui signifie que le TTL sur le contenu a expiré, ou il peut être inexistant si le contenu n’est pas trouvé dans le cache.

Si le contenu devient périmé, à la prochaine demande, le cache peut le revalider en vérifiant le contenu à l’origine. S’il n’a pas changé, il peut réinitialiser la date de fraîcheur et servir le contenu actuel. Sinon, il récupère le contenu modifié et le stocke pendant la durée autorisée par sa politique de mise en cache.

Vue d’ensemble du module

La logique de mise en cache HTTP est disponible à travers le module mod_cache. La mise en cache réelle est effectuée avec l’un des fournisseurs de mise en cache. Généralement, le cache est stocké sur le disque à l’aide du module mod_cache_disk, mais le cache d’objets partagés est également disponible via le module mod_cache_socache.

Le module mod_cache_disk met en cache sur le disque, il peut donc être utile si vous procurez du contenu à partir d’un emplacement distant, si vous le générez à partir d’un processus dynamique, ou si vous essayez simplement d’accélérer les choses en mettant en cache sur un disque plus rapide que celui sur lequel votre contenu réside généralement. Il s’agit du fournisseur le mieux testé et devrait probablement être votre premier choix dans la plupart des cas. Le cache n’est pas nettoyé automatiquement, un outil appelé htcacheclean doit donc être exécuté de temps en temps pour alléger le cache. Cela peut être exécuté manuellement, configuré comme un travail régulier cron, ou exécuté comme un démon.

Le module mod_cache_socache met en cache vers l’un des fournisseurs d’objets partagés (les mêmes que ceux discutés dans la dernière section). Cela peut potentiellement avoir de meilleures performances que mod_cache_disk (selon le fournisseur de cache partagé sélectionné). Cependant, il est beaucoup plus récent et s’appuie sur les fournisseurs d’objets partagés, qui ont les bogues discutés précédemment. Des tests complets sont recommandés avant de mettre en œuvre l’option mod_cache_socache.

Placement du cache HTTP

Le cache HTTP d’Apache peut être déployé dans deux configurations différentes en fonction de vos besoins.

Si le CacheQuickHandler est défini sur « on », le cache sera vérifié très tôt dans le processus de traitement des requêtes. Si du contenu est trouvé, il sera servi directement sans autre manipulation. Cela signifie que c’est incroyablement rapide, mais cela signifie également que cela ne permet pas des processus comme l’authentification pour le contenu. S’il y a du contenu dans votre cache qui nécessite normalement une authentification ou un contrôle d’accès, il sera accessible à quiconque sans authentification si le CacheQuickHandler est défini sur « on ».

Basiquement, cela émule un cache séparé devant votre serveur web. Si votre serveur web a besoin de faire n’importe quel type de vérification conditionnelle, d’authentification ou d’autorisation, cela ne se produira pas. Apache n’évaluera même pas les directives situées dans les blocs <Location> ou <Directory>. Notez que CacheQuickHandler est défini à « on » par défaut!

Si le CacheQuickHandler est défini à « off », le cache sera vérifié significativement plus tard dans la séquence de traitement de la requête. Pensez à cette configuration comme plaçant le cache entre votre logique de traitement Apache et votre contenu réel. Cela permettra aux directives de traitement conventionnelles d’être exécutées avant la récupération du contenu dans le cache. En réglant cette configuration sur « off », on échange un peu de vitesse contre la possibilité de traiter les requêtes plus en profondeur.

Comment configurer la mise en cache HTTP standard

Pour activer la mise en cache, vous devrez activer le module mod_cache ainsi qu’un de ses fournisseurs de mise en cache. Comme nous l’avons dit plus haut, mod_cache_disk est bien testé, nous allons donc nous fier à cela.

Activation des modules

Sur un système Ubuntu, vous pouvez activer ces modules en tapant :

 
sudo a2enmod cache
 
sudo a2enmod cache_disk
 

Cela activera la fonctionnalité de mise en cache au prochain redémarrage du serveur.

Vous devrez également installer le paquet apache2-utils, qui contient l’utilitaire htcacheclean utilisé pour réduire le cache lorsque cela est nécessaire. Vous pouvez l’installer en tapant :

 
sudo apt-get update
 
sudo apt-get install apache2-utils
 

Modification de la configuration globale

La plupart de la configuration pour la mise en cache aura lieu dans les définitions d’hôtes virtuels individuels ou les blocs d’emplacement. Cependant, l’activation de mod_cache_disk active également une configuration globale qui peut être utilisée pour spécifier certains attributs généraux. Ouvrez ce fichier maintenant pour y jeter un coup d’œil:

sudo nano /etc/apache2/mods-enabled/cache_disk.conf

Avec les commentaires retirés, le fichier devrait ressembler à ceci:

<IfModule mod_cache_disk.c> CacheRoot /var/cache/apache2/mod_cache_disk CacheDirLevels 2 CacheDirLength 1</IfModule>

Le wrapper IfModule indique à Apache de ne se préoccuper de ces directives que si le module mod_cache_disk est activé. La directive CacheRoot spécifie l’emplacement sur le disque où le cache sera maintenu. Les directives CacheDirLevels et CacheDirLength contribuent toutes deux à définir la manière dont la structure des répertoires du cache sera construite.

Un hachage md5 de l’URL servie sera créé comme clé utilisée pour stocker les données. Les données seront organisées en répertoires dérivés des caractères de début de chaque hachage. CacheDirLevels spécifie le nombre de sous-répertoires à créer et CacheDirLength spécifie le nombre de caractères à utiliser comme nom de chaque répertoire. Ainsi, un hachage de b1946ac92492d2347c6235b4d2611184 avec les valeurs par défaut indiquées ci-dessus serait classé dans une structure de répertoire de b/1/946ac92492d2347c6235b4d2611184. Habituellement, vous n’aurez pas besoin de modifier ces valeurs, mais il est bon de savoir à quoi elles servent.

Si vous choisissez de modifier la valeur deCacheRoot, vous devrez ouvrir le fichier/etc/default/apache2

et modifier la valeur deHTCACHECLEAN_PATHpour correspondre à votre sélection. Ceci est utilisé pour nettoyer le cache à intervalles réguliers, il doit donc avoir l’emplacement correct du cache.

Certaines autres valeurs que vous pouvez définir dans ce fichier sont CacheMaxFileSize et CacheMinFileSize qui définissent les plages de tailles de fichiers en octets qu’Apache engagera dans le cache, ainsi que CacheReadSize et CacheReadTime, qui permettent d’attendre et de mettre en mémoire tampon le contenu avant de l’envoyer au client. Cela peut être utile si le contenu réside ailleurs que sur ce serveur.

Modification du serveur virtuel

La plupart de la configuration pour la mise en cache se fera à un niveau plus granulaire, soit dans la définition de l’hôte virtuel, soit dans un bloc d’emplacement spécifique.

Ouvrez l’un de vos fichiers d’hôte virtuel pour suivre. Nous supposerons que vous utilisez le fichier par défaut dans ce guide :

sudo nano /etc/apache2/sites-enabled

Dans le bloc d’hôte virtuel, en dehors de tout bloc d’emplacement, nous pouvons commencer à configurer certaines des propriétés de mise en cache. Dans ce guide, nous supposerons que nous voulons désactiver le CacheQuickHandler pour que plus de traitement soit effectué. Cela nous permet de monter des règles de mise en cache plus complètes.

Nous allons également profiter de cette occasion pour configurer le verrouillage du cache. Il s’agit d’un système de verrouillage de fichiers qu’Apache utilisera lorsqu’il vérifiera auprès de l’origine du contenu si celui-ci est toujours valide. Pendant le temps où cette requête est satisfaite, si des demandes supplémentaires pour le même contenu arrivent, cela entraînerait des demandes supplémentaires à la ressource backend, ce qui pourrait provoquer des pics de charge.

La définition d’un verrouillage de cache pour une ressource pendant la validation indique à Apache que la ressource est actuellement en cours de rafraîchissement. Pendant ce temps, la ressource périmée peut être servie avec un en-tête d’avertissement indiquant son état. Nous allons mettre en place un répertoire de verrouillage du cache dans le dossier /tmp. Nous laisserons un maximum de 5 secondes pour qu’un verrou soit considéré comme valide. Ces exemples sont tirés directement de la documentation d’Apache, ils devraient donc bien fonctionner pour nos besoins.

Nous allons également dire à Apache d’ignorer les en-têtes Set-Cookie et de ne pas les stocker dans le cache. Ce faisant, nous empêcherons Apache de divulguer accidentellement des cookies spécifiques à l’utilisateur à d’autres parties. L’en-tête Set-Cookie sera dépouillé avant que les en-têtes ne soient mis en cache.

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie</VirtualHost>

Nous devons encore activer réellement la mise en cache pour cet hôte virtuel. Nous pouvons le faire avec la directive CacheEnable. Si celle-ci est définie dans un bloc d’hôte virtuel, nous devrions fournir la méthode de mise en cache (disk ou socache) ainsi que les URI demandés qui devraient être mis en cache. Par exemple, pour mettre en cache toutes les réponses, cela pourrait être défini à CacheEnable disk /, mais si vous voulez seulement mettre en cache les réponses sous l’URI /public, vous pourriez le définir à CacheEnable disk /public.

Nous allons prendre une route différente en activant notre cache dans un bloc d’emplacement spécifique. En procédant ainsi, nous n’avons pas à fournir un chemin d’accès URI à la commande CacheEnable. Tout URI qui serait servi à partir de cet emplacement sera mis en cache. Nous allons également activer la directive CacheHeader afin que nos en-têtes de réponse indiquent si le cache a été utilisé pour servir la requête ou non.

Une autre directive que nous allons définir est CacheDefaultExpire afin que nous puissions définir une expiration (en secondes) si ni les en-têtes Expires ni Last-Modified ne sont définis sur le contenu. De même, nous définirons CacheMaxExpire pour plafonner le temps pendant lequel les éléments seront sauvegardés. Nous définirons le CacheLastModifiedFactor pour qu’Apache puisse créer une date d’expiration s’il a une date Last-Modified, mais pas d’expiration. Le facteur est multiplié par le temps depuis la modification pour définir une expiration raisonnable.

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 </Location></VirtualHost>

Sauvegarder et fermer votre fichier lorsque vous avez configuré tout ce dont vous avez besoin.

Vérifiez l’ensemble de votre configuration pour les erreurs de syntaxe en tapant :

sudo apachectl configtest

Si aucune erreur n’est signalée, redémarrez votre service en tapant :

sudo service apache2 restart

Définition des expirations et des en-têtes de mise en cache sur le contenu

Dans la configuration ci-dessus, nous avons configuré la mise en cache HTTP, qui repose sur les en-têtes HTTP. Cependant, aucun du contenu que nous servons n’a réellement les en-têtes Expires ou Cache-Control nécessaires pour prendre des décisions de mise en cache intelligentes. Pour définir ces en-têtes, nous devons tirer parti de quelques modules supplémentaires.

Le module mod_expires peut définir à la fois l’en-tête Expires et l’option max-age dans l’en-tête Cache-Control. Le module mod_headers peut être utilisé pour ajouter des options Cache-Control plus spécifiques afin d’affiner la politique de mise en cache.

Nous pouvons activer ces deux modules en tapant :

 
sudo a2enmod expires
 
sudo a2enmod headers
 

Après avoir activé ces modules, nous pouvons à nouveau modifier directement notre fichier d’hôte virtuel :

sudo nano /etc/apache2/sites-enabled/000-default.conf

Le module mod_expires fournit seulement trois directives. La ExpiresActive active le traitement des expirations dans un certain contexte en lui attribuant la valeur « on ». Les deux autres directives sont très similaires les unes aux autres. La directive ExpiresDefault définit le délai d’expiration par défaut, et la ExpiresByType définit le délai d’expiration en fonction du type MIME du contenu. Ces deux directives définiront les Expires et Cache-Control « max-age » aux valeurs correctes.

Ces deux paramètres peuvent prendre deux syntaxes différentes. La première est simplement « A » ou « M » suivie d’un nombre de secondes. Cela définit l’expiration par rapport à la dernière fois que le contenu a été « consulté » ou « modifié » respectivement. Par exemple, ces deux options feraient expirer le contenu 30 secondes après son accès.

ExpiresDefault A30ExpireByType text/html A30

L’autre syntaxe permet une configuration plus verbeuse. Elle vous permet d’utiliser des unités autres que les secondes qui sont plus faciles à calculer pour les humains. Elle utilise également le mot complet « accès » ou « modification ». Toute la configuration de l’expiration doit être conservée entre guillemets, comme ceci :

ExpiresDefault "modification plus 2 weeks 3 days 1 hour"ExpiresByType text/html "modification plus 2 weeks 3 days 1 hour"

Pour nos besoins, nous allons simplement définir une expiration par défaut. Nous commencerons par la fixer à 5 minutes, de sorte que si nous commettons une erreur en nous familiarisant, elle ne sera pas stockée sur les ordinateurs de nos clients pendant une période extrêmement longue. Lorsque nous serons plus confiants dans notre capacité à sélectionner des politiques appropriées pour notre contenu, nous pourrons ajuster cela à quelque chose de plus agressif :

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 ExpiresActive on ExpiresDefault "access plus 5 minutes" </Location></VirtualHost>

Ceci définira notre en-tête Expires à cinq minutes dans le futur et définira Cache-Control max-age=300. Afin d’affiner davantage notre politique de mise en cache, nous pouvons utiliser la directive Header. Nous pouvons utiliser l’option merge pour ajouter des options Cache-Control supplémentaires. Vous pouvez appeler cette directive plusieurs fois et ajouter toutes les politiques supplémentaires que vous souhaitez. Consultez ce guide pour avoir une idée des politiques de mise en cache que vous souhaitez définir pour votre contenu. Pour notre exemple, nous allons juste définir « public » afin que les autres caches puissent être sûrs qu’ils sont autorisés à stocker des copies.

Pour définir ETags pour le contenu statique de notre site (à utiliser pour la validation), nous pouvons utiliser la directive FileETag. Cela fonctionnera pour le contenu statique. Pour le contenu généré dynamiquement, votre application sera responsable de générer correctement ETags.

Nous utilisons la directive pour définir les attributs qu’Apache utilisera pour calculer le Etag. Cela peut être INode, MTime, Size, ou All selon que nous voulons modifier le ETag chaque fois que le inode du fichier change, que son temps de modification change, que sa taille change, ou tout cela à la fois. Vous pouvez fournir plus d’une valeur, et vous pouvez modifier le paramètre hérité dans les contextes enfants en faisant précéder les nouveaux paramètres d’un + ou -. Pour nos besoins, nous utiliserons simplement « all » afin que tous les changements soient enregistrés:

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 ExpiresActive on ExpiresDefault "access plus 5 minutes" Header merge Cache-Control public FileETag All </Location></VirtualHost>

Ceci ajoutera « public » (séparé par une virgule) à la valeur Cache-Control déjà présente et inclura un ETag pour notre contenu statique.

Lorsque vous avez terminé, enregistrez et fermez le fichier. Vérifiez la syntaxe de vos modifications en tapant :

sudo apachectl configtest

Si aucune erreur n’a été trouvée, redémarrez votre service pour mettre en œuvre vos politiques de mise en cache :

sudo service apache2 restart

Conclusion

Configurer la mise en cache avec Apache peut sembler être un travail intimidant en raison du nombre d’options disponibles. Heureusement, il est facile de commencer de manière simple et d’évoluer au fur et à mesure que vous avez besoin de plus de complexité. La plupart des administrateurs n’auront pas besoin de chacun des types de mise en cache.

Lorsque vous configurez la mise en cache, gardez à l’esprit les problèmes spécifiques que vous essayez de résoudre pour éviter de vous perdre dans les différents choix d’implémentation. La plupart des utilisateurs bénéficieront au moins de la configuration des en-têtes. Si vous utilisez un proxy ou générez du contenu, la mise en place d’un cache HTTP peut être utile. La mise en cache des objets partagés est utile pour des tâches spécifiques comme le stockage des sessions SSL ou des détails d’authentification si vous utilisez un fournisseur backend. La mise en cache des fichiers peut probablement être limitée à ceux qui ont des systèmes lents.