OPcache na hostingu — co daje WordPressowi i jak sprawdzić, czy działa?

OPcache przyspiesza wykonywanie PHP, przechowując skompilowaną postać kodu w pamięci współdzielonej. Dzięki temu przy kolejnych żądaniach PHP nie musi za każdym razem ponownie wczytywać i kompilować tych samych plików źródłowych.

Dla WordPressa ma to znaczenie, ponieważ pojedyncze żądanie może ładować kod rdzenia, motywu i wielu wtyczek. OPcache nie zapisuje jednak gotowej strony HTML, nie zastępuje Redis i nie naprawia wolnych zapytań do bazy danych. Przyspiesza konkretny etap wykonywania kodu PHP.

Najprościej rozróżnić te mechanizmy tak: OPcache przechowuje skompilowany kod PHP, object cache przechowuje dane używane przez aplikację, a page cache może ominąć wykonanie dużej części WordPressa, zwracając wcześniej przygotowaną odpowiedź.

OPcache, Redis i page cache — trzy różne warstwy

PHP przed wykonaniem kodu musi wczytać pliki źródłowe, przeanalizować je i przekształcić do postaci wykonywanej przez silnik Zend. OPcache zapisuje taki skompilowany bytecode w pamięci współdzielonej, dzięki czemu przy kolejnych żądaniach nie trzeba wykonywać całego tego etapu od początku.

W WordPressie korzyść dotyczy przede wszystkim kosztu uruchamiania kodu PHP. Nadal mogą jednak wykonywać się zapytania do bazy, połączenia z zewnętrznymi usługami, logika wtyczek i generowanie HTML.

Persistent object cache, na przykład Redis, działa w innym miejscu. WordPress może przechowywać w nim dane i wyniki części operacji pomiędzy kolejnymi żądaniami. Page cache idzie jeszcze dalej: dla cache'owalnego żądania może zwrócić gotową odpowiedź bez pełnego uruchamiania WordPressa.

Mechanizm	Co przechowuje	Co może ograniczyć
OPcache	Skompilowany bytecode PHP	Powtarzane parsowanie i kompilowanie plików PHP
Persistent object cache, np. Redis	Dane i obiekty używane przez aplikację	Powtarzane pobieranie lub obliczanie części danych
Page cache	Gotową odpowiedź lub jej dużą część	Pełne wykonywanie WordPressa dla cache'owalnego żądania

Te mechanizmy mogą działać równocześnie i uzupełniać się. Redis szerzej opisujemy w poradniku Redis na hostingu — kiedy przyspiesza WordPressa i kiedy nie?.

Czy OPcache powinien działać na hostingu WordPress?

WordPress Hosting Handbook rekomenduje włączenie OPcache dla produkcyjnych żądań webowych oraz dobranie jego parametrów do strony lub całej platformy hostingowej.

W typowym środowisku produkcyjnym OPcache pozwala uniknąć wielokrotnego kompilowania tego samego kodu. Sama informacja „OPcache: tak” mówi jednak niewiele o jakości konfiguracji. Znaczenie mają także dostępna pamięć, limit skryptów i sposób odświeżania cache po zmianach kodu.

Najważniejsze parametry OPcache

Lista dyrektyw jest długa, ale przy ocenie hostingu kilka z nich wyjaśnia większość praktycznych problemów.

opcache.enable

opcache.enable określa, czy opcode cache jest włączony dla PHP.

Przy sprawdzaniu hostingu liczy się konfiguracja używana przez stronę WWW. PHP uruchamiane w terminalu może mieć inne ustawienia niż PHP-FPM obsługujące witrynę.

opcache.memory_consumption

opcache.memory_consumption określa wielkość pamięci współdzielonej przeznaczonej na OPcache.

Jeżeli przydzielona pamięć jest zbyt mała, OPcache może przestać mieścić kolejne potrzebne skrypty, a przy określonych warunkach zaplanować restart cache. Dlatego sama obecność wolnego RAM-u na koncie nie mówi, czy przestrzeń OPcache została właściwie dobrana.

Nie ma jednej wartości odpowiedniej dla każdej instalacji. Prosta witryna z kilkoma wtyczkami i duży sklep z rozbudowanym zestawem rozszerzeń mają inny zbiór plików PHP.

opcache.max_accelerated_files

opcache.max_accelerated_files określa maksymalną liczbę kluczy skryptów, które mogą znaleźć się w tablicy OPcache.

To ograniczenie niezależne od samej ilości pamięci. Rozbudowana instalacja WordPressa może zawierać tysiące plików PHP, dlatego przy ocenie konfiguracji warto patrzeć na oba parametry razem.

opcache.validate_timestamps

opcache.validate_timestamps decyduje, czy OPcache sprawdza zmiany plików źródłowych.

Jeśli jest włączony, częstotliwość kontroli zależy między innymi od opcache.revalidate_freq. Przy wyłączonej walidacji zmieniony plik nie zostanie automatycznie potraktowany jako nowa wersja tylko dlatego, że zmienił się na dysku. Wdrożenie musi wtedy zapewnić unieważnienie lub reset cache albo odpowiedni restart procesów.

Pamięć OPcache i memory_limit to dwa różne zasoby

memory_limit ogranicza pamięć dostępną dla wykonywanego skryptu PHP. opcache.memory_consumption dotyczy współdzielonej pamięci używanej do przechowywania skompilowanego kodu.

Podniesienie memory_limit WordPressa nie zwiększa więc przestrzeni OPcache, a większy OPcache nie daje pojedynczemu requestowi wyższego limitu pamięci.

Stary kod po wdrożeniu — kiedy winny może być OPcache?

Przy niewłaściwej konfiguracji może pojawić się sytuacja, w której plik na dysku został zmieniony, a aplikacja nadal zachowuje się jak przed aktualizacją.

Dotyczy to szczególnie środowisk, w których wyłączono sprawdzanie timestampów, a proces wdrożenia nie unieważnia OPcache w odpowiednim momencie.

Podobny objaw mogą jednak powodować inne warstwy:

• page cache,
• reverse proxy,
• CDN,
• cache obiektowy,
• inna kopia pliku używana przez aplikację,
• wdrożenie do niewłaściwego katalogu.

W praktyce najpierw trzeba ustalić, która warstwa przechowuje starą wersję, zamiast resetować wszystkie cache naraz.

Jak sprawdzić konfigurację i stan OPcache?

Najprościej zacząć od panelu hostingu lub dokumentacji operatora. Część dostawców pokazuje OPcache jako element konfiguracji PHP, inni zarządzają nim wyłącznie po stronie serwera.

Przy dostępie do konfiguracji przydatne są między innymi:

opcache.enable
opcache.memory_consumption
opcache.max_accelerated_files
opcache.validate_timestamps
opcache.revalidate_freq

PHP udostępnia również funkcje opcache_get_configuration() oraz opcache_get_status(). Mogą zwrócić informacje o konfiguracji i stanie cache, choć administrator hostingu może ograniczyć dostęp do części danych.

CLI nie zawsze pokazuje konfigurację strony

Polecenie:

php -i | grep -i opcache

pokazuje ustawienia PHP uruchamianego przez CLI. Strona WWW może działać przez PHP-FPM z inną wersją interpretera, innym zestawem plików INI i inną konfiguracją OPcache.

Wynik z terminala jest więc użyteczny dopiero po potwierdzeniu, że opisuje to samo środowisko, które obsługuje stronę. Ten sam problem omawiamy w poradniku o limitach PHP na hostingu.

Co sprawdzić w statusie OPcache?

Jeżeli środowisko udostępnia status, warto zwrócić uwagę przede wszystkim na wykorzystaną i wolną pamięć, liczbę przechowywanych skryptów oraz informacje o restartach cache.

Problem staje się bardziej prawdopodobny, gdy:

• cache regularnie nie mieści kolejnych potrzebnych skryptów,
• liczba przechowywanych plików dochodzi do ograniczenia,
• pojawiają się restarty związane z brakiem miejsca lub nadmierną ilością pamięci oznaczonej jako zmarnowana,
• po wdrożeniach występują problemy z odświeżaniem kodu.

Nie ma jednego procentowego progu, po którego przekroczeniu każda instalacja WordPressa wymaga takiej samej zmiany konfiguracji.

Jak OPcache wygląda na hostingu współdzielonym?

Na hostingu współdzielonym użytkownik często nie kontroluje najważniejszych parametrów OPcache. Wiele ustawień, w tym opcache.memory_consumption i opcache.max_accelerated_files, ma poziom INI_SYSTEM i jest konfigurowanych systemowo.

Własny wpis w .user.ini albo użycie ini_set() nie daje więc automatycznie możliwości zmiany tych wartości.

Także model współdzielenia cache zależy od architektury operatora. PHP-FPM może być rozdzielone na różne pule i konta, a sposób izolacji zasobów nie jest identyczny na każdej platformie.

Z tego powodu informacja typu „OPcache 128 MB” wymaga kontekstu. Nie mówi sama w sobie, czy jest to przestrzeń przypisana do jednej witryny, konta, puli PHP czy szerszego środowiska.

Użytkownik hostingu może przede wszystkim sprawdzić:

• czy OPcache jest aktywny dla WWW,
• czy operator publikuje jego parametry,
• czy support potrafi wyjaśnić sposób przydzielania zasobów,
• czy dostępny jest status cache,
• jak środowisko odświeża OPcache po zmianie kodu.

Kiedy OPcache pomoże, a kiedy problem leży gdzie indziej?

OPcache zmniejsza koszt przygotowania kodu PHP do wykonania. Jeżeli to istotna część czasu requestu, efekt może być zauważalny.

Nie rozwiązuje jednak problemów wynikających z:

• wolnych zapytań SQL,
• zewnętrznego API odpowiadającego przez kilka sekund,
• przeciążonego CPU,
• braku page cache,
• kosztownych operacji wykonywanych przez wtyczkę,
• zbyt małej liczby PHP workers.

PHP workers są osobnym ograniczeniem. OPcache może skrócić część czasu zajmowania workera, ale nie zwiększa liczby procesów zdolnych do równoległego obsługiwania żądań.

Jeżeli problemem jest ogólna wydajność WordPressa, zacznij od poradnika Dlaczego WordPress działa wolno — hosting czy sama strona?. Z kolei zależność od liczby procesów opisujemy w poradniku PHP workers na hostingu — ile ich potrzeba i co naprawdę ograniczają?.

JIT i preloading — funkcje dodatkowe, nie podstawa wyboru hostingu

JIT

OPcache i JIT są powiązane w implementacji PHP, ale wykonują inne zadania. Podstawowy OPcache przechowuje skompilowany bytecode PHP, natomiast JIT może dodatkowo kompilować część kodu do kodu maszynowego.

Od PHP 8.4 domyślna wartość opcache.jit to disable. Włączony OPcache nie oznacza więc automatycznie działającego JIT.

Dla typowej aplikacji webowej ważniejsze jest prawidłowe działanie podstawowego OPcache i właściwie dobrane zasoby niż sam checkbox „JIT”.

Preloading

PHP umożliwia preloading od wersji 7.4. Pozwala skompilować wskazane pliki przy uruchamianiu procesu i utrzymywać zdefiniowane w nich klasy oraz funkcje pomiędzy żądaniami.

Preloading zwiększa bazowe wykorzystanie pamięci, a zmiana preładowanego kodu wymaga ponownego uruchomienia procesu. To funkcja wymagająca świadomego zaprojektowania konfiguracji, a nie uniwersalny parametr, którego należy wymagać od każdego hostingu WordPress.

Co sprawdzić przed zakupem i przy diagnozie problemu?

Przed zakupem hostingu

Jeżeli zależy Ci na wydajności PHP, warto ustalić:

• czy OPcache jest włączony dla stron WWW,
• czy działa dla wszystkich oferowanych wersji PHP,
• czy operator publikuje lub udostępnia jego podstawowe parametry,
• czy użytkownik ma możliwość podejrzenia statusu,
• jak hosting odświeża OPcache po zmianach kodu,
• czy zasoby cache są zarządzane per konto, per pulę PHP czy w inny sposób.

Brak danych warto potraktować jako pytanie do operatora zamiast zakładać konkretną pojemność albo model izolacji.

Jeżeli analizujesz konkretny pakiet, możesz przejść również przez audyt planu hostingowego przed zakupem.

Gdy podejrzewasz problem z OPcache

1. Potwierdź, że diagnozujesz PHP używane przez WWW.
2. Sprawdź, czy OPcache jest aktywny.
3. Jeśli masz dostęp do statusu, sprawdź pamięć, liczbę skryptów i restarty.
4. Ustal, czy problem występuje stale, czy przede wszystkim po zmianie kodu.
5. Oddziel OPcache od page cache, CDN i object cache.
6. Jeżeli ustawienia są systemowe, poproś operatora o weryfikację zamiast dodawać przypadkowe dyrektywy do konfiguracji użytkownika.

Przy problemach obejmujących również CPU, RAM, procesy lub I/O przydatna będzie diagnostyka zasobów hostingu.

Najważniejsze wnioski

• OPcache przechowuje skompilowany bytecode PHP i ogranicza potrzebę ponownego parsowania oraz kompilowania tych samych skryptów;
• OPcache, Redis i page cache działają na różnych warstwach i mogą się uzupełniać;
• dla produkcyjnych środowisk WordPress zalecane jest włączenie OPcache dla żądań webowych;
• sama informacja „OPcache włączony” nie mówi, czy właściwie dobrano pamięć i limit skryptów;
• opcache.memory_consumption i PHP memory_limit to różne zasoby;
• konfiguracja PHP CLI może różnić się od środowiska obsługującego stronę WWW;
• przy wyłączonej walidacji timestampów wdrożenie musi zapewnić prawidłowe odświeżenie cache;
• OPcache nie zwiększa liczby PHP workers i nie usuwa problemów z wolną bazą danych albo zewnętrznym API;
• JIT i preloading są funkcjami dodatkowymi, a nie podstawą oceny hostingu WordPress.

Źródła

1. PHP Manual — OPcache — działanie opcode cache i funkcje diagnostyczne.
2. PHP Manual — OPcache Runtime Configuration — parametry pamięci, liczby skryptów, walidacji timestampów i JIT.
3. PHP Manual — OPcache Installation — instalacja i przykładowe ustawienia konfiguracji.
4. PHP Manual — Preloading — działanie preloadingu, pamięć i wymaganie restartu procesu.
5. Make WordPress Hosting Handbook — Performance — zalecenie OPcache dla środowisk produkcyjnych WordPress oraz podstawowe parametry do monitorowania.