déc 21

Magento : un cache capricieux ?


Voici un petit article composé suite à des recherches menées conjointement par NBS System et la Magento Academy.

En effet, le directeur de production (Emile pour les intimes) a touver un comportement étrange lors du paramétrage des systèmes Magento > 1.4.0. Avec l’apparition du slow backend, on avait en effet des résultats beaucoup plus « slow ».

Fabrice nous a proposé d’élucider certains mystères en allant faire de l’inspection de code. Voici les premiers retours :

Magento 1.4 : Changement du système de cache


Depuis la version 1.4 de Magento un nouveau système gérant le cache à été mis en place appelé cache à 2 niveaux.

Le premier niveau appelé fast backend est un cache rapide et est le cache principal et le second niveau, le slow backend et est un cache de secours en cas d’indisponibilité ou de saturation du cache de premier niveau.

L’utilisation de ce Slow Backend est imposé dès qu’un cache de premier niveau dit « rapide » est configuré.

Autrement dis même si vous ne configurez rien en slow backend, le simple fait d’utiliser APC, Memcached, Xcache ou Eaccelerator activera le cache de second niveau avec pour type un file cache.

Configurer son cache correctement

Magento attends comme valeurs de configuration dans le fichier local.xml les nœuds suivants :

<backend /> pour le fast backend

<slow_backend /> pour le slow backend

Magento attends normalement les valeurs suivantes (attention à la case) pour le noeud <backend> :

  • file
  • sqlite
  • memcached
  • apc
  • xcache
  • eaccelerator
  • database

Toutefois pour le noeud <slow_backend> Magento attends les valeurs suivantes sous peine de plantage (attention à la case) :

  • File
  • Sqlite
  • Memcached
  • Apc, Xcache
  • Varien_Cache_Backend_Eaccelerator
  • Varien_Cache_Backend_Database

Un bug semble présent dans l’Admin quand le système de cache à 2 niveaux est présent, en effet dans Système > Gestion du cache, tous les caches semblent désactivé même s’ils le sont bien, il semble que ce soit un bug qui peut être corrigé facilement (même si l’on vous déconseille de patcher le Core a moins d’en avoir un suivi très précis) :

Dans le fichier app/code/core/Mage/Core/Model/Cache.php

Méthode _initOptions()
La ligne
if ($options === false) {
  devrait être
if ($options === false || $options === null) {

Toutefois ce bug ne semble se manifester que si le cache APC est plein.

Ce cache APC d’ailleurs se remplit en continue et n’est pas « rafraichit » assez vite, ce qui fait qu’on tombe vite dans le slow backend qui, s’il n’est pas configuré, atterrit sur les disques dur (ou en RAMdisk si vous en avez paramétré). Il reste possible de le nettoyer en l’effaçant mais ce n’est pas optimal.

Des arbitrages déroutants

Magento vérifie si le cache a suffisamment de place libre avant de faire les mises en cache. Pour APC c’est la consommation de mémoire qui est vérifiée, sur le taux d’utilisation dépasse 80% le cache APC est ignoré. Déjà, 80% de 64 Mo ou de 1 Go ce n’est pas la même chose, pourquoi ne pas mettre un seuil en Mégas plutôt qu’en pourcentage ?

A l’écriture Magento écrit dans APC à l’unique condition que son taux d’utilisation soit inférieur à 80%, dans tous les cas il écrira dans le slow backend.

A la lecture seul le fast backend est utilisé, s’il n’existe pas ou n’est pas disponible Magento lira dans le slow_backend

Notez que le cache à 2 niveau possède une option auto_refresh_fast_cache il semble bizarre car il ne fait que remettre en cache les données chargées depuis le cache repoussant ainsi sa date d’expiration, cela ne se fait que si le taux d’utilisation du cache est < 80%.

Conclusion sur le cache Magento 1.4+


L’écriture du slow backend est donc systématique mais ne se fait que si le fast backend doit écrire lui aussi, donc si tu ouvre une page le slow et le fast backend sont générés. Si par la suite on supprime les fichiers du slow_backend mais pas du fast, les fichier du slow backend ne seront régénéré que si le fast backend l’est aussi. Tant que le fast backend a un cache valide les fichier du slow backend ne sont pas régénérés.

Il n’y a donc pas de bugs majeurs dans la configuration, elle est juste un peu subtile à comprendre et non documenté ce qui n’aide pas. Par contre, le principe de l’utilisation du Fast et son taux de renouvellement trop faible en font un système moins efficace puisque le Fast est presque tout le temps plein, des données les plus anciennes.

Merci à Emile pour la piste et Fabrice pour l’analyse.

écrit par Philippe Humeau \\ tags: , , , ,


5 commentaires sur “Backend et systèmes de cache Magento”

  1. 1. Matthieu Dit :

    Bonjour,

    Effectivement, l’utilisation du cache sous Magento est assez fastidieuse depuis le passage en 1.4 et l’équivalent Enterprise. C’est bien dommage, car l’idée principale (avoir un cache de secours en cas d’indisponibilité du rapide) est séduisante. Mais le fait de l’utilisation quasi systématique du slow backend oblige quasiment d’utiliser un cache rapide en mémoire pour le slow backend du point de vue performances. D’où une dénomination « slow » peut-être un peu trompeuse.. ce qui n’arrange rien :)

    Enfin, nous avons déjà observé des plantages Magento lors de tests de fallback (notamment avec du memcache). Donc attention car le mecanisme n’est pas bien rodé, même si je suppose que ceci est plus lié au couple Magento(Zend) / Memcache. A ce propos, des bugs ont été corrigés ces derniers temps par MagentoInc, mais dans le cas de memcache, ce qui serait à mon avis un grand avancement serait de pouvoir utiliser l’extension php memcached (notez le ‘d’ à la fin) en lieu et place de la vieillissante extension memcache.

  2. 2. Philippe Humeau Dit :

    Bonjour Matthieu,

    C’est un soucis de fond mais il y a plusieurs contournements.
    Le seul truc un peu épuisant dans cette histoire c’est qu’on reçoit les problèmes arriver les uns après les autres et du coup c’est un peu la surprise à chaque version.
    Sur la EE, le full page cache est pour ainsi dire inutilisable dans 90% des cas, là on a une syntaxe tordue et peu documentée, sur le blog de NBS System, notre DT a publié un bug assez folklorique sur l’identification des backends php… Ça devient récurrent ces soucis, là où justement on espérait que l’élargissement de l’équipe Magento allait palier à ces soucis.

    Je grou

  3. 3. Matthieu M Dit :

    Bonjour,

    Votre étude est valable si le slow_backend est en fichier, mais a un comportement bien différent lorsque celui ci est en base de données.
    Et dans ce cas, on ne peut plus faire de généralité sur la 1.4, mais il faut inclure la version mineure.
    Bien cordialement,

    Matthieu MARY

  4. 4. Guillaume Dit :

    Je rencontre un gros problème sur un des mes sites :

    J’ai suivi le tutoriel de nbs (www.nbs-system.com/blog/magento-optimization-howto.html) en montant en taille fixe (tmpfs) mon dossier cache et j’ai donc paramétrer mon local.xml :

    file
    MAGE_
    File
    0
    1
    259200

    Mais j’ai toujours cette erreur dans mon system.log

    2012-05-12T11:35:44+00:00 ERR (3): Warning: include(File.php): failed to open stream: No such file or directory in /home/site/public_html/lib/Varien/Autoload.php on line 93
    2012-05-12T11:35:44+00:00 ERR (3): Warning: include(): Failed opening ‘File.php’ for inclusion (include_path=’/home/site/public_html/app/code/local:/home/site/public_html/app/code/community:/home/site/public_html/app/code/core:/home/site/public_html/lib:.:/usr/share/php:/usr/share/pear’) in /home/site/public_html/lib/Varien/Autoload.php on line 93

    Comment cela peut il se résoudre ?

  5. 5. Philippe Humeau Dit :

    c’est juste une erreur de typo entre File et file, magento est casse sensitive, il suffit donc de changer la premiere lettre. (désolé, imprécision corrigée dans le howto)

Poster une réponse