Mentionsy
188 - Jak działa Object Cache w WordPressie i dlaczego Redis to game changer
🎧 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.
🔧 Partnerem odcinka jest Cyberfolks - dostawca hostingu i domen idealnych pod WordPressa.
Sponsorzy odcinka (1)
podcast
"Partnerem dzisiejszego odcinka jest marka Cyberfolks. Pamiętaj, że z kodem podcast dostaniesz 20% rabatu na hosting WordPress."
Szukaj w treści odcinka
W tym odcinku podcastu zajmiemy się tematem Object, Cache i Redisa w WordPressie.
No to po pierwsze musimy mieć Redisa.
Jaka jest zaleta tego Redisa?
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.
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.
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.
I domyślna konfiguracja właśnie zakładała, że takie snapshoty będą robione co ileś tam requestów chyba do Redisa.
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.
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.
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
Natomiast to już nie wynika tak naprawdę z samego Object Cacha i z Redisa, tylko z nieprawidłowej implementacji przez programistów.
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.
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.
Ostatnie odcinki
-
190 - Efekt motyla w WordPressie: Jak drobne ni...
31.03.2026 08:07
-
189 - Koniec wróżenia z fusów. New Relic - czar...
08.01.2026 20:25
-
188 - Jak działa Object Cache w WordPressie i d...
30.10.2025 10:05
-
187 - WordPress i Amazon S3 - historia o tym ja...
16.09.2025 08:50
-
186 - Pierwszy dwujęzyczny WordCamp w Polsce - ...
22.08.2025 09:25
-
185 - Scyzoryk WordPress Developera: WP-CLI eva...
04.08.2025 09:33
-
184 - Pierwszy WordCamp w tym roku - co nas cze...
15.06.2025 13:39
-
183 - Must-use Plugins - trochę inne wtyczki dl...
03.06.2025 12:05
-
182 - Różne środowiska dla WordPressa - po co t...
20.05.2025 11:49
-
181 - Cloudflare i WordPress - jak to działa?
07.04.2025 16:46