Ist Lack das Richtige für Sie?
Lack ist nicht das A und O der Magento-Performance. Es ist großartig, um die Last von Bots und Window-Shoppern auszugleichen - aber es sollte nicht Ihre erste Anlaufstelle sein, um Ihr Geschäft tatsächlich schneller zu machen.
Tatsächlich sollte die Implementierung von Varnish die letzte Leistungsänderung in Ihrem Geschäft sein. Lassen Sie es erst einfließen, wenn Sie die Ladezeiten der Seite sehen, die Magento ohne sie bereitstellen kann (z. B. <600 ms Ladezeiten der Seite).
Ihr Geschäft muss immer noch schnell sein
Da für Varnish immer noch mindestens eine einzelne Seite geladen werden muss, um den Cache zu füllen, muss die nicht zwischengespeicherte Leistung immer noch sehr gut sein. Ein Großteil der eindeutigen URLs (mehrschichtige Navigationstreffer, Suchanfragen usw.) wird nur dann wirklich von Varnish geliefert, wenn:
a) Ihre TTLs sind so hoch, dass eine Suchanfrage von vor 4 Tagen heute noch gültig ist
b) Die Tritt- auf dem Gelände so groß ist , dass die URLs in sehr kurzer Zeit aufgefüllt werden
Man muss auch bedenken, dass sich nicht jedes Geschäft für Lack eignet . Jede Site, die Benutzer dazu ermutigt, zu Beginn ihrer Kundenreise eine persönliche Sitzung zu erstellen (z. B. Anmelden, Hinzufügen zum Warenkorb usw.), führt dazu, dass Varnish letztendlich überflüssig wird.
Private Shopping-Sites ermutigen zum Beispiel dazu, sich direkt am Set anzumelden. Dabei bedeutet dies jedoch, dass Varnish niemals wirklich nicht eindeutige Inhalte enthält, die im Cache gespeichert werden können. Daher sind Ihre Trefferquoten drastisch niedrig, und die Verwendung von Lack hat keinerlei Vorteile.
Frischer Inhalt oder höhere Trefferquoten
Bild mit freundlicher Genehmigung von magestack.com
Beim effektiven Einsatz von Varnish geht es darum, ein Gleichgewicht zwischen veraltetem Inhalt und der Anzahl der Besucher auf Ihrer Website herzustellen.
Wenn Sie eine stark frequentierte Site haben, können Sie wahrscheinlich mit niedrigeren TTLs davonkommen und trotzdem eine hohe Varnish-Trefferquote erzielen - und auch weiterhin niedrige TTLs haben -, was zu einem frischeren Inhalt führt. So werden Ihre Aktien- / Kursänderungen schnell wiedergegeben und der Cache wird ständig vom Aufkommen abhängig gemacht.
Wenn Sie eine verkehrsarme Site haben, müssen Sie einen Kompromiss eingehen. Erhöhen Sie entweder Ihre TTLs, um eine höhere Trefferquote zu gewährleisten, oder verfügen Sie über aktuelle Inhalte. Beides kann man nicht haben. Ja, Sie könnten ein Crawler- / Spider-Tool ununterbrochen ausführen - aber die damit verbundenen Ressourcen und das schiere Volumen oder die URLs, die gecrawlt werden können (normalerweise Zehntausende für kleine Läden), führen dazu, dass es einfach nicht effektiv ist. Daher würden kleinere Geschäfte in der Regel mehr von einer guten FPC-Erweiterung und einer hochoptimierten Serverkonfiguration profitieren .
Aber natürlich kann ich Varnish auch dann verwenden, wenn Benutzer angemeldet sind. Was ist mit Cache pro Benutzer oder ESIs?
ESIs
ESIs sind ein hervorragendes Dienstprogramm, um Inhalte im Cache zu halten und dennoch dynamische Blöcke auf der Seite zu haben. Um jedoch effektiv eingesetzt zu werden, müssen Sie die Anzahl der Rückrufe auf das Nötigste reduzieren. Es gibt ein kleines Startmodul, das Sie als Grundlage für diesen Prozess verwenden können. Stellen Sie jedoch sicher, dass Sie die Sicherheitslücken in diesem Modul schließen , da es standardmäßig sehr unsicher ist. Es gibt keine Einschränkungen dafür, welche Layout-Handles Sie laden können / können
Jedes Mal, wenn der Magento-Bootstrap geladen wird, kommt es zu einer Performance-Beeinträchtigung von ca. 200 ms - bevor überhaupt eine Sammlung geladen / ein Block gerendert wird usw. Wenn Sie also mehr als 3x ESIs haben, sind die Chancen gut, mit denen Sie am Ende gelandet sind Langsameres Laden von Seiten mithilfe von Varnish + ESIs für dynamische Inhalte als das Umgehen von Varnish und die direkte Weitergabe der Anforderung an Magento.
Um ESIs effektiv nutzen zu können, müssen Sie in der Lage sein, mehrere Anforderungen in einer einzigen Anforderung zu kombinieren.
Zum Beispiel muss eine Kategorieansichtsseite mit 20 Produkten genaue Lagerbestände anzeigen. Sie verwenden also ESIs für jeden Block auf der Seite. Das wären 20x ESI-Aktienanfragen. Während Bestandsanfragen sehr gering sind, würde die gleichzeitige Ausführung von 20x die Leistung beeinträchtigen. Sie könnten also stattdessen den gesamten Block / die gesamte Sammlung von 20 Produkten bedienen und nur diese 1x-Anfrage erhalten. Das Laden und Rendern der Sammlung ist jedoch wahrscheinlich das langsamste Element auf der Seite - Sie haben also nicht viel gewonnen.
Die effektive Verwendung von ESIs erfordert eine ordnungsgemäße Planung und Ausführung. Andernfalls ist die Verwendung von Varnish langsamer als die Verwendung von Varnish.
Cache pro Benutzer
Dann gibt es die Alternative, einen benutzerspezifischen Cache zu verwenden. Dies ist eine schlechte Idee, es sei denn, Sie haben eine sehr verkehrsarme Website. Ihre Trefferquote ist furchtbar niedrig, da die Wahrscheinlichkeit, dass ein Besucher dieselbe Seite besucht, auf der er bereits war, sehr niedrig ist. Und für jeden Kunden nimmt diese 6-KB-Seite immer mehr Platz in Ihrem Lackvorratsbehälter ein.
Zum Beispiel, wenn Sie Varnish 1 GB zugewiesen haben. Bei einer typischen Website, auf der Benutzer 8 Seiten pro Besuch anzeigen, sind durchschnittlich 6 dieser Seiten eindeutig. Das sind also 28 Besucher pro 1 MB Speicherplatz. Berücksichtigen Sie dann Ihre Bilder, CSS und JS - diese sind (zum Glück) üblich, belegen aber wahrscheinlich immer noch gut 7-800 MB Ihres verfügbaren Speichers. So bleiben 200 MB Speicherplatz übrig, genug Cache für 5.600 eindeutige Besucher.
Es ist mir egal, ich will nur Lack
Okay, dann müssen Sie Folgendes tun:
- Installiere einen SSL-Terminator, der vor dem Lack sitzt (zB stud / pound / nginx)
- Installieren Sie Varnish auf dem Server
- Stellen Sie sicher, dass Sie
X-Forwarded-Forrichtig konfiguriert haben
- Installieren Sie ein Lackmodul in Ihrem Geschäft
- Richten Sie Ihre Varnish-VCLs so ein, dass Erweiterungen von Drittanbietern ausgeschlossen werden
Da die ersten drei Punkte den Rahmen dieser Antwort sprengen, überlasse ich es Ihnen. Punkt 4 ist ein Kinderspiel und mit Punkt 5 - lesen Sie weiter.
Das Wichtigste bei der Implementierung von Varnish ist, dass Sie niemals Inhalte zwischenspeichern, die niemals zwischengespeichert werden sollten.
Z.B.
- Rückruf von Zahlungs-Gateways
- Warenkorbübersicht
- Kunde meine Kontoübersicht
- Checkout (und entsprechende Ajax-Aufrufe)
etc.
Für die wichtigsten Magento-URLs gibt es eine ziemlich standardmäßige Liste von URIs, die Sie in Varnish umgehen können:
admin|checkout|customer|catalog/product_compare|wishlist|paypal
Sie müssen jedoch auch alle benutzerdefinierten Erweiterungen / Erweiterungen von Drittanbietern berücksichtigen, die über benutzerdefinierte Routen, Router und Namespaces verfügen. Leider gibt es keine einfache Möglichkeit, festzustellen, welche URLs von diesen Erweiterungen zwischengespeichert werden können und welche nicht. Daher müssen Sie diese von Fall zu Fall bewerten.
In der Regel identifizieren wir bei der Konfiguration von Varnish zunächst die entsprechenden Routen, Router und Namespaces, die sie möglicherweise belegen, und gehen von dort aus. Wir machen das via SSH:
grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local
Auf diese Weise erhalten Sie keine endgültige Liste der URLs, aber mit ziemlicher Sicherheit erhalten Sie einen Einstieg.
Wir können nicht betonen, wie wichtig es ist, niemals Inhalte zwischenzuspeichern, die nicht zwischengespeichert werden sollen. Die Ergebnisse könnten katastrophal sein.
in Summe
Wie bei jeder anderen Leistungsoptimierung von Magento-Servern kann eine korrekte Implementierung und Abstimmung wirklich Vorteile bringen. Durch das bloße Ablegen der Software ohne ordnungsgemäße Konfiguration wird Ihr Geschäft jedoch nicht nur nicht schneller, sondern möglicherweise auch langsamer, unsicherer und weniger zuverlässig.