Introduction au cache web
Documentation préalable
Si la gestion de cache web est pour vous une notion vague je vous invite à lire cette excellente documentation de Mark Nottingham en français nommée tutoriel de la mise en cache pour les auteurs Web et les webmestres. Vous y apprendrez tout sur les caches de navigateurs les caches de serveurs mandataires nommé proxy et reverses proxy ainsi que tout sur la configuration des en tête ou header du protocole HTTP nécessaire tel quel documenté dans la rfc 2616 section Caching in HTTP
La chaîne des caches.
Les caches web forme sont présent sur tout la chaîne de distribution entre vote site web et l’internaute. Cette chaîne peux être complexe ou très simple mais vous n’en maitrisez pas la structure. Imaginons le cas d’une chaîne complexe, quel sont les chainons ?
- Votre serveur web apache
- Un reverse proxy en amont de votre serveur sur la même architecture
- Un proxy chez le FAI dont dépendant la connexion de l’internaute
- Un second proxy en entré du réseau Lan de l’internaute (typique d’un réseau d’entreprise, école, université etc..)
- Le cache navigateur du logiciel client utilisé pour l’internaute pour consulté votre site.
- Et enfin l’internaute.
Entre votre serveur apache et l’internaute nous avons ici 4 étapes intermédiaires qui sont autant de cache sur la chaîne de distribution. Savoir tirer partie de ces caches est important pour économiser les ressources de votre hébergement et produire un site à l’affichage rapide et sans erreur (qualité indispensable au succès).
L’enjeux est important :
- Les économies réalisables sont immenses. Dans l’exemple 4 services de cache peuvent répondre à l’internaute avant que votre propre serveur soient consulté.
- Les dangers sont immenses. Dans l’exemple 4 services de cache peuvent répondre à l’internaute, avant votre propre serveur, une information obsolète que vous n’avez pas maitrisé.
Les acteurs: développeur et administrateur système LAMP[1]
La gestion des caches web pour une site eZ publish est le sujet d’exemple de la collaboration nécessaire entre les développeur ou responsable d’application et les responsable d’hébergement ou administrateur système.
Dans le cas ou vous ne maitrisez pas votre hébergement directement, quelque soit la raison, il est nécessaire de vous attacher les compétences de l’administrateur système en charge de votre serveur web.
Tâche à la charge du developpeur ou responsable d’application eZ Publish
Le développeur, ayant la haute main sur le code de son application, ce doit pour une parfaite configuration de la chaine des caches web de configurer son instance de eZ Publish pour cela. A cette fin il s’attachera à comprendre les paramètres de configuration de la section HTTPHeaderSettings du fichier site.ini[2]
Header HTTP par defaut de eZ publish
Voici tel que ce présente cette section HTTPHeaderSettings par défaut sans modification après une installation de eZ publish 4.2. Cette configuration par défaut désactive toute possibilité de cache web.
[HTTPHeaderSettings] # Enable/disable custom HTTP header data. CustomHeader=disabled # Only apply custom headers for anonymous users OnlyForAnonymous=disabled # Header list. Contains all HTTP which should override standard ones. HeaderList[] HeaderList[]=Cache-Control HeaderList[]=Pragma HeaderList[]=Expires # Default Cache-Control header # HTTP Headers are specified using the following format : # <HTTP header>[<eZ Publish path|module{/view}>]=<value>{;<depth>{;<level>}} # # Example : # # Set Pragma HTTP header to no-cache for whole site, except /news, and 2 levels below news. # Pragma[] # Pragma[/]=no-cache;2 # Pragma[/news]=;2;0 # Cache-Control values are set directly Cache-Control[] Cache-Control[/]=no-cache, must-revalidate # Pragma values are set directly Pragma[] Pragma[/]=no-cache # Expires specifies time offset compared to current time # Default expired 2 hours ago ( no caching ) Expires[] Expires[/]=-7200
Header HTTP de eZ publish pour Voici.fr
Sur Voici.fr nous avons fait les choix suivants:
- Un cache à 5 minutes pour la home page afin d’être réactif tout en utilisant le cache web. Cette période courte offre la possibilité d’avoir une actualisation de site fréquente entre deux visites pour l’internaute tout en lissant le nombre de requêtes à nos serveur durant une même visite.
- Pour les têtes de rubriques, flux rss et autre sitemap nous avons porté le temps de cache à 15 minutes
- Pour le compte utilisateur et les fonctions communautaire nous avons configuré un temps de cache négatif en plus d’une instruction pragma no cache afin d’être actualisé à chaque affichage.
Nos paramètre sont donc les suivants (extrait):
[HTTPHeaderSettings] CustomHeader=enabled Cache-Control[] Cache-Control[/]=public,must-revalidate Cache-Control[/potins-people]=public,must-revalidate ... Cache-Control[/communaute/espace-prive]=no-cache,must-revalidate Cache-Control[/rss]=public,must-revalidate Cache-Control[/prismaatom]=public,must-revalidate Expires[] Expires[/]=300 Expires[/potins-people]=900 ... Expires[/communaute/espace-prive]=-7200 Expires[/rss]=900 Expires[/prismaatom]=900 Pragma[] Pragma[/]= Pragma[/potins-people]= ... Pragma[/communaute/espace-prive]=no-cache Pragma[/rss]= Pragma[/prismaatom]=
Header HTTP de la home page de Voici.fr
Taches a la charge du responsable d’hébergement ou administrateur système.
L’administrateur système n’est pas exempt de tache. En tant que responsable de l’hébergement et donc de la configuration serveur il doit mettre en oeuvre la couche LAMP. D’un point de vue système les besoins de eZ Publish sont important au point que la limite entre l’application et le système m’apparais bien flou, surtout si vous visez la haute performance.
Concernant apache il est nécessaire de le configurer avec un vhost comportant un certain nombre de paramètre précis. Entre autre l’utilisation du mod_rewrite est systèmatique avec eZ Publish. En effet tout appel de page doit ce faire au travers du index.php de l’application et uniquement par lui. Tout autre appel de ressources devant être appelé directement et de façon statique.
Le Vhost apache eZ Publish
De ce fait le vhost par défaut de eZ publish tel qu’il est recommandé dans la documentation de la version 4 ressemble à ceci :
NameVirtualHost 128.39.140.28 <VirtualHost 128.39.140.28> <Directory /var/www/example> Options FollowSymLinks AllowOverride None </Directory> <IfModule mod_php5.c> php_admin_flag safe_mode Off php_admin_value register_globals 0 php_value magic_quotes_gpc 0 php_value magic_quotes_runtime 0 php_value allow_call_time_pass_reference 0 </IfModule> DirectoryIndex index.php <IfModule mod_rewrite.c> RewriteEngine On RewriteRule content/treemenu/? /index_treemenu.php [L] Rewriterule ^/var/storage/.* - [L] Rewriterule ^/var/[^/]+/storage/.* - [L] RewriteRule ^/var/cache/texttoimage/.* - [L] RewriteRule ^/var/[^/]+/cache/texttoimage/.* - [L] Rewriterule ^/design/[^/]+/(stylesheets|images|javascript)/.* - [L] Rewriterule ^/share/icons/.* - [L] Rewriterule ^/extension/[^/]+/design/[^/]+/(stylesheets|images|javascripts?)/.* - [L] Rewriterule ^/packages/styles/.+/(stylesheets|images|javascript)/[^/]+/.* - [L] RewriteRule ^/packages/styles/.+/thumbnail/.* - [L] RewriteRule ^/favicon\.ico - [L] RewriteRule ^/robots\.txt - [L] # Uncomment the following lines when using popup style debug. # RewriteRule ^/var/cache/debug\.html.* - [L] # RewriteRule ^/var/[^/]+/cache/debug\.html.* - [L] RewriteRule .* /index.php </IfModule> DocumentRoot /var/www/example ServerName www.example.com ServerAlias admin.example.com </VirtualHost>
Or si le mod_rewrite et les expression régulières ne vous sont pas trop inconnues vous constaterez que tout appel d’image, de css ou de javascript pour le design du site comme ceux du contenue publié bénéficie d’exclusion à la régle de redirection final vers le index.php.
Du fait de ces exclusion les image, css et javascript sont directement fournit par apache sans que les paramètres de configuration des headers du protocole http tel que configuré par le développeur ou responsable d’application ne soit pris en compte.
Le Vhost apache eZ Publish pour Voici.fr
Afin de configurer les headers du protocole HTTP en réponse à chaque requête image, css et javascript il est nécéssaire de mettre en oeuvre des mécanismes propre à apache. L’enjeux est d’importance au regard du poids de l’image dans la volume total d’une page web.
Mod_expires pour Voici.fr, ne jeter plus les images après usage
Afin de configurer les header HTTP avec les instructions de mise à cache nous avons utilisé le mod_expire en précisant pour chaque type mime un temps de vie. Dans le cas de notre site nous avons inclus le block suivant dans le vhost apache de voici.fr.
<IfModule mod_expires.c> ExpiresActive on ExpiresByType text/css "access 1 days" ExpiresByType application/x-javascript "access 1 days" ExpiresByType text/javascript "access 1 days" ExpiresByType image/gif "access 1 days" ExpiresByType image/jpeg "access 1 days" ExpiresByType image/png "access 1 days" </IfModule>
Header HTTP du logo de Voici.fr
Mod_gzip pour Voici.fr, le régime des css
Dans le cas de voici.fr nous recherchions à limiter la sollicitation de nos serveurs mais également bande passante utilisée, l’utilisation des headers HTTP est une solution efficace et performante.
Mais nous avons constaté un autre phénomène lié à la vie médiatique du site. La dynamique d’un site comme voici.fr impose des modifications de style, de présentation et de format en continue pour ce distingué de la concurrence répondre au demande SEO ou tout simplement faire « vivre » le site. Une telle vie trépidante à conduit à un hyper croissance des fichiers css.
A chaque nouvelle charte graphique ou mise à jour les fichiers css grossissaient de nouvelle instruction de design. De l’habillage original les têtes de rubrique on commencé à changé, puis le format des articles, plus les formats des videos etc.. D’un css A nous avions maintenant en plus A1 pour les têtes de rubrique, A2 pour les articles, A3 pour les vidéos et ainsi de suite. Chaque css comportant ça propre présentation de balise html courante, chaque webdesigner a ajouter sa patte sans toucher à ce qui a été réalisé précédemment. Un final, dans un tel cas, le fichier css peux atteindre des tailles respectable de l’ordre de 500Ko[3].
Notre solution le mod_gzip qui permet à apache avant de délivrer un fichier css de le zipper. Nous l’avons configuré de façon à ne travailler que sur des fichiers de taille pertinente (ni top gros ni trop petit). Nous l’avons configuré pour qu’il ne zippe que les fichiers texte du type mime css ou javascript.
<IfModule mod_gzip.c> mod_gzip_on Yes mod_gzip_can_negotiate Yes mod_gzip_static_suffix .gz AddEncoding gzip .gz mod_gzip_update_static No mod_gzip_command_version '/mod_gzip_status' mod_gzip_temp_dir /tmp mod_gzip_keep_workfiles No mod_gzip_minimum_file_size 500 mod_gzip_maximum_file_size 1000000 mod_gzip_maximum_inmem_size 60000 mod_gzip_min_http 1000 mod_gzip_handle_methods GET POST mod_gzip_item_include mime ^text/css$ mod_gzip_item_include mime ^text/javascript$ mod_gzip_item_include mime ^application/x-javascript$ mod_gzip_dechunk Yes mod_gzip_add_header_count Yes mod_gzip_send_vary Yes </IfModule>
Poids des css dans la home de Voici.fr
Conclusion en forme de scénario
Un internaute consultant le site voici.fr sollicitera nos serveurs pour l’intégralité des éléments de la première page appelée. Dès le seconde page les images et fichiers css du desing du site ne seront plus appelés, les instructions des hearder http donnant l’autorisation au navigateur de ce fournir dans son cache pour ces éléments la précisément, ceci durant 24 heures à partir de l’heure ou il à accédé pour la première fois à l’élément.
Concernant le code html constituant la page web il sera demandé à nos serveur à chaque nouvelle page. Mais si l’internaute retourne sur la home page durant les 5 minutes de temps de vie du cache le navigateur, tout comme pour les images, ce fournira sans son cache sans consulté les serveurs.
Passé 5 minutes toute nouvelle demande de la home page sur le navigateur généra un appel aux serveurs pour le code html, mais pas pour les images.
Il ne vous reste plus qu’a concevoir un architecture de reverse proxy en amont de vos serveurs pour garder en cache toute ces informations et éviter durant les périodes de temps de vie définir de sollicité vos serveurs.
