Czym jest object cache? Redis i Memcached w WordPressie wyjaśnione

Object cache, po polsku cache obiektów, przechowuje wyniki zapytań do bazy danych w pamięci RAM, dzięki czemu WordPress nie musi przy następnym żądaniu znowu pobierać ich z bazy. Brzmi mało spektakularnie. Ale w sklepach, serwisach członkowskich i wszędzie tam, gdzie zalogowanych jest wielu użytkowników, często to właśnie on najmocniej skraca czas ładowania. WordPress ma co prawda własny object cache, tyle że ten zapomina wszystko po każdym wczytaniu strony. Dopiero z Redisem albo Memcached w tle zmienia się w persystentny object cache, który trzyma dane przez wiele kolejnych żądań. Z tego artykułu dowiesz się, jak to dokładnie działa, czym różnią się Redis i Memcached, kiedy ten wysiłek się opłaca i jakich błędów unikać przy konfiguracji.

Czym jest object cache w WordPressie?

Za każdym razem, gdy ktoś otwiera stronę Twojej witryny, WordPress składa ją z mnóstwa drobnych elementów. Wczytuje ustawienia witryny, menu, widżety, sam wpis, dane autora, kategorie, tagi i wszystko, czego dodatkowo potrzebują Twoje wtyczki. Prawie wszystko to siedzi w bazie danych (MySQL albo MariaDB). Na zwykłej stronie szybko uzbiera się w ten sposób od 50 do 150 zapytań do bazy, a z WooCommerce i kilkoma większymi wtyczkami wyraźnie więcej. Wiele z nich przy każdym wywołaniu pyta dokładnie o to samo: Jak nazywa się witryna? Które wtyczki są aktywne? Jak wygląda menu główne?

Object cache zapamiętuje odpowiedzi na takie pytania. WordPress najpierw zagląda do cache i dopiero gdy nic tam nie znajdzie, zapytanie trafia do bazy danych. Wynik ląduje potem w cache i następnym razem jest gotowy od ręki. Nazwa bierze się stąd, że WordPress nie odkłada tam gotowych stron, tylko pojedyncze obiekty danych: wpis, listę opcji, metadane użytkownika.

Wyobraź sobie karteczkę przyklejoną obok klawiatury. Zamiast za każdym razem grzebać w szafie z dokumentami, najpierw zerkasz na karteczkę. Przy jednym pytaniu oszczędzasz w ten sposób niewiele czasu. Ale gdy to samo pytanie pada tysiąc razy dziennie, oszczędzasz bardzo dużo.

Jak działa object cache w WordPressie?

WordPress od wielu lat ma własną klasę do obsługi cache obiektów, WP_Object_Cache. Rdzeń WordPressa i wiele wtyczek korzysta z niej przez funkcje takie jak wp_cache_get() i wp_cache_set(). Jest jednak haczyk: bez dodatkowego oprogramowania ten cache żyje tylko tak długo, jak pojedyncze wczytanie strony. Gdy strona trafi już do przeglądarki, pamięć jest znowu pusta, a przy kolejnym odwiedzającym wszystko zaczyna się od nowa.

Mimo to taki nietrwały cache nie jest bezużyteczny, bo zapobiega powtarzaniu tych samych zapytań w obrębie jednego wywołania. Naprawdę ciekawie robi się jednak dopiero z persystentnym cache obiektów. Do tego potrzebny jest plik o nazwie object-cache.php w katalogu wp-content. WordPress wykrywa go automatycznie przy starcie i zamiast własnej pamięci tymczasowej korzysta wtedy z zewnętrznej usługi, takiej jak Redis albo Memcached. Dane zostają tam przez wiele wczytań strony, dopóki nie wygasną, nie zmienią się albo dopóki pamięć się nie zapełni. Tego pliku nie musisz pisać sam. Wtyczki takie jak Redis Object Cache mają go w zestawie i przy aktywacji umieszczają we właściwym miejscu.

Jest też efekt uboczny, o którym mało kto wie, a dotyczy tak zwanych transientów. To zbuforowane wartości z datą ważności, chętnie używane przez wtyczki, na przykład do przechowywania odpowiedzi z zewnętrznych API. Bez persystentnego cache obiektów transienty lądują w tabeli wp_options, która z czasem przez nie puchnie. Z Redisem albo Memcached przenoszą się do pamięci RAM, a baza danych pozostaje szczuplejsza.

Object cache, cache strony i OPcache: czym się różnią?

Gdy mowa o WordPressie i cachingu, szybko padają trzy pojęcia, które łatwo ze sobą pomylić. Działają na różnych poziomach i uzupełniają się nawzajem, zamiast się zastępować.

• Cache strony (page cache): zapisuje całą gotową stronę jako HTML i serwuje ją, w ogóle nie uruchamiając WordPressa. Tak działają na przykład WP Rocket, LiteSpeed Cache czy WP Super Cache. Szybciej się nie da, ale tylko dopóki wszyscy odwiedzający widzą tę samą stronę.
• Object cache: przechowuje pojedyncze wyniki z bazy danych. WordPress nadal uruchamia się przy każdym żądaniu, ale do bazy musi zaglądać znacznie rzadziej.
• OPcache: nie ma nic wspólnego z Twoimi danymi. Sprawia, że PHP nie musi przy każdym żądaniu od nowa wczytywać i kompilować plików WordPressa. Dziś jest włączony praktycznie na każdym hostingu.

Najważniejsze jest to, że cache strony pomaga tylko przy stronach, które wyglądają tak samo dla wszystkich. Gdy ktoś jest zalogowany, dodaje coś do koszyka albo pracuje w panelu administracyjnym, cache strony zostaje pominięty. I właśnie tu wkracza object cache. Na blogu czytanym niemal wyłącznie przez anonimowych gości więcej da więc dobry cache strony. W sklepie, na platformie edukacyjnej albo na forum większy efekt daje często object cache.

Redis czy Memcached: który object cache wybrać dla WordPressa?

Oba systemy trzymają dane w pamięci RAM i zapisują je jako proste pary klucza i wartości. Jako object cache oba są wystarczająco szybkie. Różnice tkwią w szczegółach.

Redis to dziś standardowy wybór dla WordPressa. Potrafi przechowywać więcej niż same klucze i wartości, na przykład listy, hashe i zbiory, a jeśli chcesz, zapisuje swoją zawartość na dysku, dzięki czemu cache przetrwa restart. Do tego dochodzą replikacja, dokładniejsza kontrola dostępu i duży ekosystem. Dla WordPressa istnieje poza tym Redis Object Cache, bardzo popularna i dobrze utrzymywana wtyczka. Po zmianie licencji Redisa w 2024 roku powstał dodatkowo Valkey, otwarty fork pod skrzydłami Linux Foundation, z którego korzysta dziś wielu dostawców hostingu. Dla WordPressa zachowuje się dokładnie tak jak Redis i zwykle w ogóle nie zauważysz różnicy.

Memcached jest starszy i celowo prosty. Zna tylko klucze i wartości, niczego nie zapisuje na stałe i przy każdym restarcie traci całą zawartość. W zamian wykorzystuje jednocześnie kilka rdzeni procesora i bardzo łatwo rozłożyć go na kilka serwerów. Jest też limit, na który przy WordPressie czasem się trafia: pojedynczy element może mieć domyślnie najwyżej 1 MB. Przy bardzo dużych opcjach, na przykład rozdętych ustawieniach niektórych page builderów, może to sprawiać problemy.

Nasza rada: jeśli Twój hostingodawca oferuje oba, postaw na Redis. Jeśli dostępny jest tylko Memcached, nie ma powodu do zmartwień, jako object cache w zupełności wystarczy. Dużo ważniejsze od wyboru między nimi jest to, żeby persystentny cache obiektów w ogóle działał i był rozsądnie skonfigurowany. Trzecim kandydatem jest zresztą APCu, cache wbudowany bezpośrednio w PHP. Nie potrzebuje osobnej usługi, ale działa tylko na jednym serwerze i w praktyce odgrywa mniejszą rolę.

Kiedy opłaca się persystentny cache obiektów?

Object cache to nie cudowny lek. To, ile da, zależy od tego, jak wiele żądań omija cache strony i trafia prosto do WordPressa oraz ile pracy ma przy nich baza danych. Efekt najbardziej czuć tutaj:

• Sklepy na WooCommerce, bo koszyk, kasa i konto klienta nigdy nie pochodzą z cache strony.
• Serwisy członkowskie, platformy edukacyjne i fora z wieloma zalogowanymi użytkownikami.
• Redakcje, w których kilka osób pracuje jednocześnie w panelu administracyjnym.
• Witryny z wieloma wtyczkami, które trzymają swoje dane w opcjach i transientach.
• Duże witryny z tysiącami wpisów, terminów albo użytkowników.

Sam WordPress też daje Ci tu wskazówkę. Od wersji 6.1 ekran Kondycja witryny w menu Narzędzia zaleca persystentny cache obiektów, gdy Twoja witryna przekroczy określoną wielkość, na przykład ponad 1000 wpisów, komentarzy lub użytkowników.

Niewiele da natomiast object cache na małej stronie firmowej z dziesięcioma podstronami, którą odwiedzają prawie wyłącznie anonimowi goście i która ma już dobry cache strony. Tam cache strony i tak odpowiada na niemal każde żądanie, zanim WordPress w ogóle wystartuje.

Jak skonfigurować object cache z Redisem w WordPressie?

Dokładna droga zależy od Twojego hostingu. U wielu dostawców hostingu zarządzanego Redis jest już dostępny i włączysz go jednym przełącznikiem w panelu klienta, a niektórzy konfigurują nawet wszystko za Ciebie. W razie wątpliwości zapytaj krótko pomoc techniczną, zanim zaczniesz sam coś instalować. Na własnym serwerze wygląda to zwykle tak:

1. Zainstaluj i uruchom Redis, na Debianie albo Ubuntu na przykład z pakietu redis-server.
2. Zainstaluj rozszerzenie PHP phpredis (pakiet php-redis), żeby PHP mogło rozmawiać z Redisem. Wtyczka ma co prawda w zestawie Predis, wariant działający całkiem bez rozszerzenia, ale jest on wyraźnie wolniejszy.
3. Wpisz dane połączenia do wp-config.php, nad wierszem oznaczającym koniec edycji.
4. Zainstaluj wtyczkę Redis Object Cache i w jej ustawieniach włącz object cache. Wtyczka utworzy przy tym plik object-cache.php.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mysite_' );
define( 'WP_REDIS_MAXTTL', 86400 );

Prefiks ustawiaj zawsze, gdy z tej samej instancji Redisa korzysta kilka witryn. Bez niego dwie instalacje mogą nawzajem nadpisywać sobie dane, a to kończy się bardzo dziwnymi błędami. Jeśli wolisz wiersz poleceń, ostatni krok załatwisz poleceniem wp plugin install redis-cache --activate, a potem wp redis enable. Dla dużych sklepów jest jeszcze płatne rozwiązanie Object Cache Pro.

Jakie błędy przy object cache zdarzają się najczęściej?

Object cache konfiguruje się szybko, ale kilka pułapek wraca jak bumerang.

• Brak limitu pamięci: bez maxmemory Redis rośnie, dopóki na serwerze nie skończy się pamięć. Z limitem, ale z domyślną polityką noeviction, Redis odrzuca nowe dane, gdy tylko pamięć się zapełni, a WordPress nagle zaczyna sypać błędami. Dla cache właściwym wyborem jest allkeys-lru: Redis po prostu wyrzuca wtedy te elementy, których najdłużej nikt nie używał.
• Redis otwarty na internet: Redis powinien być dostępny tylko pod 127.0.0.1 albo w sieci prywatnej i mieć hasło. Otwarte instancje na porcie 6379 są w sieci celowo wyszukiwane i wykorzystywane przez atakujących.
• Nieaktualne dane po bezpośrednich zmianach: jeśli zmieniasz dane bezpośrednio w bazie, na przykład przez phpMyAdmin albo podczas importu, omijasz cache. WordPress dalej pokazuje wtedy stare wartości. Wyczyść potem cache, w ustawieniach wtyczki albo poleceniem wp cache flush.
• Zapomniany plik object-cache.php po przeprowadzce: gdy przenosisz witrynę na serwer bez Redisa, plik czasem zostaje w katalogu wp-content. W łagodnym przypadku zobaczysz tylko komunikat w panelu administracyjnym, w gorszym WordPress przerwie działanie z błędem krytycznym. Wtedy pomaga usunięcie pliku przez FTP.
• Redis na zdalnym serwerze: każde odwołanie do cache oznacza wtedy podróż przez sieć. Przy setkach odwołań na jedno wczytanie strony opóźnienia zjadają część zysku. Dlatego Redis powinien w miarę możliwości stać na tym samym serwerze, a przynajmniej w tym samym centrum danych.

maxmemory 256mb
maxmemory-policy allkeys-lru

Te dwa wiersze w redis.conf wystarczą większości witryn. Ile pamięci potrzebujesz, zależy od wielkości witryny. Dla typowego sklepu 256 MB to dobry punkt wyjścia.

Jak sprawdzić, czy object cache działa?

To, czy cache naprawdę pracuje, sprawdzisz na kilka sposobów:

• We wtyczce: Redis Object Cache pokazuje w swoich ustawieniach, czy połączenie działa, i podaje prostą statystykę trafień i chybień.
• W wierszu poleceń: wp cache type zdradza, który object cache jest aktywny. Jeśli widzisz tam Default, żaden persystentny cache nie działa.
• Za pomocą Query Monitor: ta darmowa wtyczka pokazuje dla każdego wczytania strony współczynnik trafień object cache i liczbę zapytań do bazy danych. Porównaj raz wartości z cache i bez niego, różnica często jest większa, niż się spodziewasz.
• Bezpośrednio w Redisie: redis-cli info stats zwraca między innymi keyspace_hits i keyspace_misses. Jeśli współczynnik trafień po kilku godzinach pracy wciąż jest niski, zwykle coś jest nie tak z konfiguracją, na przykład limit pamięci jest za mały.

Jak InspectWP pomaga ocenić caching Twojej witryny

Object cache pracuje na serwerze, więc z zewnątrz nie da się go zobaczyć bezpośrednio. Jego efekt już tak. Raport InspectWP mierzy między innymi Time to First Byte (TTFB), czyli czas, jaki mija, zanim pierwszy bajt strony dotrze z serwera. Wartości powyżej 800 milisekund InspectWP oznacza jako ostrzeżenie i właśnie tam object cache pomaga, gdy odpowiedź nie pochodzi z cache strony. Poza tym InspectWP rozpoznaje, które wtyczki odpowiadają za caching, w tym Redis Object Cache, po krótkim komentarzu, który wtyczka domyślnie zostawia w kodzie źródłowym. Razem z informacjami o dostawcy hostingu, serwerze i wersji PHP szybko zorientujesz się, czy w cachingu danej witryny jest jeszcze pole do poprawy.