Warum der PrestaShop-Checkout langsamer wird, wenn Sie eine externe Suchmaschine einbinden
Ein Nebeneffekt, mit dem man nicht rechnet
Elasticsearch, OpenSearch oder Meilisearch setzt man bei PrestaShop fast immer aus einem einzigen Grund ein: Die native Suche kommt mit einem großen Katalog nicht mehr mit. Und die Suche wird tatsächlich besser. Seltener prüft man, was dabei mit dem Rest des Shops geschieht, besonders mit Warenkorb und Checkout, wenn dieser externe Index mit Lagerbestand und Verfügbarkeit synchron bleiben muss, die sich bei jedem Verkauf ändern.
Dass dieser Teil oft unbemerkt bleibt, hat einen einfachen Grund: In der Demo, mit einer Handvoll Bestellungen, sieht man nichts. Das Problem zeigt sich erst unter echter Last, wenn mehrere Bestellungen gleichzeitig eintreffen, und dann ist der Kunde bereits beim Bezahlen. Das ist nicht der Ort, an dem man einen Engpass entdecken möchte.
Was passieren muss, wenn ein Kunde im Warenkorb eine Menge ändert
Mit einer externen Suchmaschine existiert jedes Produkt doppelt: als Zeile in der Datenbank von PrestaShop und als „Dokument“ im Index der Suchmaschine, das die Felder enthält, die zum Finden und Filtern nötig sind (Name, Preis, Kategorien, Verfügbarkeit usw.). Legt ein Kunde ein Produkt in den Warenkorb, ändert er eine Menge oder wird eine Bestellung bestätigt, ändert sich die Verfügbarkeit dieses Produkts, und das Dokument im Index muss das widerspiegeln. Sonst sähe ein anderer Kunde ein Produkt als verfügbar, das gerade ausverkauft ist.
Der einfachste Weg, und zugleich der teuerste, ist, jedes Mal das ganze Dokument neu aufzubauen: Name, Beschreibung, Preis, Kategorien, Bilder und alles Übrige aus der Datenbank neu einzulesen, nur um drei Zahlen zu ändern (Menge, Verfügbarkeit, Sortierreihenfolge nach Verfügbarkeit). Wird dieser Neuaufbau einmal pro Bestellposition ausgelöst, läuft er bei einer Bestellung mit fünf verschiedenen Produkten fünfmal, und zwar genau dann, wenn der Kunde auf die Bestätigung seiner Zahlung wartet.
Die echten Zahlen
Gemessen auf PrestaShop 9.0.0, mit zwei an Elasticsearch angebundenen Shops, kostete eine Bestellung mit fünf Positionen, die für jede Position das komplette Dokument neu aufbaute, 243 SQL-Abfragen und 229 Millisekunden, nur um drei Zahlen im Suchindex zu verschieben. Das ist nicht die Zeit des gesamten Checkouts, sondern die Zeit eines einzelnen Schritts darin, nämlich des Schritts, der den Index synchron hält.
Mit einem eigenen Pfad, der nur die tatsächlich geänderten Felder aktualisiert (Menge, Verfügbarkeit, Reihenfolge nach Verfügbarkeit), statt das ganze Dokument neu aufzubauen, sank dieselbe Bestellung in denselben Shops auf 9 Abfragen und 16 bis 47 Millisekunden. Gleicher Vorgang, gleiches Endergebnis im Index: Es ändert sich nur, wie viel Arbeit nötig ist, um dorthin zu kommen.
Der technische Unterschied lässt sich auch jemandem erklären, der keinen Code schreibt: Eine externe Suchmaschine bietet normalerweise zwei Wege, ein Dokument zu aktualisieren. Der erste, „komplett ersetzen“, ist für den Fall gedacht, dass sich wirklich etwas Grundlegendes ändert, etwa der Name oder der Preis. Der zweite, „nur diese Felder aktualisieren“, ist für den viel häufigeren Fall vorgesehen, dass sich nur die Verfügbarkeit ändert. Immer den ersten zu nehmen, auch wenn der zweite genügt, ist die häufigste Ursache dafür, dass der Checkout gerade dann langsamer wird, wenn der Shop mehr verkauft.
Warum es fast immer an derselben Stelle passiert
In PrestaShop kann das Ereignis, das während einer Bestellung eine Mengenänderung meldet, einmal pro Bestellposition ausgelöst werden und nicht einmal pro Bestellung. Der Code, der auf dieses Ereignis lauscht, ist schnell geschrieben, mit dem Gedanken „das ist ja nur ein Update“, und dabei fällt leicht nicht auf, dass sich diese kleine Entscheidung bei einer Bestellung mit vielen Positionen oder in einer Verkaufsspitze mit vielen gleichzeitigen Bestellungen mit der Zahl der Positionen und der Zahl der gerade laufenden Bestellungen vervielfacht. Ein Suchmodul, das im Test mit einer Bestellung nach der anderen schnell wirkt, kann sich am Black Friday mit Hunderten gleichzeitiger Checkouts ganz anders verhalten.
Was Sie fragen sollten, wenn Sie schon eine externe Suchmaschine haben
- Fragen Sie den Anbieter Ihres Suchmoduls oder Ihren Integrator, ob eine Mengenänderung im Warenkorb nur die Lagerfelder aktualisiert oder das gesamte Produktdokument neu aufbaut.
- Machen Sie einen Test mit einer Bestellung mit mehreren Positionen zu einem ruhigen Zeitpunkt und beobachten Sie während des Checkouts das Protokoll langsamer Abfragen der Datenbank: Sehen Sie Dutzende wiederholter Abfragen für dasselbe Produkt, ist es genau dieses Symptom.
- Betreiben Sie einen B2B- oder Großhandelsshop mit Warenkörben aus vielen Positionen, skaliert dieses Problem schlecht: Ein Warenkorb mit dreißig Positionen und vollständigem Neuaufbau pro Position ist sechsmal langsamer als einer mit fünf Positionen, während der Unterschied bei gezielter Aktualisierung viel kleiner ausfällt.
- Das ist kein Grund, auf eine externe Suchmaschine zu verzichten: Ein großer Katalog braucht sie für die Suche immer. Es ist ein Grund zu prüfen, wie die Verbindung zwischen Warenkorb und Index tatsächlich geschrieben wurde.
Zusammengefasst
Eine externe Suchmaschine bremst den Checkout nicht von allein. Den Checkout bremst eine Integration, die das gesamte Suchdokument neu aufbaut, obwohl sich nur drei Zahlen geändert haben. Der gemessene Unterschied, von 243 Abfragen und 229 Millisekunden auf 9 Abfragen und 16 bis 47 Millisekunden bei derselben Bestellung, entspricht der Arbeit, die wir in cll_essearch geleistet haben, indem wir Lagerupdates von strukturellen Updates getrennt haben, für Elasticsearch, OpenSearch und Meilisearch. Nutzt Ihr Shop eine externe Suchmaschine und wird der Checkout gerade dann langsamer, wenn der Umsatz anzieht, ist das das Erste, was Sie prüfen sollten.
Elasticsearch Suche und Facettierte NavigationBlitzschnelle, tippfehlertolerante Suche mit moderner facettierter Navigation im modalen Filterpanel, mit der…99,99 €Produkt ansehen