Warum die PrestaShop-Suche langsamer wird, wenn der Katalog wächst

Das Symptom

Mit einem Demo-Katalog von zwanzig oder dreißig Produkten funktioniert die PrestaShop-Suche immer gut: Egal, welche Konfiguration man wählt, die Seite antwortet in einem Bruchteil einer Sekunde. Das Problem tritt erst auf, wenn der Katalog wirklich groß wird, und dann ist es zu spät, um es rechtzeitig zu bemerken: Ein Shop mit 50.000, 100.000 oder 200.000 Produkten kann plötzlich eine Suchergebnisseite haben, die mehrere Sekunden zum Antworten braucht, oder eine gefilterte Kategorieseite, die zur langsamsten der ganzen Website wird.

Das ist kein subjektiver Eindruck. Auf einem synthetischen Katalog mit 200.000 Produkten brauchte mit der nativen PrestaShop-Suchmaschine (der, die in der Datenbank des Shops läuft, ohne externe Engine) eine Suchergebnisseite 28 Sekunden und eine große Kategorieseite 30 Sekunden, bevor gezielt optimiert wurde. Danach antwortet dieselbe Seite in 2 bis 6 Sekunden. Es sind immer noch Sekunden, keine Millisekunden: Warum das so ist, ist das eigentliche Thema dieses Artikels.

Warum die Zeit schneller wächst als der Katalog

Die häufigste Ursache ist nicht „die Datenbank ist langsam“, sondern dass dieselbe Arbeit innerhalb einer einzigen Anfrage mehrfach erledigt wird. Eine Suchmaschine mit Facetten muss auf jeder Seite zwei verschiedene Fragen beantworten: welche Produkte angezeigt werden und, für jeden verfügbaren Filter, wie viele Produkte übrig blieben, wenn der Besucher ihn auswählte. Wird die Menge der zur aktuellen Suche passenden Produkte für jeden Filter von Grund auf neu berechnet, statt einmal berechnet und wiederverwendet zu werden, ist der Aufwand nicht mehr proportional zur Zahl der Produkte, sondern proportional zur Zahl der Produkte multipliziert mit der Zahl der Filter. Bei einem kleinen Katalog fällt der Unterschied nicht auf. Bei 200.000 Produkten und Dutzenden aktiver Filter kann eine Suche, die theoretisch nur fünf Produkte betrifft, am Ende den gesamten Katalog etwa zehnmal durchlaufen.

Ähnlich verhält es sich bei kleineren Aufgaben, die sehr oft wiederholt werden: Wird der Preis jedes Produkts einer Kategorieseite einzeln bei der Datenbank abgefragt, statt gebündelt abgerufen zu werden, können aus hundert Produkten pro Seite bei einem großen Katalog mit Preisregeln pro Gruppe oder Menge leicht hunderttausend Abfragen werden. Keine dieser Abfragen ist für sich genommen langsam. Unerträglich wird ihre Anzahl.

Die versteckten Kosten der Zahlen neben den Filtern

Es gibt einen zweiten, vom ersten unabhängigen Kostenpunkt: die Anzeige, wie viele Produkte zu jedem Wert eines Filters passen, das klassische „Rot (12)“ neben einem Kontrollkästchen. Mit einer externen Suchmaschine (Elasticsearch, OpenSearch, Meilisearch) kostet diese Zahl nichts: Sie kommt mit derselben Abfrage, die auch die Ergebnisse berechnet. Mit der nativen Engine, die in der Datenbank des Shops arbeitet, kann jeder Wert jedes Filters eine eigene Zählabfrage erfordern.

Auf einem Katalog mit 200.000 Produkten und rund 2.250 Gruppen von Attributen und Merkmalen ließ die Deaktivierung der exakten Filterzählung (Anzeige der Wertliste ohne die Zahl daneben) eine Kategorieseite mit einem aktiven Filter von 43,3 Sekunden auf 11,9 Sekunden sinken. Allein bei den Facetten für Merkmale und Attribute sank die Zeit von 6,8 bzw. 5,4 Sekunden auf 15 bzw. 19 Millisekunden. Das ist keine Rundung: Es ist der Unterschied zwischen einer Abfrage, die die Zeilen in der Datenbank einzeln zählen muss, und einer Abfrage, die sich darauf beschränkt, eine Liste verschiedener Werte bis zu einer bestimmten Grenze zu lesen, ohne alle zu zählen.

Für den Händler ist die praktische Frage einfach: Ist die Zahl in Klammern ihren Preis wert? Bei einem Katalog mit einigen tausend Produkten mit ziemlicher Sicherheit ja. Bei einem Katalog mit Hunderttausenden Produkten und vielen Merkmalen kann sie der teuerste Posten der ganzen Seite sein, und sie abzuschalten erfordert oft nur ein Kontrollkästchen in der Konfiguration, keine Neuprogrammierung.

Was ein echter Test auf einem Katalog dieser Größe zeigt

Auf einem synthetischen Katalog mit 200.321 Produkten ergab ein interner Test der vollständigen Suchseite (Berechnung der Ergebnisse und aller Facetten) Antwortzeiten zwischen 2,2 und 2,4 Sekunden. Das passt zu der oben genannten Spanne von 2 bis 6 Sekunden, die auf einer anderen Installation gemessen wurde: zwei unabhängige Messungen, die dasselbe erzählen. Ein Katalog dieser Größe antwortet in einer Zeit, die in Sekunden zählt, nicht in Zehntelsekunden, selbst nach guter Optimierung. Wer für einen Katalog dieser Größe allein mit der nativen Datenbank-Engine das Gegenteil verspricht, misst wahrscheinlich an einem kleineren Katalog, als er angibt.

Was Sie prüfen sollten, bevor Sie es im Livebetrieb entdecken

• Machen Sie mindestens einen Test mit einer Produktmenge nahe an der realen Menge, nicht mit dem Demo-Katalog. Dieses Problem ist unterhalb von zehntausend Zeilen unsichtbar und oberhalb sehr deutlich.
• Prüfen Sie das PHP-Speicherlimit Ihres Hostings. Viele Shared-Hosting-Angebote bleiben bei 128 oder 256 MB: Vorgänge, die Datenbankzeilen in den Speicher laden, statt die Datenbank zählen zu lassen, können es bei großen Katalogen mit vielen per CSV importierten Merkmalen oder Attributen überschreiten.
• Wenn Sie bei einem großen Katalog die native Engine verwenden, prüfen Sie, ob sich die exakte Filterzählung deaktivieren lässt oder ob der Wechsel zu einer externen Engine (Elasticsearch, OpenSearch oder Meilisearch) sinnvoller ist, die sie als Nebenprodukt derselben Abfrage berechnet.
• Egal, welches Suchmodul Sie prüfen: Fragen Sie, ob sein Aufwand wirklich an einem großen Katalog gemessen wurde, mit einer Zahl. „Schnell“ ohne eine Zahl daneben sagt nicht viel.

Zusammenfassung

Die PrestaShop-Suche wird nicht wegen eines rätselhaften Fehlers langsamer: Sie wird langsamer, weil dieselbe Arbeit öfter wiederholt wird als nötig, und das wird erst sichtbar, wenn der Katalog groß genug ist, um es offenzulegen. Die beiden am leichtesten zu kontrollierenden Stellschrauben sind, ob dieselbe Ergebnismenge von einem Filter zum nächsten wiederverwendet wird und ob die Zahlen neben den Filtern sparsam oder aufwendig berechnet werden. Wir haben Monate damit verbracht, genau diese Art von Problem in cll_essearch zu messen und zu beheben, unserem Modul für Suche und facettierte Navigation für PrestaShop, das sowohl mit der nativen Engine als auch mit Elasticsearch, OpenSearch und Meilisearch funktioniert: Wenn Sie in Ihrem Shop die hier beschriebenen Symptome wiedererkennen, ist es genau für diese Art von Problem entwickelt worden.

Elasticsearch Suche und Facettierte NavigationBlitzschnelle, tippfehlertolerante Suche mit moderner facettierter Navigation im modalen Filterpanel, mit der…99,99 €Produkt ansehen