Cache obiektowy Redis: kiedy naprawdę przyspieszy

Redis pojawia się w każdej dyskusji o przyspieszaniu WordPressa i bardzo często jest włączany bez sprawdzenia, czy w danym serwisie ma cokolwiek do roboty. Bywa, że po instalacji nie zmienia się nic, a czasem zmienia się bardzo dużo. Różnica jest przewidywalna i da się ją ocenić przed wdrożeniem. Poniżej pokazujemy, jak.

Cache obiektowy to nie to samo co cache strony

To rozróżnienie decyduje o wszystkim pozostałym.

Cache strony zapisuje gotowy dokument HTML i podaje go kolejnym odwiedzającym, pomijając PHP i bazę. Jest niezwykle skuteczny dla treści identycznej dla wszystkich: bloga, strony firmowej, artykułu.

Cache obiektowy działa piętro niżej. Zapisuje w pamięci pojedyncze wyniki zapytań do bazy, żeby przy kolejnym żądaniu nie liczyć ich od nowa. Ma sens tam, gdzie cache strony nie zadziała, bo każdy użytkownik widzi coś innego: w koszyku, w panelu klienta, na liście produktów z cenami zależnymi od grupy.

Stąd prosty wniosek. Jeśli Twój serwis dobrze buforuje się jako całe strony, Redis dołoży niewiele. Jeśli sporo widoków jest zależnych od zalogowanego użytkownika, dołoży dużo.

Komu pomoże, a komu nie

Pomoże wyraźnie:

• sklepom z koszykiem, kontem klienta i filtrowaniem produktów,
• serwisom z panelem użytkownika, gdzie większość ruchu jest po zalogowaniu,
• stronom z dużą liczbą wtyczek odpytujących bazę o te same ustawienia przy każdym żądaniu,
• serwisom wielojęzycznym, gdzie ta sama treść liczona jest w kilku wariantach.

Nie zmieni prawie nic:

• na stronie wizytówce z kilkunastoma podstronami,
• na blogu z działającym cache strony,
• tam, gdzie problemem jest jedno ciężkie zapytanie bez indeksu, bo cache zapamięta wtedy wolny wynik zamiast go naprawić.

Ten ostatni punkt jest ważny. Cache obiektowy nie jest zamiennikiem optymalizacji. Najpierw znajdź zapytania przeglądające całą tabelę i dołóż indeksy, a dopiero potem buforuj. W odwrotnej kolejności ukryjesz problem, który wróci przy pierwszym czyszczeniu pamięci.

Dlaczego potrzebujesz własnego serwera

Redis to osobna usługa, którą trzeba zainstalować, uruchomić jako proces w tle i skonfigurować. Na hostingu współdzielonym nie masz do tego dostępu, bo nie instalujesz tam własnych usług systemowych.

Naturalnym środowiskiem jest więc serwer VPS. W ofercie RapidDC dostajesz pełną wirtualizację KVM, dostęp root i wybór systemu spośród Debiana, Ubuntu, CentOS i Fedory, a reinstalacje są nielimitowane, więc nieudany eksperyment kosztuje tylko czas. Co jeszcze daje własna maszyna, zebraliśmy we wpisie o najważniejszych funkcjach serwera VPS.

Uruchomienie krok po kroku

Na Debianie lub Ubuntu instalacja sprowadza się do jednego polecenia:

apt update && apt install redis-server

Potem trzy ustawienia w pliku /etc/redis/redis.conf, które warto zmienić od razu:

bind 127.0.0.1
maxmemory 512mb
maxmemory-policy allkeys-lru

Pierwsza linia jest najważniejsza z punktu widzenia bezpieczeństwa. Redis domyślnie nie wymaga hasła, więc usługa wystawiona na publiczny adres oznacza, że każdy może czytać i kasować jej zawartość. Ograniczenie nasłuchiwania do pętli lokalnej rozwiązuje to w całości, o ile aplikacja działa na tej samej maszynie. Jeśli musi łączyć się z zewnątrz, ustaw hasło i dołóż regułę na zaporze, o czym pisaliśmy we wpisie o zaporze sieciowej.

Druga i trzecia linia decydują o zachowaniu przy zapełnieniu pamięci. Polityka allkeys-lru usuwa wpisy używane najdawniej, co jest właściwym wyborem dla cache. Bez tego ustawienia Redis po prostu zacznie odmawiać zapisu, a aplikacja zacznie zgłaszać błędy.

Po stronie WordPressa zostaje instalacja wtyczki obsługującej cache obiektowy i włączenie jej w ustawieniach. Wtyczka dopisze plik object-cache.php do katalogu wp-content i od tej chwili zapytania zaczną trafiać do pamięci.

Jak sprawdzić, czy to działa

Sam fakt, że usługa jest uruchomiona, nic nie znaczy. Sprawdź dwie rzeczy.

Pierwsza to statystyka trafień, dostępna w konsoli Redisa poleceniem INFO stats. Interesuje Cię stosunek keyspace_hits do keyspace_misses. Jeśli trafienia stanowią wyraźną większość, cache pracuje. Jeśli przeważają chybienia, dane są za każdym razem inne i buforowanie nie ma w tym miejscu sensu.

Druga to pomiar przed i po. Zmierz czas odpowiedzi tej samej podstrony dynamicznej przy wyłączonym i włączonym cache, kilka razy, po zalogowaniu. Jeśli różnica jest w granicach błędu, wyłącz Redisa i wróć do szukania wolnych zapytań.

Podsumowanie

Redis jest narzędziem precyzyjnym, a nie ogólnym przyspieszaczem. Odciąża bazę przy zapytaniach powtarzalnych i nieobjętych cache strony, czyli głównie w sklepach i serwisach z logowaniem. Na prostej stronie firmowej nie zrobi różnicy.

Jeśli Twój serwis mieści się w ramach pakietu, hosting RapidDC obsłuży go z wersjami PHP do 8.3 bez żadnych dodatków. Gdy potrzebujesz własnych usług i kontroli nad konfiguracją, właściwym miejscem jest VPS z dostępem root.

FAQ – najczęściej zadawane pytania o Redis

Czy Redis zastąpi cache strony?

Nie, one działają na różnych poziomach i najlepiej uzupełniają się nawzajem. Cache strony obsługuje ruch niezalogowany, cache obiektowy odciąża bazę tam, gdzie treść jest różna dla każdego użytkownika.

Ile pamięci przydzielić Redisowi?

Zacznij od 256 albo 512 MB i obserwuj statystyki. Jeśli wpisy są usuwane, zanim zdążą zostać użyte, dołóż pamięci. Przydzielanie kilku gigabajtów na start zwykle oznacza, że odbierasz ją bazie i PHP, gdzie przyda się bardziej.

Co się stanie, gdy Redis przestanie działać?

Poprawnie napisana wtyczka wróci do pobierania danych wprost z bazy, więc serwis będzie działać wolniej, ale będzie działać. Warto to przetestować, zatrzymując usługę na chwilę na środowisku testowym.

Czy Redis jest bezpieczny?

Sam w sobie tak, o ile nie wystawisz go na publiczny adres bez hasła. Domyślna konfiguracja nie wymaga uwierzytelnienia, więc ograniczenie nasłuchiwania do pętli lokalnej jest pierwszą rzeczą do ustawienia po instalacji.

Czy Redis przyspieszy WooCommerce?

Zwykle tak, i jest to jeden z najlepszych przypadków użycia. Koszyk, sesje i widoki po zalogowaniu nie podlegają cache strony, więc to właśnie tam cache obiektowy ma najwięcej pracy do wykonania.

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu RapidDC. Grafika ilustracyjna została wygenerowana przez AI.