Boty i wyszukiwanie fasetowe w PrestaShop: CPU 100 % i awarie

Sobotnie popołudnie. Przychodzi e-mail od firmy hostingowej z ostrzeżeniem, że Twoje konto od kilku godzin pracuje na 100 % CPU. Otwierasz statystyki, spodziewając się tłumu klientów, i widzisz coś odwrotnego: czterdzieści tysięcy odsłon i zero zamówień.

To nie atak, nie zepsuty moduł i nie dziwne zachowanie Twojego sklepu. Ktoś zaczął przechodzić przez każdy filtr w Twoim katalogu, jeden po drugim.

Co się właściwie dzieje?

Twój sklep ma wyszukiwanie fasetowe: rozmiar, kolor, marka, cena, dostępność, a do tego sortowanie. To dzięki niemu wygodnie się z niego korzysta.

Problem w tym, że każda kombinacja tych filtrów to inny adres internetowy. Rozmiar M w kolorze niebieskim jednej marki sortowany po cenie to jeden adres. Rozmiar M w kolorze niebieskim tej marki sortowany od najnowszych to drugi. I tak dalej, przez wszystkie możliwe kombinacje: w średnim sklepie to setki tysięcy, w dużym — miliony.

Roboty sieci społecznościowych i usług AI — Facebooka, TikToka, kilku firm, o których nigdy nie słyszałeś — uznały, że muszą zobaczyć je wszystkie. I proszą o wszystkie naraz, bez przerwy.

Żaden z tych adresów nie jest stroną, którą masz zapisaną: każdy to nowe wyszukiwanie w Twojej bazie danych.

Moduł, który za tym stoi: wyszukiwanie fasetowe PrestaShop

Filtry w Twoim sklepie rysuje jeden konkretny moduł, Wyszukiwanie fasetowe (ps_facetedsearch), dostarczany z PrestaShop od wersji 1.7, który zastąpił dawną nawigację warstwową. Jeśli masz filtry na stronach kategorii, masz go włączonego.

Łatwo go wypatrzyć w logach: każda kombinacja jedzie w parametrze q adresu i wygląda tak.

/12-tshirts?q=Size-M/Colour-Blue/Brand-Adidas

Jeśli w logu dostępu masz tysiące linii z ?q=, wszystkie różne i jedna po drugiej, wiesz, co zjada maszynę.

I oto dlaczego jest to tak kosztowne. Kiedy przychodzi takie zapytanie, moduł nie tylko szuka produktów pasujących do filtra: przelicza też liczniki wszystkich pozostałych filtrów — te „Niebieski (12)”, „Zielony (5)” obok każdego pola — a żeby to zrobić, wysyła kilka zapytań liczących do swoich tabel indeksu. Pomnóż to przez duży katalog i tysiące zapytań na minutę.

Dwie dźwignie, które są w samym module i których prawie nikt nie rusza, w Moduły → Menedżer modułów → Nawigacja fasetowa:

• Wyłącz liczbę produktów obok każdego filtra. To najdroższa część każdego zapytania i w większości sklepów nikt za nią nie tęskni.
• Przejrzyj szablony filtrów dla każdej kategorii. Każdy filtr, który zostawiasz, mnoży możliwe kombinacje. Osiem filtrów w kategorii to nie osiem adresów, tylko tysiące.

Żadna z nich sama nie rozwiązuje problemu, ale obie obniżają koszt każdego wejścia, zanim ruszysz cokolwiek innego.

Dlaczego to tak boli?

Wyszukiwanie z filtrami to jedna z najdroższych rzeczy, jakie robi sklep: musi przejść przez cały katalog, zestawić atrybuty, policzyć, ile produktów zostaje pod każdym filtrem, i posortować wynik. Klient robi trzy czy cztery takie wyszukiwania w ciągu całej wizyty. Robot — trzy czy cztery na sekundę.

A oto część, która wszystkich zbija z tropu: pamięć podręczna Cię nie uratuje. Pamięć podręczna pomaga, kiedy wielu odwiedzających prosi o to samo. Tu nic się nie powtarza: każda kombinacja jest unikalna, więc wszystkie są „pierwszymi wizytami” i wszystkie trafiają do bazy danych.

Efekt jest zawsze ten sam. Zapytania się piętrzą, serwerowi kończy się miejsce, a sklep przestaje odpowiadać — robotowi i klientowi, który właśnie miał zapłacić. Jeśli trafi to w środek kampanii, zapłaciłeś za reklamy prowadzące na stronę, która się nie otwierała.

Jak sprawdzić, czy to Twój przypadek?

Cztery objawy — dowolne dwa naraz to niemal pewność:

• Duże obciążenie bez sprzedaży. Ogromna liczba odsłon, zero koszyków. Wizyty i zamówienia się nie zgadzają, nawet w przybliżeniu.
• Hosting Cię ostrzega, że zużywasz za dużo, albo na jakiś czas zawiesza konto „dla ochrony innych klientów”.
• Sklep pada o dziwnych porach: w nocy, w niedzielę, losowymi seriami, bez żadnego handlowego wzoru.
• Log dostępu pokazuje tysiące kolejnych adresów z parametrami filtrów, wszystkie różne, wywołane w ciągu kilku sekund.

Jeśli w tym czasie panel administracyjny działa wolno, masz potwierdzenie: to nie część publiczna, maszyna jest przeciążona. Pisaliśmy o tym w tekście kiedy winny jest sklep, a kiedy serwer.

Co Ci doradzą i dlaczego to nie wystarcza?

Ten problem przyciąga mnóstwo popularnych rozwiązań, które w praktyce się nie sprawdzają:

1. „Zablokuj je w robots.txt”. Ten plik to uprzejma prośba, a nie drzwi. Roboty, które go szanują, nie są Twoim problemem; te, które Cię kładą, go nie czytają. A jeśli przesadzisz, posłucha Google i sam usuniesz się z wyników.
2. „Zablokuj Facebooka i TikToka po nazwie”. Działa przez tydzień. Zmieniają tożsamość, wchodzą z tysięcy różnych adresów, a co miesiąc pojawiają się trzy nowe. To lista, której nigdy nie skończysz.
3. „Po prostu oznacz je jako noindex”. Strona ze znacznikiem noindex nadal Cię kosztuje: robot musi o nią poprosić, żeby w ogóle przeczytać ten znacznik. Pomaga to wyszukiwarce, a nie Twojemu procesorowi.
4. „Weź większy serwer”. Płacenie dwa razy więcej, żeby za darmo serwować robotowi Twój katalog, to zły interes: następny szczyt będzie większy, bo im lepiej odpowiadasz, tym szybciej proszą.
5. „Wyłącz wyszukiwanie fasetowe”. Naprawia obciążenie i psuje sklep: filtry to sposób, w jaki ludzie znajdują to, co kupią. Następnego dnia widać to w konwersji.
6. „Postaw przed sklepem CDN i po sprawie”. CDN przyspiesza to, co się powtarza. Tu nic się nie powtarza: każda kombinacja jest unikalna i i tak trafia do Twojej bazy danych.
7. „Włącz tryb ochrony przed atakiem”. Albo utrudniasz życie klientom i Google, albo roboty dalej przechodzą. To pozwala przetrwać popołudnie, ale nie da się tak żyć.

Wszystkie mają tę samą wadę: leczą objaw, czyli ruch, a nie przyczynę, czyli to, że Twój sklep jest gotów wyprodukować miliony różnych stron dla każdego, kto poprosi.

Gdzie leży prawdziwe rozwiązanie?

To, co naprawdę działa, buduje się w trzech warstwach i żadna z nich nie polega na wyłączaniu filtrów:

• Zdecyduj, które kombinacje istnieją. Ze wszystkich, które Twój sklep mógłby wygenerować, tylko garść ma sens dla klienta albo dla Google. Reszta nie potrzebuje własnych adresów, a odebranie im ich zmniejsza boisko z milionów do kilku tysięcy.
• Nie dopuszczaj drogich zapytań na sam dół. Zapytania, które są szumem, dostają odpowiedź, zanim dotkną bazy danych, i jest limit tego, ile wyszukiwań na minutę może wysłać jedno źródło. Klient robi trzy; kto robi trzysta, nie jest klientem, jakkolwiek by się nazywał.
• Rozdziel tych, którzy walczą o zasoby. Przeszukiwanie przez roboty nigdy nie powinno walczyć o ten sam procesor co czyjeś zamówienie. Jeśli zbudujesz to dobrze, robot może poczekać; klient nie.

Dzięki temu obciążenie zwykle mocno spada już pierwszego dnia, a sklep przestaje padać — bez ruszania ani jednego filtra z punktu widzenia klientów i bez utraty pozycji w Google. Wręcz przeciwnie: kiedy przestajesz zużywać czas Google na czterysta tysięcy powtórzonych stron, zaczyna on patrzeć na te, które są dla Ciebie ważne — dokładnie o tym pisaliśmy w tekście od czego zacząć, gdy nie ma Cię w Google.

Walczysz z tym od miesięcy?

To paskudny problem, bo nigdy nie pokazuje twarzy: nie ma błędu, na który można spojrzeć, jest tylko sklep, który jednego dnia działa, a drugiego nie, i hosting, który mówi, że to Twoja wina.

Wszystko to — decyzja, które kombinacje istnieją, odpowiedź przed bazą danych i trzymanie robotów z dala od zamówień — jest wbudowane w moduł Ochrona przed botami dla PrestaShop: instalujesz go, chroni od pierwszej minuty bez ruszania ani jednego filtra z punktu widzenia klientów, wpuszcza zweryfikowane Google, a następnego dnia jego panel pokazuje, ile zapytań zostało przed drzwiami i kto je wysyłał. Jak ustawić limity na adres i na sieć, nie blokując Google, opisujemy w tekście ograniczanie liczby zapytań na IP w PrestaShop.

A jeśli nie masz pewności, czy to Twój przypadek, wyślij nam log dostępu ze złego dnia przez formularz kontaktowy: za darmo powiemy Ci, ile z tych zapytań to ludzie, a ile szum.