Magento Automatic Caching Insight

Nous exécutons Magento EE 1.11 avec memcache. 2 Go par serveur memcahce, 4 Go au total. Nous avons environ 240k produits.

• RAM disponible: 6 Go
• Noyaux: 16
• Fils: 32

Voici l'affaire, plus de nouveaux produits sont ajoutés et des changements de produits se produisent quotidiennement et, bien sûr, chaque fois qu'un nouveau produit est ajouté / modifié dans le back-end, le cache est invalidé, en particulier le `` cache pleine page ''.

Lorsque Magentos Auto Cache Generation est activé, il faut environ 2 jours pour créer le cache, avec 8 threads alloués au robot. Après 2 jours, le memcache flotte autour de ~ 2 Go séparés entre les deux disques RAM.

Le problème est que lorsque les produits sont modifiés quotidiennement, le cache est invalidé et dès que le `` cache pleine page '' est actualisé, ces 2 Go de cache sont de retour à la case départ, 0, et le cycle visqueux du cache Magentos Auto recommence. Maintenant, non seulement le cache revient à 0, mais l'utilisation du processeur atteint 90% et le site Web se transforme en un jeu d'attente de 5 à 10 secondes et vous pouvez simplement oublier d'essayer de demander un produit avec plus de 100 variantes, si c'est le cas. pas mis en cache cela prendrait quelques minutes pour charger la première fois, c'est ridicule.

Donc, mes questions à la communauté.

• Existe-t-il un moyen pour Magento de "mettre à jour" automatiquement le cache s'il est invalidé, sans reconstruire tout le cache et à partir de 0? Je sais quand le cache est invalidé que Magento sait que quelque chose a changé, mais pas exactement où dans le cache (corrigez-moi si je me trompe). Existe-t-il des modules / configurations pour contourner la reconstruction de tout le cache?

Sur la note de côté, nous utilisons le module Tiny Bricks LightSpeed.

• La génération automatique de cache Magentos peut-elle être contrôlée dans le temps avec un cronjob? Dites, pour commencer à ramper de 22h à 6h.

• Quelle serait la meilleure façon d'aborder cette situation?, Comme vous le comprenez, la reconstruction d'un cache de gigaoctets tous les jours n'est tout simplement pas acceptable.

Vous n'avez pas assez de RAM

Nous avons environ 240k produits Ram
disponible: 6 Go
Fils: 32

Vous n'avez pas assez de RAM pour la quantité de produits dont vous disposez. En règle générale, nous recommandons au moins 2 à 4 Go de RAM par cœur logique.

Si vous tracez votre utilisation possible de la mémoire:

• 64 threads PHP avec un max_memory~ 768 Mo = 24 Go
• 240 000 produits signifieront probablement environ 15 Go d'espace de table InnoDB
• 64 threads PHP garantissent environ 128 connexions MySQL, généralement cela coûte environ 200 Mo par connexion minimum
• Stockage backend pour 240 000 produits en Redis ET lzfcompressé - consommera toujours environ 6 Go de RAM

Donc, jusqu'à présent, le total est de 70 Go de RAM engagée - nous n'avons même pas mentionné le système d'exploitation, etc.

Votre matériel est terriblement sous-spécifié . Je suggérerais de lire cet article sur la configuration du serveur Magento pour un peu sur la façon de progresser.

Memcached ne prend pas en charge les balises de cache

Si vous utilisez Memcached (ce n'est pas un problème, ses très hautes performances), vous stockez ou non des balises de cache. Si vous n'avez pas de slow_backenddéfinition définie - vous ne stockez pas de balises, ce qui signifie que votre cache ne peut pas faire de distinction entre les différents types de cache - vous ne pourrez donc pas les vider indépendamment.

Lisez ceci, http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/

Nous suggérons fortement de passer à Redis. Il a ses particularités et a besoin d'un réglage fin important pour les grands magasins. Mais dans l'ensemble, il fonctionnera légèrement mieux que Memcached avec le réel avantage de la prise en charge des balises de cache.

404 et FPC

FPC a un vrai problème, en fait, tous les moteurs de mise en cache ont un problème avec les 404. La raison en est que toutes les anciennes URL toujours explorées ou liées à atterriront sur une page qui doit parcourir toute la core_url_rewritetable, essayer de trouver une correspondance avec tous les routeurs et espaces de noms définis avant de finalement abandonner et charger un 404.

Mettre ensuite en cache une ressource qui n'a aucune valeur et consommera de l'espace dans votre mémoire cache. Vous constaterez probablement qu'une énorme proportion de votre stockage Memcached est en fait consommée par le contenu 404.

Avec de grands catalogues (240 000 produits), vous aurez certainement votre juste part du chiffre d'affaires des produits, et donc, des changements d'URL et, par la suite, de nombreux 404.

FPC Invalidate vs. Clean

À l'heure actuelle - et par défaut - le comportement de FPC est de nettoyer le cache lors des modifications, plutôt que de simplement invalider l'entrée du cache. Nous avons écrit une extension pour modifier ce comportement afin qu'un magasin EE fasse exactement ce dont vous avez besoin.

Voici un correctif rapide pour vous donner une idée de la façon de résoudre votre problème.

app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
             <observers>
                 <enterprise_pagecache>
                     <class>enterprise_pagecache/observer</class>
-                    <method>cleanCache</method>
+                    <method>invalidateCache</method>
                 </enterprise_pagecache>
             </observers>
         </catalogrule_after_apply>

Ne lancez pas de robot

Si vous avez suffisamment de trafic décent - nous déconseillons d'exécuter l'outil d'analyse, il génère une charge inutile. Les personnes / robots / robots d'exploration qui naviguent sur le site doivent garder le cache amorcé.

Mais pour répondre à votre question, si vous regardez dans le fichier de configuration mentionné ci-dessus - vous voyez le calendrier cron qui a été défini pour la fenêtre de navigation d'exploration.

Si vous pouvez vous permettre un contenu périmé

Et finalement, si vous avez suffisamment de RAM. Vous pourriez bien bénéficier de l'augmentation du TTL du contenu stocké dans FPC - pour garder vos données en cache en vie plus longtemps.

Dans la <full_page_cache>balise dans votre ./app/etc/local.xmljuste définir

<lifetimelimit>86400</lifetimelimit>

La durée de vie est définie en secondes. Vous devez trouver un équilibre entre la fraîcheur du contenu, les performances et la quantité d'espace de stockage dont vous disposez réellement.

Pourquoi utilisez-vous une extension de mise en cache tierce avec EE

Vous payez une prime pour FPC - ce qui me fait mal de dire que c'est très bien. Alors pourquoi utilisez-vous des alternatives tierces par-dessus. Retirez-le.

Mets le comme ça. Si votre voiture fonctionnait mal - ajouteriez-vous simplement un autre moteur dans le coffre pour compenser; ou simplement réparer le moteur déjà là-dedans?

Nous vous comprenons très bien! Nous ajoutons de nouveaux produits ou changeons nos produits tous les jours et modifions également les blocs statiques. Nous étions donc pleins avec le cache Magento invalidé et cette constante allant dans Système -> Gestion du cache. Nous détestions la nécessité d'actualiser manuellement les types de cache invalidés.

Ensuite, nous avons installé la nouvelle extension Magento Optimizer . Ce module automatise ce processus. Il rafraîchit le cache invalidé / tous les types ou vide le stockage du cache Magento à la fréquence spécifiée. Ce fut un vrai soulagement pour toute notre équipe!

Une autre fonctionnalité intéressante de cette extension est qu'elle nettoie les fichiers de session et les rapports d'erreurs plus anciens que X jours. Tout le monde sait que la taille des répertoires var / session et var / report peut augmenter en gigaoctets et que le nombre de ces fichiers peut dépasser la centaine. Alors maintenant, pour ralentir les performances du site Web, nous avons défini Magento Optimizer une fois et oublié le rafraîchissement périodique de ces répertoires.

Magento est connu pour avoir fusionné un panier abandonné avec le panier actuel lorsque les clients essaient de se connecter. Du point de vue de l'expérience client et de la fidélité, c'est destructif. Le module Magento Optimizer supprime automatiquement les paniers abandonnés datant de plus de X jours. Vous pouvez également utiliser cette fonctionnalité au moment de la vente et limiter le temps pour les paniers abandonnés existants.