Shopware HTTP Cache Performance vs. Artikelpflege über die API

Von und
27. Februar 2018
Lesezeit: 3 Minuten

Zitat des Kunden: „Hilfe, unsere Ladezeiten sind unterirdisch und wir erhalten regelmäßig 503er Fehlermeldung! Was habt ihr gemacht? So verkaufen wir keinen einzigen Artikel …“

Analyse der Ladezeiten

Zunächst folgte eine umgehende Analyse der Ladezeiten mittels Google Chrome DevTools. Es fehlten jedoch sämtliche Vergleichswerte der vorhergehenden Woche.

Jaja, kein Performance Monitoring … jetzt schon!

Da die Inhalte von der eigentlichen Domain in etwa 1,5 Sekunden geladen werden konnten, bietet sich ein Fingerpointing in Richtung externer Ressourcen an, welche die Ladezeit insgesamt auf > 6 Sekunden verzögeren.

Analyse der Antwortzeiten

Dazu noch schnell ein Blick auf die Antwortzeit des Webservers (TTFB), um ganz sicher gehen zu können, dass wir bei den aufgerufenen Ressourcen nicht auf die Abarbeitung des jeweiligen PHP Prozesses warten!

Quatsch, wieso denn auch, wir nutzen ja schließlich den Shopware HTTP Cache.

Analyse der Response Header

Passt! Dann schauen wir uns doch noch schnell den Response Header an und stellen sicher, dass wir hier die erwarteten Cache Hits erhalten.

Oops!! Entgegen der Erwartung erhalten wir keinen Cache Hit und bitten einen Kollegen, das Ganze ebenfalls mit seinem Browser einmal durchzuspielen.

Dort funktioniert natürlich zunächst Alles wie gewünscht, sodass wir kein Stück weiter sind …

Eine weitere Schleife bringt dann Klarheit und es stellt sich heraus, dass der HTTP Cache zwar grundsätzlich funktioniert, die Objekte jedoch nur für recht kurze Zeit (wenige Sekunden) im Cache verweilen … komisch!

Wer kennt das nicht, es gibt immer wieder Kunden, die den ganzen Tag fleißig im Backend an den CMS Seiten arbeiten und zur Sicherheit andauernd den Cache leeren … also haben wir den Kunden gebeten, den Cache nicht zu leeren.

Nochmal auf Anfang

F: Warum ist die TTFB und die Auslastung des Systems durchgängig so hoch?
A: Weil die Seiten nur für kurze Zeit im HTTP Cache liegen!
F: Warum liegen sie nur für kurze Zeit im Cache?
A: Weil jemand den Cache leert, richtig!

Aber nun ist keiner mehr da, der auf den Knopf drückt.

Analyse der Webserver Logs

Eine Prüfung der Logfiles liefert eine erste Spur und zeigt neben ein paar regulären Aufrufen des Shop Frontend eine durchschnittlich hohe Anzahl von Aufrufen der Shopware API zur Artikelpflege.

Shopware HTTP Cache Einstellungen

Wir prüfen also noch einmal die Einstellungen bzgl. des Shopware HTTP Cache und werden auf die Option „Automatische Cache-Invalidierung“ aufmerksam, welche im Standard aktiviert ist.

Der Hilfetext dieser Option schafft etwas mehr Klarheit mit den Worten „Artikel-URLs werden bei Änderungen über einen BAN Request invalidiert“.

Nun wird ein Schuh draus! Mit etwas über 100 Aufrufen der Shopware API pro Minute liegt die Lebensdauer für ein Cache Objekt in der Regel nur bei wenigen Sekunden.

Anders ausgedrückt geht die Effizienz des Shopware HTTP Cache eher gegen Null.

Die Folge ist somit, dass die jeweilige Seite bei der nächsten Anfrage erst wieder komplett berechnet werden muss, wodurch sich der fortlaufend hohe Bedarf der Systemressourcen (CPU, RAM, DiskIO) erklärt.

Die Antwortzeit (TTFB) zeigt sich erneut mit nicht akzeptablen Werten und die Erwartung des Besuchers wird massiv enttäuscht.

Der Kunde hat recht: „So verkaufen wir keinen einzigen Artikel!“

Zum Vergleich wird die Einstellung also zunächst deaktiviert und die Caching Quote erneut geprüft. Nach etwa 30 Minuten lässt sich ein deutlicher Anstieg der Effizienz des Shopware HTTP Cache sowie ein wesentlich geringer Bedarf der Ressourcen erkennen.

Die Ladezeiten liegen nun konstant unter einer Sekunde.

Problem gelöst? Leider nein!

Durch die Änderung der Einstellungen bzgl. des Invalidieren der Cache Objekte sind Änderungen an den Artikeldaten (Preis, Verfügbarkeit) nun nicht mehr sofort im Frontend verfügbar.

Der Shopware HTTP Cache muss nun manuell aktualisiert werden und es entstehen zusätzliche Lastspitzen bzw. zusätzlicher Ressourcenbedarf.

Unser Lösungsansatz

Zur Lösung des Problems haben wir den Ansatz gewählt, die Aufrufe der Shopware API zunächst in einer Tabelle zu speichern und das direkte Invalidieren des HTTP Cache zu unterbinden.

Die Aufrufe der API können so aggregiert verarbeitet und die betroffenen Cache Objekte gezielt neu aufgebaut werden.

Mehr aus unserem Blog

So verhinderst du Warenkorbabbrüche
13. November 2021 · Lesezeit: 3 Minuten

Vermutlich kennst du das: Du stöberst durch den Shop – auf der Suche nach einer Thermo-Laufhose. Du findest auch ein …

Weiterlesen
Weil datenbasiert besser ist: Ranking im E-Commerce
21. März 2022 · Lesezeit: 3 Minuten

Was für Google-Suchergebnisse gilt, gilt auch im Onlineshop: Die relevanten Produkte gehören nach oben. Die Position auf der Liste beeinflusst …

Weiterlesen
Above the fold: Das sollten Kund:innen sofort sehen
14. März 2022 · Lesezeit: 4 Minuten

Fundierte Erklärungen, der Link zu einer Studie und ein paar nützliche Praxisbeispiele ‒ an alles ist gedacht im Onlineshop. Doch …

Weiterlesen
Was ist so toll am Hyvä-Theme?
16. Juli 2021 · Lesezeit: 4 Minuten

Seit seiner Vorstellung auf der Reacticon Conference 2020, spätestens aber seit dem Release Anfang Februar 2021, sorgt das neue Magento-2-Theme …

Weiterlesen
Personalisierung: Knapp die Hälfte der Kund:innen kauft mehr ein
26. Mai 2021 · Lesezeit: 3 Minuten

Wenn der Barista im Lieblingscafé Ihnen den Latte Macchiato mit Hafermilch und einem Hauch Zimt bereits zubereitet ‒ noch bevor …

Weiterlesen