Od 10 do 1000 zamówień miesięcznie: skalowanie sklepu PrestaShop

Dziesięć zamówień miesięcznie to hobby. Sto to dodatkowy biznes. Tysiąc to prawdziwa firma. Pułapka polega na tym, że droga między nimi wydaje się łagodnym podjazdem. Nie jest. Wzrost na PrestaShop przychodzi etapami, a na każdym etapie coś, co jeszcze wczoraj działało dobrze, po cichu przestaje wystarczać — hosting współdzielony, który radził sobie z 30 zamówieniami, dławi się przy 300, ręczne aktualizacje statusów, które zajmowały dziesięć minut, pochłaniają teraz cały poranek, a tabela ps_cart, wcześniej pomijalna, staje się najwolniejszym zapytaniem w sklepie. Ten poradnik pokazuje, co konkretnie psuje się na każdym poziomie wolumenu w PrestaShop i co zmienić w panelu administracyjnym, zanim zacznie się problem, a nie dopiero po fakcie.

Ostatnia aktualizacja: czerwiec 2026.

Najpierw jedna rzecz dotycząca zakresu. To artykuł o mechanice skalowania — infrastrukturze, pracy w panelu administracyjnym i higienie bazy danych wraz ze wzrostem liczby zamówień. Celowo nie omawia od nowa wcześniejszych etapów: jeśli nadal walczysz o pierwsze zamówienia, temat ten opisuje artykuł pierwsze 100 zamówień: na czym skupić się na początku, a brutalnie szczera lista niespodzianek znajduje się w tekście 15 rzeczy, których nikt nie mówi Ci przed startem. Tutaj zakładamy, że zamówienia już przychodzą, a pytanie brzmi, czy Twój sklep jest w stanie je udźwignąć.

Dlaczego sklepy PrestaShop psują się etapami, a nie stopniowo

Sklep PrestaShop zużywa w miarę wzrostu trzy zasoby, a one nie wyczerpują się równomiernie. Pojemność serwera (CPU, RAM, procesy PHP-FPM, połączenia MySQL) pogarsza się pod wpływem współbieżności — wszystko jest w porządku, dopóki skok ruchu jej nie nasyci, a wtedy cały sklep zwalnia naraz. Twój własny czas zużywa się liniowo wraz z liczbą zamówień, aż jedno ręczne zadanie przekracza granicę między „irytujące” a „nie mogę robić niczego innego”. A baza danych rośnie monotonicznie z każdym koszykiem, gościem, połączeniem i wpisem w logach — sama się nie kurczy, więc we wtorek, bez widocznego powodu, przekracza próg wydajności.

Ponieważ te trzy obszary osiągają swoje limity w różnych momentach, wzrost odczuwasz jako serię wyraźnych chwil typu „wszystko się pali”, a nie jako łagodne pogorszenie. Poniższe progi są uporządkowane według tego, kiedy każdy z tych problemów zwykle zaczyna boleć. Traktuj liczby zamówień jako przybliżone punkty orientacyjne, a nie obietnice — sklep sprzedający jedną maszynę za 4000 € tygodniowo obciąża PrestaShop zupełnie inaczej niż sklep sprzedający 40 naklejek po 5 € na godzinę.

Cztery progi w skrócie

Próg 1: 1–50 zamówień miesięcznie — oprzyj się pokusie skalowania

Przy tym wolumenie wąskim gardłem nie jest sklep, tylko popyt. Standardowy PrestaShop na skromnym hostingu obsłuży 50 zamówień miesięcznie bez zauważalnego wysiłku. Najdroższym błędem jest tutaj przedwczesna infrastruktura: kupowanie serwera dedykowanego, dokładanie warstw pamięci podręcznej i automatyzowanie procesów dla ruchu, którego jeszcze nie masz. Wydasz pieniądze i, co gorsza, uwagę na problemy, z którymi jeszcze się nie mierzysz.

Naprawdę przydatnym ruchem technicznym na tym etapie jest włączenie podstawowej higieny produkcyjnej PrestaShop, żeby sklep był szybki i uporządkowany od pierwszego dnia — to nic nie kosztuje. W Parametry zaawansowane → Wydajność wyłącz Tryb debugowania, włącz Cache Smarty przy wyłączonym Wymuś kompilację i aktywuj Łączenie, kompresję i cache (CCC) dla CSS/JS. To cała lista zadań infrastrukturalnych na tym etapie. Reszta jest komercyjna — walidacja produktów, szukanie klientów — i to temat na inny artykuł: jak zweryfikować produkty, zanim zainwestujesz oraz dlaczego specjalizacja wygrywa ze sprzedawaniem wszystkiego.

Próg 2: 50–200 zamówień miesięcznie — gdy ręczna obsługa zamówień zaczyna kosztować

To moment, w którym większość właścicieli po raz pierwszy czuje obciążenie, a winowajca prawie zawsze jest ten sam: ręczne zarządzanie statusami zamówień. Każde zamówienie w PrestaShop przechodzi przez statusy (Płatność zaakceptowana → Przygotowanie w toku → Wysłane → Dostarczone), a przy 50 zamówieniach dziennie oznacza to setki kliknięć w listy rozwijane w Zamówienia → Zamówienia tygodniowo — każde z nich to okazja, żeby zapomnieć o e-mailu z informacją o śledzeniu przesyłki albo wysłać coś dwa razy.

Automatyzuj cykl życia zamówienia, nie tylko powiadomienia

PrestaShop uruchamia hooki przy każdej zmianie stanu (actionOrderStatusUpdate, actionOrderStatusPostUpdate), czyli dokładnie tam, gdzie powinna działać automatyzacja oparta na regułach. Zamiast klikać ręcznie, definiujesz przejścia raz: gdy moduł płatności potwierdzi transakcję, automatycznie przejdź do statusu Przygotowanie w toku; gdy zostanie zapisany numer śledzenia przewoźnika, automatycznie przejdź do statusu Wysłane i wyślij powiadomienie do klienta. To zadanie naszego modułu Advanced Order Workflow — co konkretnie zyskujesz? Godzinę dziennie, którą dziś poświęcasz na pilnowanie listy zamówień, mniej błędów ludzkich i konfigurację z panelu administracyjnego bez dotykania kodu. Wygraną na tym poziomie nie jest szybszy serwer; jest nią odzyskanie własnego czasu, tak aby rósł wolniej niż liczba zamówień.

Wyprzedź potrzeby hostingowe, ale rozsądnie

Jeśli nadal korzystasz z hostingu współdzielonego, to jest moment na przejście na VPS — 4 GB RAM, SSD i PHP 8.1+ to rozsądne minimum. Powodem jest współbieżność, nie sama liczba zamówień: setki sesji dziennie oznaczają wiele jednoczesnych procesów PHP i połączeń MySQL, a hosting współdzielony pod obciążeniem odcina Ci dostęp do jednego i drugiego. Nie potrzebujesz jeszcze serwera dedykowanego; potrzebujesz przewidywalnych zasobów, których nie dzielisz z hałaśliwym sąsiadem.

Próg 3: 200–500 zamówień miesięcznie — problemem stają się dokładność i szybkość

To już prawdziwy biznes, a tryby awarii zmieniają się z „to jest żmudne” na „to jest błędne” i „to jest wolne”. Trzy rzeczy zwykle zaczynają boleć jednocześnie.

Rozjazd stanów magazynowych

Magazyn prowadzony w arkuszu kalkulacyjnym działa do momentu, w którym przestaje działać. Przy 200+ zamówieniach miesięcznie — plus zwrotach, ręcznych korektach i być może drugim kanale sprzedaży — stan zapisany w systemie rozjeżdża się ze stanem rzeczywistym i zaczynasz sprzedawać ponad dostępny zapas. Natywny stan magazynowy PrestaShop znajduje się w ps_stock_available i wystarcza do liczenia w jednym magazynie — ma nawet alerty niskiego stanu — ale nie oferuje procesu zamówień do dostawców, zaawansowanego uzupełniania zapasów ani prawdziwego modelu wielu lokalizacji. Jeśli zbliżasz się do tej ściany, nasz moduł Warehouse Revolution dodaje stany dla każdego magazynu, alerty niskiego stanu i zarządzanie uzupełnianiem zapasów, dzięki czemu liczba w panelu administracyjnym odpowiada liczbie na półce. (Szersze pytanie „co prowadzić samodzielnie, a co oddać na zewnątrz” — realizacja zamówień, wsparcie, księgowość — to osobna decyzja: zobacz co delegować, a co zostawić u siebie.)

Obsługa klienta przekracza możliwości jednej skrzynki

Nie możesz już odpowiadać na każdą wiadomość ad hoc ze swojej prywatnej skrzynki. Wbudowana obsługa klienta PrestaShop (Obsługa klienta → Obsługa klienta) tworzy wątki z wiadomości formularza kontaktowego, a kierowanie ich według tematu — zamówienia, zwroty, pytania przed zakupem — pozwala utrzymać rozsądny czas odpowiedzi wraz ze wzrostem wolumenu. Skategoryzowany, dobrze kierowany formularz kontaktowy, taki jak nasz Better Contact Form, sprawnie zasila ten proces. To także próg, na którym pytanie „czy zatrudnić?” po raz pierwszy staje się realne; konkretne sygnały omówiliśmy w artykule kiedy zatrudnić pierwszego pracownika, a komercyjne znaczenie szybkich odpowiedzi w tekście dlaczego odpowiadamy na każde zgłoszenie w ciągu kilku godzin.

Szybkość strony staje się dźwignią przychodów

Przy tysiącach odsłon dziennie czas do pierwszego bajtu (TTFB) przestaje być próżnościową metryką. Domyślne renderowanie PrestaShop przy każdym żądaniu oznacza, że każde wejście na stronę niezapisaną w cache uruchamia PHP i stos zapytań SQL. Tutaj liczą się dwa ruchy. Po pierwsze, przenieś cache zapytań PrestaShop do pamięci, na przykład Redis, żeby powtarzalne odczyty nie obijały się o MySQL. Ekran Parametry zaawansowane → Wydajność → Cache w PrestaShop natywnie oferuje Memcached/APCu; konkretnie dla Redis nasz moduł Instant Redis podłącza go bez pracy w konsoli serwera. Po drugie, postaw CDN przed zasobami statycznymi, żeby obrazy i paczki CCC nie były zawsze pobierane z Twojego serwera źródłowego. Szczegółowy rozbiór diagnozowania powolnego PrestaShop to osobny tekst — lepiej go podlinkować niż streszczać tutaj na szybko — ale zasada na tym etapie brzmi: mniej przejść do bazy danych na jednego odwiedzającego.

Próg 4: 500–1000+ zamówień miesięcznie — infrastruktura i współbieżność

Po przekroczeniu 500 zamówień zwykle masz tysiące dziennych odwiedzających przeglądających katalog, podczas gdy stały strumień kupujących przechodzi przez finalizację zamówienia, a baza danych staje się zasobem, o który rywalizuje wiele procesów. To poziom, na którym przestajesz tylko stroić i zaczynasz projektować architekturę.

Cache pełnych stron przestaje być opcją

Najbardziej efektywną zmianą jest tutaj obsługiwanie większości ruchu katalogowego z cache zamiast regenerowania stron. CCC (Próg 1) tylko minifikuje zasoby; nie powstrzymuje PHP i MySQL przed ponownym budowaniem strony. Cache pełnych stron serwuje anonimowym odwiedzającym zapisaną kopię HTML, dzięki czemu procesy PHP i baza danych zostają zarezerwowane dla osób, które faktycznie dodają produkty do koszyka i finalizują zamówienie. Nasz moduł Performance Revolution dostarcza to na poziomie aplikacji, a warstwa Varnish przed Nginx/Apache robi to na krawędzi sieci. Przekładając na biznes: ten sam serwer jest teraz w stanie przyjąć skok ruchu, który wcześniej położyłby sklep w środku promocji — a sprawna finalizacja zamówienia w najlepszej godzinie sprzedaży jest sednem całej sprawy.

Oddziel bazę danych od serwera WWW

Na jednej maszynie MySQL i PHP-FPM pod obciążeniem walczą o ten sam RAM i CPU. Przeniesienie MySQL na osobny serwer — PrestaShop czyta połączenie z bazą z app/config/parameters.php (albo config/settings.inc.php w 1.6), więc to zmiana konfiguracji, nie kodu — pozwala każdej maszynie wyspecjalizować się w swoim zadaniu: węzły WWW uruchamiają PHP, a węzeł bazy danych obsługuje zapytania z dużą ilością RAM dla puli buforów (16 GB+ jest rozsądne na tej skali). Jeśli zostajesz przy jednym serwerze, praktycznym minimum są dyski NVMe i 8 GB+ RAM.

Wszystko staje się operacją masową

Praca administracyjna wykonywana po jednej sztuce, która była tolerowalna na Progu 2, teraz jest pełnoetatowym zajęciem, którego nikt nie powinien wykonywać. Musisz drukować 50 dokumentów pakowania jedną akcją, zmieniać statusy 100 zamówień jednym zaznaczeniem i eksportować zamówienia dla księgowości lub 3PL w jednym pliku, zamiast kopiować i wklejać. Lista zamówień PrestaShop natywnie obsługuje akcje masowe; do czystych, filtrowanych eksportów nasz Orders CSV List Exporter zamienia przefiltrowany widok zamówień w gotowy CSV. Zasada na tym etapie: jeśli zadanie skaluje się wraz z liczbą zamówień i wykonujesz je dla każdego zamówienia osobno, masz wyciek czasu.

Bezpieczeństwo i kontrola dostępu przy wyższej stawce

Większy wolumen oznacza większy przepływ pieniędzy i większy cel. Najpierw dwa ruchy natywne dla PrestaShop: utwórz prawdziwe profile pracowników w Parametry zaawansowane → Zespół z uprawnieniami ograniczonymi do danej pracy (pakowacz nie potrzebuje zakładek Płatność ani Klienci) oraz włącz monitorowanie katalogu i logów, które wykrywa brute-force i aktywność skanerów — nasz moduł Security Revolution obejmuje stronę monitoringu. Kopie zapasowe przestają być dobrym pomysłem, a stają się nienegocjowalne: przy 1000 zamówieniach miesięcznie jeden utracony dzień bazy danych to utracony dzień przychodów i danych klientów.

Baza danych to część, której nikt nie obserwuje, dopóki nie jest za późno

Ten temat zasługuje na osobną sekcję, bo to najczęstszy cichy zabójca rosnącego sklepu PrestaShop. Każdy odwiedzający, który nie kupuje, i tak zostawia po sobie wiersze: porzucony koszyk w ps_cart, gościa w ps_guest, połączenie w ps_connections / ps_connections_source, odsłony stron w ps_page_viewed oraz statystyki w tabelach ps_stats* (ps_statssearch, ps_statsdata i podobne). Sklep realizujący 1000 zamówień może generować 50 000+ sesji, z których ogromna większość tylko rozdyma te tabele. Pozostawione bez kontroli rosną bez ograniczeń, aż joiny z nimi spowalniają cały panel administracyjny, a sprawdzanie reguł koszyka przy finalizacji zamówienia zaczyna się ciągnąć.

Rozwiązaniem jest zaplanowane czyszczenie wygasłych koszyków, użytych/wygasłych reguł koszyka i starych wierszy statystyk — ostrożnie, bo część tych tabel zasila prawidłowe raportowanie. Nasz moduł Cleanup Revolution automatyzuje tę konserwację według harmonogramu, dzięki czemu baza danych pozostaje lekka wraz ze wzrostem wolumenu, zamiast wymagać od Ciebie pamiętania o ręcznym uruchamianiu SQL (i ryzykowania usunięcia nie tego, co trzeba). I co z tego? Panel administracyjny, który przy 1000 zamówieniach pozostaje równie responsywny jak przy 100, bez tajemniczego spowolnienia za trzy miesiące.

Błędy, które pojawiają się na każdym progu

• Skalowanie za wcześnie. Kupowanie infrastruktury z Progu 4 przy 30 zamówieniach miesięcznie. Wydajesz pieniądze i uwagę na rozwiązywanie problemów, których nie masz, zaniedbując ten, który faktycznie istnieje — popyt.
• Skalowanie za późno. Czekanie z cache pełnych stron do momentu, aż strona padnie podczas promocji. Gdy klienci mówią Ci, że sklep jest wolny, zamówienia są już stracone.
• Dodawanie narzędzi zamiast usuwania tarcia. Nakładanie dziesięciu w połowie skonfigurowanych modułów na wolną bazę. Mniej modułów używanych dobrze wygrywa z większą liczbą modułów używanych źle — dodatkowe moduły to dodatkowe hooki uruchamiane przy każdym ładowaniu strony.
• Ignorowanie bazy danych. Opisane wyżej — próg, którego nie widzisz, dopóki go nie przekroczysz.
• Brak monitoringu. Przy skali o awarii musisz dowiedzieć się z alertu, a nie z e-maila od klienta. Monitoring dostępności i śledzenie błędów to tanie ubezpieczenie przed kosztowną, cichą awarią.

Zasada: jeden krok do przodu, nie dziesięć

Sklep obsługujący 1000 zamówień ma prawie zerową wspólną infrastrukturę ze sklepem, który obsługiwał 10, i dokładnie tak powinno być. Przegrywającym ruchem jest próba zbudowania konfiguracji na 1000 zamówień pierwszego dnia; drugim przegrywającym ruchem jest odmawianie aktualizacji do momentu, aż coś się zepsuje. Działa wzorzec, w którym jesteś mniej więcej jeden próg przed faktycznym wolumenem — przy 200 zamówieniach po cichu przygotowujesz się na 500, tak aby gdy dojdziesz do 500, systemy były już gotowe, a wzrost przypominał nabieranie rozpędu zamiast kryzysu.

Ekonomia jest przy tym równie ważna jak inżynieria. Skalowanie liczby zamówień ma sens tylko wtedy, gdy każde dodatkowe zamówienie jest faktycznie rentowne po policzeniu realnych kosztów — opłat płatniczych, czasu wsparcia, zwrotów i opisanej wyżej infrastruktury. Zanim mocno naciśniesz na wolumen, upewnij się, że jednostkowa ekonomia się broni: zrozumienie prawdziwych marż oraz koszty, o których nikt nie mówi. Tysiąc rentownych zamówień to prawdziwa firma; tysiąc zamówień na granicy opłacalności to po prostu tysiąc jednostek pracy.

FAQ

Liczby zamówień nie pasują do mojego sklepu — czy źle czytam te progi?

Nie. Traktuj liczby zamówień jako przybliżone punkty orientacyjne, a nie progi graniczne. Liczy się główne ograniczenie, nie sama liczba. Sklep sprzedający kilka drogich maszyn osiąga limity bazy danych i współbieżności znacznie później niż sklep sprzedający dużo tanich produktów, bo ten drugi generuje o wiele więcej sesji, koszyków i odsłon katalogu na jedno zamówienie. Znajdź swój próg po tym, który objaw uderza pierwszy — ręczna obsługa zjadająca dzień, rozjazd stanów, wolne strony albo finalizacja zamówienia padająca pod obciążeniem — i reaguj na to, a nie na docelową liczbę zamówień.

Kiedy dodać cache pełnych stron — w którym momencie CCC przestaje wystarczać?

Dodaj cache pełnych stron, gdy anonimowy ruch katalogowy regeneruje strony szybciej, niż Twoje procesy PHP i baza danych są w stanie obsłużyć podczas skoku ruchu — zwykle w okolicach progu 500 zamówień miesięcznie, gdy masz tysiące odwiedzających dziennie. CCC tylko minifikuje i łączy CSS/JS; nie robi nic, żeby zatrzymać ponowne budowanie strony przez PHP i MySQL przy każdym wejściu. Cache pełnych stron serwuje anonimowym odwiedzającym zapisany HTML, więc procesy i baza danych pozostają dla osób, które faktycznie dodają produkty do koszyka i finalizują zamówienie. Jeśli promocja kiedykolwiek spowolniła sklep do ślimaczego tempa, jesteś już po punkcie, w którym powinno to być włączone.

Czy naprawdę muszę czyścić bazę danych, czy to przedwczesna optymalizacja?

Gdy przekroczysz kilkaset zamówień miesięcznie, staje się to realną konserwacją, a nie przedwczesną optymalizacją. Każdy odwiedzający, który nie kupuje, i tak zostawia po sobie wiersze — porzucone koszyki w ps_cart, gości, połączenia, odsłony stron, statystyki — a te tabele tylko rosną. Sklep realizujący 1000 zamówień może obsługiwać 50 000+ sesji, z których ogromna większość tylko rozdyma te tabele, aż joiny z nimi spowalniają panel administracyjny i sprawdzanie reguł koszyka przy finalizacji zamówienia. Zaplanowane czyszczenie wygasłych koszyków, użytych reguł koszyka i starych statystyk utrzymuje bazę danych w ryzach; rób to ostrożnie, bo część tych tabel zasila prawidłowe raportowanie.

Czy przenieść MySQL na osobny serwer, czy po prostu kupić większą maszynę?

Zostań na jednej, dobrze dobranej maszynie (dyski NVMe, 8 GB+ RAM), dopóki jeden serwer komfortowo obsługuje szczytowe obciążenie. Przenieś bazę danych na osobny serwer, gdy MySQL i PHP-FPM wyraźnie walczą pod obciążeniem o ten sam RAM i CPU — zwykle głęboko w progu 500–1000+. PrestaShop czyta połączenie z bazą z konfiguracji (app/config/parameters.php albo config/settings.inc.php w 1.6), więc przeniesienie bazy danych jest zmianą konfiguracji, nie kodu. Po rozdzieleniu każda maszyna specjalizuje się w swoim zadaniu: węzły WWW uruchamiają PHP, a węzeł bazy danych obsługuje zapytania z dużą pulą buforów.

Jaki jest najczęstszy błąd przy skalowaniu?

Dwa przeciwne błędy, równie kosztowne. Skalowanie za wcześnie — kupowanie infrastruktury z progu 4 przy 30 zamówieniach miesięcznie — wydaje pieniądze i uwagę na problemy, których nie masz, zaniedbując ten, który faktycznie masz, czyli popyt. Skalowanie za późno — czekanie, aż sklep padnie w środku promocji, żeby dodać cache — oznacza, że klienci mówią Ci o wolnym sklepie dopiero wtedy, gdy zamówienia są już stracone. Wzorzec, który działa, to pozostawanie mniej więcej jeden próg przed faktycznym wolumenem, tak aby systemy były gotowe tuż przed momentem, w którym ich potrzebujesz.