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

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ę.

Można powiedzieć na jedno kliknięcie. Tu jeszcze w zależności od tego jak ten Redis na danym hostingu jest skonfigurowany, czy jest na local hostie na standardowym porcie. No to albo działa nam od razu po zainstalowaniu, gdzie możemy włączyć sobie tą wtyczkę i on po prostu działa. 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 Współczynnik procentowy.

A ile danych jest zaciąganych z bazy i zwykle ten współczynnik na takich powiedzmy standardowych WordPressach oscyluje gdzieś w okolicach 95%. Oczywiście mamy również zdecydowanie mniej zapytań do bazy danych. 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. O transientach był już odcinek w moim podcaście, więc jeśli interesuje Cię ten temat, to możesz sobie do niego wrócić.

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. No i wtedy już dosyć szybko pokojarzyłem fakty. 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. I tu się już dosyć szybko potem wyjaśniło, no nie dziwne, że na przykład 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 Po prostu sobie wczytuję tą wartość, która siedzi w tym Object Cache'u i WordPress widzi zupełnie inną wartość niż jest w bazie danych. Problem oczywiście się rozwiązał po usunięciu tego pliku ze Snapshotem. Redis startował wtedy z pustą bazą, jeśli była konieczność restartowania usługi. No i problem się więcej nie pojawił. Kolejnym częstym problemem z Object Cache'em, ogólnie z takimi mechanizmami właśnie bazującymi na Object Cache'u na Redisie,

Które się wykonują podczas użycia właśnie odpowiednich funkcji do operacji czy to na opcjach WordPressowych czy właśnie na polach meta, user meta, post meta i tak dalej. Jest po prostu to wykonywane z pominięciem, trochę tak jakbyśmy weszli do phpMyAdmin czy innego tego typu narzędzia. I zmienili sobie tą wartość bezpośrednio w bazie danych. 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.

Jakiegoś ifa, że jeśli nam nie zwrócił nic, no to pobierz z bazy, a jeśli zwrócił, no to przejdź dalej, na przykład do wyświetlenia tych postów. Mniej więcej tak to działa. Oczywiście w tym scenariuszu jeszcze będzie dosyć znaczącą rolę odgrywać ten czas wygasania cache'a. Możemy to ustawić na zero, czyli na to, żeby ten cache nie wygasał nigdy, ale musimy pamiętać o tym, że na przykład musimy podpiąć pod akcję save post odpowiednią funkcję, która będzie nam czyściła ten cache. 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. Krótko podsumowując, Object Cache to często pomijana, ale bardzo potężna warstwa, na której możemy zoptymalizować naszego WordPressa. Ten Redis myślę, że powinien być takim must have dla każdej, nawet prostej strony na WordPressie.