--- title: "PrestaShop i 500 tys. produktów: jak przyspieszyć sklep z dużym katalogiem" description: "Dlaczego PrestaShop zwalnia i pada przy setkach tysięcy produktów, jak Elasticsearch przyspiesza wyszukiwarkę i filtry oraz co jeszcze zoptymalizować." url: https://stronny.pl/blog/prestashop-duzy-katalog-elasticsearch/ updated: 2026-10-15 --- # PrestaShop i 500 tys. produktów: jak przyspieszyć sklep z dużym katalogiem Dlaczego PrestaShop zwalnia i pada przy setkach tysięcy produktów, jak Elasticsearch przyspiesza wyszukiwarkę i filtry oraz co jeszcze zoptymalizować. Sklep z kilkoma tysiącami produktów działa na PrestaShop bez specjalnych zabiegów. Przy dziesiątkach i setkach tysięcy pozycji, np. 500 tys. produktów z plików hurtowni, sytuacja się zmienia: strony kategorii ładują się coraz dłużej, wyszukiwarka odpowiada po kilku sekundach, a przy większym ruchu sklep potrafi przestać odpowiadać. Opisujemy, skąd biorą się te problemy, jak rozwiązaliśmy je w sklepie, który regularnie padał, i co sprawdzić we własnym sklepie, zanim zamówisz mocniejszy serwer. ## Dlaczego duży katalog spowalnia PrestaShop PrestaShop trzyma wszystko w jednej bazie MySQL: produkty, ceny, stany, cechy, koszyki, zamówienia i statystyki odwiedzin. Przy małym katalogu baza radzi sobie ze wszystkim naraz. Przy setkach tysięcy produktów kilka miejsc zaczyna ją przeciążać. ### Wyszukiwarka Standardowa wyszukiwarka PrestaShop korzysta z własnego indeksu słów zapisanego w tabelach bazy danych (search_word i search_index). Przy dużym katalogu te tabele mają miliony wierszy, a każde wyszukiwanie klienta to złączenie dużych tabel. Jeśli w ustawieniach wyszukiwania włączone jest szukanie wewnątrz słów, baza nie może skorzystać z indeksu i przegląda cały słownik. Do tego przebudowa indeksu wyszukiwania dla całego katalogu trwa długo i sama mocno obciąża serwer. ### Filtry w kategoriach Filtry, czyli wybór rozmiaru, koloru, marki czy przedziału cen, obsługuje zwykle standardowy moduł ps_facetedsearch. Przy każdym widoku kategorii moduł liczy, ile produktów pasuje do każdej wartości każdego filtra, z uwzględnieniem filtrów już zaznaczonych. To wiele zapytań SQL łączących produkty, kategorie, atrybuty, cechy i ceny. Moduł zapamiętuje część wyników, ale w dużym katalogu możliwych kombinacji filtrów jest tak dużo, że większość wejść i tak trafia do bazy. ### Roboty, które chodzą po filtrach Każda kombinacja filtrów ma własny adres, w PrestaShop zwykle z parametrem ?q=. Dla robotów wyszukiwarek, narzędzi SEO i botów AI to praktycznie nieskończona liczba stron do odwiedzenia, a każda z nich jest liczona od zera. Kilka botów przechodzących przez filtry potrafi obciążyć sklep mocniej niż prawdziwi klienci. W logach serwera widać to jako tysiące wejść na adresy kategorii z długimi parametrami filtrów. ### Importy, ceny i statystyki - **Aktualizacje z hurtowni.** Duże katalogi zwykle zasilają pliki XML lub CSV od dostawców. Każda aktualizacja cen i stanów to zapisy w bazie i przeliczenia indeksów wyszukiwarki i filtrów. Przy setkach tysięcy pozycji aktualizowanych kilka razy dziennie baza ma coraz mniej czasu na obsługę klientów. - **Ceny specyficzne i reguły cenowe.** Reguły cen katalogowych i rabaty dla grup klientów zapisują się jako osobne wiersze dla produktów. Przy dużym katalogu tabela cen specyficznych szybko rośnie, a PrestaShop sprawdza ją przy liczeniu ceny każdego produktu na liście. - **Statystyki odwiedzin.** Moduł zbierania danych do statystyk zapisuje w bazie odwiedziny, także botów. Tabele takie jak connections i guest potrafią mieć miliony wierszy. Jeśli korzystasz z Google Analytics, wbudowane statystyki często można wyłączyć albo regularnie czyścić. ## Dlaczego wolny sklep w końcu pada Spowolnienie i awaria to często ten sam problem na różnych etapach. Serwer obsługuje jednocześnie tylko określoną liczbę procesów PHP i połączeń z bazą. Gdy strona kategorii z filtrami liczy się kilka sekund zamiast ułamka sekundy, każde wejście dłużej zajmuje proces i połączenie. Przy większym ruchu, kampanii albo wizycie kilku botów kolejka rośnie szybciej, niż serwer ją obsługuje. Wtedy klienci widzą błędy 502, 503 lub 504 i sklep „pada”, choć żadna pojedyncza funkcja nie jest zepsuta. Dlatego samo dokładanie procesorów i pamięci daje zwykle krótką ulgę. Gdy katalog i ruch dalej rosną, problem wraca, bo jego źródłem jest sposób, w jaki sklep szuka i filtruje produkty. ## Nasz przypadek: sklep z dużym katalogiem, który padał Trafił do nas sklep na PrestaShop z bardzo dużym katalogiem. Działał wolno i co jakiś czas przestawał odpowiadać. Rozwiązanie składało się z trzech części: - **Wyszukiwarka oparta na Elasticsearch.** Moduł, który zamiast tabel w MySQL odpytuje osobny indeks produktów w Elasticsearch. - **Filtry oparte na Elasticsearch.** Moduł filtrów, w którym listę produktów w kategorii i liczby przy wartościach filtrów liczy Elasticsearch, a nie baza sklepu. - **Optymalizacja sklepu i serwera.** Porządki w konfiguracji, modułach i bazie danych. Typowy zakres takiej optymalizacji opisujemy niżej. Po wdrożeniu sklep przestał padać i działa sprawnie mimo dużego katalogu. MySQL obsługuje głównie koszyki, zamówienia i dane klientów, a przeglądanie katalogu i wyszukiwanie trafia do Elasticsearch. ## Czym jest Elasticsearch i dlaczego pomaga Elasticsearch to silnik wyszukiwania działający jako osobna usługa obok sklepu. Moduł PrestaShop przesyła do niego dane produktów: nazwy, opisy, kategorie, cechy, warianty, ceny i stany. Elasticsearch przechowuje je w indeksie zbudowanym pod szybkie wyszukiwanie i filtrowanie. Zadanie Standardowy PrestaShop Z Elasticsearch Wyszukiwanie produktów Indeks słów w tabelach MySQL, dopasowanie słów Osobny indeks pełnotekstowy, wyniki według trafności Liczby przy filtrach Wiele zapytań SQL przy każdym widoku kategorii Agregacje liczone w tym samym zapytaniu co lista produktów Obciążenie bazy przy przeglądaniu katalogu Każde wejście w kategorię lub wyszukiwarkę odpytuje MySQL MySQL obsługuje głównie koszyk, zamówienia i klientów Infrastruktura Tylko serwer sklepu Dodatkowa usługa Elasticsearch na serwerze lub w chmurze Poza szybkością Elasticsearch poprawia też jakość wyników. W zależności od modułu i konfiguracji może tolerować literówki, obsługiwać synonimy, a z dodatkiem do analizy języka polskiego rozpoznawać odmiany słów, np. „kurtka”, „kurtki” i „kurtek”. Klient częściej znajduje produkt za pierwszym razem. ## Na co uważać przy wdrożeniu Elasticsearch w PrestaShop - **Serwer.** Elasticsearch to osobna usługa w Javie, która potrzebuje własnej pamięci RAM. Na typowym hostingu współdzielonym zwykle nie da się go uruchomić. Potrzebny jest serwer VPS lub dedykowany albo usługa w chmurze, np. Elastic Cloud. Część modułów obsługuje też OpenSearch, otwartoźródłową odmianę Elasticsearch. - **Zgodność modułu.** Sprawdź, czy moduł obsługuje Twoją wersję PrestaShop, PHP i Elasticsearch, czy jest aktualizowany i czy współpracuje z Twoim motywem. Filtry są częścią szablonu kategorii, więc przy nietypowym motywie trzeba liczyć się z dopasowaniem wyglądu. - **Synchronizacja danych.** Indeks musi nadążać za zmianami cen i stanów. Ustal, jak moduł go aktualizuje: przy zapisie produktu, z kolejki czy zadaniem cron. Przy importach z hurtowni najlepiej sprawdza się aktualizacja tylko zmienionych produktów zamiast przebudowy całego indeksu. - **Porządek w cechach.** Przed indeksowaniem warto ujednolicić cechy produktów. Jeśli ten sam kolor jest zapisany jako „czarny”, „Czarny” i „czarna”, filtr pokaże trzy osobne wartości niezależnie od silnika. - **Bezpieczeństwo.** Elasticsearch nie może być dostępny z internetu. Port usługi powinien być otwarty tylko dla serwera sklepu, a dostęp chroniony hasłem. - **Plan na awarię.** Sprawdź, co się stanie, gdy Elasticsearch będzie niedostępny. Najlepiej, żeby sklep wracał wtedy do standardowej wyszukiwarki albo pokazywał komunikat, zamiast zwracać błąd na stronach kategorii. ## Co jeszcze obejmuje optymalizacja dużego sklepu Elasticsearch rozwiązuje problem wyszukiwania i filtrów, ale nie przyspieszy karty produktu, koszyka ani panelu administracyjnego. Dlatego przy dużych katalogach sprawdzamy także: - **Serwer i bazę danych.** Wersję PHP obsługiwaną przez Twoją wersję PrestaShop, włączony OPcache, liczbę procesów PHP dopasowaną do pamięci serwera i konfigurację MySQL lub MariaDB, w której indeksy najważniejszych tabel mieszczą się w pamięci. - **Wolne zapytania.** Log wolnych zapytań MySQL pokazuje, które strony i moduły najbardziej obciążają bazę. Często winny jest pojedynczy moduł, któremu brakuje indeksu w tabeli. - **Moduły i hooki.** Moduł podpięty pod listę produktów albo nagłówek strony wykonuje się przy każdym wejściu. Nieużywane moduły warto odinstalować, a ciężkie zastąpić lżejszymi. - **Cache.** Ustawienia wydajności PrestaShop (cache szablonów Smarty, łączenie i kompresja CSS i JS), cache obiektów w pamięci, np. Memcached, a przy dużym ruchu gości także cache całych stron. Koszyk i proces zamówienia nie mogą być cachowane. - **Ruch botów.** Reguły w robots.txt, które zatrzymują roboty przed niekończącymi się kombinacjami filtrów, oraz limit zapytań dla agresywnych botów na serwerze lub w CDN. Jeśli niektóre zestawy filtrów mają przynosić ruch z Google, lepiej przygotować dla nich osobne, stałe kategorie. - **Porządki w bazie.** Czyszczenie statystyk odwiedzin, porzuconych koszyków gości i starych logów, które latami rosną w tle. Przed każdą taką operacją potrzebna jest kopia bazy. - **Zdjęcia.** Setki tysięcy produktów to nawet kilka milionów plików miniatur. Warto ograniczyć liczbę rozmiarów zdjęć do tych, których motyw naprawdę używa, i nie generować ich od nowa na produkcji w godzinach ruchu. - **Importy.** Aktualizacje z hurtowni w mniejszych paczkach, poza godzinami największego ruchu i tylko dla produktów, które faktycznie się zmieniły. Na koniec mierzymy szybkość najważniejszych widoków, czyli strony głównej, kategorii i karty produktu. O tym, jak czytać wyniki PageSpeed Insights i Core Web Vitals, pisaliśmy w artykule o [szybkości strony i sklepu](/blog/szybkosc-strony-sklepu-pagespeed/). ## Kiedy warto rozważyć Elasticsearch Nie ma jednej liczby produktów, od której Elasticsearch jest konieczny. Sklep z kilkoma tysiącami produktów na dobrym serwerze zwykle dobrze działa ze standardową wyszukiwarką i filtrami. Warto go rozważyć, gdy: - katalog liczy dziesiątki lub setki tysięcy produktów, szczególnie z wieloma wariantami i cechami, - strony kategorii z zaznaczonymi filtrami ładują się wyraźnie wolniej niż bez filtrów, - wyszukiwarka odpowiada po kilku sekundach albo nie znajduje produktów przy odmienionych słowach i literówkach, - sklep zwalnia lub pada przy większym ruchu, kampaniach albo wizytach botów, - przebudowa indeksu wyszukiwania lub filtrów trwa godzinami. Zanim zdecydujesz, zmierz, gdzie naprawdę jest problem. Na kopii testowej sklepu włącz tryb profilowania PrestaShop (stała _PS_DEBUG_PROFILING_ w pliku config/defines.inc.php), który pokazuje czas zapytań SQL i działania modułów. Do tego log wolnych zapytań MySQL i logi serwera z adresami, które generują najwięcej ruchu. Te trzy źródła zwykle wystarczą, żeby odróżnić problem z katalogiem od problemu z hostingiem albo pojedynczym modułem. ## Podsumowanie PrestaShop poradzi sobie z katalogiem liczonym w setkach tysięcy produktów, ale nie w domyślnej konfiguracji. Najwięcej pracy wykonują wyszukiwarka i filtry, które standardowo liczą wszystko w bazie MySQL. W sklepie z naszego przykładu przeniesienie ich do Elasticsearch razem z optymalizacją sklepu sprawiło, że sklep przestał padać i działa sprawnie. Jeśli Twój sklep zwalnia wraz z rozwojem katalogu, w ramach [opieki technicznej](/oferta/opieka-techniczna/) sprawdzimy, co go obciąża, i zaproponujemy rozwiązanie. Planujesz nowy sklep z dużym katalogiem? Zobacz, jak wygląda [projekt i wdrożenie sklepu PrestaShop](/oferta/sklepy-prestashop/), albo [opisz swój projekt](/kontakt/).