Dlaczego realizacja zamówienia w PrestaShop zwalnia przy zewnętrznej wyszukiwarce

Efekt uboczny, którego się nie spodziewamy

Elasticsearch, OpenSearch lub Meilisearch instaluje się w PrestaShop prawie zawsze z jednego powodu: natywna wyszukiwarka nie wyrabia w dużym katalogu. I wyszukiwanie faktycznie się poprawia. Rzadziej sprawdza się natomiast, co dzieje się z resztą sklepu, zwłaszcza z koszykiem i realizacją zamówienia, gdy ten zewnętrzny indeks musi pozostawać zsynchronizowany ze stanem magazynowym i dostępnością, które zmieniają się przy każdej sprzedaży.

Ta część często pozostaje niezauważona z prostego powodu: w wersji demonstracyjnej, z garstką zamówień, nic nie widać. Problem pojawia się pod rzeczywistym obciążeniem, gdy kilka zamówień napływa jednocześnie, a wtedy klient już płaci. To nie jest miejsce, w którym chcielibyśmy odkryć wąskie gardło.

Co powinno się dziać, gdy klient zmienia ilość w koszyku

Przy zewnętrznej wyszukiwarce każdy produkt istnieje podwójnie: jako wiersz w bazie danych PrestaShop oraz jako „dokument” w indeksie wyszukiwarki, zawierający pola potrzebne do jego znalezienia i filtrowania (nazwa, cena, kategorie, dostępność itd.). Gdy klient dodaje produkt do koszyka, zmienia ilość albo zamówienie zostaje potwierdzone, zmienia się dostępność tego produktu, a dokument w indeksie musi to uwzględnić, w przeciwnym razie inny klient mógłby zobaczyć jako dostępny produkt, który właśnie się wyprzedał.

Najprostszy sposób, a zarazem najkosztowniejszy, polega na każdorazowej przebudowie całego dokumentu: ponownym odczytaniu z bazy nazwy, opisu, ceny, kategorii, zdjęć i całej reszty, aby zaktualizować trzy liczby (ilość, dostępność, kolejność sortowania według dostępności). Jeśli ta przebudowa uruchamia się raz na każdą pozycję zamówienia, zamówienie z pięcioma różnymi produktami uruchamia ją pięć razy, dokładnie wtedy, gdy klient czeka na potwierdzenie płatności.

Prawdziwe liczby

W pomiarze na PrestaShop 9.0.0, z dwoma sklepami połączonymi z Elasticsearch, zamówienie z pięcioma pozycjami, które przebudowywało pełny dokument dla każdej pozycji, kosztowało 243 zapytania SQL i 229 milisekund, wyłącznie po to, by przenieść trzy liczby w indeksie wyszukiwania. To nie jest czas całej realizacji zamówienia, lecz czas jednego etapu wewnątrz niej, tego, który utrzymuje synchronizację indeksu.

Przy dedykowanej ścieżce, która aktualizuje tylko pola faktycznie zmienione (ilość, dostępność, kolejność według dostępności) zamiast przebudowywać cały dokument, to samo zamówienie w tych samych sklepach spadło do 9 zapytań i 16 do 47 milisekund. Ta sama operacja, ten sam końcowy wynik w indeksie: zmienia się tylko ilość pracy potrzebnej, by do niego dojść.

Różnicę techniczną łatwo wyjaśnić nawet komuś, kto nie pisze kodu: zewnętrzna wyszukiwarka zwykle oferuje dwa sposoby aktualizacji dokumentu. Pierwszy, „zastąpić go w całości”, służy wtedy, gdy naprawdę zmienia się coś strukturalnego, jak nazwa lub cena. Drugi, „zaktualizować tylko te pola”, jest przewidziany na znacznie częstszy przypadek, gdy zmienia się wyłącznie dostępność. Stosowanie zawsze pierwszego, nawet gdy wystarczyłby drugi, jest najczęstszą przyczyną zwalniania realizacji zamówienia właśnie wtedy, gdy sklep sprzedaje więcej.

Dlaczego dzieje się to prawie zawsze w tym samym miejscu

W PrestaShop zdarzenie sygnalizujące zmianę ilości podczas zamówienia może się uruchomić raz na każdą pozycję zamówienia, a nie raz dla całego zamówienia. Łatwo napisać kod nasłuchujący to zdarzenie, myśląc „to tylko aktualizacja”, i nie zauważyć, że przy zamówieniu z wieloma pozycjami albo w szczycie sprzedaży, z wieloma równoczesnymi zamówieniami, ten prosty wybór mnoży się przez liczbę pozycji i przez liczbę zamówień realizowanych w tej samej chwili. Moduł wyszukiwarki, który w teście z jednym zamówieniem naraz wydaje się szybki, może zachowywać się zupełnie inaczej podczas Black Friday, przy setkach równoczesnych realizacji zamówień.

O co należy zapytać, jeśli mają już Państwo zewnętrzną wyszukiwarkę

• Proszę zapytać dostawcę modułu wyszukiwarki lub integratora, czy zmiana ilości w koszyku aktualizuje wyłącznie pola magazynowe, czy przebudowuje cały dokument produktu.
• Proszę wykonać test z zamówieniem o kilku pozycjach w spokojnym momencie i obserwować dziennik wolnych zapytań bazy danych podczas realizacji zamówienia: jeśli widać dziesiątki zapytań powtarzanych dla tego samego produktu, jest to dokładnie ten objaw.
• Jeśli prowadzą Państwo sklep B2B lub hurtowy z koszykami o wielu pozycjach, ten problem narasta niekorzystnie: koszyk z trzydziestoma pozycjami przy pełnej przebudowie dla każdej pozycji jest sześć razy wolniejszy niż koszyk z pięcioma, podczas gdy przy ukierunkowanej aktualizacji różnica jest znacznie mniejsza.
• To nie jest powód, by rezygnować z zewnętrznej wyszukiwarki: duży katalog zawsze jej potrzebuje do wyszukiwania. To powód, by sprawdzić, jak naprawdę została napisana integracja między koszykiem a indeksem.

Podsumowanie

Zewnętrzna wyszukiwarka sama w sobie nie spowalnia realizacji zamówienia. Spowalnia ją integracja, która przebudowuje cały dokument wyszukiwania przy zmianie dotyczącej tylko trzech liczb. Zmierzona różnica, od 243 zapytań i 229 milisekund do 9 zapytań i 16 do 47 milisekund dla tego samego zamówienia, odpowiada pracy, którą wykonaliśmy w cll_essearch, oddzielając aktualizacje stanów magazynowych od aktualizacji strukturalnych w Elasticsearch, OpenSearch i Meilisearch. Jeśli Państwa sklep korzysta z zewnętrznej wyszukiwarki, a realizacja zamówienia zwalnia właśnie wtedy, gdy sprzedaż rusza, jest to pierwsza rzecz do sprawdzenia.

Wyszukiwarka Elasticsearch i nawigacja fasetowaBłyskawiczne wyszukiwanie z tolerancją literówek i nowoczesna nawigacja fasetowa we wbudowanym silniku lub w o…99,99 €Zobacz produkt