Mentionsy

W tym odcinku podcastu zajmiemy się tematem Object, Cache i Redisa w WordPressie.

Dzisiaj przybliżę ci czym jest Object Cache, jak go wykorzystać, jak działa i co z tym wspólnego ma Redis.

I tutaj cały na biało wchodzi Redis, ewentualnie memcache.

Wciąż dostępne oczywiście na różnych hostingach, ale myślę, że na ten moment takim wiodącym rozwiązaniem jest Redis.

No to po pierwsze musimy mieć Redisa.

Redis jest po prostu usługą, jest serwerem w obrębie danego hostingu, danej maszyny, serwera dedykowanego czy jakkolwiek macie to zorganizowane.

Jaka jest zaleta tego Redisa?

Redis jest trzymany w ramie, czyli dostęp do tych informacji jest bardzo szybki i co więcej on przechowuje dane na zasadzie klucz wartość.

Kryterium jeśli chodzi o unikalność czy po prostu dostęp do tych danych, bo możemy mieć taką sytuację, że mamy na przykład jakieś zapytanie do bazy danych, ale ono się różni jakimś tam jednym parametrem, no to oczywiście Redis musi wiedzieć, który wynik jest z którego zapytania, ale o to już dba WordPress, tym się nie musimy zupełnie przejmować.

I dzięki temu, że Redis jest taką zewnętrzną usługą w stosunku do WordPressa, te dane są trzymane niezależnie od requestu jaki jest wykonywany do WordPressa.

I dzięki temu jeśli jeden request załaduje tą tabelę z bazy danych z MySQL do Redisa właśnie, no to przy następnych wejściach na stronę, nieważne czy ten sam użytkownik czy inny użytkownik, te dane już mogą być pobrane bezpośrednio właśnie z Redisa zamiast z bazy danych, co przekłada się na szybkość generowania strony, no bo te dane są dostępne po prostu szybciej.

Są one skaszowane właśnie w Redisie.

Jak działa Object Cache w WordPressie i dlaczego Redis to game changer.

Najpopularniejszą wtyczką, która integruje nam WordPressa i potrafi zrobić ten Persistent Object Cache jest Redis Object Cache autorstwa Tila Krusa, bodajże tak to się czyta i tutaj mamy taką integrację.

Tu jeszcze w zależności od tego jak ten Redis na danym hostingu jest skonfigurowany, czy jest na local hostie na standardowym porcie.

Ewentualnie czasem musimy uzupełnić jakieś dane konfiguracyjne, jak choćby adres tego serwera Redis, czy ewentualnie jakiś customowy port, na którym ten Redis został uruchomiony na naszym hostingu.

Po zainstalowaniu tej wtyczki WordPress po prostu z automatu będzie trzymał sobie te wszystkie dane, które trzyma w tym Object Cache standardowym, będzie je trzymał po prostu w Redisie, bądź w memcache, jeśli użylibyśmy

Jeśli mamy choćby query monitora zainstalowanego, to też zaraz zauważysz, że tych zapytań do bazy danych jest znacznie mniej, bo te dane są już trzymane właśnie w Redisie, a nie potrzeba odpytywać bazy danych.

Efektem ubocznym instalacji tego Redisa jest również to, że transienty są trzymane zamiast w bazie danych, to właśnie też w tym Redisie i są wczytywane z Redisa, a nie z bazy danych.

z określonym czasem ważności i w zasadzie po instalacji Redisa będzie to działało prawie tak samo jak ten Object Cache API.

Jeśli nie mamy tego Redisa, no to Transienty są trwałe między poszczególnymi wykonaniami skryptu PHP-owego całego WordPressa.

No chyba, że podłączymy sobie Redisa, no to wtedy mamy ten Persistent Object Cache.

I być może w tym momencie zadajesz sobie pytanie czy w zasadzie ten cały Redis ci jest potrzebny na twojej stronie czy na stronach które robisz.

Ogólnie rzecz biorąc jeśli masz tylko taką możliwość jeśli na hostingu ten Redis jest dostępny nie musisz za niego dopłacać czy aktywować jakiegoś tam wyższego pakietu.

We wcześniejszym fragmencie tego odcinka powiedziałem o tym, że ten Redis jest praktycznie transparentny i przynosi same korzyści WordPressowi.

Był to bardziej mój błąd niż błąd Redisa, no ale jednak spowodował dosyć dziwne działanie jednej ze stron i nie do końca wiedzieliśmy skąd to działanie się bierze.

No i w pewnym momencie zainstalowałem tam Redisa po to, żeby przyspieszyć stronę, zoptymalizować właśnie też czas generowania tej strony i ograniczyć zapytania do bazy danych.

Instalacja Redisa na Linuxie to nie jest jakiś tam wielki wyczyn, powiedzmy kilka komend, sprawdzamy czy działa, działa, instalujemy wtyczkę do WordPressa, wszystko jest okej.

No i tak sobie ten Redis tam działał.

Snapshoty to jest taki mechanizm, że po prostu Redis zrzuca z ramu, bo domyślnie on operuje tylko na pamięci RAM i zrzuca to po prostu z ramu do

I domyślna konfiguracja właśnie zakładała, że takie snapshoty będą robione co ileś tam requestów chyba do Redisa.

W sklepie, z zewnętrznego systemu i przez to ta baza danych była dosyć intensywnie używana i ten Redis też bardzo często robił te zrzuty.

Więc jak zauważyłem, że w logach gdzieś to są te problemy, no to zmieniłem konfigurację Redisa, żeby nie robił tych zrzutów, bo tak jak powiedziałem, są one zupełnie zbędne w kontekście WordPressa, a powodowały jakieś tam problemy i dodatkowy narzut, że serwer musiał jeszcze zapisywać te dane na dysk.

W logach nie widać tego, żeby Redis robił te zrzuty na dysk.

A tam w międzyczasie jeszcze były wykonywane na tej wirtualce jakieś takie operacje typu zwiększenie parametrów i tak dalej, co się wiązało z tym, że trzeba było zrestartować całą wirtualkę, no co za tym idzie Redis również został zrestartowany.

I dosyć szybko dotarłem do tego, że w logach było widać, że przy każdym restarcie Redisa, czy to razem z całą maszyną, czy po prostu samego Redisa, samej usługi na tej maszynie, jest wczytywany jakiś dump z dysku, z pliku.

Okazało się, że mimo tego, że wyłączyłem w Redisie w configu robienie tych snapshotów, no to zapomniałem o tym, że został na dysku snapshot z zawartością tego Redisa z momentu, w którym po prostu zmieniłem tą konfigurację.

No a Redis jeśli widział ten snapshot w odpowiednim katalogu, no to niewiele myśląc ładował go przy każdym załadowaniu Redisa na nowo, czy przy każdym restarcie usługi.

Dane typu data, która była trzymana w tabeli wp-options cofała się o dwa tygodnie, no bo to był ten moment, w którym ten snapshot wykonał się po raz ostatni i Redis ładował to w tego pliku i w momencie, w którym WordPress pytał o tą opcję, no to nie odpytywał bazy danych, gdzie była poprawna data, tylko odpytywał Redisa i Redis zwracał właśnie tą datę tego snapshota.

Podobnie było zresztą z tym hasłem użytkownika, po prostu w Redisie były zapisane dane tego użytkownika i ten snapshot był wykonany w momencie, gdy użytkownik miał jeszcze stare hasło, po czym po zmianie hasła on się mógł zalogować tam danego dnia, ale następnego dnia

Wczoraj był restart tego serwera, wczytał się ten zrzut z Redisa sprzed dwóch tygodni i z punktu widzenia WordPressa ten użytkownik miał stare hasło, mimo że w bazie się działo poprawne, no bo Redis jeśli ma tą informację w sobie, no to nie pobiera z bazy danych, tylko

Redis startował wtedy z pustą bazą, jeśli była konieczność restartowania usługi.

Kolejnym częstym problemem z Object Cache'em, ogólnie z takimi mechanizmami właśnie bazującymi na Object Cache'u na Redisie,

Natomiast to już nie wynika tak naprawdę z samego Object Cacha i z Redisa, tylko z nieprawidłowej implementacji przez programistów.

No to WordPress nie będzie o tym wiedział, przez co nie będzie mógł wyczyścić tego cacha w Redisie, no bo domyślnie jeśli właśnie użyjemy jakiejś funkcji updateOptions, deleteOptions czy analogicznych dla pool postmeta.

No to wtedy WordPress wie, żeby też w tym Redisie wyczyścić te wartości i załadować je na nowo ewentualnie.

A jeśli to zrobimy gdzieś tam od boku, no to tak naprawdę Redis może nam zwracać zupełnie inne dane niż te, które są w bazie danych.

To, co omówiłem do tego momentu, to jest sytuacja, w której po prostu instalujesz tą wtyczkę do WordPressa, podpinasz tego Redisa, który gdzieś tam sobie pracuje na twoim hostingu i twój WordPress ma lżej, po prostu wykonuje się szybciej, nie ma tego problemu z narzutem tych zapytań do bazy danych.

Ja w ostatnich dniach dosyć mocno korzystałem z tego, podczas optymalizacji takiego dosyć trudnego przypadku WordPressowego, gdzie trafiła do nas strona, która była skrajnie niewydajna i pewne elementy, tak jak choćby generowanie nawigacji, były zaimplementowane w taki sposób, że generowały ogromny narzut i dzięki temu, że skasowałem sobie pewne rzeczy za pomocą tego Object Cache API, oczywiście na stronie pracował Redis, no to

Albo możemy dać tam zero i wtedy ten cache jest trzymany do momentu tak naprawdę, gdy Redis go nie wyrzuci z jakiegoś powodu.

No a Redis go może wyrzucić albo z powodu takiego, że właśnie na przykład został zresetowany, wyczyszczony, bądź na przykład skończył się limit pamięci, który był przydzielony do Redisa.

No i naturalnie coś Redis musiałby wyrzucić z tego RAMu, żeby zwolnić sobie miejsce na nowe dane.

Czyli jeśli zapisujemy sobie wynik jakiegoś tam zapytania do tego Object Cache'u, no to naturalnym jest to, że jeśli jakiś post się zmieni, no to powinniśmy wyczyścić ten Cache, żeby WordPress mógł wczytać te dane z bazy danych i zapisać sobie je w Redisie na nowo.

I było to trzymano właśnie w Redisie, także było między kolejnymi wywołaniami strony

Jak działa Object Cache w WordPressie i dlaczego Redis to game changer.

Ten Redis myślę, że powinien być takim must have dla każdej, nawet prostej strony na WordPressie.