„Der Shop ist langsam“ ist zwar eine nützliche Kundenrückmeldung, aber keine aussagekräftige Diagnose. Eine Kategorieseite, die für einen Erstbesucher nur langsam geladen wird, ist ein anderes Problem als ein Bestellvorgang, der nach der Auswahl einer Zahlungsmethode ins Stocken gerät.
Mein erster Schritt besteht darin, die Beschwerde in eine reproduzierbare Anfrage umzuwandeln: eine URL, den Kundenzustand, das Gerät, den ungefähren Zeitpunkt und die Aktion. Ohne diese Angaben führen Änderungen an der Infrastruktur in der Regel dazu, dass derjenige Benchmark verbessert wird, der am einfachsten durchzuführen ist.
Ermitteln Sie die Verzögerung, bevor Sie irgendetwas einstellen
Ich unterscheide zwischen drei Aspekten: wie lange der Server braucht, um mit der Antwort zu beginnen, wie lange der Browser braucht, um die Seite zusammenzustellen, und wie lange es dauert, bis eine Benutzeraktion abgeschlossen ist. Eine schnelle HTML-Antwort kann dennoch zu einer schlechten Benutzererfahrung führen, wenn der Browser damit beschäftigt ist, unnötige Skripte auszuführen.
Außerdem vergleiche ich anonymen und authentifizierten Datenverkehr. Ein gut gefüllter Cache öffentlicher Seiten kann einen ressourcenintensiven Anwendungspfad verbergen, der immer dann auftritt, wenn eine Sitzung die Antwort verändert. Das wiederholte Aktualisieren einer bereits geladenen Seite spiegelt nicht die Customer Journey wider.
Ein aussagekräftiges Untersuchungsprotokoll enthält den Zeitpunkt der Anfrage, den Cache-Status, die Antwortgröße, den Anwendungs-Trace sowie die relevanten Infrastrukturkennzahlen aus demselben Zeitfenster. Der Abgleich dieser Beobachtungen ist wichtiger als die Erfassung einer Vielzahl zusammenhangloser Durchschnittswerte in einem Dashboard.
Verfolgen Sie die Anfrage durch den Stack
Bei einer nicht zwischengespeicherten Anfrage gehe ich schrittweise vor. Wartet der Webserver auf einen verfügbaren PHP-Worker? Verbringt PHP Zeit mit Datenbankabfragen? Führt ein Modul eine synchrone Anfrage an einen Remote-Dienst durch? Steht die Anfrage in Konkurrenz zu Katalogvorgängen?
| Beobachtung | Nächste Frage |
|---|---|
| Verzögerungen bei Importen nehmen zu | Kommen Indizierungsvorgänge oder Datenbank-Schreibvorgänge mit Kundenanfragen in Konflikt? |
| Nur die Seiten, auf denen man angemeldet ist, laden langsam | Welche nicht zwischengespeicherten Blöcke oder kundenspezifischen Vorgänge überwiegen? |
| Der Bezahlvorgang wird zeitweise unterbrochen | Wartet eine Versand-, Steuer- oder Zahlungsabhängigkeit ohne sinnvolle Zeitüberschreitung? |
| Die Serverantwort erfolgt schnell, die Interaktion verläuft langsam | Was beansprucht den Hauptthread des Browsers? |
Ich vermeide es, die Anzahl der Worker zu erhöhen, bis ich die Speicher- und nachgelagerten Kapazitäten verstanden habe. Mehr gleichzeitig ausgeführte PHP-Prozesse können dazu führen, dass aus einer Warteschlange auf der Anwendungsebene eine größere Warteschlange auf der Datenbankebene wird. Änderungen an der Parallelität sollten durch Messungen begründet sein.
Die durch Erweiterungen eingeführten Änderungen überprüfen
Das Erweiterungsmodell von Magento macht es einfach, dass mehrere für sich genommen sinnvolle Module eine einzelne Anfrage zusätzlich belasten. Eine Produktliste kann zusätzliche Ladevorgänge für Sammlungen, Remote-Prüfungen oder wiederholte Konfigurationsabfragen auslösen. Die Summe dieser Kosten ist das, was der Kunde spürt.
In einer kontrollierten Umgebung vergleiche ich die Ablaufverläufe, wobei das mutmaßlich problematische Verhalten deaktiviert ist. Das Ziel besteht darin, den Vorgang zu identifizieren, der für die Verzögerung verantwortlich ist, und nicht darin, jedes Modul eines Drittanbieters als Problem einzustufen. Wenn eine Funktion notwendig ist, könnte es die richtige Lösung sein, ihre Ausführung aus dem kritischen Anforderungspfad herauszunehmen.
Caching ist nur dann sinnvoll, wenn der Cache-Schlüssel und das Invalidierungsverhalten zu den Daten passen. Kundenspezifische Informationen dürfen nicht allein zur Verbesserung eines Timing-Diagramms zu gemeinsam genutzten Inhalten werden. Die Caching-Dokumentation von Adobe ist hilfreich, um die Cache-Ebenen der Plattform zu verstehen, bevor Änderungen daran vorgenommen werden.
Gegen eine Customer Journey überprüfen, einschließlich der langsamen Fälle
Mein Testablauf umfasst eine Kategorieseite, ein Produkt mit Varianten, das Hinzufügen zum Warenkorb, den Übergang zur Kasse sowie die entsprechende Integrationsgrenze. Ich vergleiche die Verteilung der Anfragen, einschließlich langsamerer Antworten, anstatt nur ein erfolgreiches Beispiel zu präsentieren.
Die Änderung muss auch in der Praxis überprüft werden. Hat die Datenbankauslastung zugenommen? Sind geplante Aufgaben in Verzug geraten? Ist die Fehlerquote gestiegen, während die Seite schneller geworden ist? Eine lokale Verbesserung kann das Problem lediglich an einen weniger sichtbaren Ort verlagern.
Ich betrachte die Untersuchung als abgeschlossen, wenn ich die ursprüngliche Verzögerung erklären, nachweisen kann, dass sich die betroffene Verbindung unter vergleichbaren Bedingungen verbessert hat, und beschreiben kann, wie sich die Änderung in Spitzenzeiten auswirkt. Diese Erklärung ist hilfreicher als eine weitere Runde von Server-Upgrades.
Aktualisiert am 25. September 2026.