jan 28

Le coup du mailing…

Alors voila…

Imaginons que la cellule marketing d’un client décide unilatéralement d’une super offre marketing. (ca n’arrive jamais rassurez vous, c’est dans un monde imaginaire)

Elle envoie un gros mailing pour soutenir le feu mais… Oublie de prévenir l’IT ou son hébergeur (pareil, c’est totalement utopique, toute ressemblance avec des faits réels serait fortuite). Forcément, le site monte dans les tours.

La solution

L’hébergeur et le DSI détecte le problème et se mettent d’accord, on lance trois machines en Cloud et là, le problème est résolu :) Merci Extend To Cloud.

Les ventes marche, le client est content, on va tous manger, satisfait de ce devoir accomplit.

Le vrai drame

Quand tout à coup… Entre en scène M. X et il appuie sur le bouton « Flush Magento cache », sans raison particulière, juste pour être sûr, parce que dans le doute, l’humain curieux explore tout son potentiel de liberté et que c’est aussi un peu cela le fameux « développement personnel », cliquez là où on veut, quand on veut !

Alors là, forcément, c’est pas la même…

Les serveurs ne disposent plus de leur cache, le drame arrive inexorablement. Une plateforme sans son cache chaud (hot cache) est 2 à 3 fois moins performante. Bilan, les utilisateurs en surfant vont petit à petit réchauffer le cache et générer les pages statiques mais ca demande de la ressource, le système rame.

Le drame « visuellement » parlant

Sur le Graph ci-dessous, lié au CPU de la machine qui sert la base de données, la barre nommée 1 montre le début du mailing et la barre nommée 2 montre le début du vidage de cache. (bien sur c’est un graph totalement hypothétique vous l’aurez compris)

Clairement, durant le mailing, on monte en charge mais ca tient bien. Dès que le bouton magique est pressé, la machine consomme 2 à 3 fois plus de CPU et se met à ramer.

La Conclusion

Si je ne l’ai pas dit cent fois, je ne l’ai jamais dit, mais informer, c’est aussi répéter :

  • On ne vide JAMAIS le cache en production sans raison
  • On ne vide JAMAIS le cache lors d’un pic de trafic type solde ou d’un mailing
  • On ne met jamais un nouveau site en production avant un pic (ce qui implique un vidage de cache)
  • Faire du développement personnel ne passe pas forcément par le fait de cliquer sur tous les boutons et particulièrement sur le bouton « Flush Cache »

D’une manière générale, avant d’appuyer sur le bouton magique qui provoque l’armaggedon, on en discute, on se pose la question de pourquoi on le fait, on vérifie si c’est indispensable, si c’est le seul moyen et dans le doute on en le fait pas.

Ce n’est pas une solution magique mais une solution de dernier recours. Un site en « cold cache » c’est atrocement lent pour les visiteurs et atrocement lourd pour les serveurs. J’ai même vu des setup ou les gens vident les caches en Cron toutes les heures, d’autres où sont lancé des réindexation de base de données plusieurs fois par jour…

Tout cela contribue à tuer les performances et là, pour le coup, Magento n’y est pour rien et n’y peut rien.

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

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: , , , ,