Warum dein Magento-2-Shop trotz Varnish und Redis langsam wirkt

Mittwochnachmittag. Eine Freundin erzählt dir, sie habe versucht, in deinem Shop zu bestellen, und es habe „ewig" gedauert. Du rufst die Seite auf, klickst ein wenig herum, und ja, sie fühlt sich träge an. Du schreibst deiner Agentur. Die Antwort ist dieselbe wie letztes Quartal: Du hast Varnish. Du hast Redis. Die Hardware ist in Ordnung. Der Shop dürfte eigentlich nicht langsam sein.

Aber er ist es. Und die Rechnung für diese Hardware liegt in deinem Posteingang.

Wenn sich dein Magento-2-Shop trotz Varnish und Redis langsam anfühlt, liegt es meistens an einer dieser drei Ursachen:

Nichts davon taucht auf einer CPU-Kurve auf. Es zeigt sich als „die Seite fühlt sich komisch an", verlorene Sitzungen und Support-Tickets.

Varnish und Redis sind keine Schalter. Es sind Werkzeuge. Du kannst einen sehr guten Ofen besitzen und das Abendessen trotzdem verbrennen, wenn die Regler falsch eingestellt sind.

Magento 2 wird mit beiden aktiviert ausgeliefert, aber die Standardkonfiguration geht davon aus, dass dein Theme, deine Erweiterungen und deine Drittanbieter-Skripte alle sauber zusammenarbeiten. In der Realität bricht ein einziger schlechter Cookie oder eine geschwätzige Erweiterung das Ganze leise auf, und niemand merkt es, weil die Seite immer noch lädt. Nur langsam. Bei jeder Anfrage. Für immer.

Wenn dir also jemand sagt „Varnish läuft", ist das eine Ja/Nein-Antwort auf die falsche Frage. Die richtige Frage lautet: Liefert Varnish tatsächlich den Großteil deines Traffics aus, oder schaut es nur zu, wie PHP die ganze Arbeit macht?

Varnish hat eine einfache Aufgabe. Ein Besucher ruft /herrenschuhe auf. Varnish prüft, ob es bereits eine Kopie hat. Wenn ja, liefert es diese Kopie in Millisekunden, ohne PHP zu bemühen. Wenn nicht, holt es eine frische, speichert sie und bedient den nächsten Besucher aus dem Cache.

Der Haken: Varnish cacht keine Antwort, die „persönlich" aussieht. Und Magento 2 sowie viele Erweiterungen lassen Antworten gerne persönlich aussehen, obwohl sie es gar nicht sein müssten.

Die üblichen Verdächtigen:

Jede einzelne dieser Ursachen verwandelt eine schnelle Kategorieseite in eine volle Magento-Anfrage. Jedes. Einzelne. Mal. Wir haben Shops gesehen, bei denen der Großteil des Traffics Varnish aus genau diesem Grund umgangen hat. Die Hardware langweilte sich. Die Besucher nicht.

So erkennst du es ohne eine Zeile Code: Öffne deinen Shop in einem privaten Browserfenster. Öffne den Netzwerk-Tab (Rechtsklick, Untersuchen, Netzwerk). Lade die Startseite. Klicke auf eine beliebige Kategorie. Schau dir die Response-Header des HTML-Dokuments an. Wenn du Cache-Control: no-store oder no-cache siehst, oder eine Set-Cookie-Zeile auf einer Gast-Seite, bekommt Varnish die Anweisung, nicht zu cachen. Das ist der erste Dominostein.

Du kannst deinem Entwickler auch diese eine Zeile weiterreichen. Sie zeigt ihm auf einen Blick, ob Varnish seinen Job wirklich macht:

1varnishstat -1 | grep -E 'cache_hit|cache_miss'

Wenn die Misses die Hits deutlich übersteigen, ist Ursache 1 aktiv.

Diese Ursache ist subtil, und niemand fängt sie ab, auch erfahrene Teams nicht.

Magento nutzt Redis, um Kundensitzungen zu speichern: das, was den Warenkorb sich an seinen Inhalt erinnern lässt, einen Login eingeloggt bleiben lässt, einen Checkout wissen lässt, in welchem Schritt du gerade bist. Standardmäßig sperrt Magento die Sitzung, während eine Anfrage verarbeitet wird, damit sich zwei Anfragen nicht gegenseitig die Daten überschreiben.

Moderne Storefronts feuern fünf, zehn, manchmal dreißig Anfragen gleichzeitig ab, wenn ein Kunde eine Seite lädt. Hintergrund-Tabs. AJAX-Aufrufe für den Mini-Warenkorb. Tracking-Pixel, die die Sitzung anfassen. Ein Werbebanner, das eine Sitzung startet, um die Kundengruppe zu prüfen. Alle reihen sich hinter der ersten Anfrage ein und warten auf das Lock.

Auf einem gesunden Shop sind das Millisekunden Reibung. Auf einem Shop mit einer geschwätzigen Erweiterung, die unnötig Sitzungen startet, bekommst du Session-Lock-Contention: Kunden, die im Checkout 2 bis 5 Sekunden vor einem Ladesymbol sitzen, ohne sichtbaren Grund. Kein Server-Alarm schlägt an. Kein Log-Eintrag schreit. Die CPU-Kurve bleibt flach. Und der Kunde springt ab.

Das ist das Performance-Problem Nummer eins, das wir im vergangenen Jahr auf ansonsten gesunden Magento-Shops diagnostiziert haben. Und es ist das Problem, das Performance-Optimierungsrunden am häufigsten unberührt überlebt, denn wenn man nicht weiß, dass man danach suchen muss, versteckt es sich.

So erkennst du es ohne eine Zeile Code: Frag deinen Entwickler: „Nutzen wir Redis Session Locking in der Standardkonfiguration, und welche Erweiterungen starten Sitzungen im Storefront?" Wenn die Antwort „öhm" lautet, hast du es wahrscheinlich gefunden.

Cron ist Magentos Hintergrundarbeiter. Er verschickt Warenkorbabbruch-E-Mails, aktualisiert Produktpreise aus deinem ERP, räumt alte Daten auf, erneuert die Sitemap und synchronisiert Bestände. Wenn Cron zufrieden ist, denkst du nie an ihn. Wenn Cron kaputt ist, stirbt dein Geschäft in Zeitlupe.

So sieht das Fehlermuster aus: Ein Cron-Job, meist aus einer alten Integration mit ERP, CRM oder Marketing-Tool, läuft deutlich länger, als er sollte. Fünf Minuten. Zehn Minuten. Wir haben einen gesehen, der jedes Mal über acht Minuten brauchte. Magentos Cron-System ist höflich. Es wartet, bis ein Job fertig ist, bevor der nächste startet. Also blockiert dieser eine lange Job alles, was dahinter steht.

Das Ergebnis, aus einem echten Shop, den wir kürzlich angeschaut haben: über 90 Prozent der geplanten Jobs wurden übersprungen. Nicht „verzögert". Nicht „langsam". Komplett übersprungen. Das heißt: Preise wurden nicht aktualisiert. Bestell-E-Mails wurden nicht verschickt. Bestände wurden nicht synchronisiert. Der Händler hatte keine Ahnung, weil nichts im sichtbaren Sinn „kaputt" war. Die Seite lud. Der Checkout funktionierte. Aber der Hintergrund des Geschäfts hatte leise aufgehört, sich zu drehen.

Das spürst du nicht als Langsamkeit, wie du Ursache 1 und Ursache 2 spürst. Du spürst es als: „Warum hat dieser Kunde keine Bestellbestätigung bekommen?" „Warum zeigt dieses Produkt noch Bestand, obwohl es gestern ausverkauft war?" „Warum wurde unser Newsletter-Segment übersprungen?" Es ist Performance einer anderen Art. Der Shop ist nicht langsam, das Geschäft ist es.

So erkennst du es ohne eine Zeile Code: Frag deinen Entwickler nach der Anzahl der verpassten Cron-Jobs der letzten sieben Tage. Wenn es mehr als eine Handvoll sind, blockiert etwas die Queue.

Kopiere dies in ein Ticket. Auf deiner Seite ist kein technisches Wissen nötig.

Vier Fragen. Wenn dein Team alle vier souverän beantworten kann, steht es wahrscheinlich gut um dich. Wenn nicht, hast du ein Projekt fürs Wochenende.

Dein Entwickler sollte auch den Begleitartikel lesen: So diagnostizieren Sie eine niedrige Varnish-Hit-Rate auf Magento 2. Das ist die technische Fassung von Ursache 1 mit den genauen Befehlen und der Konfiguration, die er braucht.