Black Friday w e-commerce: 3 kroki do optymalizacji MariaDB, PHP-FPM i Redis zanim serwer padnie

01 Diagnoza z terminala: Dlaczego większy VPS to nie rozwiązanie

Black Friday to dla sklepu internetowego moment próby ogniowej. Gdy ruch rośnie wykładniczo, a serwer zaczyna się zacinać przy 200 zapytaniach na sekundę, pierwszym impulsem jest bezrefleksyjne wykupienie większego VPS-a lub dodanie kolejnych vCPU. Jednak w zdecydowanej większości przypadków problem nie leży w braku czystej mocy obliczeniowej, a w nieoptymalnej konfiguracji usług działających na domyślnych ustawieniach producenta.

Zamiast wydawać budżet na droższy pakiet w chmurze, możesz wycisnąć maksimum wydajności z obecnej infrastruktury, koncentrując się na trzech filarach: bazie danych MariaDB, menedżerze procesów PHP-FPM oraz pamięci podręcznej obiektów Redis. Poniższy przewodnik pokazuje konkretne parametry i wartości liczbowe, które wdrażasz w 30 minut, a które potrafią podnieść przepustowość sklepu nawet dwukrotnie.

02 Krok 1: MariaDB/InnoDB – serce Twojego sklepu

W WooCommerce, które ze względu na swoją strukturę zachowuje się jak mocno obciążona aplikacja transakcyjna, najczęstszym wąskim gardłem jest baza danych. Jej wydajność w środowisku produkcyjnym zależy od trzech kluczowych elementów: rozmiaru bufora InnoDB, indeksów oraz struktury tabel zamówień.

2.1 InnoDB Buffer Pool – trzymaj gorące dane w RAM

Sercem silnika InnoDB jest bufor innodb_buffer_pool_size – wydzielony obszar pamięci RAM, gdzie MariaDB przechowuje najczęściej używane dane i indeksy tabel. Jeśli ten bufor jest zbyt mały, system przy każdym zapytaniu klienta musi odwoływać się bezpośrednio do dysku. Nawet szybkie nośniki NVMe są tysiące razy wolniejsze od pamięci operacyjnej, a podczas Black Friday, gdy zapytań są tysiące na sekundę, dysk po prostu nie nadąży z operacjami I/O.

Zasada konfiguracji: Ustaw parametr na tyle wysoko, aby „gorący zbiór danych” – czyli najczęściej używane tabele, takie jak tmp6eaf3c_posts, wp_postmeta, wp_wc_order_product_lookup czy wp_woocommerce_sessions – w całości zmieścił się w pamięci RAM. Na serwerze współdzielonym, gdzie MariaDB funkcjonuje obok PHP-FPM i Nginx, bezpieczną i sprawdzoną regułą kciuka jest przeznaczenie na ten cel 30–40% całkowitej pamięci RAM serwera.

ini

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
innodb_buffer_pool_size = 4G

Jak zweryfikować trafienie w bufor? Po wdrożeniu zmiany monitoruj wskaźnik Innodb_buffer_pool_reads względem Innodb_buffer_pool_read_requests:

sql

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Jeśli Innodb_buffer_pool_reads (odczyty z dysku) stanowią więcej niż 1% wszystkich żądań odczytu, bufor jest nadal zbyt mały i wymaga dalszego zwiększenia.

2.2 Indeksy i zmora wp_postmeta

Tabela wp_postmeta to strukturalny punkt zapalny WordPressa i WooCommerce. Przechowuje dane w układzie EAV (Entity-Attribute-Value), co oznacza, że każda właściwość produktu czy zamówienia to osobny wiersz. Zapytania wykonujące wiele złączeń (LEFT JOIN) na tej tabeli bez odpowiednich indeksów kompozytowych potrafią zablokować cały sklep, wyczerpując pulę dostępnych połączeń w ułamku sekundy.

Procedura przed Black Friday:

1. Włącz logowanie wolnych zapytań z progiem 2 sekund:

sql

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 2;

2. Po kilku godzinach normalnego ruchu (lub po teście obciążeniowym) przeanalizuj log:

bash

mysqldumpslow /var/log/mysql/mariadb-slow.log

3. Zidentyfikuj zapytania wykonujące FULL TABLE SCAN na wp_postmeta i załóż brakujące indeksy kompozytowe. Najczęściej potrzebne są indeksy na kolumnach (post_id, meta_key) lub (meta_key, meta_value) z określoną długością prefixu dla wartości tekstowych.

2.3 HPOS – High-Performance Order Storage

Jeśli jeszcze nie wdrożyłeś HPOS, to absolutny priorytet przed sezonem wyprzedażowym. Funkcja ta, dostępna natywnie w WooCommerce od wersji 8.2, przenosi dane zamówień z uniwersalnych i chronicznie przeciążonych tabel tmp6eaf3c_posts oraz wp_postmeta do dedykowanych, płaskich tabel wp_wc_orders i pokrewnych.

Efekt: struktura zapytań SQL ulega radykalnemu skróceniu – zamiast wielopoziomowych złączeń przez tabele EAV, zamówienia pobierane są prostymi zapytaniami z dedykowanych kolumn. W testach producenckich i niezależnych benchmarkach przyspieszenie operacji na zamówieniach sięga od 1,3x do 1,5x.

Wdrożenie: WooCommerce → Ustawienia → Zaawansowane → Funkcje eksperymentalne → Włącz HPOS. Przed migracją wykonaj pełny backup bazy danych.

03 Krok 2: PHP-FPM – ustaw odpowiednią liczbę procesów

PHP-FPM to menedżer procesów odpowiedzialny za wykonywanie kodu PHP Twojego sklepu. Każdy uruchomiony proces (worker) może obsłużyć dokładnie jedno żądanie HTTP w danym momencie – zachowuje się analogicznie do kasjera w supermarkecie.

3.1 pm = static zamiast dynamic

Na co dzień tryb dynamic lub ondemand sprawdza się dobrze, ponieważ usypia nieaktywne procesy i oszczędza pamięć RAM. Jednak na Black Friday to kardynalny błąd. Dynamiczne tworzenie (forkowanie) nowych procesów PHP w momencie nagłego skoku ruchu drastycznie obciąża procesor i generuje dodatkowe opóźnienia, podczas gdy klienci czekają na załadowanie strony.

Konfiguracja na czas wyprzedaży: przełącz PHP-FPM w tryb static. Maksymalna liczba workerów zostanie powołana do życia od razu przy starcie usługi i będzie stale rezydować w pamięci RAM, gotowa do natychmiastowego obsłużenia ruchu bez narzutu na forkowanie.

ini

; /etc/php/8.3/fpm/pool.d/www.conf
pm = static

3.2 pm.max_children – realny limit mocy obliczeniowej

To najważniejszy pojedynczy parametr w całej konfiguracji PHP-FPM. Określa, ilu maksymalnie workerów może jednocześnie przetwarzać zapytania.

• Ustawiony za nisko: w momencie szturmu klientów tworzą się kolejki, czas do pierwszego bajta (TTFB) rośnie do kilkunastu sekund, a użytkownicy widzą błędy 502 Bad Gateway lub 504 Gateway Timeout.
• Ustawiony za wysoko: procesy PHP skonsumują cały dostępny RAM, system operacyjny zacznie zrzucać dane do przestrzeni wymiany (swap) na dysku, co doprowadzi do całkowitego zawieszenia serwera.

Metoda obliczenia bezpiecznej wartości:

1. Sprawdź średnie zużycie pamięci (RSS) przez pojedynczy proces PHP-FPM pod obciążeniem:

bash

ps -o rss,cmd -C php-fpm8.3 --no-headers | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'

2. Zastosuj wzór:

text

max_children = RAM dostępny dla PHP-FPM / średni rozmiar jednego procesu

Przykład produkcyjny: Proces PHP waży średnio 200 MB. Po odliczeniu 2 GB na system operacyjny i 4 GB na bufor MariaDB, na PHP-FPM pozostaje dokładnie 4 GB (4096 MB) z całkowitych 10 GB RAM serwera. Matematyczny limit wynosi 20 procesów. Uwzględniając bezpieczny bufor 20% na nagłe anomalie (np. eksport raportu przez administratora w panelu), wartość pm.max_children ustawiasz na 16.

ini

pm.max_children = 16

3.3 pm.max_requests – ochrona przed wyciekami pamięci

Parametr określa, po ilu obsłużonych żądaniach dany proces PHP jest zabijany i tworzony na nowo. Chroni to przed kumulującymi się wyciekami pamięci (memory leaks), które są plagą niesoptymalizowanych wtyczek WooCommerce – szczególnie tych operujących na dużych zbiorach danych bez zwalniania referencji.

Bezpieczny zakres na Black Friday: od 500 do 1000. Wartości poniżej 500 generują niepotrzebny narzut na cykliczne niszczenie i tworzenie procesów; wartości powyżej 1000 ryzykują, że wyciek pamięci zdąży się skumulować do niebezpiecznego poziomu.

ini

pm.max_requests = 500

04 Krok 3: Redis Object Cache – wyeliminuj zbędne zapytania do bazy

Redis to niezwykle wydajna baza danych działająca bezpośrednio w pamięci RAM (in-memory). W ekosystemie WordPress i WooCommerce pełni rolę pamięci podręcznej obiektów (Object Cache), odciążając MariaDB z powtarzalnych, kosztownych zapytań.

4.1 Jak Redis odciąża bazę danych

Zamiast za każdym razem zmuszać serwer MariaDB do wykonywania tych samych, ciężkich operacji SQL – pobierania konfiguracji sklepu (wp_options), struktury menu, danych technicznych popularnego produktu czy sesji koszyka – WooCommerce pobiera gotowy, przetworzony wynik bezpośrednio z ultraszybkiego Redisa.

Efekt w liczbach: poprawnie skonfigurowany Object Cache redukuje liczbę zapytań do bazy danych z kilkuset do zaledwie kilku na jedno przeładowanie strony produktowej. Dla sklepu z 5000 SKU przekłada się to na spadek średniego czasu generowania strony o 40–60%.

4.2 Bezpieczna konfiguracja Redis pod obciążeniem

Poza instalacją serwera Redis i aktywacją wtyczki w WordPressie (np. Redis Object Cache), absolutnie kluczowa jest konfiguracja limitów pamięci. Zaniedbanie tego kroku grozi katastrofą w trakcie zakupowego szczytu.

W pliku /etc/redis/redis.conf ustaw dwa parametry:

conf

maxmemory 512mb
maxmemory-policy allkeys-lru

Dlaczego allkeys-lru to jedyny bezpieczny wybór: Gdy podczas Black Friday Redis zapełni całą przyznaną mu pamięć, polityka allkeys-lru (Least Recently Used) automatycznie usuwa najstarsze i najrzadziej używane klucze, zwalniając miejsce na nowe dane. Alternatywne polityki, takie jak noeviction, w momencie przepełnienia pamięci zwracają błąd zapisu – co w przypadku WooCommerce oznacza wysypanie się sesji koszyków klientów i utratę przetwarzanych zamówień.

05 Czy to wystarczy? Test obciążeniowy jako walidacja

Przedstawione trzy kroki to absolutny fundament i najskuteczniejsza pierwsza linia obrony przed paraliżem serwera. Kluczem do sukcesu jest jednak wdrożenie zmian i przeprowadzenie testów obciążeniowych jeszcze przed Black Friday, a nie w trakcie jego trwania.

Narzędzia do testów: k6 (open-source, skryptowalny w JavaScript) lub Loader.io (chmurowy, z interfejsem graficznym). Skonfiguruj scenariusz symulujący realistyczny ruch: przeglądanie katalogu, dodawanie do koszyka, inicjowanie checkoutu.

Trzy metryki, które monitorujesz podczas testu:

1. SWAP – jakiekolwiek użycie przestrzeni wymiany oznacza, że konfiguracja pamięci RAM jest błędna i wymaga natychmiastowej korekty.
2. CPU – tryb static PHP-FPM powinien ustabilizować wykres obciążenia procesora; skoki wskazują na wąskie gardła w indeksach bazy danych.
3. Innodb_buffer_pool_reads – jeśli wskaźnik rośnie podczas testu, bufor bazy danych jest nadal za mały i gorący zbiór danych nie mieści się w RAM.

Dopiero gdy precyzyjna konfiguracja oprogramowania osiągnie swój technologiczny limit, a serwer nadal będzie łapał zadyszkę – masz twarde dane, że nadszedł czas na fizyczne skalowanie infrastruktury. Zrobisz to jednak z uzasadnieniem w metrykach, a nie z braku przygotowania.

06 Podsumowanie: Checklista optymalizacyjna przed Black Friday

Warstwa	Parametr	Wartość rekomendowana	Priorytet
MariaDB	innodb_buffer_pool_size	30–40% RAM serwera	Krytyczny
MariaDB	HPOS	Włączony	Krytyczny
MariaDB	Slow Query Log + indeksy	Włączony, wp_postmeta zoptymalizowana	Wysoki
PHP-FPM	pm	static	Krytyczny
PHP-FPM	pm.max_children	RAM / średni rozmiar procesu – 20% buforu	Krytyczny
PHP-FPM	pm.max_requests	500–1000	Średni
Redis	maxmemory	256–512 MB (zależnie od katalogu)	Wysoki
Redis	maxmemory-policy	allkeys-lru	Krytyczny

Sekwencja działań: Wdróż powyższe zmiany → przeprowadź test obciążeniowy → przeanalizuj metryki → wyciągnij wnioski → dopiero wtedy podejmij decyzję o ewentualnym skalowaniu sprzętowym.

Zauważyłeś, że panel administracyjny ładuje się ostatnio zbyt wolno, a klienci czekają sekundy na dodanie produktu do koszyka? Twój stos technologiczny prawdopodobnie dławi się na domyślnych ustawieniach – a do Black Friday zostało coraz mniej czasu.