Skalowanie WordPressa: 10 tys. użytkowników na godzinę

Każdy właściciel strony marzy o “viralu”. O momencie, w którym jego artykuł trafia na Wykop, Reddit, lub stronę główną Onetu.

Ale dla administratora serwera ten moment często zamienia się w koszmar. Strona zaczyna ładować się 30 sekund, a potem użytkownicy widzą już tylko “Error 500: Internal Server Error” lub “503 Service Unavailable”.

W tym artykule, opartym na mojej prezentacji z “Fuckup Night”, pokażę Ci, jak przygotować WordPressa na duży ruch (High Traffic) i dlaczego Twoja wtyczka cache to za mało.

#1. Matematyka katastrofy: Limit PHP workers

Większość awarii WordPressa nie wynika z braku RAMu czy procesora, ale z wyczerpania limitu PHP Workers.

#Czym jest PHP worker?

Wyobraź sobie PHP Workera jako kasjera w sklepie.

• Jeśli masz 10 kasjerów (10 workers).
• Każdy klient (odwiedzający) potrzebuje 1 sekundy na obsłużenie (czas generowania strony).
• Możesz obsłużyć maksymalnie 10 klientów na sekundę.

Jeśli przyjdzie 11. klient, musi czekać w kolejce. Jeśli kolejka się zapełni -> Błąd 503.

#Wzór na przepustowość:

Maksymalny Ruch (RPS) = Liczba Workerów / Średni Czas Generowania Strony

Masz 10 workerów na hostingu współdzielonym.

• Strona generuje się 0.5s -> Możesz przyjąć 20 osób/sekundę.
• Strona generuje się 2.0s -> Możesz przyjąć tylko 5 osób/sekundę!

Wniosek: Aby skalować, musisz albo dokupić kasjerów (droższe serwery VPS/Dedykowane), albo sprawić, by kasjerzy pracowali szybciej (Optymalizacja kodu/Cache).

#2. Poziom 1: Full page cache (fpc) – Omiń PHP

Najszybszy PHP to taki, który się nie uruchamia.

Jeśli Twoja strona jest statyczna (np. artykuł na blogu), nie ma sensu, by PHP generował ją za każdym razem od nowa. Powinieneś serwować gotowy plik HTML.

#Rozwiązania:

1. Wtyczki (Podstawowe): WP Rocket, W3 Total Cache. Tworzą pliki HTML na dysku. Dobre dla małych stron, ale przy dużym ruchu “zabijają dysk” operacjami I/O.
2. Server-Side Cache (Profesjonalne):
   • Varnish: Serwer proxy, który trzyma całą stronę w pamięci RAM przed Apache/Nginx. Czas odpowiedzi: ~5ms.
   • Nginx FastCGI Cache: Wbudowane w Nginx. Bardzo wydajne.
   • Cloudflare (Edge Cache): Serwowanie strony z serwerów Cloudflare, zanim ruch w ogóle dotrze do Twojego hostingu.

Zasada: W idealnym świecie 95% ruchu anonimowego (niezalogowanego) nie powinno w ogóle dotykać PHP.

#3. Poziom 2: Object cache (Redis) – Odciąż bazę danych

Co że sklepami WooCommerce lub panelami użytkownika, których nie da się w pełni skaszować w HTML? Tam PHP musi pracować.

WordPress przy każdym ładowaniu wykonuje dziesiątki tych samych zapytań SQL: “Pobierz opcje strony”, “Pobierz ID kategorii”, “Pobierz metadane usera”.

Redis (Object Cache) przechowuje wyniki tych zapytań w pamięci RAM. Zamiast pytać MySQL (wolny dysk), PHP pyta Redis (szybki RAM).

• Bez Redisa: 150 zapytań SQL na odsłonę.
• Z Redisem: 5 zapytań SQL na odsłonę.

W 2026 roku uruchamianie WooCommerce bez Redisa to samobójstwo.

#4. Case study: Fuckup night (analiza awarii)

Oto historia jednej z naszych awarii, którą analizowaliśmy na spotkaniu WordUp.

Pacjent: Serwis informacyjny. Objawy: Nagły skok ruchu (Black Friday), serwer padł w 3 minuty. CPU 100%.

#Co poszło nie tak? (Diagnostyka)

1. Zabójczy Ajax: Pewna wtyczka “Licznik Odwiedzin” wysyłała zapytanie AJAX (admin-ajax.php) przy każdym wejściu użytkownika, by zliczyć wizytę.

   • Ajax w WordPressie zawsze uruchamia cały silnik PHP (wszystkie wtyczki).
   • To zapytanie NIE było cache’owane.
   • 10,000 wejść = 10,000 pełnych uruchomień WordPressa. Limit PHP Workers wyczerpany w 10 sekund.

2. Brak Indeksów w Bazie: Tabela z postami miała 500,000 rekordów. Wtyczka do “Podobnych wpisów” robiła ORDER BY RAND(). To zarżnęło bazę MySQL.

#Jak to naprawiliśmy?

1. Wyłączenie Ajaxa: Zastąpiliśmy licznik wtyczką Google Analytics (JavaScript po stronie klienta).
2. Redis: Wdrożenie Redisa zmniejszyło obciążenie MySQL o 90%.
3. Varnish: Skonfigurowaliśmy Varnish, by serwował stronę główną z RAMu.

Wynik: Serwer, który dławił się przy 100 userach, nagle obsłużył 5000 userów jednocześnie, a CPU spadło do 5%.

#5. Jak monitorować?

Nie zgaduj “czemu muli”.

1. Query Monitor (Dev): Wtyczka, która pokazuje wolne zapytania SQL i zużycie pamięci na bieżącej stronie.
2. New Relic (Pro): Zaawansowany monitoring APM. Pokazuje dokładnie, która funkcja PHP lub wtyczka zajmuje najwięcej czasu.
3. Logs: tail -f /var/log/nginx/error.log (patrz nasz poradnik o SSH).

#Podsumowanie: Lista kontrolna high traffic

Przygotowujesz się na duży ruch?

1. Hosting: Wybierz taki z Redisem i konfigurowalnym limitem PHP Workers (np. dedykowany, cloud VPS).
2. Cache: Skonfiguruj Nginx FastCGI Cache lub Varnish.
3. Baza: Zainstaluj wtyczkę Object Cache (np. Redis Object Cache).
4. Sprzątanie: Wyłącz wtyczki używające admin-ajax.php na frontendzie.
5. CDN: Przenieś obrazki i CSS do Cloudflare.

Stabilny WordPress to nie magia. To matematyka. Zmniejsz czas generowania (Cache) i zwiększ przepustowość (Workers + Redis).

Potrzebujesz pomocy że skalowaniem? Jako specjalista WordPress pomagam przygotować strony na duży ruch. Sprawdź cennik usług WordPress.