Vue d’ensemble
La plupart des sites Web comportent de grandes quantités de contenu qui reste inchangé ou est rarement modifié après sa publication. Et chaque fois qu’il est demandé au serveur web, modifié ou non, il est retraité et transmis au client, consommant inutilement de précieuses ressources système et de la bande passante réseau. Au fur et à mesure que votre site Web ou votre application gagne en popularité, nous demandons davantage à votre serveur de traiter un contenu qui, bien que généré dynamiquement, est statique.
Ce n’est pas une utilisation efficace des ressources et cela finira par vous coûter cher, car vous installerez davantage de matériel pour suivre la charge. C’est là que la mise en cache entre en jeu. Ne gaspillons pas les cycles de l’unité centrale ou la mémoire vive en traitant du contenu déjà consulté qui n’est pas susceptible de changer dans un délai déterminé. Au lieu de cela, nous allons servir un contenu prétraité, stocké temporairement sur le serveur ou dans le cache des navigateurs web. Et ce n’est qu’après que le contenu ait été modifié ou qu’un temps déterminé se soit écoulé que nous retraiterons le contenu demandé.
Configurer la mise en cache dans Apache
Apache est livré avec trois modules pour la mise en cache du contenu, l’un l’active et les deux autres déterminent l’endroit où le magasin de cache existe – sur le disque ou en mémoire. Déterminer le module à utiliser pour le magasin de cache dépend de vos ressources matérielles disponibles et de vos exigences de performance.
Servir à partir du disque est lent mais moins coûteux. La desserte à partir de la mémoire est rapide, mais coûteuse – à la fois en termes de coût et de consommation de ressources. Cependant, vous pouvez stimuler les performances du cache sur disque en le plaçant sur un stockage SSDFLASH au lieu d’un disque tournant conventionnel.
- S’assurer que le cache_module est chargé par Apache, en vérifiant que la ligne suivante existe dans le fichier de configuration du serveur d’Apache, non commentée.
LoadModule cache_module modules/mod_cache.so
- Pour le cache sur disque, s’assurer que le disk_cache_module est chargé par Apache. Recherchez la ligne suivante, non commentée.
LoadModule disk_cache_module modules/mod_disk_cache.so
- Ajoutez les lignes suivantes dans le fichier de configuration du serveur Apache (pour le global) ou à l’intérieur d’une directive VirtualHost (application localisée).
CacheEnable disk /CacheRoot /webapps/cache/app1CacheDefaultExpire 3600CacheDisable /wp-admin
CacheEnable disk / Unable caching to disk for relative directory « / ».
Cacheroot Définir le répertoire de stockage du cache, où tout le contenu mis en cache sera enregistré.
CacheDefaultExpire Définir la date d’expiration par défaut, par rapport à la date de la requête originale, en secondes.
CacheDisable Désactiver la mise en cache pour les chemins relatifs suivant l’option. Les zones sensibles et celles qui ne devraient pas être mises en cache devraient être ajoutées ici.
Définir l’expiration du contenu
La mise en cache nécessite une date d’expiration pour qu’elle fonctionne. Sans une date d’expiration sur votre contenu, le cache ne peut pas déterminer s’il est périmé ou non.
Utiliser le Mod_Expires
Ce module vous permet de définir des dates d’expiration pour votre contenu, dans son ensemble ou individuellement en fonction du type ou de la chaîne correspondante.
- S’assurer que le module est chargé dans Apache. Ouvrez le fichier de configuration du serveur (httpd.conf dans CentOS) et recherchez cette ligne. Décommentez-la, si elle est commentée par un ‘#’.
LoadModule expires_module modules/mod_expires.so
- Ajoutez les lignes suivantes soit à la configuration du serveur Apache, soit à une configuration d’hôte virtuel, soit à une directive de répertoire, soit à .htaccess, en fonction de l’endroit où vous voulez que votre politique de mise en cache soit définie.
<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 1 day"</IfModule></pre>
ExpiresActive On Active les expirations du mod.
ExpiresDefault Définit la date d’expiration par défaut pour tout le contenu. L’accès plus 1 jour définit le délai d’expiration à l’heure d’accès du contenu + 1 jour, ce qui signifie qu’il sera mis en cache pendant 24 heures.
- Si vous souhaitez attribuer des valeurs d’expiration différentes à des types de contenu spécifiques, vous pouvez utiliser l’option ExpiresByType, en plus ou sans l’option ExpiresDefault. Voici quelques exemples:
<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 1 day" ExpiresByType image/jpg "access plus 5 days" ExpiresByType image/jpeg "access plus 5 days" ExpiresByType image/gif "access plus 5 days" ExpiresByType image/png "access plus 5 days" ExpiresByType text/css "access plus 1 month" ExpiresByType application/pdf "access plus 1 month" ExpiresByType text/x-javascript "access plus 1 month" ExpiresByType application/x-shockwave-flash "access plus 1 month" ExpiresByType image/x-icon "access plus 1 year"</IfModule>
Utiliser les en-têtes HTTP dans l’application Web
Les dates d’expiration et de dernière modification peuvent être définies par l’application Web à l’aide de paramètres d’en-tête HTTP. Cela donne le contrôle de la fraîcheur du contenu aux développeurs ou à l’application. La façon de procéder dépend de votre application.
- HTML
Utiliser la balise Meta et définir l’âge du contenu. Dans l’exemple ci-dessous, définissez le cache à privé (client demandeur uniquement) et l’âge maximal à 1 heure (3600 secondes).<meta http-equiv="Cache-control" content="private,max-age:3600">
- PHP
Utilisez la fonction Header() pour définir l’âge du contenu dans l’en-tête des documents.header("Cache-Control: private, max-age=3600");
Cache du contenu non expirant
Parfois, vous devez mettre en cache du contenu qui n’a pas de date d’expiration définie. Comme mentionné précédemment, les dates d’expiration sont une condition pour que le mécanisme de mise en cache fonctionne, par défaut. Cependant, nous pouvons demander à Apache d’ajouter une date d’expiration par défaut aux contenus qui n’ont pas de date d’expiration définie, et de les mettre en cache. Le CacheIgnoreNoLastMod nous permet de le faire.
- Ajouter l’option CacheIgnoreNoLastMod avec une valeur de On à l’emplacement où vous avez activé la mise en cache – le fichier de configuration du serveur d’Apache ou un fichier de configuration des hôtes virtuels.
CacheEnable disk /CacheRoot /webapps/cache/app1CacheDefaultExpire 3600CacheDisable /wp-adminCacheIgnoreNoLastMod On
Prévenir la mise en cache du contenu par les navigateurs
Le problème avec les configurations de mise en cache ci-dessus est que le contenu de votre application est mis en cache à deux endroits : sur le client et sur le serveur. Si vous mettez à jour votre contenu et que vous voulez que l’utilisateur le voie immédiatement, il peut ne pas le faire si sa version mise en cache localement n’a pas expiré. Vous pouvez raccourcir le temps d’expiration, mais vous risquez alors d’aller à l’encontre de l’objectif de la mise en cache entièrement.
Prenez plutôt le contrôle total de la mise en cache, en l’activant sur le serveur uniquement. Forcez le navigateur web à obtenir le contenu du serveur pour chaque requête, mais servez le contenu Java ou PHP prétraité, par exemple, à moins que le contenu ait été modifié. Cela permet de s’assurer que l’utilisateur voit toujours la version la plus récente, tout en ne gaspillant pas les cycles du processeur ou la mémoire vive en retraitement inutilement.
- Ajouter l’option CacheIgnoreCacheControl à l’emplacement ont la mise en cache activée – le fichier de configuration du serveur Apache ou la configuration d’un hôte virtuel – avec une valeur de On . Cela permet à Apache d’ignorer les demandes de rafraîchissement du contenu du navigateur. Tout le contenu sera servi à partir du cache du serveur, lorsque cela est possible, jusqu’à ce qu’il ait expiré.
CacheEnable disk /CacheRoot /webapps/cache/app1CacheDefaultExpire 3600CacheDisable /wp-adminCacheIgnoreNoLastMod OnCacheIgnoreCacheControl On
- Enregistrez vos modifications.
- Redémarrez Apache pour appliquer vos modifications.
WordPress et autres frameworks d’application
Les frameworks, comme celui de WordPress et ceux similaires à CodeIgniter, acheminent tout le contenu à travers Index.php. Selon la façon dont vous avez écrit vos règles mod_rewrite, votre contenu en cache s’affichera de façon incorrecte. Vous pouvez constater que le contenu d’une page demandée, d’une catégorie, etc, s’affiche à la place de ce qui a été réellement demandé.
Pour combattre cela, nous devons nous assurer que le cache d’Apache considère les paramètres ajoutés à la fin de l’index.php lorsque le contenu est mis en cache et tiré. Modifiez la règle Rewrite pour index.php, comme on le voit dans l’exemple ci-dessous.
# WordPress Permalink rewritesRewriteBase /RewriteRule ^index.php$ – RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule ^(.*)$ /index.php/