Spis treści:
- Hosting współdzielony vs VPS vs serwer dedykowany
- Architektura dedykowana
- Tuningi bazy danych
- OPcache
- Limit pamięci PHP (memory_limit)
- Podsumowanie
W trzech poprzednich częściach uporządkowaliśmy aplikację (cache i moduły), bazę danych (indeksy, slow log, EXPLAIN) oraz zadbaliśmy o higienę tabel – teraz czas na warstwę, która scala to wszystko w trakcie piku: konfiguracja serwera PrestaShop na okresy wzmożonego ruchu. Nawet świetnie zoptymalizowany kod nie utrzyma dobrych czasów odpowiedzi na zbyt słabym lub źle ustawionym środowisku. Celem tego artykułu jest praktyczne dobranie typu hostingu i ustawień systemowych tak, by utrzymać niski TTFB i stabilność ścieżki karta produktu → koszyk → checkout, gdy ruch rośnie wielokrotnie.
Dlaczego to ważne?
- Wąskie gardła bardzo często znajdują się poza kodem: w procesach PHP/FPM, w konfiguracji MySQL/MariaDB, w dysku czy w braku cache’u na poziomie serwera.
- W szczycie sprzedażowym liczy się nie tylko szybkość pojedynczego żądania, ale też odporność na równoległą liczbę jednoczesnych zapytań, dlatego izolacja ról i rozsądne limity są tak samo ważne jak optymalizacje w aplikacji.
1. Hosting współdzielony vs VPS vs serwer dedykowany
Wybór środowiska to fundament – nawet najlepiej zoptymalizowana aplikacja nie utrzyma niskiego TTFB, jeśli zasoby są współdzielone i ograniczane w szczycie ruchu. Hosting współdzielony sprawdza się przy małych projektach, ale w Black Week staje się loterią, bo wydajność zależy od sąsiadów na tej samej maszynie. Dlatego do kampanii o podwyższonym ryzyku lepiej przejść na VPS/Cloud lub serwer dedykowany (ew. managed), gdzie można świadomie dobrać limity i samodzielnie stroić konfigurację serwera.
Dlaczego hosting współdzielony to ryzyko:
- Ograniczone zasoby: niskie limity CPU/RAM per konto powodują timeouty i zabijanie procesów, gdy ruch skacze – to prosta droga do wzrostu TTFB i błędów podczas checkoutu.
- Brak izolacji: obcy ruch na tym samym serwerze obniża przepustowość niezależnie od optymalizacji sklepu – w piku nie da się przewidzieć wahań.
- Ograniczona konfiguracja: brak pełnego wpływu na php.ini i ustawienia bazy (np. OPcache, limity pamięci, liczba workerów PHP, parametry InnoDB) uniemożliwia realne strojenie pod profil sklepu.
- throttling: dostawca może dławić CPU lub I/O przy nadmiernym użyciu, co w praktyce spowalnia ładowanie stron akurat wtedy, gdy kampania działa najlepiej.
Rekomendacja
W okresie Black Friday unikaj współdzielonego środowiska. Wybierz VPS/Cloud albo serwer dedykowany (samodzielnie zarządzany lub w modelu managed), który daje pełną kontrolę nad zasobami i konfiguracją. Zyskujesz izolację, przewidywalność i możliwość ustawienia parametrów tak, by utrzymać niskie czasy odpowiedzi w piku.
Co zyskujesz na serwerze VPS/Cloud/dedykowanym:
- elastyczne skalowanie (łatwiej dodać vCPU/RAM lub drugi węzeł aplikacyjny),
- pełną kontrolę nad konfiguracją usług serwera PHP, MySQL, Redis, Varnish,
- przewidywalność – ruch innych klientów nie zabiera zasobów, a czasy pozostają stabilne.
Praktyczny krok przed kampanią
Zaplanuj krótkie okno migracji na VPS/Cloud/dedyk: przenieś aplikację i bazę, sprawdź ścieżki karta produktu → koszyk → checkout, włącz monitoring oraz test obciążeniowy. Jeśli model Cloud na to pozwala, przygotuj profil auto‑scale lub ręczny „plan B” (szybkie podniesienie vCPU/RAM) na czas piku.
2. Architektura dedykowana
Kiedy sklep wchodzi na poziom realnego ruchu liczonym w tysiącach jednoczesnych użytkowników, jeden serwer od wszystkiego przestaje być bezpieczną opcją. Separacja ról – osobno aplikacja, osobno baza – to najprostszy sposób, by usunąć wzajemne wykorzystywanie zasobów i zyskać przewidywalność pod presją.
Jak rozdzielić to w praktyce
- Serwer aplikacji: Nginx/Apache + PHP‑FPM + PrestaShop. Tutaj liczą się rdzenie CPU dla PHP, szybkie I/O dla statyków oraz poprawnie zestrojony OPcache i menedżer procesów FPM. Gdy prognoza ruchu jest wysoka, uruchom 2+ serwery aplikacyjne za load balancerem – łatwiej wtedy zwiększać przepustowość horyzontalnie.
- Serwer bazy danych: MySQL/MariaDB na szybkim NVMe, z dużym RAM na InnoDB Buffer Pool i sensownie dobranymi parametrami (o których w kolejnym akapicie). To węzeł nastawiony na niski czas dostępu do danych i stabilny I/O.
- Oddzielenie zasobów: intensywne zapytania SQL nie przyduszają procesów PHP (i odwrotnie), więc piki w koszyku/checkout nie przekładają się na nagłe skoki TTFB spowodowane konkurencją o RAM i dysk.
Oddzielne serwery aplikacji i bazy: żądania HTTP trafiają do warstwy aplikacyjnej, a zapytania SQL obsługuje dedykowany serwer MySQL/MariaDB. Taki podział upraszcza skalowanie i stabilizuje czasy odpowiedzi.
Korzyści, które czuć od razu
- Lepsze wykorzystanie zasobów: serwer bazy dostaje RAM i szybkie dyski pod InnoDB, a serwer aplikacji – rdzenie pod PHP i buforowanie kodu (OPcache). Każdy węzeł robi to, w czym jest najlepszy.
- Skalowalność bez niespodzianek: kiedy brakuje CPU dla PHP – dodajesz kolejny węzeł aplikacyjny – kiedy rośnie working set danych – powiększasz RAM dla InnoDB. Płacisz tylko za to, czego realnie potrzebujesz.
Drobne, ale istotne wskazówki wdrożeniowe
- Utrzymuj krótką, szyfrowaną ścieżkę między aplikacją a bazą (ta sama strefa/region, niska latencja).
- Traktuj warstwę cache (Redis/Memcached) jako trzecią „dźwignię” – przenosi część odczytów z DB i poprawia odporność na skoki ruchu.
- Zaplanuj monitoring per węzeł (CPU, RAM, I/O, FPM metrics, InnoDB metrics), żeby szybko wykrywać, która warstwa potrzebuje dołożenia zasobów.
Taki układ daje przewidywalność w dniu kampanii – kiedy ruch skacze, wiesz dokładnie, który suwak podnieść: rdzenie dla PHP, RAM dla InnoDB, czy kolejny węzeł aplikacyjny za load balancerem.
3. Tuningi bazy danych
Wydzielenie serwera bazy to dopiero początek – realny efekt daje dopasowanie konfiguracji MySQL/MariaDB do profilu ruchu sklepu i dostępnych zasobów. Poniżej zmienne, na które warto zwrócić uwagę w my.cnf, wraz z krótkim uzasadnieniem.
- innodb_buffer_pool_size: najważniejszy suwak InnoDB. Im większa część aktywnych danych i indeksów mieści się w pamięci, tym mniej kosztownych odczytów z dysku. Na maszynie dedykowanej bazie warto zacząć od wartości rzędu większości dostępnego RAM (zostawiając rozsądną rezerwę dla systemu i innych buforów) i korygować po obserwacji obciążenia.
- max_connections: ustaw tę wartość pod realną liczbę jednoczesnych połączeń z bazy, jakich może wymagać aplikacja (suma aktywnych workerów PHP/FPM oraz zapas na skoki ruchu), zamiast na oko lub z dużym nadmiarem. Najpierw policz możliwy szczyt połączeń z warstwy aplikacyjnej, potem dodaj bezpieczny margines.
- thread_cache_size: przy wielu krótkich, powtarzalnych połączeniach pozwala recyklingować wątki zamiast tworzyć je od nowa. Efekt widać zwłaszcza w piku – mniejsze opóźnienie startu połączenia i mniej pracy administracyjnej po stronie serwera.
- table_open_cache: zbyt niski limit wymusza ciągłe otwieranie i zamykanie tabel, co kosztuje CPU i I/O – zbyt wysoki marnuje pamięć. Zwiększaj stopniowo, obserwując tempo przyrostu liczników otwarć i użycie RAM.
- innodb_log_file_size: większe pliki dziennika pomagają przy intensywnych zapisach (INSERT/UPDATE), ponieważ rzadziej wymuszają synchronizację zmian z pamięci na dysk – pamiętaj jednak, że bardzo duże logi transakcyjne wydłużają czas odtwarzania bazy po awarii – to kompromis między przepustowością zapisu a czasem odzyskiwania.
Jak stroić w praktyce
- Zacznij od mocnego buffer pool i obserwuj: jeśli nie mamy nadmiaru operacji I/O na dysku, a cache trafia, to dobry znak – jeśli system zaczyna swapować, zmniejsz pamięć przydzieloną bazie.
- Dobierz max_connections do liczby workerów PHP/FPM i mechanizmów puli połączeń – nie ustawiaj na zapas bez policzenia RAM‑u.
- W ruchu złożonym z wielu krótkich żądań (np. listingi, filtrowanie) podnieś thread_cache_size i sprawdź, czy spada latencja pierwszego zapytania po połączeniu.
- Gdy widzisz częste ponowne otwieranie tabel, podnieś table_open_cache i skontroluj zużycie pamięci.
- Jeśli sklep intensywnie zapisuje (promocje, koszyki, reguły, importy), rozważ większe logi InnoDB, ale zaplanuj procedury awaryjne i test odzyskiwania.
Tip: zmiany wprowadzaj iteracyjnie, po każdym kroku rób krótkie testy pod ruchem (również syntetycznym) i spisuj notatkę „przed/po” z metrykami. Dzięki temu konfiguracja dojrzewa razem z ruchem i nie zaskoczy Cię w Black Week.
Narzędzia takie jak mysqltuner mogą pomóc wskazać parametry do poprawy. Kluczowe jest jednak, aby serwer bazy miał wystarczająco dużo pamięci, szybki dysk oraz poprawnie skonfigurowany innodb_buffer_pool_size – to znacząco przyspieszy operacje na tabelach podczas wzmożonego ruchu.
4. OPcache
OPcache to rozszerzenie PHP, które przechowuje w RAM już skompilowany kod PHP. Dzięki temu kolejne żądania nie tracą czasu na parsowanie i kompilację plików – serwer od razu wykonuje gotowy bytecode. Efekt: krótszy czas wykonania skryptów i niższe obciążenie CPU, co stabilizuje TTFB w piku ruchu.
Jak włączyć i ustawić OPcache (php.ini)
- Upewnij się, że rozszerzenie jest dostępne i aktywne – jeśli nie, poproś administratora o instalację i załadowanie modułu.
- Kluczowe parametry startowe (dopasuj do wielkości instalacji i liczby modułów):
opcache.memory_consumption: rezerwuje pamięć dla OPcache. Dla PrestaShop sensownym punktem startu jest 128–256 MB – przy rozbudowanych instalacjach podnieś do 256–512 MB, obserwując poziom zapełnienia.
opcache.max_accelerated_files: ustaw powyżej liczby wszystkich plików PHP w sklepie (rdzeń + moduły). Przykładowo 10000 lub więcej przy większej instalacji.
opcache.validate_timestamps = 0 na produkcji: wyłącza automatyczne sprawdzanie dat modyfikacji plików, dzięki czemu każdy hit leci z cache bez dodatkowych operacji. Po wdrożeniach korzystaj z ręcznego resetu OPcache.
Gdzie ustawić
- W pliku php.ini (lub odpowiednim ini dla FPM/Apache). Po zmianie wykonaj reload serwera PHP (np. reload php-fpm), aby ustawienia zadziałały.
Na co zwrócić uwagę po wdrożeniu
- Monitoruj zapełnienie pamięci OPcache i liczbę wysunięć z cache. Jeśli widzisz częste „wyrzucanie” skryptów, zwiększ memory_consumption lub max_accelerated_files. Status OPcache możesz sprawdzić korzystając z funkcji opcache_get_status
- Sprawdź, czy TTFB na krytycznych ścieżkach (karta produktu, koszyk, checkout) się ustabilizował – to szybki wskaźnik, że OPcache realnie działa.
Przykład praktyczny
Sklep z wyłączonym OPcache miał wysoki TTFB. Po włączeniu i ustawieniu pamięci oraz liczby plików czasy odpowiedzi skróciły się o około połowę (z ~1 s do ~600 ms), a obciążenie CPU spadło podczas piku.
Tip: jeśli środowisko wymaga częstych wdrożeń w godzinach pracy, rozważ pozostawienie validate_timestamps = 1 na stagingu i 0 na produkcji, a w procesie wdrożeniowym dodaj krok czyszczenia OPcache. Dzięki temu zyskasz maksimum wydajności bez ryzyka serwowania starego kodu.
5. Limit pamięci PHP (memory_limit)
memory_limit to parametr w php.ini, który określa, ile RAM może zużyć pojedynczy proces PHP. Zbyt niski limit kończy się błędem „Allowed memory size exhausted”, zbyt wysoki bywa pułapką – każdy proces może wtedy odebrać dużą porcję pamięci i przy wielu równoległych żądaniach łatwo wyczerpać RAM całego serwera.
Jak dobrać memory_limit w praktyce
- Zacznij od rozsądnego pułapu 256–512 MB na proces. Jeśli sklep nie wykonuje wyjątkowo ciężkich operacji (masowe generowanie PDF, obróbka wielu obrazów), te wartości zazwyczaj wystarczą.
- Obserwuj realne zużycie: jeśli logi wskazują przekroczenia limitu, podnoś wartości stopniowo i równolegle szukaj źródeł nadmiernej konsumpcji (moduły, integracje, zapytania). Podnoszenie limitu nie powinno zastępować optymalizacji aplikacji.
- Planuj łącznie: memory_limit × liczba procesów/workerów PHP + rezerwa na system i inne usługi musi zmieścić się w RAM.
Przykład praktyczny
Serwer 8 GB RAM, memory_limit 256 MB: mając wiele procesów PHP, nie ustawiaj ich na maksimum. Jeśli przeciętny proces zużywa ~40–100 MB, realna bezpieczna liczba workerów bywa niższa, niż prosty iloczyn 8 GB / 256 MB. Zostaw bufor na system, cache, serwer www i ewentualne piki.
Wskazówki wdrożeniowe
- Zmieniaj memory_limit w miejscu właściwym dla używanego SAPI (np. ini dla FPM/Apache) i wykonaj przeładowanie serwisu PHP, aby ustawienia faktycznie zadziałały.
- Dokumentuj zmiany i po każdej korekcie sprawdzaj czasy odpowiedzi na krytycznych ścieżkach (karta produktu → koszyk → checkout) oraz stabilność RAM.
Pamiętaj, że celem jest równowaga. Każdy proces ma dość pamięci, by działać stabilnie, ale suma procesów nie wykorzystuje całego RAM. Nie ustawiaj limitów nieproporcjonalnie wysoko – przy dużej liczbie równoległych żądań to najkrótsza droga do braku pamięci i niestabilności w piku.
Podsumowanie
Za nami cztery kluczowe warstwy przygotowań do Black Week: aplikacja, baza i serwer. Najpierw uporządkowaliśmy fundamenty PrestaShop (cache, moduły, porządek w override’ach), dzięki czemu widoki renderują się szybciej i przewidywalnie. Następnie dopracowaliśmy bazę danych: celne indeksy, analiza slow logów i EXPLAIN oraz retencja w „puchnących” tabelach usunęły wąskie gardła SQL i ograniczyły rozmiar oraz koszt I/O. Na koniec ustawiliśmy serwer pod realny ruch: świadomy wybór środowiska (VPS/Cloud/dedyk zamiast współdzielonego), separacja aplikacji i bazy, zdrowe parametry MySQL/MariaDB, włączony i zestrojony OPcache oraz rozsądne memory_limit i liczba workerów. Efekt to niższy TTFB na ścieżce karta produktu → koszyk → checkout, większa odporność na skoki ruchu i mniejsze ryzyko zadyszki w krytycznym momencie.
Pamiętaj, że optymalna infrastruktura to nie jeden szablon, tylko konfiguracja dopasowana do konkretnego projektu i prognozy ruchu. Bez policzenia obciążenia i zrozumienia ścieżek krytycznych nie da się odpowiedzialnie wskazać konkretnych zasobów. Dlatego tuż przed Black Friday warto czasowo zwiększyć moc (vCPU/RAM/instancje, przepustowość, cache), a po szczycie – wrócić do profilu dziennego, aby nie przepłacać. Dzięki temu środowisko pozostaje szybkie wtedy, kiedy najbardziej na to pracuje sprzedaż – i ekonomiczne, gdy ruch wraca do normy.
Co dalej?
W kolejnym artykule: Jak CDN (Content Delivery Network) odciąży serwer: odciążenie pasma i CPU dzięki serwowaniu statycznych zasobów z węzłów blisko użytkownika, kompresja/konwersja obrazów i stabilne czasy ładowania przy ruchu z kampanii.
Jeśli potrzebujesz wsparcia przy hostingu czy optymalizacji swojego sklepu na PrestaShop lub po prostu chcesz porozmawiać o rozwoju – skontaktuj się z nami.
