Ganzseitiger Cache unter CE 1.8 - Ein FPC-Magento-Modul? Lack? Beide?

Ich bin also ein bisschen verwirrt, wenn ich mich mit der Untersuchung von Full Page Caching für Community Edition 1.8 befasse. Ich habe bereits einen Two-Level-Redis-Cache (CDN) implementiert, die my.cnf von MySQL auf maximale Leistung optimiert (wobei sich die DB natürlich auf einem separaten Server befindet), und ich habe 2 Server, die unseren Shop hinter einem Load Balancer hosten. Ich sage dies, um darauf hinzuweisen, dass ich nicht sofort zur FPC springen werde, bevor ich die anfänglichen Leistungsverbesserungen vornehme.

Ich habe Varnish noch nie auf einer Website verwendet, geschweige denn in Magento, und ich habe auch noch nie eine FPC in Magento eingerichtet. Ich verstehe Varnish als einen Proxy, der als Kreuzung zwischen einem CDN und einem eigenen Seiten-Cache fungiert und Daten an den Browser sendet, bevor die Anfrage überhaupt an den Webserver gelangt. Und meines Erachtens erstellt ein FPC-Modul lokal einen Cache, den der Webserver selbst ausgibt. Ich weiß, dass Sie für beide Setups einige "Hole Punching" -Vorgänge durchführen müssen, um den dynamischen Inhalt in den Browser zu übertragen (obwohl die Techniken zwischen der Verwendung eines Moduls oder der Verwendung von Varnish unterschiedlich sind). Bitte korrigieren Sie mich, wenn ich hier etwas missverstehe.

Bis jetzt habe ich sie als zwei separate Entitäten betrachtet, die Sie implementieren könnten, um Ihrer Site zu helfen, aber jetzt scheint etwas, das ich gelesen habe, das Gegenteil zu implizieren. Mein ursprünglicher Plan war es, das Modul " Warp Advanced Full Page Cache " für Magento (ehemals "Tiny Brick Lightspeed FPC", glaube ich) zu kaufen , da es am beliebtesten zu sein scheint, wenn auch etwas teurer (aber ehrlich gesagt) 350 US-Dollar sind nicht viel für unser Unternehmen, vor allem nicht für das, was es leisten kann. Ich selbst und zwei meiner Mitentwickler wollten lernen, wie man es richtig und vollständig in unser eigenes, selbstgemachtes Thema umsetzt, um das zu maximieren, was wir daraus machen können. Nachdem dies erledigt war, überlegte ich mir irgendwann, ob ich auch die Implementierung von Varnish in Betracht ziehen würde - aber wie ich bereits sagte, hatte ich verstanden, dass sie getrennt waren.

Jetzt stoße ich jedoch auf Erweiterungen wie diesen PageCache Powered by Varnish, der kostenlos ist, oder diesen Vortex Cache Powered by Varnish Cache, der fast 800 USD kostet. Dies sind Magento-Ganzseiten-Cache-Module, die direkt mit Varnish zusammenarbeiten.

Meine Frage an Sie, Stapelaustausch, ist, wie soll ich einen FPC und einen Lack sehen? Als getrennte Einheiten? Wenn ja, schließen sie sich gegenseitig aus? Sind das zwei Seiten einer Medaille, die ich gemeinsam umsetzen sollte? Oder sind sie ähnlich, aber weder exklusiv noch inklusiv?

Kann ich die oben erwähnte Warp Advanced FPC mit Varnish verwenden? Soll ich es mit Lack verwenden? Oder wäre es besser, eine andere FPC zu verwenden, wenn ich Lack verwenden möchte? ODER noch weiter, gibt es eine FPC, die so gut ist, dass ich keinen Lack benötige? Oder umgekehrt, sollte ich einfach Lack verwenden und die FPC-Idee fallen lassen?

Es tut mir leid für die Textwand, aber ich habe viele Artikel, Blogs und Forenbeiträge gelesen und konnte keine endgültige Antwort auf diese Fragen finden. Ich schätze deine Hilfe und deinen Input in dieser Angelegenheit sehr =)

Oh und zum Schluss noch eine kurze Frage zu Varnish und Webservern. Derzeit verwende ich das normale Apache LAMP-Stack-Setup, aber seit einiger Zeit schwärmen die Leute von der Verwendung von Nginx mit Magento. Ich habe einige Tests selbst durchgeführt, Stresstests und Belastungstests, und es scheint, dass es unter den richtigen Bedingungen definitiv ein bisschen besser funktionieren kann. Aus diesem Grund habe ich in naher Zukunft über einen Wechsel nachgedacht. Würde dies meinen Wunsch und meine Entscheidung, eine FPC und / oder einen Lack zu verwenden, irgendwie beeinträchtigen?

Vielen Dank!!!

EDIT: Oh! Und noch eine kurze Frage: Da sich hinter einem Load Balancer zwei Server befinden, auf denen meine Site gehostet wird (dies ist auch eine Einrichtung, die bei Bedarf horizontal erweitert werden kann), nutze ich Redis und Memcached, die auf einem anderen Server als dem gehosteten Server ausgeführt werden Web- und DB-Versionen für meine Sessions und jede Ebene des Two Level Cache von Magento (Zend). Ich nehme an, der FPC würde seine Daten in einem dieser Systeme speichern. Benötige ich eine bestimmte Erweiterung, um sie dort zu speichern, oder machen das alle? Und obwohl ich nicht davon ausgehe, würde dies Varnish in irgendeiner Weise beeinträchtigen? Danke noch einmal!!

In der Informatik gibt es zwei schwierige Dinge:

1. Dinge benennen
2. Cache-Invalidierung.

Lochstanzen fällt in Kategorie # 2 :)

Allgemeines

Der beste Ansatz ist, an den unteren Punkten des Stapels zu beginnen und bis zum Frontend von Magento zu optimieren.

Datenbank und Dateisystem

Sollte immer der erste Bereich sein, auf den man sich konzentriert. Weil. I / O.

MyTop ist ein handliches Linux-basiertes Perl-Skript, das den Linux-Befehl 'top' nachahmt und Ihnen einen Einblick in den Status Ihrer MySQL-Instanz (en) gibt.

• https://github.com/jzawodn/mytop

Htop ist ein robusteres Top . Die Strace- Funktion kann dabei helfen , die Details eines Prozesses zu bestimmen, um potenzielle Engpässe zu finden.

• https://github.com/hishamhm/htop

Iotop ist ein weiteres zu berücksichtigendes Tool für die Überwachung von E / A.

• http://guichaz.free.fr/iotop/

Andere nützliche Hilfsskripte wie mysqltuner.pl und mysql tunning primer bieten einen Einblick in Ihre MySQL-Laufzeitvariablen und geben Ratschläge zur Hilfe. Denken Sie daran, dass dies nur als Leitfaden dienen soll, da der beste Ansatz immer eine Bewertung der Anforderungen und der Abstimmung auf der Grundlage der gesammelten bekannten Daten ist. Blinde Handlungen können manchmal mehr Schaden anrichten als nützen. Und wenn Sie diese vorzeitig ausführen, ohne mindestens 24 Stunden MySQL-Laufzeitvariablen zu haben, kann dies einen schlechten Ratschlag darstellen.

• http://mysqltuner.pl
• https://launchpad.net/mysql-tuning-primer

Denken Sie daran , dass Percona , MariaDB und Standard-MySQL mit all diesen Funktionen funktionieren sollten. Bevorzugen Sie Percona als MySQL-Fork, da Magento InnoDB und XtraDB so stark belastet, dass es viele Tools und Verbesserungen für die Datenbank-Engine bietet.

• http://www.percona.com/software
• https://mariadb.org/en/about/

Apache oder Nginx

Ich benutze immer noch Apache, da es vielen anderen gute Dienste geleistet hat, auch mir. Ich habe auch Nginx benutzt und konfiguriert. Während es einige Vorteile bietet, gibt es eine Lernkurve. Während die beiden populären Optionen sind, bietet es einige Vorteile gegenüber Apache, eine wäre ein kleinerer Speicherbedarf. Ein schlanker Apache, auf dem PHP-FPM ausgeführt wird, hat jedoch einen ähnlichen Speicherbedarf.

• http://arstechnica.com/business/2011/11/a-faster-web-server-ripping-out-apache-for-nginx

Ein typisches Beispiel:

Da es in diesem Artikel um die Leistung ging, sollte ich darauf hinweisen, dass eine der einfachsten Möglichkeiten, Apache dabei zu unterstützen, seinen eigenen Weg zu finden, darin besteht, keine .htaccess-Dateien zu verwenden. Wenn Sie das, was Sie dort gespeichert haben, in Ihre Directory-Zeilengruppen aufnehmen, AllowOverride auf "None" setzen und Apache nicht aufgefordert wird, den gesamten Dokumentpfad zu durchlaufen, um herauszufinden, ob .htaccess beachtet werden muss oder nicht. Dies ist ein grundlegender, einfacher Abstimmungshinweis, den viele Leute vermissen.

So erleichtern Sie das Auschecken:

• https://github.com/preinheimer/htaccessConverter

Die Verwendung eines CDN, um beide Probleme zu lösen, ist offensichtlich hilfreich, hat jedoch einen zusätzlichen Vorteil bei der Frontend-Optimierung, da die meisten Endbenutzer-Browser mit der gleichen Anzahl von Verbindungsbeschränkungen eine Verbindung zu beiden Servern herstellen können. Dies befreit Apache auch davon, nicht durch Prüfungen springen zu müssen, um nur ein einfaches statisches Image bereitzustellen. Lighthttpd ist eine Option, wenn Sie einen statischen Webserver nur für Inhalte neben einem CDN ausführen möchten.

PHP

PHP-FPM und APC. Verwenden Sie sie, entfernen Sie nicht benötigte oder nicht benötigte PHP-Module, die für Magento nicht benötigt werden.

Magento-Codebasis

Mit AOE_TemplateHints können Sie feststellen, ob Ihre Blöcke ordnungsgemäß zwischengespeichert werden:

• https://github.com/fbrnc/Aoe_TemplateHints
• http://www.fabrizio-branca.de/magento-advanced-template-hints-20.html

AOE_Profiler eignet sich gut für die Profilerstellung. Stellen Sie sicher, dass die Profilerstellung für die DB-Ebene aktiviert ist (in einer lokalen / dev-Umgebung natürlich). Dies in Verbindung mit dem oben erwähnten Tool mytop erleichtert das Auffinden von SQL- Fehlern .

• https://github.com/fbrnc/Aoe_Profiler

Module von Drittanbietern und benutzerdefinierter Code

Einige sehr gute Best Practices für die Optimierung von Magento selbst sind eine gute Lektüre und sollten beachtet werden, wenn Module von Drittanbietern überprüft werden, bevor sie verwendet werden. (Es gibt viele schlechte Verhaltensweisen, IMO).

• http://info.magento.com/rs/magentocommerce/images/Conquer_the_5_Most_Common_Magento_Coding_Issues_to_Optimize_Your_Site_for_Performance.pdf

Mit dem Tool Magniffer von Magento ECG können Sie auf der Grundlage des oben bereitgestellten PDF-Dokuments leicht Code identifizieren, der sich schlecht verhält. Es ist Symfony / PHP-Parser-basiert, aber über Composer installierbar.

• https://github.com/magento-ecg/magniffer

Lack

Als Verfechter von Varnish, der als Autor ein FreeBSD-Kernel-Entwickler war, bietet es einige verrückte Sub-Sekunden-Ladezeiten. Wenn Sie jedoch auch nur einige der geringfügigsten Unterschiede in Ihren Vorlagen haben, die nicht im Auslieferungszustand sind, müssen Sie Lack / Magento so konfigurieren, dass der benötigte Inhalt vollständig gelocht wird. Das meiste, was ich gesehen habe, wird einfach AJAX'ify die benötigten Gegenstände ungecacht von Lack.

Es gibt eine Reihe von Magento-Modulen, die das Lochen und Zwischenspeichern erleichtern:

• AOE_Static: https://github.com/AOEmedia/Aoe_Static
• Nexcess-Terpentin: https://github.com/nexcess/magento-turpentin

Letztlich soll dies am letzten Ende der Optimierung Reise sein, und KöNNTE einige Anpassungen erfordern Dinge richtig zu machen.

Magento CE FPC

Bisher ist die beste CE-FPC, die ich gefunden habe: Lesti :: FPC

Es ist eine sehr gut zusammengestellte (alle Beobachter basierende) Open Source und kostenlose FPC für die Community.

• http://gordonlesti.com/lestifpc/
• https://github.com/GordonLesti/Lesti_Fpc (Github im Falle eines toten zukünftigen Links)

Am Ende des Tages verwenden Sie Ihre eigenen Tests und Beurteilungen.

Einige weitere Lektüre:

• http://www.kingletas.com/2012/08/caching-performance-optimization.html
• https://www.sonassi.com/knowledge-base/magento-with-varnish/
• http://info.magento.com/rs/magentocommerce/images/HostandBoastBestPracticesForMagentoHosting.pdf

Ich weiß, dass dieser Thread etwas spät ist, aber wenn Sie immer noch nach einer Lösung suchen, sollten Sie Evolved Caching in Betracht ziehen . Es ist der gleiche Preis wie Warp, aber es:

• Ist sehr schnell und einfach zu installieren und zu konfigurieren - das gesamte Lochen und Konfigurieren erfolgt über den Administrator
• Integriert sich direkt in Varnish und ermöglicht es Ihnen, Ihren Varnish-Cache in Magento zu leeren und aufzuwärmen
• Funktioniert mit dem in 1.8 CE eingeführten Frontend form_key sowohl in Varnish als auch im eigenen Cache.
• Ist sehr aktiv mit reaktionsschneller Unterstützung entwickelt. Regelmäßige neue Versionen mit dem Ziel, Fehlerbehebungen innerhalb weniger Tage nach der Berichterstellung zu veröffentlichen
• Verfügt über eine umfangreiche Dokumentation, die mit jedem Release aktualisiert wird

Einstellung mit Firnis nach oben ist gerade nach vorne, Sie müssen nur eine Admin - Einstellung aktivieren und verwenden Sie die .vcl gefunden hier . Sie sind auch nicht darauf beschränkt, nur den Cache von Varnish zu bedienen, wenn keine Cookies wie gewohnt vorhanden sind - Sie erhalten eine sehr hohe Cache-Trefferquote.

Wir haben eine FPC geschrieben, die mit dem neuen Formularschlüssel von Magento 1.8 kompatibel ist. Brims ganzer Seiten-Cache: http://ecommerce.brimllc.com/full-page-cache-magento.html

BOOMER legt großen Wert darauf, möglichst wenig zu stapeln und sich nach oben zu arbeiten. Ein FPC oder Lack sollte ungefähr das Letzte sein, was Sie tun. Wir führen Leistungsprüfungen durch und stellen häufig Probleme mit MySQL- und APC-Konfigurationen fest, die einfach nicht stimmen. Wie Innodb Puffergrößen auf den Standard gesetzt und die Datenbank ist weit darüber hinaus gewachsen.

Wir empfehlen, kein FPC mit Lack zu verwenden, es sei denn, dies wurde speziell für die Zusammenarbeit entwickelt. Im Allgemeinen empfehlen wir Varnish nicht, es sei denn, Sie haben eine Handvoll leistungsfähiger Server, die alle zusammen mit Ihrer Codebasis optimiert wurden und immer noch Probleme haben, mit dem Datenverkehr Schritt zu halten. Das Aktualisieren dynamischer Inhalte kann mit Varnish schwierig sein, insbesondere wenn Sie versuchen, Ihre Anforderungen auf das Magento-Backend zu beschränken und damit die Last zu reduzieren. Wenn Sie einen oder zwei Webköpfe haben, sind die Gewinne möglicherweise die Zeit und die Komplikation nicht wert.

In den meisten Situationen erhalten Sie mit einem guten FPC die Leistung, die Sie benötigen, natürlich nachdem Sie Server und Codebasis optimiert haben. Mit unserer FPC können Sie Erzeugungszeiten unter 15 ms für den Level 1-Cache und unter 100 ms für den Standard-Cache erhalten. Unser Level-1-Cache wird für Fälle verwendet, in denen der Benutzer nicht angemeldet ist und nichts in seinem Einkaufswagen hat, da kein Lochen ausgeführt wird. Wenn eine dieser Bedingungen falsch ist, wird der Standard-Cache mit voller Lochunterstützung verwendet.

Unser FPC verfügt über eine integrierte, einfache Lochung und funktioniert sofort mit allen Standard-Magento-Blöcken sowie allen benutzerdefinierten Blöcken, die Sie möglicherweise haben. Es ist alles über das Admin-Panel konfigurierbar.

Ich würde empfehlen, bei Redis zu bleiben, es sei denn, Sie haben Skalierungsprobleme. Es unterstützt Tags und ist viel schneller als das Speichern von Dateien oder Datenbanken als langsames Backend. Wenn Sie konsistente Tags und Bereinigung wünschen, müssen Sie memcached with database verwenden, wenn Sie mehrere Webköpfe haben. Dank der integrierten Tag-Unterstützung von Redis müssen Sie sich keine Sorgen mehr machen. Sie können Redis auch für Ihre Sitzungen verwenden.

Ich kann für alle FPCs sprechen, aber bei uns können Sie über den Administrator konfigurieren, wo sie gespeichert werden sollen. Sie können das standardmäßige Magento-Cache-Backend verwenden oder benutzerdefinierte Einstellungen für die Verwendung von Datei, Datenbank, APC, Redis, Memcache und einem optimierten Datei-Backend festlegen.

Es gibt keine richtige Antwort. Ein Geschäft sollte über dynamische Seitenladevorgänge von weniger als 3 Sekunden und im Idealfall über dynamische Seitenladevorgänge von weniger als 1 bis 2 Sekunden verfügen. Eine Sekunde ist nicht erforderlich und in erster Linie eine marketingbasierte Statistik. Apache ist leicht zu erlernen und schwer zu implementieren, Nginx ist schwer zu erlernen und leicht zu implementieren. Viele Websites wechseln zu Nginx. Eine qualitativ hochwertige Architektur auf der Basis von Nginx und Magento ist jedoch nicht einfach.

Magento-Cluster mit mehreren Servern sind bereits komplex zu implementieren und noch schwieriger zu warten, wenn nicht die richtige Architektur verwendet wird. Normalerweise arbeiten wir mit größeren Clustern, wodurch alles reibungsloser funktioniert, auch das Ranking. Wir tun dies mit der Standardinstallationskonfiguration mit geringfügigen Änderungen für mittel- bis langfristige Stabilität, die auf die dynamischen Seitenladevorgänge von 1-2s abzielen. Dies vereinfacht die Wartung erheblich.

Lack kann eine FPC sein, unter anderem eine CDN. In Ihrem Fall ist es jedoch am besten, sich eine FPC vorzustellen. Ein FPC ermöglicht mehr Besucher auf dem Server und eine schnellere statische Bereitstellung, wobei Varnish ein solches Tool ist. Es gibt jedoch verschiedene Probleme, einschließlich dynamischer Inhalte, Bestandskontrolle und Preisgestaltung. Die Antwort hängt davon ab, wie Ihr Unternehmen strukturiert ist, wie Ihre Daten geladen werden, wie häufig Ihre Hosting-Art und mehr, und einfach davon, ob Ihr Unternehmen statische Inhalte für Besucher bereitstellt. Mit der FPC-Konfiguration können Sie einen Großteil davon technisch abmildern, was jedoch die Geschäftsumgebung kompliziert. Aus Sicht des Geschäftsinhabers führt dies möglicherweise nicht zu einer ausgewogenen Kapitalrendite.

Die FPC ist der letzte Teil, wenn Sie eine dynamische Belastung von weniger als 3 Sekunden oder besser haben. Ihre Architektur kann eine Vielzahl von Besucheranfragen bewältigen, da dies das Ranking beeinflusst, Marketing- und Urlaubsspitzen absorbiert und das Budget zur Erhöhung der Komplexität der Serverarchitektur ausreicht. Das Hosting sollte 0,5 betragen -1% des Umsatzes für kleinere Unternehmen, wobei die meisten davon erheblich darunter leiden und viele indirekte geschäftliche Probleme verursachen.

Der Grund, warum Sie keine endgültige Antwort gefunden haben, liegt in der Tatsache begründet, dass die Beantwortung dieser Fragen Monate dauert, da sie qualitativ sind (geschäftsbezogen) und Informationen erfordern, die ein Unternehmen nicht öffentlich veröffentlichen möchte. Die Seitenladegeschwindigkeiten sind quantitativ (technisch) ) die öffentlich veröffentlicht werden kann, ist es, wie Sie die beiden kombinieren, die die Lösung macht.

Sie können diesen Magento-Seiten-Cache verwenden, der Ihren Anforderungen entspricht und lackähnlich ist. Es wird von vielen der größten Magento-Stores genutzt. Einige Eigenschaften:

1. Wie bei Varnish wird für 90% der Anforderungen keine Datenbankverbindung verwendet. Infolgedessen ist es extrem schnell
2. Es kann Seiten automatisch leeren, wenn sich beispielsweise das Produktinventar ändert, und das ist sehr gut
3. Da es sich um einen mehrschichtigen Cache handelt, wird auch das Lochen beim Anmelden von Benutzern unterstützt (diese Anforderungen erfordern die Verwendung der Datenbank).

Als mehrstufiger Cache ist er selbst für Läden mit hohem Datenaufkommen skalierbar und wurde auf vielen Websites mit extrem hohem Datenaufkommen verwendet, auf denen der Datenverkehr am höchsten ist, z.