Magento Automatic Caching Insight

Wir führen Magento EE 1.11 mit Memcache aus. 2 GB pro Memcahce-Server, insgesamt 4 GB. Wir haben ungefähr 240k Produkte.

• Verfügbarer RAM: 6GB
• Kerne: 16
• Themen: 32

Hier ist der Deal, es werden täglich mehr neue Produkte hinzugefügt und Änderungen an den Produkten vorgenommen. Jedes Mal, wenn ein neues Produkt im Back-End hinzugefügt / geändert wird, wird der Cache ungültig, insbesondere der "Ganzseiten-Cache".

Wenn die automatische Cache-Generierung von Magentos aktiviert ist, dauert der Aufbau des Caches mit 8 dem Crawler zugewiesenen Threads ungefähr 2 Tage. Nach 2 Tagen schwebt der Memcache zwischen den beiden RAM-Datenträgern um ~ 2 GB.

Das Problem besteht darin, dass bei täglichen Produktänderungen der Cache ungültig wird. Sobald der Cache für die gesamte Seite aktualisiert wird, sind die 2 GB des Caches wieder auf 1: 0 und der viskose Zyklus des Magentos Auto-Caches beginnt erneut. Jetzt ist nicht nur der Cache wieder auf 0, sondern die CPU-Auslastung steigt auf 90% und die Website wird zu einem Wartespiel mit mehr als 5 bis 10 Sekunden und Sie können einfach vergessen, ein Produkt mit mehr als 100 Variationen anzufordern, wenn dies der Fall ist nicht zwischengespeichert würde es Minuten dauern, um das erste Mal zu laden, es ist lächerlich.

Also meine Fragen an die Community.

• Gibt es eine Möglichkeit für Magento, den Cache bei Ungültigkeit automatisch zu "aktualisieren", ohne den gesamten Cache neu zu erstellen und bei 0 zu beginnen? Ich weiß, wenn der Cache ungültig ist, dass Magento weiß, dass sich etwas geändert hat, aber nicht genau, wo im Cache (korrigiere mich, wenn ich falsch liege). Gibt es Module / Konfigurationen, mit denen der gesamte Cache nicht neu erstellt werden kann?

Nebenbei bemerkt verwenden wir das Tiny Bricks LightSpeed-Modul.

• Kann die automatische Cache-Generierung von Magentos mit einem Cronjob zeitgesteuert werden? Sagen wir, um von 22:00 bis 06:00 Uhr mit dem Crawlen zu beginnen.

• Was wäre der beste Weg, um dieser Situation entgegenzutreten? Wie Sie verstehen, ist die Neuerstellung eines Cache, der täglich in Gigabyte angegeben wird, einfach nicht akzeptabel.

Sie haben fast nicht genug RAM

Wir haben ungefähr 240k Produkte
Verfügbarer RAM: 6GB
Gewinde: 32

Sie haben nicht annähernd genug RAM für die Menge der Produkte, die Sie haben. Als Faustregel empfehlen wir mindestens 2-4 GB RAM pro logischem Kern.

Wenn Sie Ihre mögliche Speichernutzung herausfinden:

• 64 PHP-Threads mit max_memory~ 768MB = 24GB
• 240.000 Produkte bedeuten wahrscheinlich etwa 15 GB InnoDB-Tabellenbereich
• 64 PHP-Threads garantieren rund 128 MySQL-Verbindungen. Dies kostet in der Regel mindestens 200 MB pro Verbindung
• Backend-Speicher für 240.000 Produkte in Redis UND lzfkomprimiert - verbraucht immer noch etwa 6 GB RAM

Die Gesamtsumme beträgt also bis jetzt 70 GB zugesicherten Arbeitsspeicher - das Betriebssystem usw. haben wir noch nicht einmal erwähnt.

Ihre Hardware ist furchtbar unterbestimmt . Ich würde vorschlagen, dass Sie diesen Artikel über die Einrichtung des Magento-Servers lesen, um sich ein Bild von den Fortschritten zu machen.

Memcached unterstützt keine Cache-Tags

Wenn Sie Memcached verwenden (kein Problem, sehr hohe Leistung), speichern Sie entweder Cache-Tags oder nicht. Wenn Sie keine slow_backenddefiniert haben, werden keine Tags gespeichert. Dies bedeutet im Grunde, dass Ihr Cache nicht zwischen den verschiedenen Cache-Typen unterscheiden kann, sodass Sie sie nicht unabhängig voneinander leeren können.

Lesen Sie dies durch: http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/

Wir empfehlen dringend, auf Redis umzusteigen. Es hat seine Macken und muss für größere Geschäfte erheblich verfeinert werden. Insgesamt ist die Leistung jedoch etwas besser als bei Memcached, was den eigentlichen Vorteil der Cache-Tag-Unterstützung mit sich bringt.

404's und FPC

FPC hat ein echtes Problem. Tatsächlich haben alle Caching-Engines ein Problem mit 404s. Der Grund dafür ist, dass alle alten URLs, die noch gecrawlt oder mit denen verlinkt werden, auf einer Seite landen, die die gesamte core_url_rewriteTabelle durchlaufen muss. Versuchen Sie, eine Übereinstimmung mit allen definierten Routern und Namespaces zu finden, bevor Sie eine 404 endgültig aufgeben und laden.

Anschließend wird eine Ressource zwischengespeichert, die keinen Wert hat und Speicherplatz in Ihrem Cache-Speicher belegt. Sie werden wahrscheinlich feststellen, dass ein großer Teil Ihres Memcached-Speichers tatsächlich von 404-Inhalten aufgefressen wird.

Bei großen Katalogen (240.000 Produkte) haben Sie mit Sicherheit einen angemessenen Anteil am Produktumsatz und damit an Änderungen der URLs und anschließend an vielen 404-Produkten.

FPC Invalidate vs. Clean

Gegenwärtig - und standardmäßig - bereinigt FPC den Cache bei Änderungen, anstatt nur den Cache-Eintrag ungültig zu machen. Wir haben eine Erweiterung geschrieben, um dieses Verhalten zu ändern, damit ein EE-Speicher genau das tut, was Sie benötigen.

Hier ist ein kurzer Patch, der Ihnen eine Vorstellung davon gibt, wie Sie Ihr Problem lösen können.

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>

Führen Sie keinen Crawler aus

Wenn Sie genügend Trittfrequenz haben - wir raten davon ab, das Crawl-Tool auszuführen, da es unnötige Belastung erzeugt. Personen / Bots / Crawler, die auf der Website surfen, sollten den Cache stets auf dem neuesten Stand halten.

Um Ihre Frage zu beantworten, sehen Sie in der oben genannten Konfigurationsdatei den Cron-Zeitplan, der für das Crawl-Browsing-Fenster definiert wurde.

Wenn Sie sich veraltete Inhalte leisten können

Und letztendlich, wenn Sie genug RAM haben. Sie können die TTL von Inhalten, die in FPC gespeichert sind, erhöhen, um Ihre zwischengespeicherten Daten länger am Leben zu erhalten.

In dem <full_page_cache>Tag ./app/etc/local.xmldefinieren Sie einfach

<lifetimelimit>86400</lifetimelimit>

Die Lebensdauer wird in Sekunden angegeben. Sie müssen ein Gleichgewicht zwischen der Aktualität des Inhalts, der Leistung und dem tatsächlich verfügbaren Speicherplatz finden.

Warum verwenden Sie eine Caching-Erweiterung eines Drittanbieters mit EE?

Du bezahlst eine Prämie für FPC - was mich schmerzt zu sagen, ist sehr gut. Warum lassen Sie also Alternativen von Drittanbietern übertrieben laufen? Entfernen Sie es.

Sagen Sie es so. Wenn Ihr Auto schlecht läuft - würden Sie einfach einen weiteren Motor in den Kofferraum einbauen, um dies zu kompensieren? oder einfach den motor schon drin reparieren?

Wir verstehen dich sehr gut! Wir fügen täglich neue Produkte hinzu oder ändern sie und modifizieren auch statische Blöcke. Wir waren also mit ungültigem Magento-Cache und dieser Konstante unter System -> Cache-Management voll. Wir hassten die Notwendigkeit, die ungültigen Cache-Typen manuell zu aktualisieren.

Dann haben wir die neue Magento Optimizer Erweiterung installiert . Dieses Modul automatisiert diesen Prozess. Es aktualisiert ungültig / alle Cache-Typen oder leert den Magento-Cache-Speicher mit der angegebenen Häufigkeit. Es war eine echte Erleichterung für unser gesamtes Team!

Ein weiteres großartiges Merkmal dieser Erweiterung ist, dass Sitzungsdateien und Fehlerberichte bereinigt werden, die älter als X Tage sind. Jeder weiß, dass die Größe der Verzeichnisse var / session und var / report auf Gigabyte anwachsen kann und die Anzahl dieser Dateien Hunderte überschreiten kann. Um die Leistung der Website zu verringern, haben wir Magento Optimizer einmal eingestellt und die regelmäßige Aktualisierung dieser Verzeichnisse vergessen.

Magento ist dafür bekannt, einen verlassenen Warenkorb mit dem aktuellen Warenkorb zusammenzuführen, wenn Kunden sich anmelden möchten. Aus Sicht der Kundenerfahrung und Loyalität ist dies destruktiv. Das Magento Optimizer-Modul löscht aufgegebene Warenkörbe, die älter als X Tage sind, automatisch. Sie können diese Funktion auch zum Verkaufszeitpunkt verwenden und die Zeit für aufgegebene Warenkörbe begrenzen.