En discutant hier avec un autodidacte, je me suis rendu compte que je n'avais jamais rencontré d'article qui tentait d'expliquer les différents niveaux de cache (certainement parce que je n'ai jamais cherché).
Aujourd'hui, je vais relever le défi et tenter de partager avec vous les quelques notions que j'ai pu acquérir au cours de mes différentes expériences.
Je vais me concentrer sur les niveaux de cache coté serveur, concernant les techniques de cache dans les navigateurs je vous renvoie vers l'excellent tutorial de mnot.net.
Vous ne trouverez pas de code dans cet article mais une base de réflexion pour les curieux.
***ATTENTION***
Une fois avoir lu cet article n'utilisez pas du cache partout, cacher un blog facile ... cacher un forum ou des résultats de recherche : beaucoup moins (voir inutile). En générale il faut cacher les (données|pages) les plus accédées (souvent les données valables pour le plus grand nombre de visiteurs).
Les différents niveaux de cache
Au travers des différents applications que j'ai développées (principalement des CMS, mais en adaptant c'est valable pour quasiment toutes les sites...), le découpage du cache a toujours pu se faire en suivant les niveaux suivants :
- Le cache "Page" : au niveau de l'url (la page html complète)
- Le cache "Bloc" : au niveau des éléments composants la page
- Le cache "Objet" : principalement au niveau de votre modèle de données
En prenant un raccourci on peut dire que plus le niveau de cache est haut dans cette hiérarchie, moins vous aurez de code php à exécuter et plus la réponse de votre serveur sera rapide.
Les présentations faites, rentrons dans le détail de chacun de ces niveaux.
Le cache de page
Ajouter un cache au niveau de la page est certainement la première chose à faire pour soulager votre serveur.
Pour ce faire, différentes techniques s'offrent à vous : du simple cache écrit en php au reverse proxy spécialisé.
Lister toutes les solutions possibles sort du contexte de cet article. Vous trouverez facilement ce qu'il vous faut chez Google.
Le cache de page permet d'éviter d’exécuter tous les traitements php (parsing, requêtes en base de données) lorsqu'une même page est affichée plusieurs fois.
Le premier visiteur appelle la page et on stocke le résultat. Si la page est à nouveau demandée avant qu'elle n'expire, on lui sert le même résultat.
Simple et efficace mais cela implique d'afficher la même page pour tous les visiteurs.
Quelques remarques à prendre en compte avant de mettre en place un cache de page :
- Une url = une page (query string comprise), utilisez à volonté les 301 et 302 (votre SEO vous remerciera) et éviter d'avoir deux versions d'une page sur une même url (La home page connectée/déconnectée est une mauvaise idée)
- Éviter de démarrer vos sessions inutilement, réservez vos sessions à des pages massivement personnalisée.
- Utilisez javascript pour personnaliser un minimum vos pages cachées, par exemple : pour afficher l'avatar et le nom de l'utilisateur connecté.
Le cache de bloc
Comment expliquer le cache de bloc ... Le plus simple, est encore en images :
Dans l'image précédente, deux pages différentes de deux articles différents.
Question : vous pensez vraiment qu'il est nécessaire d'aller chercher en base de données la liste des derniers articles et les sites dans copinages ?
Deuxième image :
En vert : tout ce que le cache de bloc m'évite de générer quand mes deux pages ne sont pas cachées. En rouge ce qui change réellement : l'article.
Pour gérer le cache de bloc, tout comme pour les pages, vous pouvez faire simplement en php (en bidouillant avec des ob_start et ob_get_content), utiliser les Server Side Include ou encore les ESI. Je me suis même amusé à faire des Client Side Includes en Javascript il fut un temps.
Encore une fois l’embarra du choix mais le principe reste le même : composer votre page avec fragments de html provenant d'un cache pour éviter de générer les données en php.
Petit clin d'oeil à certain graphiste : Et oui sur un site, tout doit rentrer dans des carrées.
Le cache objet
Cette fois vous aurez le droit à du code car j'ai déjà traité ce type de cache avec une implémentation basique : cache objet php
Que dire de plus ... Un id, un objet ... cet objet peut être vos articles, vos templates, vos utilisateurs... et même vos blocs (ça commence à piqué là, non ?). En gros vous pouvez stocker n'importe quelle entité de vos applications dans du cache.
Et picétou ?
Et oui, comme annoncé, le but n'était pas de parler technique (memcache, varnish, nginx et encore moins de décache ou d'expiration) mais d'apporter quelques clés à d'éventuels débutants en s'extirpant de la mélasse technologique (Framework ..).
J'invite aussi les personnes expérimentés à partager, préciser ou critiquer cet article dans les commentaires ;)
PS : Un grand merci à Yvan Taviaud (mon maitre Jedi en la matière) avec qui nous avons longtemps débattu sur ces problématiques, ça me manque presque ;)
Image : Frederique B
