Wtyczka Object Cache Pro - 1.25.6

Object Cache Pro to backend trwałej pamięci podręcznej obiektów dla WordPressa, oparty na Redisie – odciąża MySQL tam, gdzie cache stron nie sięga. Sprawdza się w sklepach WooCommerce i sieciach multisite, gdzie batch prefetching i kompresja danych obniżają koszt operacji na Redisie.

Object cache w Redisie a cache stron — co Object Cache Pro przyspiesza

Object Cache Pro zapisuje w Redisie wyniki zapytań do bazy danych, opcje WordPressa, metadane i transienty. Przy kolejnym żądaniu HTTP te same dane trafiają z pamięci operacyjnej – bez ponownego odpytywania MySQL. To warstwa uzupełniająca cache stron, nie jego zamiennik – pracuje tam, gdzie statyczny HTML nie wystarcza: koszyk, kasa, panel administracyjny, strony zalogowanych użytkowników.

Dlaczego wbudowany object cache WordPressa nie wystarcza

Standardowy object cache WordPressa jest nietrwały – przechowuje dane wyłącznie przez czas obsługi jednego żądania HTTP. Żądanie kończy się, pamięć znika. Przy kolejnym wejściu WordPress odpytuje bazę o te same opcje, metadane i transienty od nowa.

Object Cache Pro podmienia tę nietrwałą warstwę plikiem drop-in object-cache.php, który łączy WordPressa z Redisem. Dane zapisane przy pierwszym żądaniu zostają w pamięci operacyjnej i są dostępne przy każdym kolejnym – bez powtarzania zapytań SQL.

Koszyk, kasa i panel — miejsca, których cache stron nie obejmuje

Cache stron generuje statyczny HTML i serwuje go anonimowym odwiedzającym. Koszyk, kasa, konto klienta, panel administracyjny, wyniki filtrowania produktów – te strony są z tego mechanizmu wyłączone. Ich treść zmienia się przy każdym żądaniu w zależności od sesji użytkownika.

Każde załadowanie tych stron generuje zapytania do MySQL. Object cache – jedyna warstwa cache, która zmniejsza to obciążenie – przechowuje powtarzalne dane w pamięci Redisa.

Czego Object Cache Pro nie robi (bez minifikacji, obrazów i CDN-a)

Object Cache Pro operuje wyłącznie w warstwie danych. Nie generuje statycznego HTML, nie minifikuje CSS ani JavaScript, nie optymalizuje obrazów, nie zarządza CDN-em. To pojedynczy element stosu wydajnościowego – uzupełnia WP Rocket, LiteSpeed Cache czy Batcache, nie zastępuje ich.

Prefetching, kompresja danych i binarna serializacja

Object Cache Pro obniża koszt operacji na Redisie trzema mechanizmami: batch prefetching pobiera klucze cache zbiorczo – jedną paczką na grupę zamiast dziesiątek osobnych zapytań; kompresja algorytmami lzf, lz4 lub zstd zmniejsza objętość danych; serializer igbinary zapisuje struktury PHP w zwartej formie binarnej. Redukcja zużycia pamięci Redisa sięga 70–80% wg producenta.

Batch prefetching kluczy cache

Wtyczka pamięta, po które klucze sięgała wcześniej dana strona, i przy kolejnym wejściu odbiera je z Redisa jednym zapytaniem – całą grupę naraz. Lista prefetchowanych kluczy odświeża się przy każdym żądaniu, więc dostosowuje się do zmieniającej struktury strony.

Mechanizm jest domyślnie wyłączony – wymaga ręcznego włączenia w konfiguracji. Grupy generujące problemy da się wykluczyć opcją non_prefetchable_groups.

Kompresja lz4 i zstd oraz serializer igbinary

Do kompresji danych przesyłanych między WordPressem a Redisem służą trzy algorytmy: lzf, lz4 i zstd. Dobór zależy od priorytetu – lz4 minimalizuje opóźnienie odczytu, zstd stawia na mały rozmiar danych.

Serializer igbinary zastępuje standardową serializację PHP zwartą formą binarną – średni rozmiar danych spada o około 50% wg producenta. Wymaga rozszerzenia PHP igbinary oraz kompilacji PhpRedis z flagą –enable-redis-igbinary.

Uwaga: zmiana serializera lub algorytmu kompresji na działającej instalacji wymaga uprzedniego wyczyszczenia całej bazy Redis – bez tego grozi uszkodzenie danych.

Asynchroniczne i atomowe czyszczenie grup cache

Opcja async_flush przenosi usuwanie dużych zbiorów kluczy do procesu w tle Redisa (Redis 4.0+) – operacja czyszczenia nie blokuje pozostałych zapytań. Uwaga: Dragonfly nie obsługuje async_flush.

Gałąź 2.0 wprowadza atomowe czyszczenie grup (group_flush => atomic) – grupy cache trafiają do hashów Redis z wygasaniem pól, a wywołanie wp_cache_flush_group() czyści dokładnie jedną grupę bez skanowania kluczy po wzorcu. Wymagania: Redis 8.0 lub Valkey 9.0 oraz PhpRedis 6.3 lub Relay 0.12.1.

Kontrola czasu życia kluczy i rozbijanie alloptions

Opcja maxttl narzuca maksymalny czas życia wszystkim nowym kluczom cache – nieaktualne dane nie zalegają w Redisie bezterminowo. Osobna opcja queryttl (domyślnie 24 godziny) kontroluje wygasanie kluczy w grupach *-queries. Wtyczka raz na godzinę automatycznie czyści przeterminowane klucze zapytań.

Mechanizm split_alloptions zapisuje każdą autoload-owaną opcję w osobnym polu hasha zamiast trzymać komplet w jednym kluczu. Efekt: mniejsze ryzyko race conditions przy równoczesnych zapisach i – przy Relay – ograniczone inwalidacje pamięci współdzielonej.

Analityka cache, log czyszczeń i komendy WP CLI

Object Cache Pro prezentuje w panelu WordPressa wykresy trafień, chybień, opóźnień i zużycia pamięci Redisa. Log czyszczeń rejestruje ostatnie flushe i próbuje ustalić, która wtyczka lub funkcja je wywołała. Z poziomu konsoli dostępnych jest kilkanaście komend wp redis – od status i diagnostics przez flush i flush-group po slowlog, groups i prune-queries.

Wykresy trafień, chybień i opóźnień w panelu WordPressa

Sekcja Settings > Object Cache w panelu administracyjnym zawiera interaktywne wykresy: trafienia i chybienia cache, opóźnienia, zużycie pamięci Redisa. Widget w Kokpicie pokazuje status połączenia – jednym kliknięciem włącza drop-in lub czyści cache.

Retencja danych (domyślnie 2 godziny), procent mierzonych żądań (sample_rate) i opcja footnote – komentarz HTML z metrykami na dole każdej strony – są konfigurowalne.

Log czyszczeń — która wtyczka kasuje cache

Wtyczka zapisuje ostatnie 10 czyszczeń cache (limit zmienny filtrem) i próbuje ustalić, która wtyczka lub funkcja wywołała flush. Przy instalacjach z kilkudziesięcioma aktywnymi wtyczkami to narzędzie do tropienia spadku hit ratio.

Filtr pre_objectcache_flush pozwala programowo zablokować flushe wywoływane przez konkretną wtyczkę – bez modyfikowania jej kodu.

Komendy wp redis, REST API i logowanie PSR-3

Z poziomu WP CLI dostępne są m.in.:

• wp redis status – podsumowanie stanu połączenia, trafień i pamięci.
• wp redis diagnostics – pełny raport diagnostyczny.
• wp redis flush / flush-group – czyszczenie całego cache lub wybranej grupy, z możliwością wskazania witryny w sieci multisite.
• wp redis groups – skan grup cache z liczbą kluczy i opcjonalnym podglądem zużycia pamięci.
• wp redis slowlog / commands – log wolnych operacji i statystyki komend Redisa.

REST API pod endpointem /objectcache/v1/ udostępnia analitykę, grupy cache i opcje wtyczki. Wtyczka loguje zdarzenia przez interfejs PSR-3 – domyślnie błędy trafiają do stderr, a przy włączonym WP_DEBUG aktywuje się wewnętrzny ArrayLogger.

Klastry Redis, Sentinel i połączenia TLS

Object Cache Pro łączy się z pojedynczą instancją Redisa, z klastrem Redis, z układem Sentinel i z replikacją primary–repliki. Obsługuje szyfrowane połączenia TLS, uwierzytelnianie przez ACL Redis 6+ i sockety uniksowe. Konfiguracja mieści się w stałej WP_REDIS_CONFIG w wp-config.php – około 50 opcji, każda dostępna też jako zmienna środowiskowa.

Redis, Valkey, KeyDB i Dragonfly

Object Cache Pro współpracuje z Redisem i trzema forkami: Valkey, KeyDB i Dragonfly. Zgodność z KeyDB dopracowano w wersji 1.25.0. Jedyne znane ograniczenie dotyczy Dragonfly – brak obsługi asynchronicznego czyszczenia kluczy (async_flush).

Klaster, repliki i strategie failover

Klaster Redis konfiguruje się tablicą węzłów i strategią failover (none, error, distribute, distribute_replicas). Redis Sentinel automatycznie wykrywa aktualny primary i repliki po podaniu listy wartowników i nazwy usługi. Replikacja primary–repliki rozkłada odczyty na repliki ze strategiami distribute, distribute_replicas i concentrate.

Wtyczka współpracuje z AWS ElastiCache, w tym z wariantem Serverless. Relay 0.22+ dodaje opcje klastrowe: cluster_az (przypięcie odczytów do strefy dostępności), cluster_distribution_strategy i cluster_failover_strategy.

Konfiguracja w wp-config.php, przez zmienne środowiskowe i jako mu-plugin

Stała WP_REDIS_CONFIG w wp-config.php to jedyne miejsce konfiguracji połączenia – ekran ustawień w panelu administracyjnym służy do analityki i narzędzi, nie do konfiguracji hosta, portu czy hasła. Każdą opcję da się podać zmienną środowiskową, co pasuje do wdrożeń kontenerowych i skryptowych.

Object Cache Pro działa też jako Must-Use plugin, również z katalogiem poza web rootem (stała WP_REDIS_DIR). Instalacja przez Composer jest wspierana natywnie – gotowy scenariusz post-update-cmd automatycznie aktualizuje drop-in.

Dla jakich witryn Object Cache Pro ma sens

Object Cache Pro przynosi efekt przede wszystkim w sklepach WooCommerce z dużym katalogiem produktów, w portalach i serwisach członkowskich obsługujących ruch zalogowanych użytkowników oraz w sieciach multisite, gdzie każde czyszczenie cache dotyka wielu witryn naraz. Na małych stronach wizytówkowych z działającym cache stron różnica bywa nieodczuwalna – darmowa wtyczka object cache spełni tam tę samą rolę.

Sklepy WooCommerce z dużym katalogiem i ruchem skokowym

Koszyk, kasa, konto klienta i wyniki filtrowania renderują się poza cache stron – każde takie wejście obsługuje bezpośrednio baza danych. Przy sklepie z kilkoma tysiącami produktów i ruchem skokowym podczas kampanii object cache przejmuje powtarzalne zapytania o opcje, metadane produktów i wyniki archiwów.

Producent deklaruje testowanie Object Cache Pro pod WooCommerce. Grupy cache generujące problemy (np. wc_session_id) da się wyłączyć z utrwalania, a gotowa konfiguracja „High Performance” łączy lz4, igbinary, prefetch i obniżone timeouty.

Portale i serwisy z dużą liczbą zalogowanych użytkowników

Wszędzie tam, gdzie treść jest personalizowana – panele użytkowników, systemy kursów, wewnętrzne narzędzia – cache stron nie ma zastosowania, bo każdy widok zależy od sesji. Object cache jest jedyną warstwą, która zmniejsza liczbę zapytań do bazy w takim scenariuszu.

Sieci multisite i wiele witryn na jednej instancji Redis

Domyślnie wp_cache_flush() w WordPressie czyści całą bazę Redis – przy sieci multisite jedna witryna kasuje cache wszystkich pozostałych. Object Cache Pro rozwiązuje to opcją network_flush: w trybie site czyszczenie dotyczy kluczy danej witryny, a w trybie global dodatkowo czyści grupy globalne (users, usermeta). W Network Admin > Sites pojawia się akcja „Flush” per witrynę.

Przy kilku niezależnych instalacjach WordPressa na jednym serwerze Redis producent zaleca przydzielenie każdej osobnego indeksu bazy (parametr database). Redis Cluster nie obsługuje wielu baz – tam każda witryna dostaje unikalny prefix.

Kiedy Object Cache Pro nie jest potrzebny

Dla kogo Object Cache Pro nie jest potrzebny:

• Witryny na hostingu współdzielonym bez Redisa i bez rozszerzenia PhpRedis – produkt nie zawiera serwera Redis ani nie dostarcza rozszerzenia.
• Małe strony wizytówkowe i blogi z niewielkim ruchem – przy działającym cache stron zysk z object cache bywa nieodczuwalny.
• Osoby szukające jednego narzędzia do całej optymalizacji – Object Cache Pro nie robi cache stron, minifikacji, optymalizacji obrazów ani CDN-a.
• Użytkownicy bez dostępu do wp-config.php i konsoli – konfiguracja odbywa się wyłącznie przez stałą PHP.
• Klienci hostingów, u których wtyczka bywa wdrożona po stronie dostawcy (Nexcess, Cloudways, Rocket.net, Pantheon) – sprawdzenie dostępności u dostawcy przed zakupem.

Integracje z WooCommerce, Query Monitorem, Relay i narzędziami APM

Object Cache Pro jest testowany pod WooCommerce, dokłada osobny panel diagnostyczny do Query Monitora i współpracuje z Relay – rozszerzeniem PHP trzymającym część danych Redisa w pamięci współdzielonej procesu. Metryki cache trafiają do New Relic przez wbudowany tracer albo – przez OpenTelemetry – do Datadog, Blackfire czy Scout APM.

WooCommerce, Jetpack i Yoast SEO

Producent deklaruje testowanie i optymalizację Object Cache Pro pod WooCommerce – z monitorowaniem kodu i nadchodzących wydań WooCommerce pod kątem problemów z cachowaniem. Jetpack i Yoast SEO to kolejne wtyczki, pod które Object Cache Pro jest zoptymalizowany.

Object Cache Pro współpracuje z wtyczkami cache stron (Batcache, WP Rocket) jako warstwa komplementarna – object cache obsługuje dane w bazie, cache stron serwuje statyczny HTML.

Query Monitor i podgląd komend Redisa

Integracja z Query Monitorem obejmuje osobny panel z trafieniami, chybieniami i grupami cache. Przy włączonej opcji save_commands panel wyświetla wszystkie komendy Redisa wykonane podczas żądania – razem z informacją, która część kodu je wywołała. Zgodność z Query Monitor 4.x naprawiono w wersji 1.25.3.

Relay jako warstwa w pamięci PHP

Relay to rozszerzenie PHP przechowujące częściową replikę danych Redisa w pamięci współdzielonej procesu PHP. Po zmianie opcji client na Relay odczyty schodzą poniżej milisekundy – dane trafiają z pamięci lokalnej, bez komunikacji sieciowej z serwerem Redis.

Od wersji 1.24.0 dostępna jest eksperymentalna obsługa adaptive cache Relay. Opcje klastrowe Relay (cluster_az, cluster_distribution_strategy) wymagają Relay 0.22.0 lub nowszego.

New Relic, OpenTelemetry i wtyczki cache stron

Wbudowany tracer New Relic włącza się automatycznie po wykryciu rozszerzenia. Tracer open-telemetry (wymaga pakietu open-telemetry/api) otwiera integrację z Datadog APM, Blackfire i Scout APM.

Object Cache Pro współpracuje z wtyczkami cache stron (WP Rocket, LiteSpeed Cache, Batcache) bez konfliktów – obie warstwy działają niezależnie, obsługując różne etapy przetwarzania żądania.

Wymagania: serwer Redis, PhpRedis i wersje PHP

Object Cache Pro wymaga działającego serwera Redis (albo Valkey, KeyDB czy Dragonfly) oraz rozszerzenia PHP PhpRedis w wersji 4.0 lub nowszej – żadnego z tych elementów nie dostarcza w swoim pakiecie. Minimalna obsługiwana wersja PHP to 7.2. Producent testuje wtyczkę na pełnym zakresie PHP 7.2–8.6 oraz Redis 4.0–8.8, w instancjach pojedynczych i klastrach.

Rozszerzenie PhpRedis i brak obsługi Predisa

PhpRedis to jedyne wymagane rozszerzenie PHP – musi być zainstalowane zarówno dla PHP-FPM, jak i dla CLI (komendy wp redis). Minimalna wersja to 4.0, gałąź 2.0 wymaga 5.0 lub nowszej.

Predis – czysto PHP-owy klient Redisa, niewymagający rozszerzenia PECL – nie jest obsługiwany przez Object Cache Pro, mimo że ten sam autor utrzymuje bibliotekę Predis. Producent uzasadnia to wydajnością: natywne rozszerzenie C jest szybsze od klienta pisanego w PHP.

Konfiguracja serwera Redis: polityka wywłaszczania pamięci (maxmemory-policy)

Uwaga: serwer Redis musi mieć ustawioną politykę wywłaszczania pamięci (maxmemory-policy, np. allkeys-lru lub allkeys-lfu). Bez niej Redis po wyczerpaniu przydzielonej pamięci przestaje przyjmować zapisy, co powoduje błędy w działaniu WordPressa. Alternatywnie, krótki maxttl w konfiguracji wtyczki zapobiega bezterminowemu zaleganiu kluczy.

Dostępność Redisa u polskich hostingów

Object Cache Pro wymaga serwera Redis po stronie hostingu. Spośród polskich dostawców Redis udostępniają m.in.:

• dhosting.pl – serwer Redis w dPanelu (sekcja „Zaawansowane > Serwer Redis”), połączenie przez socket uniksowy.
• SeoHost i LH.pl – dostęp do Redisa w ramach pakietu hostingowego.
• MSERWIS.pl – Redis Object Cache w ramach AccelerateWP CloudLinux.

Redis bywa dostępny dopiero na wyższych planach hostingowych lub na serwerach VPS.

Najczęściej zadawane pytania