So finden Sie die eine Zeile, die den Checkout langsam macht.
Wenn ein Onlineshop langsam wirkt und die Server im Leerlauf sind, ist die Wartezeit meist ein synchroner Aufruf des Systems eines anderen innerhalb des Request-Pfads. Die Methode, die «es wirkt langsam» in eine Datei und eine Zeile verwandelt.
In diesem Artikel 8 Abschnitte
Beschwerden, ein Onlineshop sei langsam, gehören zur vagen, rufbezogenen Sorte. Kein Stack Trace, keine Zeilennummer, nur ein Händler, der weitergibt, dass ein Käufer es gesagt hat, und die Arithmetik darunter: Ein langsamer Checkout ist ein abgebrochener Warenkorb, und ein abgebrochener Warenkorb ist Umsatz, der mitten im Kauf davongeht. Die erste Aufgabe ist also nicht, etwas zu beheben. Sie ist, ein Gefühl in einen Ort zu verwandeln.
- Messen Sie die Plattform unter der Last, die fehlschlägt, nicht in einem ruhigen Moment: CPU, Load, Speicher, Platte, auf jeder Ebene. Wenn jede Ebene im Leerlauf ist, lebt die Wartezeit in der Anwendung oder in etwas, das sie aufruft.
- Trauen Sie der gecachten Startseite nicht. Sie wird vom CDN ausgeliefert und beweist nichts über Warenkorb und Checkout, die bei jedem Request live Anwendungscode ausführen.
- Zeichnen Sie jeden Request auf, der langsamer als ein Schwellwert ist, und gruppieren Sie die Stack Traces danach, wo jeder Request blockiert, nicht danach, wo er begonnen hat. Eine Gruppe überragt alle anderen, und es ist meist ein synchroner Aufruf eines Systems, das der Shop nicht betreibt.
- Übergeben Sie die exakte Datei, die exakte Zeile und die Lösung: ein kurzer Timeout mit Fallback, der externe Aufruf in einen Hintergrundjob verlegt, und die Abfragen darunter indexiert, damit sie suchen statt scannen.
Die Beschwerde kommt als Gefühl
Die Formulierung ist rufbezogen, nicht technisch: Ein Käufer hat dem Händler gesagt, die Website wirke langsam, und der Händler gibt es weiter. Für einen Onlineshop ist «langsamer Checkout» keine Kleinigkeit: Es sind Warenkörbe, die beim Bezahlschritt abgebrochen werden, der teuerste Ort auf der ganzen Website, um jemanden zu verlieren. Das rahmt die Dringlichkeit ein, aber es zeigt nirgendwohin. Langsam ist ein Gefühl, kein Ort.
Ein Ressourcenalarm sagt Ihnen, wo Sie hinsehen müssen. «Die Website ist langsam» sagt Ihnen nichts: Es kann das Netzwerk sein, der Host, die Datenbank, die Anwendung oder ein Dritter, den der Shop nicht einmal betreibt. Bevor Sie es beheben können, müssen Sie ein Gefühl in eine Zeilennummer verwandeln. Der Rest hier ist das Wie.
Messen Sie zuerst die Plattform unter der Last, die fehlschlägt
Beginnen Sie mit der Plattform, gemessen unter genau der Last, die fehlschlägt: CPU, Load Average, freier Speicher, Plattenauslastung, auf dem Web-Tier und auf der Datenbank. Lesen Sie die Werte, während die Langsamkeit auftritt, nicht von einem Dashboard, das über eine ruhige Woche mittelt. Wenn jede Ebene im Leerlauf ist, lebt die Wartezeit in der Anwendung oder in etwas, das sie aufruft, und der Rest der Methode dreht sich darum herauszufinden, was.
Dort hören viele Diagnosen auf. «Es ist die Anwendung» ist wahr und für einen Händler nutzlos: Es entlastet den Host und lässt den Shop genau so feststecken wie zuvor. Ein Shop-Betreiber will nicht wissen, dass es die Anwendung ist. Er will wissen, welche Zeile, und warum. Also geht die Methode weiter, hinein in Code, den zu beheben nicht unsere Sache ist, denn die Zeile zu finden ist das eigentliche Ergebnis.
Die Startseite wird versuchen, es zu verbergen
Das Erste, was eine Stichprobe zeigt, sieht beruhigend aus, und das ist die Falle. Die Startseite, im CDN gecacht, kommt schnell zurück. Wenn Sie einen Onlineshop prüfen, indem Sie seine erste Seite laden, schließen Sie, dass alles in Ordnung ist, und schließen das Ticket. Aber eine gecachte Startseite beweist nichts über den Checkout, denn der Schmerz lebt nur auf den Pfaden, die nicht gecacht werden können: der dynamische Warenkorb und der Checkout, wo der Shop bei jedem Request seinen echten Code ausführt.
| Die gecachte Startseite | Der Checkout-Pfad |
|---|---|
| Wird vom CDN-Edge ausgeliefert | Führt jedes Mal live Anwendungscode aus |
| WHERE THE PAIN LIVESSchnell bei jeder Stichprobe | Wo jede Sekunde der Wartezeit tatsächlich lebt |
| Sieht vollkommen gesund aus | Wird von einer Stichprobe der Startseite nie berührt |
Gruppieren Sie danach, wo es blockiert, nicht wo es beginnt
Der Schritt, der es aufbricht, verwandelt Rauschen in ein Geständnis. Statt zu raten, zeichnen Sie jeden Request auf, der langsamer als ein Schwellwert ist, über alle Web-Knoten hinweg, und gruppieren dann die Stack Traces nach dem Einzigen, das zählt. Nicht danach, wo jeder Request begonnen hat (sie beginnen alle bei einer URL), sondern nach der exakten Zeile, an der jeder Request blockiert ist, sitzt und wartet. Gruppieren Sie Tausende langsamer Requests nach ihrem Blockadepunkt, und das Raten endet. Eine Gruppe überragt alle anderen, und in einem Onlineshop ist es meist ein live ausgehender Aufruf an ein System, das der Shop nicht betreibt: eine Bestandsprüfung, eine Preisabfrage, ein Betrugsscore, ein ERP, innerhalb der Bestellvalidierung. Ein Datenbankaufruf, der dieselbe Integration speist, ist meist die nächste Gruppe darunter.
Lesen Sie einen blockierten Request von oben bis unten
Der Stack eines blockierten Requests zeigt die ganze Kette vom Einstiegspunkt hinunter bis zum externen Aufruf, auf den er wartet: oben der Bezahlknopf, in der Mitte die Bestellvalidierung, und unten ein Aufruf hinaus zu einer Maschine in einem anderen Netzwerk, wo der Request sitzt, bis diese Maschine antwortet. Dieses Bild ist das, das Sie dem Händler zeigen sollten, denn es braucht keine Interpretation: Eine Person, die dem Shop Geld geben will, wartet auf ein System, das der Shop nicht betreibt, bevor die Bestellung überhaupt validiert wird.
Dann lesen Sie die Client-Konfiguration für diesen Aufruf. Die Obergrenze der Wartezeit ist eine einzige Zeile: sein Timeout. Ein Client-Timeout in Minuten, wo der Bezahlpfad Sekunden braucht, bedeutet, dass ein Käufer so lange am Bezahlknopf festgehalten werden kann, wie der Partner zum Antworten braucht, und der langsame Tag des Partners wird zum Tag des Shops.
“Ein Käufer, der bezahlen will, wartet auf eine Maschine, die der Shop nicht betreibt, in einem Netzwerk, das der Shop nicht betreibt, bevor die Bestellung überhaupt validiert wird.”
Prüfen Sie die Abfragen darunter
Das Slow Log der Datenbank zeigt meist auf dieselbe Integration: Die Abfragen, die sie speisen, scannen statt zu suchen, und sie sitzen im selben Pfad. Der externe Aufruf ist langsam, die Abfragen darunter sind langsam, und beide stehen zwischen dem Käufer und der Bestellung. Den Aufruf ohne die Abfragen zu beheben, lässt den zweiten Engpass stehen.
Wir schreiben Ihren Checkout nicht um. Wir übergeben Ihnen die Zeile.
Wir schreiben den Checkout eines Kunden nicht um: Es ist sein Code, seine Geschäftslogik, sein Risiko. Was wir übergeben, ist nützlicher und schwerer zu bekommen: die exakte Datei, die exakte Zeile und die konkrete Lösung. Drei Schritte, der Reihe nach.
Begrenzen Sie den Timeout
: Kürzen Sie den Timeout auf wenige Sekunden mit einem sanften Fallback, damit ein langsamer Partner eine Bestandszahl verschlechtert, statt die ganze Bezahlung einzufrieren.
Holen Sie ihn aus dem Request-Pfad
: Verlegen Sie den externen Aufruf aus dem Live-Request in einen Hintergrundjob. Die Bezahlung eines Käufers sollte nicht live auf die Antwort eines Dritten warten.
Beheben Sie die Abfragen darunter
: Indexieren und schreiben Sie die Abfragen um, die die Integration speisen, damit die Daten dahinter aufhören, ein zweiter Engpass zu sein.
- Ein Live-Aufruf an ein externes System innerhalb der Bestellvalidierung
- Ein Timeout in Minuten beim Bezahlschritt
- Der Käufer, der am Bezahlknopf wartet
- Full-Table-Scans, die inline mit dem Checkout laufen
- Der externe Aufruf in einen Hintergrundjob verlegt
- Ein Timeout von wenigen Sekunden mit sanftem Fallback
- Der Bezahlknopf antwortet im Zeitbudget der Plattform selbst
- Die Abfragen indexiert und umgeschrieben
Die Lektion
Ein gesunder Server im Leerlauf ist fast nie der Ort, an dem die Langsamkeit lebt. Wenn die Plattform ruhig ist und der Käufer wartet, liegt die Wartezeit im Anwendungs-Tier oder in etwas, das es aufruft, und die Methode oben findet heraus, welche Zeile.
Halten Sie synchrone Aufrufe Dritter aus dem Request-Pfad heraus. Geben Sie externen Systemen einen kurzen Timeout und einen Fallback, und erledigen Sie die eigentliche Arbeit in einem Hintergrundjob. Der Request-Pfad gehört dem Käufer.
Klare Antworten
Warum ist mein Checkout langsam, wenn der Rest der Website schnell ist?+
Meist, weil der schnelle Teil gecacht ist und der langsame nicht. Eine Startseite, die von einem CDN ausgeliefert wird, antwortet schnell und sagt Ihnen nichts über den Checkout, der bei jedem Request Ihren live Anwendungscode ausführt, einschließlich jedes Aufrufs eines Dritten, der im Bezahlpfad sitzt. Prüfen Sie den dynamischen Warenkorb und den Checkout, nicht die erste Seite.
Ist ein langsamer Checkout ein Hosting-Problem oder ein Anwendungsproblem?+
Das sollte man beweisen, nicht annehmen. Messen Sie das Web-Tier und die Datenbank unter derselben Live-Last: CPU, Load, Speicher, Platte. Wenn nichts an Ressourcen hungert, liegt die Wartezeit in der Anwendung oder in etwas, das sie aufruft, und der nächste Schritt ist, die langsamen Requests aufzuzeichnen und zu lesen, wo sie blockieren.
Was ist ein synchroner Aufruf eines Dritten im Checkout-Pfad?+
Das ist, wenn Ihr Checkout blockiert und live auf ein externes System wartet, bevor er die Bestellung weiterlässt: ein ERP, ein Bestandsdienst, ein Betrugsscore, geprüft innerhalb der Bestellvalidierung. Wenn dieser Partner langsam ist, wartet Ihr Käufer genau so lange wie er, bis zum konfigurierten Timeout, und ein Timeout in Minuten ist eine Obergrenze in Minuten.
Wie finden Sie heraus, welche Zeile eine Seite langsam macht?+
Wir zeichnen jeden Request auf, der langsamer als ein Schwellwert ist, über alle Web-Knoten hinweg, und gruppieren dann die Stack Traces nach der exakten Zeile, an der jeder Request blockiert, nicht danach, wo er begonnen hat. Die größte Gruppe ist Ihre Antwort.
Beheben Sie meinen Code für mich?+
Wir schreiben Ihren Checkout nicht um: Es ist Ihre Geschäftslogik. Wir übergeben Ihnen die exakte Datei, die exakte Zeile und die konkrete Lösung: Timeout mit Fallback verkürzen, den Aufruf des Dritten in einen Hintergrundjob verlegen, und wir indexieren und schreiben die langsamen Abfragen darunter um. Die Diagnose, präzise geliefert, ist das Produkt.
Sollte ein Bezahlknopf ein ERP oder einen anderen Dritten direkt aufrufen?+
Halten Sie das aus dem Request-Pfad heraus. Ein System auf Infrastruktur, die Sie nicht kontrollieren, sollte nicht zwischen dem Käufer und der Bezahlung stehen. Geben Sie ihm einen kurzen Timeout und einen sanften Fallback, damit es ausfallen kann, ohne den Checkout mitzureißen, und verlegen Sie den eigentlichen Aufruf in einen Hintergrundjob.
Etwas in Ihrem Checkout ist langsam. Wir finden die Zeile.
Sprechen Sie mit einem Ingenieur, der Ihren langsamen Pfad bis zur Datei und zur Zeile liest, und es klar sagt, wenn die Antwort in Ihrem eigenen Code liegt.
Mit einem Ingenieur sprechenDie Disziplin hier ist dieselbe wie hinter zwei anderen Beiträgen: wie man einen Server dimensioniert, wo die meisten weniger brauchen, als sie denken, und warum ein neuer Server im Benchmark langsamer ist als der alte, obwohl er es nicht ist.
Sie haben das Ende erreicht.
Setzen Sie das Gelesene um
Was betreiben Sie?
Erzählen Sie uns von Workload, Traffic und Anforderungen an die Wiederherstellung. Beginnen Sie mit dem Server-Konfigurator oder besprechen Sie die Details mit einem Ingenieur.
Geschrieben von den Ingenieuren, die die beschriebene Infrastruktur bauen und betreiben.Mit einem Ingenieur sprechen