Optymalizacja serwera PHP i MySQL dla szybszego WordPressa

Serwer jako najczęstsze wąskie gardło WordPressa

Optymalizacja kodu, cache, CDN - to wszystko ważne elementy wydajności strony. Ale prawda jest taka: jeśli Twój serwer jest źle skonfigurowany, możesz zoptymalizować kod ile chcesz - strona i tak będzie wolna.

W 2025 roku większość właścicieli stron WordPress koncentruje się na pluginach do cache i optymalizacji obrazów. To dobre praktyki, ale pomijają fundamentalną kwestię: konfiguracja samego serwera jest najważniejszym czynnikiem wydajności.

W tym artykule dowiesz się, jak skonfigurować PHP i MySQL/MariaDB, aby Twój WordPress działał błyskawicznie, obsługiwał więcej użytkowników jednocześnie i kosztował Cię mniej.

Aktualna wersja PHP - co ma znaczenie w 2025 roku

Dlaczego wersja PHP ma znaczenie

PHP to język, w którym napisany jest WordPress. Każda nowa wersja PHP przynosi nie tylko nowe funkcje, ale przede wszystkim znaczące usprawnienia wydajności.

Porównanie wydajności - orientacyjne różnice

PHP 7.4 (przestarzała, ale wciąż popularna)

• Request time: 100% (baseline)
• Memory usage: 100%
• Throughput: ~400 requests/s
• Uwaga: PHP 7.4 nie jest już oficjalnie wspierana - brak aktualizacji bezpieczeństwa!

PHP 8.1 (wciąż spotykane, ale schodzące ze sceny)

• Request time: ~15% szybszy niż 7.4
• Memory usage: ~10% mniejsze zużycie RAM
• Throughput: ~480 requests/s (+20%)
• Kompilator JIT (Just-In-Time) dla wybranych operacji

PHP 8.3 (najbezpieczniejszy wybór na 2025)

• Request time: ~30% szybszy niż 7.4, ~12% szybszy niż 8.1
• Memory usage: ~18% mniejsze zużycie niż 7.4
• Throughput: ~540 requests/s (+35% vs 7.4)
• Ulepszone JIT, lepsze odśmiecanie pamięci, nowe optymalizacje kompilacji

Rekomendacja na 2025 rok: dla nowych wdrożeń celuj w PHP 8.3. PHP 8.4 warto rozważyć dopiero po sprawdzeniu kompatybilności motywu, wtyczek i integracji. Jeśli nadal używasz PHP 7.4, aktualizacja powinna być priorytetem.

Jak sprawdzić wersję PHP i ją zmienić

W większości hostingów zmiana wersji PHP to kilka kliknięć w panelu administracyjnym (cPanel, DirectAdmin, Plesk, HestiaCP). Przed zmianą:

• Sprawdź kompatybilność pluginów i motywu z nową wersją PHP
• Zrób pełny backup strony
• Przetestuj zmiany na środowisku stagingowym, jeśli to możliwe

Ustawienia php.ini - kluczowe parametry dla WordPressa

Plik php.ini kontroluje zachowanie PHP na serwerze. Poprawna konfiguracja może podwoić wydajność WordPressa bez żadnych innych zmian.

Kluczowe parametry php.ini dla WordPressa

1. memory_limit

Co robi: Definiuje maksymalną ilość RAM, jaką może użyć pojedynczy skrypt PHP.

Domyślna wartość: 128M (często za mało dla WordPress)

Rekomendacja:

• Mała strona (blog, wizytówka): 256M
• Średnia strona / e-commerce: 512M
• Duża strona / WooCommerce z dużą ilością produktów: 1024M (1G)

memory_limit = 512M

2. max_execution_time

Co robi: Maksymalny czas wykonania skryptu (w sekundach).

Domyślna wartość: 30s

Rekomendacja: 300s (5 minut) - szczególnie ważne dla importów, migracji, backupów

max_execution_time = 300

3. max_input_time

Co robi: Maksymalny czas parsowania danych wejściowych (POST/GET).

Rekomendacja: 300s

max_input_time = 300

4. upload_max_filesize i post_max_size

Co robią: Maksymalny rozmiar uploadowanego pliku i danych POST.

Rekomendacja:

• upload_max_filesize: 128M (dla dużych obrazów, filmów)
• post_max_size: 256M (musi być większe niż upload_max_filesize)

upload_max_filesize = 128M
post_max_size = 256M

OPcache - przełomowa technologia dla wydajności PHP

OPcache to najważniejsza optymalizacja PHP, którą możesz włączyć. Przechowuje skompilowany kod PHP w pamięci, dzięki czemu nie musi kompilować go przy każdym request.

Efekt włączenia OPcache:

• 2-3x szybsze wykonanie kodu PHP
• Mniejsze obciążenie CPU
• Możliwość obsługi 2-3x więcej równoczesnych użytkowników

Rekomendowana konfiguracja OPcache dla WordPressa:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.validate_timestamps=1

Większość współczesnych hostingów ma OPcache włączone domyślnie. Sprawdź w informacji o PHP (funkcja phpinfo()) czy opcache.enable = On.

Optymalizacja MySQL/MariaDB dla WordPressa

Baza danych to drugi krytyczny element wydajności WordPressa. Wolne zapytania MySQL = wolna strona, nawet jeśli PHP jest błyskawiczne.

W nowych wdrożeniach trzymaj się MySQL 8.0+ albo MariaDB 10.6+, bo to poziom zgodny z aktualnymi wymaganiami WordPressa i WooCommerce pod koniec 2025 roku.

1. Pamięć podręczna zapytań (uwaga: usunięta w MySQL 8.0)

Pamięć podręczna zapytań przechowywała wyniki zapytań w pamięci. Niestety, MySQL 8.0 całkowicie usunął pamięć podręczną zapytań ze względu na problemy z wydajnością w środowiskach wielordzeniowych.

Jeśli używasz MariaDB lub starszego MySQL: pamięć podręczna zapytań może być jeszcze dostępna, ale w praktyce lepiej postawić na Redis lub Memcached jako zewnętrzną pamięć podręczną.

2. Indeksy - kluczowe dla wydajności zapytań

Indeksy to jak spis treści w książce - umożliwiają szybkie znalezienie danych bez przeszukiwania całej tabeli.

Podstawowe indeksy dla WordPressa

WordPress domyślnie tworzy indeksy na kluczowych kolumnach (np. post_status, post_type). Ale jeśli używasz niestandardowych zapytań lub pluginów, mogą brakować indeksów.

Jak znaleźć brakujące indeksy:

Użyj pluginu Query Monitor - pokaże Ci wolne zapytania i sugestie gdzie dodać indeksy.

3. Slow Query Log - znajdź wolne zapytania

MySQL może logować wszystkie zapytania, które wykonują się dłużej niż X sekund.

Jak włączyć slow query log:

W my.cnf (konfiguracja MySQL):

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-query.log
long_query_time = 2

Loguje zapytania dłuższe niż 2 sekundy. Później możesz je przeanalizować i zoptymalizować (dodać indeksy, przepisać zapytanie).

4. Kluczowe parametry my.cnf dla WordPressa

Dla małej strony (VPS 2GB RAM):

innodb_buffer_pool_size = 512M
max_connections = 100
query_cache_size = 0  # wyłączone w MySQL 8.0+
table_open_cache = 2000

Dla średniej strony (VPS 4-8GB RAM):

innodb_buffer_pool_size = 2G
max_connections = 200
table_open_cache = 4000

innodb_buffer_pool_size to najważniejszy parametr - przechowuje dane i indeksy w pamięci RAM. Ustaw go na 50-70% dostępnej pamięci RAM dedykowanej dla MySQL.

Monitorowanie obciążenia serwera

Nie możesz optymalizować tego, czego nie mierzysz. Monitoring to klucz do zrozumienia wąskich gardeł.

1. htop - monitoring procesów w czasie rzeczywistym

htop to interaktywna wersja top - pokazuje procesor, pamięć RAM, procesy w czasie rzeczywistym.

Instalacja:

sudo apt install htop  # Ubuntu/Debian
sudo yum install htop  # CentOS/RedHat

Uruchomienie:

htop

Na co zwrócić uwagę:

• Użycie procesora: czy serwer jest przeciążony?
• Użycie pamięci: czy MySQL/PHP zużywają za dużo RAM?
• Obciążenie systemu: optymalne < liczba rdzeni procesora

2. MySQLTuner - automatyczna analiza MySQL

MySQLTuner to skrypt Perl, który analizuje konfigurację MySQL i podaje rekomendacje optymalizacji.

Instalacja i uruchomienie:

wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
perl mysqltuner.pl

MySQLTuner przeskanuje Twoją bazę danych i poda konkretne rekomendacje (np. "zwiększ innodb_buffer_pool_size do 2G").

3. New Relic / Datadog / Netdata - rozbudowany monitoring

Jeśli potrzebujesz danych historycznych, alertów i dokładniejszego profilowania, narzędzia takie jak New Relic, Datadog czy Netdata dają znacznie szerszy obraz niż podstawowe logi serwera.

• Dashboardy w czasie rzeczywistym
• Alerty przy problemach (email, SMS, Slack)
• Profilowanie PHP i MySQL
• Dane historyczne - zobacz jak wydajność zmieniała się w czasie

Praktyczne przykłady konfiguracji

Konfiguracja dla małej strony (blog, wizytówka)

Specyfikacja serwera:

• VPS: 1-2 rdzenie procesora, 2GB RAM
• Ruch: < 5000 odwiedzin/dzień

PHP (php.ini):

memory_limit = 256M
max_execution_time = 180
opcache.memory_consumption = 128

MySQL (my.cnf):

innodb_buffer_pool_size = 512M
max_connections = 50

Konfiguracja dla dużej strony (e-commerce, portal)

Specyfikacja serwera:

• VPS: 4-8 rdzeni procesora, 8-16GB RAM
• Ruch: 20,000-100,000 odwiedzin/dzień

PHP (php.ini):

memory_limit = 1024M
max_execution_time = 300
opcache.memory_consumption = 512
opcache.max_accelerated_files = 20000

MySQL (my.cnf):

innodb_buffer_pool_size = 6G
max_connections = 300
table_open_cache = 8000

Dodatkowe optymalizacje:

• Redis/Memcached jako pamięć podręczna obiektów
• CDN (Cloudflare, KeyCDN)
• Nginx jako odwrotne proxy przed Apache (lub tylko Nginx)

Podsumowanie - optymalny serwer = mniejsze koszty i szybszy WordPress

Kluczowe wnioski z optymalizacji serwera PHP i MySQL:

• Przejście z PHP 7.4 na 8.3 to zwykle najszybszy sposób na wyraźną poprawę wydajności i bezpieczeństwa
• Włącz OPcache - 2-3x szybszy PHP za darmo
• Dostosuj memory_limit i max_execution_time do rozmiaru strony
• Optymalizuj MySQL: innodb_buffer_pool_size to klucz (50-70% RAM dla MySQL)
• Monitoruj: htop, MySQLTuner, opcjonalnie New Relic
• Dodaj indeksy do wolnych zapytań (użyj Query Monitor)

Poprawna konfiguracja serwera może podwoić lub potroić wydajność WordPressa bez żadnych zmian w kodzie. To fundament - dopiero później optymalizuj pluginy, cache, obrazy.

Dobrze skonfigurowany serwer oznacza szybszą stronę, stabilniejsze działanie i mniejsze zużycie zasobów. Dopiero na takim fundamencie warto dopinać kolejne optymalizacje.