TOC

Comment configurer la mise en cache de contenu Apache sur CentOS 7

Qu’est-ce que la mise en cache?

La mise en cache est une méthode permettant d’améliorer les performances du serveur en permettant au contenu généralement demandé d’être stocké temporairement de manière à permettre un accès plus rapide. Cela accélère le traitement et la livraison en éliminant certaines opérations gourmandes en ressources.

En créant des règles de mise en cache efficaces, le contenu adapté à la mise en cache sera stocké pour améliorer les temps de réponse, préserver les ressources et minimiser la charge. Apache fournit une variété de caches permettant d’accélérer différents types d’opérations. Dans ce guide, nous verrons comment configurer Apache 2.4 sur CentOS 7 à l’aide de ses différents modules de mise en cache.

Pour en savoir plus sur le développement de stratégies de mise en cache générales, consultez this 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é. Le projet les divise en trois groupes en fonction de la méthode de mise en cache du contenu. La ventilation générale est la suivante:

  • * Mise en cache de fichiers *: stratégie de mise en cache la plus élémentaire, elle permet simplement d’ouvrir des fichiers ou des descripteurs de fichiers au démarrage du serveur et de les conserver pour accélérer l’accès.

  • * Mise en cache clé-valeur *: principalement utilisée pour la mise en cache SSL et d’authentification, la mise en cache clé-valeur utilise un modèle d’objet partagé capable de stocker des éléments dont le calcul coûte cher plusieurs fois.

  • * Mise en cache HTTP standard *: le mécanisme de mise en cache le plus flexible et le plus utile, ce système à trois états peut stocker les réponses et les valider à leur expiration. Ceci peut être configuré pour la performance ou la flexibilité en fonction de vos besoins spécifiques.

Un rapide coup d’œil aux descriptions ci-dessus peut révéler que certaines méthodes se chevauchent, mais il peut également être utile d’utiliser plus d’une stratégie à la fois. Par exemple, l’utilisation d’un magasin de valeurs-clés pour vos sessions SSL et l’activation d’un cache HTTP standard pour les réponses peuvent vous permettre de réduire considérablement la charge de vos sources de données et d’accélérer de nombreuses opérations de livraison 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 de fichiers

Aperçu général

  • * Modules principaux impliqués *: + mod_file_cache +

  • * Principaux cas d’utilisation *: stockage du contenu ou des descripteurs de fichier au démarrage du serveur. Ce sont des représentations statiques qui ne peuvent pas être modifiées de manière fiable avant le redémarrage du serveur.

  • * Features *: 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ée avec parcimonie pour respecter les limites du système d’exploitation, ne peut être utilisée 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 dotés de systèmes de fichiers lents. Il offre un choix de deux directives de configuration, qui visent toutes deux à accélérer le processus de traitement 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 + permet de spécifier le chemin d’accès aux fichiers sur le disque auxquels vous souhaitez accélérer l’accès. Lors du démarrage d’Apache, Apache ouvrira les fichiers statiques spécifiés et mettra en cache le descripteur de fichier, évitant ainsi la nécessité d’ouvrir le fichier lorsqu’il est demandé. Le nombre de fichiers pouvant être ouverts de cette manière est soumis aux limitations définies 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 simplement le gestionnaire de fichiers. Cela permet des performances plus rapides pour ces pages, mais présente de sérieuses limitations. Il ne conserve aucune trace de la quantité de mémoire utilisée, il est donc possible de manquer de mémoire. Notez également que les processus enfants copient toute la mémoire allouée, ce qui peut entraîner un épuisement plus rapide des ressources que prévu. Utilisez seulement cette directive avec parcimonie.

Ces directives ne sont évaluées qu’au démarrage d’Apache. Cela signifie que vous ne pouvez pas compter sur Apache pour prendre en compte les modifications apportées après son démarrage. Utilisez-les uniquement sur des fichiers statiques qui ne changeront pas pendant la durée de la session Apache. Selon la manière dont les fichiers sont modifiés, le serveur peut être averti des modifications, mais ce comportement n’est pas attendu et ne fonctionnera pas toujours correctement. Si des modifications doivent être apportées aux fichiers transmis à ces directives, redémarrez Apache une fois les modifications apportées.

Comment activer la mise en cache de fichiers

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

Lors de l’exécution de CentOS 7, le module sera installé lors de l’installation d’Apache, mais la configuration par défaut ne le chargera pas. Pour charger le module, nous allons créer un fichier simple dans notre répertoire + / etc / httpd / conf.modules.d + pour charger le module. Nous appellerons ce fichier + 00-cache.conf +:

sudo nano /etc/httpd/conf.modules.d/00-cache.conf

À l’intérieur, nous devons utiliser la directive + LoadModule + pour activer les fonctionnalités dont nous avons besoin. Ajoutez la ligne suivante au fichier:

/etc/httpd/conf.modules.d/00-cache.conf

LoadModule file_cache_module modules/mod_file_cache.so

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ensuite, vous devez éditer le fichier de configuration principal pour configurer vos directives de mise en cache de fichiers. Ouvrez le fichier en tapant:

sudo nano /etc/httpd/conf/httpd.conf

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

/etc/httpd/conf/httpd.conf

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

Lorsque le serveur est redémarré, Apache ouvre les fichiers répertoriés et stocke leurs descripteurs dans le cache pour un accès plus rapide.

Si, à la place, vous souhaitez mapper quelques fichiers directement dans la 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:

/etc/httpd/conf/httpd.conf

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

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

Lorsque 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 lit + Syntaxe OK +, vous pouvez redémarrer en toute sécurité votre instance Apache:

sudo systemctl restart httpd

Apache va redémarrer, mettant en cache le contenu du fichier ou des gestionnaires en fonction des directives que vous avez utilisées.

Mise en cache clé-valeur

Aperçu général

  • * Modules principaux impliqués *: + mod_socache_dbm +, + mod_socache_dc +, + mod_socache_memcache +, + mod_socache_shmcb +

  • * Modules de support impliqués *: + mod_authn_socache +, + mod_ssl +

  • * Principaux cas d’utilisation *: stockage de sessions SSL ou de détails d’authentification, agrafage SSL

  • * Caractéristiques *: cache d’objets partagés pour stocker des ressources complexes, peut aider à la mise en cache et à l’agrafage de sessions SSL, backends flexibles

  • * Inconvénients *: ne dispose pas de mécanismes de validation, il est nécessaire de configurer un logiciel distinct pour des backends plus performants / flexibles, certains bugs dans le code

Les détails

La mise en cache clé-valeur est plus complexe que la mise en cache de fichiers et offre des avantages plus ciblés. Également appelé cache d’objets partagés, le cache clé-valeur d’Apache est principalement utilisé pour éviter de répéter des 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 de l’authentification, les sessions SSL et pour fournir un agrafage SSL.

Note

La mise en cache proprement dite est réalisée grâce à l’utilisation de l’un des modules du fournisseur de mise en cache d’objets partagés. Ceux-ci sont:

  • * + mod_socache_dbm + *: Ce backend utilise le simple moteur de base de données + dbm +, qui est un magasin de clé-valeur basé sur fichier qui utilise des compartiments de hachage et de taille fixe. Ce fournisseur souffre de certaines fuites de mémoire, il est donc 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, alors utilisez-le avec prudence.

  • * + mod_socache_memcache + *: Ceci utilise le cache des objets de mémoire distribués de 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 patch a été validé dans le tronc du contrôle de version d’Apache qui corrige le problème.

  • * + mod_socache_shmcb + *: Il s’agit actuellement de la meilleure option pour la mise en cache clé-valeur. Ceci met en cache une mémoire tampon cyclique dans la mémoire partagée, qui supprimera les entrées à mesure qu’elle sera pleine. Il s’étouffe actuellement sur https://bz.apache.org/bugzilla/show_bug.cgi?id=57023&entries de plus de 11k].

En plus des modules de fournisseur 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 configurer l’agrafage SSL, vous devez activer + mod_ssl +, ce qui fournira respectivement les directives + SSLSessionCache + et + + SSLStaplingCache +. De même, pour configurer la mise en cache d’authentification, le module + mod_authn_socache + doit être activé afin que la directive + AuthnCacheSOCache + puisse être définie.

Comment activer la mise en cache clé-valeur

En gardant à l’esprit les bogues et les mises en garde ci-dessus, 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 clé-valeur dépend de son utilisation et du fournisseur que vous utilisez. Nous allons passer en revue les bases de la mise en cache d’authentification et de la session SSL ci-dessous.

Il existe actuellement un bogue avec la mise en cache de l’authentification qui empêche de passer des arguments au fournisseur de cache. Ainsi, tous les fournisseurs qui ne fournissent pas les paramètres par défaut sur lesquels ils se replient 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 la base de données. Ces types d’opérations peuvent avoir un impact significatif sur les performances si le backend doit être touché chaque fois qu’une demande d’authentification est faite.

La mise en cache implique la modification de la configuration de votre authentification existante (nous ne verrons pas comment configurer l’authentification dans ce guide). Les modifications elles-mêmes seront sensiblement les mêmes quelle que soit la méthode d’authentification d’arrière-plan. Nous allons utiliser + mod_socache_shmcb pour votre démonstration. Ce module est déjà activé dans notre fichier + / etc / httpd / conf.modules.d / 00-base.conf +.

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

sudo nano /etc/httpd/conf/httpd.conf

A l’intérieur, vers le haut du fichier, ajoutez la directive + AuthnCacheSOCache +. Spécifiez que + shmcb + doit être utilisé en tant que fournisseur. Si le bogue mentionné précédemment empêchant la transmission des options est résolu au moment où vous le lisez, vous pouvez spécifier un emplacement et une taille pour le cache. Le nombre étant en octets, l’exemple commenté donnera un cache de 512 kilo-octets:

/etc/httpd/conf/httpd.conf

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é.

Ensuite, ouvrez la page de configuration de votre hôte virtuel pour laquelle l’authentification est configurée. Nous supposerons que vous utilisez une configuration d’hôte virtuel appelée + site.conf + située dans le répertoire + / etc / httpd / conf.d +, mais vous devez la modifier pour refléter votre environnement:

sudo nano /etc/httpd/conf.d/site.conf

Un hôte virtuel de base configuré avec une authentification peut ressembler à ceci:

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   <Directory /var/www/html/private>
       AuthType Basic
       AuthName "Restricted Files"
       AuthUserFile /etc/httpd/.htpasswd
       AuthBasicProvider file
       Require valid-user
   </Directory>
</VirtualHost>

À l’emplacement où vous avez configuré l’authentification, modifiez le bloc pour ajouter la mise en cache. Spécifiquement, vous devez ajouter le + AuthnCacheProvideFor + pour lui indiquer les sources d’authentification à mettre en cache, ajouter un délai de cache avec + AuthnCacheTimeout + et ajouter + socache + à la liste + AuthBasicProvider + devant votre méthode d’authentification conventionnelle. Les résultats ressembleront à ceci:

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   <Directory /var/www/html/private>
       AuthType Basic
       AuthName "Restricted Files"
       AuthUserFile /etc/apache/.htpasswd
       AuthBasicProvider  file


       Require valid-user
   </Directory>
</VirtualHost>

L’exemple ci-dessus concerne l’authentification de 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 lorsque la spécification de «fichier» est dans l’exemple ci-dessus, l’autre méthode d’authentification serait utilisée à la place.

Enregistrez et fermez le fichier. Recherchez des erreurs de syntaxe dans vos modifications en tapant:

sudo apachectl configtest

Si aucune erreur de syntaxe n’est trouvée, redémarrez Apache pour implémenter vos modifications de mise en cache:

sudo systemctl restart httpd
Mise en cache de session SSL

La poignée de main à établir 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 des demandes ultérieures peut potentiellement éviter cette pénalité. Le cache d’objets partagés est un endroit parfait pour cela.

Si SSL est déjà configuré pour votre serveur Apache, + mod_ssl + sera activé (sinon, utilisez + yum + pour installer le module + mod_ssl +). Sous CentOS 7, cela signifie qu’un fichier + ssl.conf + sera disponible dans le répertoire + / etc / httpd / conf.d +. Cela met déjà en place la mise en cache. À l’intérieur, vous verrez des lignes comme celle-ci:

/etc/httpd/conf.d/ssl.conf

. . .

SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300

. . .

C’est en fait assez pour configurer la mise en cache de session. Pour tester cela, vous pouvez utiliser le client de connexion d’OpenSSL. Type:

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

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

Mise en cache HTTP standard

Aperçu général

  • * Modules principaux impliqués *: + mod_cache +

  • * Modules de support 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 des entrées obsolètes, peut être déployé pour une vitesse maximale ou une flexibilité en fonction de vos besoins

  • * Inconvénients *: Peut fuir des données sensibles s’il est configuré de manière incorrecte, doit utiliser des modules supplémentaires pour définir correctement la stratégie 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 chaque élément en cache pendant un certain temps, en fonction des stratégies de mise en cache définies aux origines du contenu et des propres règles de mise en cache de l’ordinateur.

Le mécanisme de mise en cache HTTP Apache met les réponses en cache en fonction des stratégies de mise en cache HTTP qu’il voit. Il s’agit d’un système de mise en cache à usage général qui respecte les mêmes règles que tout serveur intermédiaire qui aurait une participation dans la livraison. Cela rend ce système très flexible et puissant et vous permet d’exploiter les en-têtes que vous devriez déjà définir dans votre contenu (nous verrons plus loin comment le faire.).

Le cache HTTP d’Apache est également appelé cache «à trois états». En effet, le contenu qu’il a stocké peut être dans l’un des trois états. Il peut être récent, ce qui signifie qu’il est autorisé à être servi aux clients sans autre vérification, il peut être obsolète, ce qui signifie que la durée de vie du contenu a expiré ou peut être inexistante si le contenu n’est pas trouvé dans le cache. .

Si le contenu devient obsolète, le cache peut le revalider à la demande suivante 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 le temps imparti par sa stratégie de mise en cache.

Aperçu du module

La logique de mise en cache HTTP est disponible via le module + mod_cache +. La mise en cache proprement dite est effectuée avec l’un des fournisseurs de mise en cache. En règle générale, le cache est stocké sur le disque à l’aide du module + mod_cache_disk +, mais la mise en cache des objets partagés est également disponible via le module + mod_cache_socache +.

Le module + mod_cache_disk + se met en cache sur le disque. Il peut donc être utile si vous transmettez un contenu par proxy depuis un emplacement distant, le générez à partir d’un processus dynamique, ou essayez simplement d’accélérer les choses en mettant en cache sur un disque plus rapide que votre contenu sur. Il s’agit du fournisseur le mieux testé et devrait probablement être votre premier choix dans la plupart des cas. Le cache n’étant pas nettoyé automatiquement, un outil appelé + htcacheclean + doit être exécuté à l’occasion pour réduire le cache. Cela peut être exécuté manuellement, configuré en tant que tâche + cron + normale ou en tant que démon.

Le module + mod_cache_socache + met en cache l’un des fournisseurs d’objets partagés (les mêmes que ceux décrits dans la dernière section). Cela peut potentiellement avoir de meilleures performances que + mod_cache_disk + (en fonction du fournisseur de cache partagé sélectionné). Cependant, il est beaucoup plus récent et repose sur les fournisseurs d’objets partagés, qui présentent les bogues décrits plus haut. Un test complet est recommandé avant de mettre en œuvre l’option + mod_cache_socache +.

Emplacement 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 de la demande. Si du contenu est trouvé, il sera servi directement sans autre traitement. Cela signifie qu’elle est incroyablement rapide, mais qu’elle ne permet pas de processus tels que l’authentification du contenu. S’il y a du contenu dans votre cache qui requiert normalement une authentification ou un contrôle d’accès, il sera accessible à * toute personne * sans authentification si le + CacheQuickHandler + est défini sur «on».

Fondamentalement, cela émule un cache séparé devant votre serveur Web. Si votre serveur Web doit effectuer une vérification, une authentification ou une autorisation conditionnelle, cela ne se produira pas. Apache n’évaluera même pas les directives contenues dans les blocs + <Location> + ou + <Répertoire> +. Notez que + CacheQuickHandler + est défini sur «on» par * default *!

Si le + CacheQuickHandler + est réglé sur «off», le cache sera vérifié de manière significative plus tard dans la séquence de traitement de la demande. Pensez à cette configuration en 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 de récupérer le contenu du cache. Si vous désactivez cette option, la vitesse de traitement des requêtes est un peu plus rapide.

Comment configurer la mise en cache HTTP standard

Pour activer la mise en cache, vous devez activer le module + mod_cache + ainsi que l’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 en remettre à cela.

Configurer htcacheclean pour gérer automatiquement le cache

Sur un système CentOS 7, l’utilitaire + htcacheclean +, utilisé pour réduire le cache au fur et à mesure de sa croissance, est installé au cours de l’installation + httpd +. Un fichier d’unité + systemd appelé` + htcacheclean.service` est inclus par défaut.

Si vous envisagez de configurer la mise en cache, il est judicieux de configurer ce service pour qu’il s’exécute automatiquement. Le fichier de service démonèle le service en exécutant l’opération de nettoyage à un intervalle configurable. Cependant, par défaut, il n’y a pas de mécanisme pour le démarrer au démarrage d’Apache.

Pour le configurer, nous allons créer un répertoire nommé + httpd.service.requires + dans le répertoire + / etc / systemd / system +. Cela peut être utilisé pour spécifier les dépendances du fichier unité + httpd.service qui démarre Apache:

sudo mkdir -p /etc/systemd/system/httpd.service.requires

Ensuite, nous pouvons lier le fichier unité + htcacheclean.service dans ce répertoire. Cela entraînera le service + htcacheclean + pour démarrer et nettoyer le cache à intervalles réguliers au démarrage d’Apache:

sudo ln -s /usr/lib/systemd/system/htcacheclean.service /etc/systemd/system/httpd.service.requires

Vous pouvez configurer les options + htcacheclean +, y compris l’intervalle de nettoyage, en modifiant le fichier + htcacheclean + dans le répertoire + / etc / sysconfig +:

sudo nano /etc/sysconfig/htcacheclean

Ici, vous pouvez modifier l’intervalle de nettoyage, la racine du cache, la taille maximale du cache et toute autre option de l’utilitaire:

/ etc / sysconfig / htcacheclean

INTERVAL=15
CACHE_ROOT=/var/cache/httpd/proxy
LIMIT=100M
OPTIONS=

Note

Lorsque vous avez terminé, enregistrez et fermez le fichier.

Redémarrez Apache pour lancer le + htcacheclean pour vider le cache automatiquement:

sudo systemctl restart httpd
Modification de la configuration globale

La majeure partie de la configuration de la mise en cache aura lieu dans des définitions d’hôte virtuel individuelles ou des blocs d’emplacement. Cependant, certains éléments de configuration globale doivent également être utilisés pour configurer certains attributs généraux. Ouvrez votre fichier de configuration Apache principal pour configurer ces éléments:

sudo nano /etc/httpd/conf/httpd.conf

Nous devons ajouter le répertoire + CacheRoot + pour pointer vers le chemin à utiliser pour stocker nos éléments mis en cache. Cela doit toujours correspondre à la valeur + CACHE_ROOT + trouvée dans votre fichier + / etc / sysconfig / htcacheclean + afin que le cache puisse être géré correctement. Nous allons également définir les directives + CacheDirLevels + et + CacheDirLength +, qui contribuent toutes deux à la définition de la structure de la structure du répertoire de cache:

/etc/httpd/conf/httpd.conf

CacheRoot /var/cache/httpd/proxy
CacheDirLevels 2
CacheDirLength 1

Les éléments + CacheDirLevels + et + CacheDirLength + contribuent à la définition de la structure de la structure du répertoire de cache. Un hachage + md5 + de l’URL servie sera créé en tant que clé utilisée pour stocker les données. Les données seront organisées dans des 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 + b1946ac92492d2347c6235b4d2611184 + avec les valeurs par défaut indiquées ci-dessus serait classé dans une structure de répertoire de + b / 1 / 946ac92492d2347c6235b4d2611184 +. Généralement, vous n’aurez pas besoin de modifier ces valeurs, mais il est bon de savoir à quoi elles servent.

Les autres valeurs que vous pouvez définir dans ce fichier sont + CacheMaxFileSize + et + CacheMinFileSize + qui définissent les plages de taille de fichier en octets qu’Apache mettra dans le cache, ainsi que + CacheReadSize + et + CacheReadTime +, qui vous permet d’attendre et de mettre le contenu en mémoire tampon 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 majeure partie de la configuration de 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 un fichier nommé + site.conf + dans votre répertoire + / etc / httpd / conf.d + de ce guide:

sudo nano /etc/httpd/conf.d/site.conf

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

Nous en profiterons également pour configurer le verrouillage du cache. Il s’agit d’un système de verrous de fichiers que Apache utilisera lorsqu’il se connecte à l’origine du contenu pour voir si le contenu est toujours valide. Pendant le temps où cette requête est satisfaite, si des demandes supplémentaires pour le même contenu entrent, cela entraînerait des demandes supplémentaires pour la ressource principale, ce qui pourrait provoquer des pics de charge.

La définition d’un verrou de cache pour une ressource lors de la validation indique à Apache que la ressource est en cours d’actualisation. Pendant ce temps, la ressource obsolète peut être servie avec un en-tête d’avertissement indiquant son état. Nous allons configurer cela avec un répertoire de verrouillage de 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 dirons également à Apache d’ignorer les en-têtes + Set-Cookie + et de ne pas les stocker dans le cache. Cela empêchera Apache de divulguer accidentellement des cookies spécifiques à des utilisateurs vers d’autres parties. L’en-tête + Set-Cookie + sera supprimé avant que les en-têtes ne soient mis en cache.

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html








</VirtualHost>

Nous devons encore activer la mise en cache pour cet hôte virtuel. Nous pouvons le faire avec la directive + CacheEnable +. Si cela est défini dans un bloc d’hôte virtuel, nous aurions besoin de fournir la méthode de mise en cache (+ disk + ou + socache +) ainsi que les URI demandés devant être mis en cache. Par exemple, pour mettre en cache toutes les réponses, cela peut être défini sur + CacheEnable disk / +, mais si vous souhaitez uniquement mettre en cache les réponses sous l’URI + / public +, vous pouvez définir ceci sur + CacheEnable disk / public + .

Nous adopterons une approche différente en activant notre cache dans un bloc d’emplacement spécifique. Cela signifie que nous n’avons pas à fournir de chemin d’URI à la commande + CacheEnable +. Tout URI qui serait servi à partir de cet emplacement sera mis en cache. Nous activerons également la directive + CacheHeader + afin que nos en-têtes de réponse indiquent si le cache a été utilisé ou non pour répondre à la demande.

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 allons définir + CacheMaxExpire + pour limiter la durée de sauvegarde des éléments. Nous allons définir le + CacheLastModifiedFactor + afin 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 écoulé depuis la modification pour définir une expiration raisonnable.

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   CacheQuickHandler off

   CacheLock on
   CacheLockPath /tmp/mod_cache-lock
   CacheLockMaxAge 5

   CacheIgnoreHeaders Set-Cookie









</VirtualHost>

Enregistrez et fermez votre fichier lorsque vous avez configuré tout ce dont vous avez besoin.

Vérifiez toute 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 systemctl restart httpd

Définition d’expiration et mise en cache des en-têtes sur le contenu

Dans la configuration ci-dessus, nous avons configuré la mise en cache HTTP, qui repose sur des en-têtes HTTP. Cependant, aucun des contenus que nous servons ne possède les en-têtes + Expires ou` + Cache-Control` nécessaires pour prendre des décisions intelligentes en matière de mise en cache. 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 plus spécifiques` + Cache-Control` pour affiner la politique de mise en cache. Ces deux modules sont activés par défaut dans le package CentOS 7 Apache.

Nous pouvons directement modifier à nouveau notre fichier d’hôte virtuel pour commencer à configurer ces éléments:

sudo nano /etc/httpd/conf.d/site.conf

Le module + mod_expires + fournit seulement trois directives. + ExpiresActive + active le traitement de l’expiration dans un certain contexte en le définissant sur «activé». Les deux autres directives sont très similaires. La directive + ExpiresDefault + définit le délai d’expiration par défaut, tandis que + ExpiresByType + définit le délai d’expiration en fonction du type MIME du contenu. Ces deux éléments définiront les valeurs correctes + Expires et` + Cache-Control` '.

Ces deux paramètres peuvent prendre deux syntaxes différentes. Le premier est simplement “A” ou “M” suivi d’un nombre de secondes. Cela définit l’expiration par rapport à la dernière fois où le contenu a été «accédé» ou «modifié», respectivement. Par exemple, ces deux contenus expireraient 30 secondes après leur accès.

ExpiresDefault A30
ExpireByType text/html A30

L’autre syntaxe permet une configuration plus détaillée. Il vous permet d’utiliser des unités autres que les secondes qui sont plus faciles à calculer pour les humains. Il utilise également le mot complet «accès» ou «modification». La configuration d’expiration complète 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 régler le message à 5 minutes afin que, si nous commettions une erreur en nous familiarisant avec elle, elle ne soit pas stockée sur les ordinateurs de nos clients pendant une très longue période. Lorsque nous sommes plus confiants dans notre capacité à sélectionner des stratégies adaptées à notre contenu, nous pouvons ajuster cela à quelque chose de plus agressif:

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   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>

Cela définira votre en-tête + Expires sur cinq minutes dans l’avenir, ainsi que` + Cache-Control max-age = 300 + . Pour affiner davantage notre politique de mise en cache, nous pouvons utiliser la directive `+ Header +. Nous pouvons utiliser l’option + merge pour ajouter d’autres options` + Cache-Control`. Vous pouvez appeler cela plusieurs fois et ajouter les politiques supplémentaires de votre choix. Consultez this guide pour vous faire une idée des règles de mise en cache que vous souhaitez utiliser. définir pour votre contenu. Pour notre exemple, nous allons simplement définir «public» afin que les autres caches puissent s’assurer 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 chargée de générer correctement + ETags +.

Nous pouvons utiliser la directive pour définir les attributs qu’Apache utilisera pour calculer le + Etag +. Cela peut être + INode +, '+ MTime + ,' + Size +, ou '+ All + selon si nous voulons modifier le + ETag + chaque fois que le fichier + inode + du fichier, son heure de modification change, son changements de taille, ou tout ce qui précède. Vous pouvez fournir plusieurs valeurs et modifier le paramètre hérité dans des contextes enfants en faisant précéder les nouveaux paramètres d’un `+++ ou + - +. Pour nos besoins, nous utiliserons simplement «all» pour que toutes les modifications soient enregistrées:

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   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"


        All
   </Location>
</VirtualHost>

Cela ajoutera «public» (séparé par une virgule) à la valeur que + Cache-Control a déjà et comprendra 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 stratégies de mise en cache:

sudo systemctl restart httpd

Conclusion

Configurer la mise en cache avec Apache peut sembler une tâche ardue en raison du nombre d’options disponibles. Heureusement, il est facile de commencer simplement, puis de grandir au fur et à mesure de la complexité. La plupart des administrateurs n’auront pas besoin de chacun des types de mise en cache.

Lors de la configuration de la mise en cache, gardez à l’esprit les problèmes spécifiques que vous essayez de résoudre afin d’é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 mandatez ou générez du contenu, il peut être utile de définir un cache HTTP. La mise en cache d’objets partagés est utile pour des tâches spécifiques telles que le stockage de sessions SSL ou les détails d’authentification si vous utilisez un fournisseur dorsal. La mise en cache de fichiers peut probablement être limitée à ceux dotés de systèmes lents.

Related