Shopware Enterprise Redis Http Cache

Shopware setzt mittlerweile auch beim HTTP Caching auf Redis. Das kommt nicht von ungefähr, denn ein Setup mit Varnish ist Wartungsintensiv und der Free Version fehlen wichtige Features…

HTTP Caching

Http Caching ist gerade für Seiten mit viel Traffic ein wichtiges Thema. Wiederholte Aufrufe von Seiten sollten nicht immer wieder von den Appserver verarbeitet werden, sondern fertig zwischengelagert und ausgeliefert werden. Der jeweilige HTTP Cache gleicht den Request mit seiner Liste an fertigen Seiten ab und falls er ein Matching hat sendet er diese direkt an den Nutzer.

Ich möchte jetzt nicht zu sehr auf die Vor- und Nachteile der einzelnen HTTP Caches eingehen, sondern in diesem Beitrag lediglich den integrierten HTTP Cache der CE Version mit der Enterprise Redis Version vergleichen.

Test Setup

Zum testen nutze ich hier JMeter mit folgenden Einstellungen:

• 2 Groups
• 20 Threads (User)
• 5 Minuten Dauer
• Kategorien, Detailseiten, Shopseiten

Ergebnisse

Das ganze sieht ja nicht wirklich bewältigend aus. Der Redis Cache ist, wenn er auf einem externen Server läuft (sich also der Webserver und Redis nicht über die CPU streiten müssen), im Schnitt 80ms schneller.

Aberrrrrrr, wir sprechen hier über einen Einsatz in einem Cluster System. Das heißt das jeder Appserver seine Cache Files einmal ablegen muss und zwar lokal. Das heißt je größer das Setup ist, desto mehr Requests brauch es in x Stunden (Cache Invalidierungsdauer) um im Cache zu sein.

Wenn wir davon ausgehen, das Inhalte aus dem Cache im Schnitt 50% schneller geladen werden hat das schon enorme Auswirkungen. Nutzt man nun noch das aufwärmen mit sw:cache:siege geht es so richtig vorwärts.

Ich werde diesen Beitrag noch im Laufe der Zeit mit weiteren Daten befüllen – für den Anfang soll dies aber erstmal reichen.