Vorwärmen des Magento Enterprise Full Page Cache

Die Leistungsvorteile des Ganzseiten-Caches in Magento Enterprise sind allgemein bekannt. Was vielleicht nicht ganz so gut bekannt ist, ist, dass es, um den vollen Nutzen daraus zu ziehen, voll besetzt und heiß sein muss, insbesondere bei großen Produktsets, bei denen Sie nicht nur ein paar Seiten haben, um den organischen Verkehr zu nutzen Grund es schnell genug.

Magento enthält einen eingebauten Cronjob, um die Site zu crawlen und die FPC am frühen Morgen aufzuwärmen.

Ich habe Probleme gesehen und gehört, die dadurch verursacht wurden, dass die Ausführung von Jobs am frühen Morgen zu lange dauerte, andere Jobs blockierten, und möchte wissen, was andere dazu verwenden, oder ich würde vorschlagen, dies zu tun. Ein paar Ideen, die ich habe, sind:

Stellen Sie ein Shell-Skript zusammen, um jede Seite in der generierten Sitemap-Datei zu crawlen.
Verwenden Sie einen separaten crontab-Eintrag und ein kurzes PHP-Skript, um Magento zu booten und den Crawler-Prozess direkt auszuführen.

Alle Gedanken und / oder Erfahrungen dazu sind willkommen!

— Davidalger
quelle

Tatsächlich können Sie den Enterprise-Crawler aus einer separaten Datei aufrufen und ihn mithilfe der Crontab Ihres Servers auslösen, damit er nicht im Weg ist.

— Toon Van Dooren

Sie können Belagerung in Kombination mit der sitemap.xmlDatei verwenden, wie es MageSpeedTest tut.

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

Dann renne

siege -i -c 1 -t 7200s -f urls.txt

^{Inhalt von hier bezogen .}

— Ashley Schroder
quelle

Sie können auch eine Verzögerung zwischen Anforderungen hinzufügen, indem Sie–delay

— Ben Lessani - Sonassi

Hinweis: Diese sed-Befehle funktionieren nicht unter Darwin, sondern unter CentOS.

— Davidalger

Dies garantiert nicht, dass jede URL "erwärmt" wird. Belagerung wählt zufällig URLs aus der Datei aus, besucht jedoch nicht unbedingt jede URL.

— Joe Constant

Wir tun es einfach nicht - überhaupt nicht. Je. Wir werden das immer und immer wieder sagen, aber

Caching! = Leistung

Ihre Site muss schnell sein, ohne die Zugabe von FPC (oder Lack für diese Tatsache). Es wird immer eine Zeit geben, in der der Inhalt nicht vorbereitet ist (Ihr Szenario oben).

In einem entladenen Geschäft sollten die Ladezeiten von Seiten mit FPC nicht so beeindruckend sein wie mit Nicht-FPC. Magento ist durchaus in der Lage, < 400msSeitenladezeiten auf Standard-Caches (auf Kategorie- / Produkt- / Suchseiten) festzulegen. FPC bringt das auf den < 80msPunkt - aber es gibt Vorbehalte.

Die Bestands- / Preisinformationen sind bis zur Ungültigerklärung oder zum Ablauf der TTL veraltet
Neue Artikel / relevantere Suche ist veraltet, bis sie ungültig wird oder die TTL abläuft

etc.

Warum das Vertrauen in FPC (oder Lack) eine schlechte Idee ist

Wenn Sie kontinuierlich sicherstellen möchten, dass die Caches manuell vorbereitet werden, gibt es wahrscheinlich ein paar Gründe

Sie haben nicht genug natürliche Schritte, um die Caches auf dem neuesten Stand zu halten (siehe 'Wo FPC nützlich ist').
Ihre Website ist ohne sie zu langsam

Sie können nicht alles zwischenspeichern

Wenn Sie ein Geschäft mit nur 5 Kategorien, 2 Ebenen tief verschachtelt, 5 filterbaren Attributen, jeweils 5 Attributoptionen und 1000 Produkten annehmen; das sind viele mögliche kombinationen.

25 Optionen zur Auswahl, von denen ich bis zu fünf Mal hintereinander eine auswähle - ich bin kein Statistiker , aber mir ist bewusst, dass ... (vorausgesetzt, die Anzahl der Attributoptionen nimmt nicht vollständig ab)

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

Ok, das obige Szenario ist kein wahrscheinliches Szenario, wie ich mir innerhalb von 3 Klicks vorstellen würde - die Anzahl der verfügbaren Produkte wäre ausreichend gesunken, damit der Kunde sein Produkt finden kann. Also selbst wenn es wäre ...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations

Dann mal das mit 5 Kategorien, also 625 URLs. In dieser Phase handelt es sich um einen winzigen Katalog, bei dem alle Produkt-URLs vollständig ignoriert werden.

Wir berücksichtigen auch nicht, dass die Anzahl der verschachtelten Kategorien mit is_anchoron exponentiell zunehmen wird.

Wenn Sie also dieses Seitenvolumen crawlen möchten, müssen Sie entweder hoffen, dass die Ladezeiten für Ihre Seiten anfangs gut und niedrig sind, so dass es sich um einen schnellen Prozess handelt (der den Zweck des Crawls zunichte macht), oder Sie müssen dies tun genug Zeit, um den Vorgang abzuschließen, bevor die TTL abläuft.

Wenn Ihre Seiten eine Ladezeit von 0,4 s hatten und Sie eine 8-Kern-CPU - dann ...

625 * 0.4 = 250 / 8 = 31 seconds

0,5 Minuten, nicht schlecht - aber stellen wir uns vor, Sie hatten 2s Ladezeiten

625 * 2 = 1250 / 8 = 156 seconds

Aber wenn Sie das maximal mögliche Szenario genommen haben

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

Das ist also Ihr Produktionsserver, unter 100% CPU-Auslastung für 15 Minuten. Sie würden die Crawling-Geschwindigkeit proportional zur gewünschten TTL verringern.

Wenn Sie also möchten, dass der Inhalt eine TTL von 3600s hat, könnte das Crawlen viermal langsamer sein - dh. Nur 25% der CPU sind für das Crawlen vorgesehen. Das ist eine Menge Ressourcen, nur um den Inhalt der Kategorie auf dem neuesten Stand zu halten - wir haben in dieser Phase noch nicht einmal Produkte, Suchbegriffe oder zusätzliche Store Views berücksichtigt

Wenn Sie sich die bloße Größe der Kombinationen in der catalog_url_rewritesTabelle ansehen (wobei die Parameter der geschichteten Navigation nicht einmal berücksichtigt werden), erhalten Sie eine Vorstellung davon, wie viele URLs möglicherweise nicht mehr gecrawlt werden müssen.

Jeder Laden wird sicherlich anders sein, aber ich versuche, nach Hause zu kommen, weil es nicht praktisch ist, die Site auf Prime FPC zu durchsuchen. Stellen Sie einfach sicher, dass Ihr Geschäft von Anfang an schnell ist .

Wo FPC nützlich ist

Wo die Vorteile von FPC zum Tragen kommen, liegt in einem stark ausgelasteten Geschäft - wo Sie wirklich viel Verkehr haben und die Caches natürlich und ständig allein durch Fußstapfen vorbereitet sind.

FPC kommt dann ins Spiel, indem der Infrastruktur-Overhead für häufig angeforderte Inhalte reduziert wird - und so die wiederholten Aufrufe des Magento-Backends reduziert werden.

Wir haben festgestellt, dass sich FPC hervorragend für die Bereitstellung eignet, wenn Sie über ein hohes Verkehrsaufkommen verfügen - nicht um die Ladezeit der Seite zu verringern, sondern um den Ressourcenverbrauch zu verringern.

Wen kümmert es, ich will immer noch kriechen

Dann haben Sie zwei Möglichkeiten

Crawl von einer Vorlage (zB Sitemap)
Extrahieren Sie die Links Seite für Seite und durchsuchen Sie sie

Und es gibt viele Hilfsprogramme, die ich kenne

Magier-Test
HTTrack
Nutch
Sphider
Crawler4j

Mage-Perftest verwenden

Sie können Ihren Shop mit Mage-Perftest ganz einfach durchsuchen, indem Sie ihn zuerst herunterladen

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

Definieren Sie dann den Crawl-Prozess mithilfe der Magento-Sitemap (Sie können dies anpassen, indem Sie eine Sitemap aller URLs erstellen, sofern die URLs in <loc></loc>Tags eingeschlossen sind). Mit dem folgenden Befehl werden alle URLs aus der Sitemap-Datei gelesen und anschließend die URLs innerhalb von 1440 Minuten (1 Tag) gecrawlt (nur PHP). Wenn der Server mehr als 20% der CPU-Auslastung aufweist oder die durchschnittliche Auslastung 2 beträgt, wird das Crawlen vorübergehend unterbrochen.

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2

Wenn Sie 1000 URLs haben, die über einen Tag gecrawlt wurden, sind dies ca. 1 Anforderung alle 86 Sekunden ~ Ziel von 0,011 RPS

— Ben Lessani - Sonassi
quelle

Ihre Eröffnungslinie ist sehr wahr ... Seiten- Caching ist nicht der Weg, um Leistung zu erzielen. Ich weiß das. Sie wissen nicht, wie oft ich Kunden dasselbe gesagt habe. Um ehrlich zu sein, ich habe noch nie eine Site eingerichtet, auf der ein Crawler den FPC vorbereitet hat, und habe gesehen, dass er nur einmal verwendet wurde, wenn ein Client ihn im Administrator aktiviert hat. Der Hauptgrund, den ich frage, ist, dass ich mich auf der Grundlage von Recherchen in Nexcess 'Whitepaper mit diesbezüglichen Ideen befasse. Für Websites mit wahnsinnig hohem

— Datenaufkommen

Ich respektiere Nexcess - aber ihr Whitepaper konzentriert sich sehr stark auf das Cachen, um Leistung zu erzielen - anstatt sicherzustellen, dass die Umgebung bereits leistungsfähig ist und der Code sauber, schnell und effizient ist. Wir stellen unseren Kunden Lacke zur Verfügung - aber befürworten dessen Verwendung erst, wenn dies erforderlich ist. Nur dann als Mittel zur Senkung der Infrastrukturkosten - dh. wenn ~ 94% des nicht konvertierenden / auscheckenden Datenverkehrs CPU-Zyklen beanspruchen. Caching ist eine gute künstliche Benchmark-Statistik - bedeutet aber nichts in der Realität, wenn die TTLs zu lang sind (veralteter Inhalt) - oder wenn nicht genügend Datenverkehr vorhanden ist, um die Grundierung aufrechtzuerhalten.

— Ben Lessani - Sonassi

Für Websites mit wahnsinnig hohem Datenverkehr - wir haben ein paar - und der Versuch, einen Cache durch künstliches Crawlen heiß zu halten, ist sinnlos - der natürliche Datenverkehr macht das in Ordnung. Wenn überhaupt, werden durch das Crawlen nur Ressourcen entfernt, die ansonsten von Kunden verwendet würden.

— Ben Lessani - Sonassi

Ich bin mir nicht sicher, in welchem Whitepaper sie sich darauf konzentrieren, Caching für die Leistung zu verwenden. Sie zeigten, wie viel Durchsatz ein 2 + 1-Cluster erzielen konnte. Sie berührten nicht einmal die Ladezeiten, sondern nur den Transaktionsdurchsatz. Die Hardware, die sie haben, ist so optimiert, wie Sie nur bekommen können ... und ja, ich erkenne die Auswirkungen von TTLs auf zwischengespeicherte Inhalte. Um es noch einmal zu wiederholen, ich möchte hier keine Leistung erbringen, das haben wir bereits. Dabei geht es darum, Wege zu finden, um Verzögerungen / Durchsatzverluste aufgrund der Cache-Leerung am frühen Morgen zu umgehen, dh bevor der normale Datenverkehr einsetzt.

— Davidalger

Ich bin dann verwirrt. Wenn Ihr Geschäft bereits schnell ist - aber umkippt, wenn Sie den Cache leeren. Entweder a) Leeren Sie den Cache nicht am Morgen, sondern am Abend zuvor, und lassen Sie die Such-Crawling-Bots (Google / Bing usw.) das Priming für Sie durchführen, oder b) holen Sie sich die richtige Infrastruktur. Wenn Ihr Geschäft auf FPC / Lack angewiesen ist, um Verzögerungen / Verlangsamungen zu vermeiden, dann hört es sich so an, als ob Sie auf dem

— neuesten Stand sind

Ich werde meine ganze Scherzerei für einen Blogeintrag in diesen Tagen aufheben, aber in der Zwischenzeit einen Höhepunkt an meinem kleinen Cache-Wärmer haben wfpc.

Leistung testen

Sie können die Leistung Ihrer Magento-Site testen

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

FPC Erwärmung

Und Sie können den FPC erwärmen, der jede URL in sitemap.xml trifft.

./wfpc -w http://mymagentosite.com/sitemap.xml

Wenn Sie möchten, können Sie auch eine Verzögerung zwischen den Anforderungen festlegen. Hier ist eine Verzögerung von 1 Sekunde zwischen den Anforderungen.

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

Der Testmodus trifft nur 10 URLs zufällig. Sobald Sie Ihre FPC erwärmt haben, können Sie den Testmodus ausführen, um herauszufinden, welchen Unterschied die FPC macht!

Gedanken

Ich persönlich halte einen Wärmer für sinnvoll ... Auf einer kleinen Site mit etwa 40 Seiten halbiert der FPC die Download-Zeit in etwa. Auf einer großen Site mit fast 40.000 Produkten, die Lesti_FPC mit APCu als Backend verwenden, verwende ich etwas mehr als 200 MB für den Cache, was ehrlich gesagt nichts auf dem 8-GB-Produktionsserver ist.

— quickshiftin
quelle