🎧 W tym odcinku rozbieram na czynniki pierwsze Object Cache w WordPressie – czym jest, jak działa i dlaczego Redis może diametralnie przyspieszyć Twoją stronę. Opowiadam też o prawdziwym przypadku z produkcji, gdzie niepoprawna konfiguracja Redisa spowodowała cofnięcie danych w WordPressie o… dwa tygodnie! Jeśli chcesz lepiej zrozumieć, jak działa cache w WordPressie i jak realnie przyspieszyć swoje projekty – ten odcinek jest właśnie dla Ciebie.
🎙️ Nowy odcinek podcastu już dostępny!
Podcast dostępny m.in w: Spotify, Apple Podcasts, Google Podcasts
TRANSKRYPCJA AUTOMATYCZNA:
Cześć. W tym odcinku podcastu zajmiemy się tematem object, cache i reddisa w WordPressie. Zanim jednak przejdziemy do głównego tematu odcinka, krótka chwila dla partnera mojego podcastu, marki Cyberfolks, która dostarcza domeny i hosting pod WordPressa.
Jeśli pracujesz z Wordpresem od jakiegoś czasu, to myślę, że na pewno zetknąłeś się z takimi wtyczkami jak WP Super Cache czy tym podobne wtyczki, które pozwalają na tak zwany Page Cache, czyli cachowanie Wordpresa do statycznych plików HTML lub z wykorzystaniem serwerów takich jak Lightspeed, gdzie ten cache jest budowany na warstwie serwerowej.
Natomiast w WordPressie mamy jeszcze coś takiego jak Object Cache i mam wrażenie, że trochę ten temat jest pomijany często przez deweloperów nawet przy tworzeniu własnych rozwiązań. Dzisiaj przybliżę Ci czym jest Object Cache, jak go wykorzystać, jak działa i co z tym wspólnego ma Redis.
Zacznijmy od tego czym jest ten Object Cache w WordPressie. Jest to taki moduł WordPressa można powiedzieć Object Cache API, które dostarcza nam zestaw funkcji do tego aby móc przechowywać w pamięci np. jakieś wyniki takich dosyć kosztownych operacji na bazie danych np. wyciąganie jakiegoś zestawu danych z bazy danych za pomocą zapytań, które nie są do końca optymalne albo po prostu tych danych jest na tyle dużo, że to zapytanie generuje jakiś tam narzut czasowy. I za pomocą właśnie tego Object Cache API możemy sobie przechować takie dane i użyć je w kolejnych powiedzmy częściach naszego kodu tak aby nie wykonywać za każdym razem właśnie takich kosztownych fragmentów tylko skorzystać z tego co już wcześniej było wykonane.
Domyślnie działa to tak, że ten cache jest trzymany w obrębie jednego requestu. Czyli na przykład jeśli ładujemy sobie jakąś stronę i ta strona odpytuje bazę danych na przykład o dane konkretnego użytkownika czy jakieś choćby meta dane do konkretnego postu. No to potem jeśli w trakcie renderowania tej strony te informacje są gdzieś tam wykorzystywane no to wtedy one już nie są pobierane z bazy danych, nie jest wykonywany żaden select na bazie danych tylko WordPress korzysta z tego object cache’a i z tych danych, które pobrał gdzieś tam za pierwszym razem. Tylko problem jest taki, że właśnie w tym domyślnym trybie po zakończeniu request’u te dane znikają.
Ten cache jest trwały tylko w obrębie jednego requestu, czyli jeśli wchodzimy sobie na stronę główną, no to on się gdzieś tam buduje na początku i możemy go wykorzystać tylko podczas renderowania tej strony głównej. Z tego Object Cache API korzysta bardzo dużo takich standardowych wbudowanych funkcji, choćby takich odpowiadających za pobieranie danych użytkowników, jakichś metadanych, postów czy opcji WordPressa z tabeli WP. One są ładowane po prostu do tego Object Cache’a i baza nie musi być odpytywana za każdym razem, gdy dana opcja jest potrzebna na przykład kilka czy kilkanaście razy w obrębie danego wywołania, ale tak jak powiedziałem wcześniej, problemem jest to, że mamy te dane tylko na czas życia pojedynczego requestu, czyli one są wyciągnięte, przytrzymane do końca generowania strony i rozwiązaniem tego problemu jest tzw. persistent object cache, czyli taki trwały cache pomiędzy różnymi
I tutaj cały na biało wchodzi redis, ewentualnie memcached, to jest takie starsze rozwiązanie trochę, wciąż dostępne oczywiście na różnych hostingach. Ale myślę, że na ten moment takim wiodącym rozwiązaniem jest Redis. Żeby ten Persistent Object Cache nam działał w naszym WordPressie, no to po pierwsze musimy mieć Redis. Redis jest po prostu usługą, jest serwerem w obrębie danego hostingu, danej maszyny, serwera dedykowanego, czy jakkolwiek macie to zorganizowane.
I WordPress łączy się na odpowiednim porcie, można powiedzieć analogicznie jak do serwera bazy danych. Jest to po prostu usługa wystawiona gdzieś tam na hostingu, do której WordPress się łączy i korzysta z tego zamiast na przykład pytać bazy danych o jakieś tam rzeczy. I jaka jest zaleta tego Redis? A Redis jest trzymany w RAM-ie, czyli dostęp do tych informacji jest bardzo szybki, co więcej on przechowuje dane na zasadzie klucz.
Te klucze są budowane oczywiście w taki sposób, żeby te dane były zawsze poprawne, żeby te klucze były unikalne, odpowiadały tam odpowiednim kryterium jeśli chodzi o unikalność czy po prostu dostęp do tych danych.
Bo możemy mieć taką sytuację, mamy np. 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 oto już dba WordPress, tym się nie musimy zupełnie jest już jakby poza nami, my sobie korzystamy tylko z tych funkcji odpowiadających właśnie za ustawianie tego cache’a, pobranie czy wyczyszczenie.
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. Przykładowo tabela opcji w WordPressie zmienia się raczej rzadko bądź bardzo rzadko. 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 te dane już mogą być pobrane bezpośrednio właśnie z Redis, a zamiast z bazy 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, a dzięki temu, że jest to zewnętrzne narzędzie w stosunku do WordPressa, to uzyskujemy właśnie ten efekt trwałości tych danych pomiędzy różnymi requestami, które są wykonywane do naszej strony. I oczywiście żeby tego Redis zintegrować z naszym Wordpresem, to potrzebujemy wtyczki. Najpopularniejszą wtyczką, która integruje nam Wordpresa – potrafi zrobić ten Persistent Object Cache jest Redis Object
autorstwa Tila Cruza, 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 lokal-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 tego Memcache jako ten nasz powiedzmy backend dla tego Persistent Object Cache. I po kilku wejściach na stronę za chwilę tam zobaczysz w panelu też statystyki między innymi takich współczyn.
Ile danych jest pobieranych z Redis, 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. Te dane są już trzymane właśnie w Redis. Nie potrzeba odpytywać bazy danych. Takim efektem ubocznym instalacji tego Redis 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 z bazy danych. transientach był już odcinek w moim podcastie, więc jeśli interesuje Cię ten temat, to możesz sobie do niego wrócić.
W zasadzie transienty są trochę podobnym mechanizmem do tego Object Cache’u. Możemy sobie też zapisać jakąś wartość, wynik kosztownego zapytania, na przykład z określonym czasem ważności. W zasadzie po instalacji Redis będzie to działało prawie tak samo jak ten Object Cache API. Jeśli nie mamy tego Redisa, to transienty są trwałe między poszczególnymi wykonaniami skryptu PHP-owego całego WordPressa. Pomiędzy requestami te dane są trwałe w transientach. A tak jak już mówiłem wcześniej w przypadku Object Cache są one trwałe tylko po zakończeniu requesta znikają. No chyba, że podłączymy sobie Redis’a 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 no to zdecydowanie polecam bo można powiedzieć, że ma on same zalety, nie wpływa jakoś tam negatywnie na pracę WordPressa, wręcz przeciwnie. Szczególnie ważne będzie to na stronach, które nie za bardzo możemy skasować w taki klasyczny sposób za pomocą jakiegoś tam WP, Supercash’a czy podobnego pluginu, czy na przykład gdzieś tam na Edge’u, na CDN-ie. Takie rzeczy jak na przykład WooCommerce, czy jakieś powiedzmy platformy kursowe, wszędzie tam gdzie mamy sesję, gdzie po prostu te strony muszą być generowane na żywo, nie możemy sobie tak bezkarnie skaszować całej strony, bo na przykład ktoś by ujrzał koszyk jakiegoś innego użytkownika na swojej instancji, na swojej stronie. No to jak najbardziej tak, to nam się na pewno przyda i na pewno pozytywnie wpłynie to na czas ładowania się strony, na przełączanie się pomiędzy kolejnymi ekranami strony, także tutaj zdecydowanie tak, no a czasem wręcz jest to taki must have dla stron, które właśnie są bardziej wymagające, które wykonują jakieś tam dosyć skomplikowane operacje na bazie danych czy właśnie wczytują duże ilości danych lub po prostu te bazy mają po kilka bądź kilkanaście.
We wcześniejszym fragmencie tego odcinka powiedziałem o tym, że ten Redis jest praktycznie transparentny i przynosi same korzyści WordPressowi. I faktycznie tak jest jeśli wszystko działa i wszystko jest zrobione zgodnie ze sztuką.
Natomiast może też powodować pewne dziwne problemy i jeden z takich problemów wydarzył się dosłownie tydzień albo dwa tygodnie temu. 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.
Sytuacja była tego typu, że był to WordPress na serwerze, jakiejś wirtualce w chmurze i tam oczywiście mieliśmy dostęp do routa, wszystko mogliśmy sobie konfigurować pod siebie tak jak potrzebowaliśmy. No i w pewnym momencie zainstalowałem tam Redis po to, 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ś wielki wyczyn, powiedzmy kilka koment, sprawdzamy czy działa, działa, instalujemy wtyczkę do WordPressa, wszystko jest ok. No i tak sobie ten Redis tam działał, działał. Potem pojawiły się jakieś dziwne problemy, że momentami on nie przyjmował połączeń. Tam doszedłem do tego, że prawdopodobnie przez to, że jak robił snapshoty z RAM-u na dysk, no to wtedy coś tam się przycinało, brakowało chyba ramu czy procesora na tym serwerze.
No więc postanowiłem wyłączyć te snapshoty, w przypadku WordPressa były one zupełnie zbędne. Snapshoty to jest taki mechanizm, że po prostu Redis zrzuca z RAM-u, bo domyślnie on operuje tylko na pamięci RAM i zrzuca to po prostu z RAM-u do pliku na dysku przez co może potem po restarcie odtworzyć ten stan taki jaki był przed restartem usługi, czy przed np. wywaleniem się serwra.
I domyślna konfiguracja właśnie zakładała, że takie Snapshoty będą robione co ileś tam requestów chyba do Redisa. A tu akurat mieliśmy takie dosyć specyficzne wdrożenie, gdzie bardzo mocno była obciążona baza danych, bo tam można powiedzieć całą dobę szły jakieś procesy synchronizacyjne, które synchronizowały produkty w sklepie z zewnętrznego systemu i przez to ta baza danych była dosyć intensywnie. 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ę Redis’a, ż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. Zmieniłem ten konfig, sprawdziłem, wszystko się zgadza, w logach nie widać tego, żeby Redis robił te zrzuty na dysk, wszystko działa.
No i tak sobie to działało, działało i jakiś czas później pojawiły się takie symptomy w tym WordPressie tak jakbyśmy się cofnęli w czasie. Czyli mniej więcej tak jakby ktoś przywrócił backup bazy danych, bo pojawiały się tam np. jakieś daty sprzed dwóch tygodni, sprzed kilku dni, stan jakichś rzeczy. O, jednym z takich dosyć ciekawych case’ów było to, że jeden z użytkowników zmienił sobie hasło i nie mógł się zalogować następnego dnia. Ale jak spróbował hasła, które miał ustawione tydzień czy dwa tygodnie wcześniej to wtedy już wszystko zadziałało. Pierwsze podejrzenia to ktoś gdzieś przywrócił jakiś backup bazy danych i przez to nam się to posypało. To było dosyć podejrzenie i taki pierwszy kierunek jeśli chodzi o myślenie i szukanie problemów. Ktoś przywrócił pewnie backup i coś się sypnęło.
No ale jak zaczęliśmy sobie tak analizować zawartość tej bazy danych, tam akurat na tej taki mechanizm, który logował jakieś tam cykliczne zadania, które wykonywał Kron i było to logowane w bazie popatrzyłem sobie po wykonaniach, po czasach wykonań poszczególnych zadań, no to tam była ciągłość. Nie było tam żadnego takiego symptomu na zasadzie, że mamy na przykład kilkudniową przerwę w logach, a te zadania były wykonywane co kilkanaście minut, więc można powiedzieć bardzo często mieliśmy próbkowaną tą bazę danych i widziałem, jednak nie wskazuje nic na to, żeby ta baza była przywrócona i że gdzieś tam nam się te dane cofnęły w czasie, ale mimo wszystko było to nawet potwierdzone screenami, że w pewnych momentach ten WordPress pokazywał jakieś stare daty, stare dane i nie do końca wiedzieliśmy skąd to się wzięło.
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ę, co za tym idzie Redis również został zrestartowany. Dosyć szybko dotarłem do tego, że w logach było widać, że przy każdym restartie Redisa, czy to razem z całą maszyną, czy po prostu samego Redisa samej usługi na tej maszynie jest wczytywany jakiś dump z dysku. No i wtedy już dosyć szybko pokojarzyłem fakty. Okazało się, że mimo tego, że wyłączyłem w Redisie w konfigu 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 załadował go przy każdym załadowaniu Redis’a 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ł właśnie ten moment, ten snapshot wykonał się po raz ostatni i Redis załadował to z 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ę z 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, gdzie w nocy był restart tego serwera, wczytał się ten zrzut Redisa sprzed dwóch tygodni i z punktu widzenia WordPressa ten użytkownik miał stare hasło mimo, w bazie się działo poprawne, bo Redis jeśli tą informację w sobie, to nie pobiera z bazy danych tylko po prostu sobie wczytuje 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.
Kolejnym częstym problemem z Object Cache’em, ogólnie z takimi mechanizmami właśnie bazującymi na Object Cache’u, na Redisie jest taki problem, że mimo tego, że w bazie ta wartość się zmienia to WordPress widzi cały czas starą wartość. Natomiast to już nie wynika tak naprawdę z samego Object Cache’a i z Redis’a, tylko z nieprawidłowej implementacji przez programistów, mam tu na myśli takie sytuacje, w której na przykład operujemy sobie załóżmy polach post post meta wpisu, ale nie używamy tych standardowych WordPressowych typu update post meta i tak dalej. Tylko wykonujemy to na przykład za pomocą takiego zwykłego zapytania do bazy danych. W tym przypadku przyczyna jest dosyć prosta. Podczas zwykłego takiego zapytania do bazy danych jest po prostu robiona operacja bezpośrednio na bazie danych z pominięciem tych wszystkich hooków, które się wykonują podczas użycia właśnie odpowiednich 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 PHP MyAdmina czy innego tego typu narzędzia i zmienili sobie tą wartość bezpośrednio w bazie to WordPress nie będzie o tym wiedział przez co nie będzie mógł wyczyścić tego cache’a w Redisie no bo domyślnie jeśli właśnie użyjemy jakiejś funkcji update options, delete options czy analogicznych dla pool post meta to wtedy WordPress wierzy, by też w tym Redisie wyczyścić te wartości i załadować je na nowo. A jeśli to zrobimy gdzieś tam od boku, to tak naprawdę Redis może nam zwracać zupełnie inne dane niż te, które są w bazie danych. No ale tak jak już powiedziałem, zwykle to wynika po prostu tego, że programista nie przewidział, że jeśli sobie zrobi tam jakąś operację za pomocą prostego zapytania do bazy, a nie odpowiednich funkcji WordpRessowych no to spowoduje taki problem, że ten Object Cache nie będzie zinwalidowany przez co będzie zwracał często niepoprawne dane.
To co omówiłem do tego momentu to jest sytuacja w której po prostu instalujesz tą wtyczkę do WordPressa, podpinasz tego Redis, który gdzieś tam sobie pracuje na twoim hostingu. Twój WordPress ma lżej, po prostu wykonuje się szybciej, nie ma tego problemu z narzutem tych zapytań do bazy danych.
Natomiast to jest też świetne narzędzie, całe to Object Cache API. Jest to świetne narzędzie, które możesz wykorzystać przy pisaniu własnych pluginów czy własnych motywów. W ostatnich dniach dosyć mocno korzystałem z optymalizacji takiego 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 skeszowałem sobie pewne rzeczy za pomocą Object Cache API, oczywiście na stronie pracował Redis to przyspieszyłem ładowanie tej strony.
I myślę, że takie trzy najczęściej używane funkcje, z których będziesz korzystał podczas pracy z tym Object Cache API to WP Cache Set, WP Cache Get i WP Cache DELETE. Parametry są dosyć proste, zawsze musimy mieć klucz.
Opcjonalnie grupę, możemy sobie też dodać jakąś grupę, choćby właśnie nazywając to nazwą naszego pluginu, motywu. To zapobiega kolizji kluczy między jakimiś tam elementami, które pracują na tej stronie, między innymi pluginami. Zawsze warto stosować te grupy, bo zabezpieczamy się przed jakimś przypadkowym nadpisywaniem sobie danych i dla cache’a, dla każdego takiego obiektu, który sobie cache’ujemy, możemy sobie ustawić czas wygasania.
Albo możemy dać tam 0 i wtedy cache jest trzymany do momentu, tak naprawdę, gdy Redis go nie wyrzuci z jakiegoś powodu. 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. i naturalnie coś Redis musiał wyrzucić z tego ramu, żeby zwolnić sobie miejsce na nowe dane.
No to tak to będzie działało. Ewentualnie jeśli ustawimy sobie tam jakiś czas to tankerz będzie trzymany przez odpowiednią ilość sekund. WP Cache Get, analogicznie do innych tego typu funkcji, jest to po prostu pobieranie tych danych, które zapisaliśmy za pomocą WP Cache Set, czyli WordPress zwraca nam dokładnie to, co zapisaliśmy sobie wcześniej w kodzie i WP Cache Delete, usuwamy sobie to wszystko, co siedzi w tym Object Cache, w tym przypadku akurat w Redisie, jeśli mamy to spięte z Redisem.
I taki, powiedzmy, prosty przykład, do czego można to użyć w swojej wtyczce. Załóżmy, że masz jakąś wtyczkę, która bazuje na własnych typach postów i na przykład wyświetlasz jakiś tam widget na stronie, czy gdzieś tam te informacje są ale to zapytanie jest zbudowane z kilku warunków opartych o pola post meta, co jak wiemy w WordPressie nie jest najszybszą opcją na wyciąganie danych, ale powiedzmy, że takie są wymagania biznesowe, ciężko to obejść, a był to najprostszy sposób na zaimplementowanie jakiegoś mechanizmu.
No to używamy sobie tego Object Cache’a w ten sposób, że najpierw pobieramy pomocą WP Cache Get, te dane, które powinny się znajdować w cache’u. Jeśli nie ma tych danych, no to oczywiście zwróci nam 0. W oparciu o to potem sobie pobieramy te posty, wykonujemy to jedno skomplikowane zapytanie, które powiedzmy jest długie i czasochłonne. Po pobraniu zapisujemy sobie to za pomocą funkcji WP Cache Set. I potem przy kolejnych wywołaniach strony jeśli zajdzie potrzeba wyciągnięcia tych danych to już WordPress nie będzie odpytywał bazy danych, bo funkcja WP CacheGed zwróci nam te dane i to zapytanie do bazy zostanie pominięte, bo oczywiście powinniśmy sobie tam zaimplementować jakiegoś ifa, że jeśli nam nie zwrócił nic to pobierz z bazy, a jeśli zwrócił to przejdź dalej np. 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ć 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ę która będzie nam czyściła ten cache. Czyli jeśli zapisujemy wynik zapytania do tego Object Cache’u to naturalnym jest to, że jakiś post się zmieni, 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.
Oczywiście to był taki dosyć prosty przykład użycia tego Object Cache’a. Ja ostatnio optymalizowałem też bloki Gutenbergowe, które były napisane w skrajnie nieoptymalny sposób, bo miałem taki przykład bloku Gutenberga, który wyciągał właśnie dane z jakichś tam innych post typów i ten blok wykonywał bodajże około 600 zapytań do bazy danych.
W skrajnych przypadkach ten blok się generował po kilka, nawet kilkanaście sekund, bo tam były strasznie toż nieoptymalne te zapytania do bazy. I zrobiłem pewnego rodzaju obejście tego problemu na zasadzie takiej, że zapisywałem już wynikowego HTML dotego Object do momentu, którym te posty źródłowe, które zasilają tak naprawdę ten blok się nie zmieniły, to WordPress nie odpytywał bazy danych, nie wykonywał tych wszystkich skomplikowanych operacji, operacji tych pętli w pętli. Tylko podawał już gotowego HTML, który został wyrenderowany za pomocą pierwszego requestu tak naprawdę po zmianie tych danych w bazie. Było to trzymano właśnie w redisie, także było między kolejnymi wywołaniami przez co zaoszczędziliśmy sporo requestów do bazy danych podczas każdego wejścia na stronę.
Jeśli piszesz wtyczkę, bądź masz jakieś tam elementy w swojej wtyczce czy w motywie, które właśnie wykonują takie dosyć kosztowne operacje, to warto zaimplementować ten Object Cache, bo on przynosi sporo korzyści wydajnościowych. A jeśli jest poprawnie zaimplementowany, to tak naprawdę nie powoduje żadnych problemów czy nieprzewidzianych działań. 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ć taki must have dla każdej, nawet prostej strony na WordPressie. Nawet jeśli cashujemy sobie ją gdzieś tam na froncie za pomocą CDN-a czy jakiegoś pluginu takiego full page cache no to przyjemniej się pracuje choćby w panelu admina, bo to wszystko działa dużo lepiej.
Deweloperzy powinni pamiętać o tym, żeby stosować ten Object Cache w swoich rozwiązaniach, no przede wszystkim to żebyśmy rozumieli i pisali w sposób taki zgodny z dobrymi praktykami, bo wtedy wszystko działa dobrze i sprawnie. W tym odcinku to wszystko. Mam nadzieję, że przybliżyłem Ci działanie Object Cache’a i że wykorzystasz go w swoich projektach. Do zobaczenia w kolejnym odcinku.
