Cache-Cache avec Magento

Magento est une solution robuste et évolutive qui peut souffrir de lenteurs dans certains cas (volume de données important, fort trafic, ...)
L'utilisation de caches s'avère donc nécessaire pour obtenir les temps de réponse attendus sur la toile.

Je vous propose donc une présentation des solutions de cache dont l'implémentation est possible sous Magento.

Voilà le plan :
  • Qu'est ce qu'un cache
    • Différents types de cache
    • Backend de cache
  • Cache applicatif avec Magento
    • Quels éléments sont cachés par Magento
    • Backend par défaut
      • Description
      • Paramètres
    • Solutions alternatives
      • Cache à 1 niveau
      • Cache à 2 niveaux
      • Implémentation par Netapsys
  • FPC
    • Description
    • FPC + Magento
      • Quand flusher un cache ?
      • Eléments non cachables - utilisation AJAX / Cookie
    • Nitrogento
    • Varnish
      • Description
      • Retour d'expérience (Jean-Marie Heitz)
  • Conclusion

Dans ce post nous allons aborder les chapitres 1 et 2. Il s'agira d'une présentation générale, où volontairement je ne rentrerai pas dans les détails techniques de mise en oeuvre.
Dans un futur post nous parlerons du chapitre 3 qui traitera du Full Page Cache.
Enfin, cette étude ne saurait être exhaustive sans un retour d'expérience, ce sera fait dans un 3ème post rédigé par Jean-Marie Heitz, qui parlera plus en détail de la mise en place de Varnish avec Magento et qui abordera des points beaucoup plus techniques.

Qu'est-ce qu'un cache

Le principe d'un cache est de stocker le résultat d'un traitement pendant une durée déterminée, pour éviter d'avoir à relancer ce même traitement.
Avantages: gain de temps et de ressource
Inconvénients: modifications et mises à jour non prises en compte tant que le cache est utilisé

Différents type de cache

Dans le monde du Web on considère plusieurs types de cache dont :
  • navigateur
  • applicatif
  • serveur
  • base de données
  • ...
Dans ce post nous allons nous intéresser au cache applicatif, et plus particulièrement les possibilités offertes par Magento.

Backend de cache

On appelle "backends de cache" les différents stockages physiques où sont placées les données.
Voici quelques exemples :

File

Stockage sur le système de fichier

Avantages :  Facilités de mise en oeuvre, aucun soft à installer
Inconvénients :  Lenteur


Database

Dans une ou plusieurs tables de la BDD (sous Magento il s'agit de la table core_cache_tag)
Avantages :  Facilités de mise en oeuvre, aucun soft à installer
Inconvénients :  Lenteur

Memcached

Avantages :  Rapidité
Inconvénients :  Pas de gestion des tags (nécessaire sous Magento), pas de persistance des données (en cas de problème les données peuvent être perdues)
Nécessite l'installation du serveur memcached et d'une extension PHP

Redis

Advantages :  Rapidité, gestion native des tags, supporte un fort trafic, persistance des données (stockage des données sur le disque dur)
Inconvénients :  Nécessite l'installation du serveur Redis et d'une extension PHP
Nécessite l'installation de l'extension Magento Cm_Cache_Backend_Redis

Cache applicatif avec Magento

L'implémentation d'un cache applicatif est propre à chaque application.
L'idée générale est de stocker des morceaux de rendu, principalement HTML, pour les restituer rapidement à chaque requête HTTP.
Étudions plus en détail le cache de Magento.

Quels éléments sont cachés par Magento

Magento ne se limite pas à du cache HTML, voici tous les éléments cachés par cette plateforme :

Configuration

Toute la configuration issue des fichiers XML et de la BDD (table core_config_data).
Fichiers XML concernés :
  • app/etc/config.xml - configuration du Core
  • app/etc/local.xml - accès à la BDD (et configuration du cache)
  • app/etc/modules/*.xml : déclaration des modules
  • app/code/<codePool>/<namespace>/<module>/etc/config.xml - fichier de configuration de chaque module

Agencements

Instructions de construction d'agencement.
Fichiers XML de layout (agencement et Blocks associés) :
  • app/design/<area>/<interface>/<theme>/layout/*.xml

Sortie de blocs HTML

Rendu des Blocks HTML.
Fichiers concernés :
  • app/design/<area>/<interface>/<theme>/template/*.phtml

Traductions

Toutes les traductions issues des fichiers CSV de langues et de la BDD (table core_translate).

Fichier concernés :
  • app/locale/*

Données de collections

Collections des objets Magento.

Types EAV et attributs

Types d'entité et attributs EAV issue de la BDD

Backend par défaut

Description

Le mécanisme de cache utilisé par Magento s'appuie sur le framework Zend et plus particulièrement la couche Zend_Cache. 
La solution proposée "out of the box" est de type File, toutes les données cachées sont placées dans des fichiers du répertoire var/cache/
Ce système a l'avantage d'être très simple à mettre en oeuvre et suffit pour des sites de petites tailles, par contre il s’avérera trop lent dès que le volume augmentera.

Paramètres

Lors d'un stockage de données Zend_Cache propose les paramètres suivants :
  • Data : les données à stocker
  • Key : identifiant unique de la donnée en cache
  • Lifetime : définit la durée de vie, c'est-à-dire le temps qu'un élément de cache sera utilisé avant de redemander l'exécution du traitement au serveur
  • Tags : permet le taggage des données, utilise pour une suppression sélective

Solutions alternatives (Backend slow et fast)

Plusieurs solutions alternatives sont envisageables. La configuration se fait dans le fichier app/etc/local.xml de Magento.
On distingue les caches à 1 niveau et les caches à 2 niveaux :

Solution simple à 1 niveau

Comme stocker sur un disque dur peut s'avérer lent, la solution est de monter le répertoire de cache Magento sur un Ramdisk, qui est beaucoup plus rapide. Du coup rien n'est à modifier dans la configuration de Magento.
L'autre solution est d'utiliser un disque dur SSD, beaucoup plus rapide qu'un disque dur traditionnel.

Cache à 2 niveaux

Description

Le framework Zend propose un système de "two level cache". L'idée des 2 niveaux et d'avoir un cache rapide, de petite taille et utilisé prioritairement, et un deuxième plus gros mais plus lent utilisé si par exemple le premier et plein. 2 avantages donc vélocité et taille.
L'autre avantage du cache à 2 niveaux est qu'il permet la gestion de l'association key / id : dans le backend rapide on place le contenu du cache identifié par son id, l’index quant à lui est détaillé dans le backend lent.
Cela permet donc d'effacer des éléments du cache de manière précise et pas tout le cache massivement :
  • Magento donne l'instruction de suppression du cache lié à un tag
  • Le backend lent récupère toutes les clés de cache associées à ce tag
  • Pour chaque clé de cache le backend de cache lent supprime une entrée dans le backend de cache rapide, puis supprime l'entrée de cache sur son propre support physique

Implémentation possible

Voici quelques exemples de cache à 2 niveaux :
  • Memcached + Base de données (utilisation de la table core_cache_tag)
  • Memcached + Fichiers
  • Redis

Sous Magento il faut savoir que dès lors qu'on configure un cache de type rapide, l'utilisation d'un backend lent est imposée. Concrètement le simple fait d’utiliser memcached activera automatiquement le cache de second niveau avec pour type File.

Implémentation par Netapsys

Chez Netapsys nous sommes bien sûr confrontés à des problématiques d'optimisation des boutiques de nos clients.
Nous avons donc été amenés à mettre en place ces solutions alternatives :
  • montage du répertoire de cache en Ramdisk
  • système à 2 niveaux Memcached + File
  • système à 2 niveaux Memcached + BDD
Dans certains cas toutes les implémentations décrites dans ce post ne suffisent pas. Il devient alors nécessaire d'ajouter une solution de Full Page Cache. Rendez-vous au prochain post ...

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.