REDIS w WordPress – o to coraz częściej pytacie w kierowanych do nas zgłoszeniach, odkąd uruchomiliśmy specjalny hosting WordPress. Jakiś czas temu, szukając różnych sposobów na przyspieszenie strony na WordPressie, na portalu wordpress.tv natknęłam się na video „Grokking The WordPress Object Cache”. Temat, choć rzadko poruszany na blogach i forach o WordPressie, jest bardzo ciekawy. Nawet ogólna wiedza na ten temat może nam pomóc, jeśli próbujemy zoptymalizować naszą stronę.
Redis w WordPress – o co chodzi z object cache?
Object cache w WordPressie zaimplementowany jest za pomocą klasy WP Object Cache. Polega na cache’owaniu wyników zapytań SQL do bazy danych. Eliminuje to konieczność częstego łączenia się z bazą i pozwala na szybszy dostęp do danych.
Bardzo wcześnie w kodzie WordPressa tworzony jest obiekt tej klasy. Następnie są do niego wstawiane różne dane, które podczas ładowania WordPressa, pobierane są z bazy danych.
Są to m.in.:
- wszystkie opcje z tabeli wp_options, które mają ustawiony autoload na “true”
- dane zalogowanego użytkownika wraz z metadanymi
- wyniki WP Query – wpisy, strony, własne typy wpisów wraz z ich metadanymi i taksonomiami
- informacje o aktywnym motywie
- transienty
Dzięki zapisaniu tych danych w pamięci podręcznej zyskujemy do nich znacznie szybszy dostęp i nie musimy wykonywać wielokrotnych zapytań do bazy danych. Takie zapytania pojawiają się, kiedy chcemy np. wyświetlać dynamiczne elementy w różnych miejscach naszego motywu.
Mechanizm Object Cache jest całkiem sprytnie zaimplementowany w niektórych elementach WordPressa. Ciekawym przykładem są np. własne pola (custom fields).
Gdy dodajemy własne pola do wpisu lub strony, zapisane w nich metadane są później automatycznie, wraz z wpisem, pobierane z bazy danych (za pomocą WP QUERY).
Następnie, gdy wyświetlamy metadane za pomocą np. funkcji get_post_meta(), to funkcja ta, zanim wykona zapytanie do bazy, stara się najpierw pobrać dane z Object Cache. Dzięki temu unikamy wielokrotnego odpytywania bazy danych.
Na podobnej zasadzie działają też inne natywne funkcje w WordPressie np. get_option(), gdy chcemy pobrać daną opcję. Funkcja ta też najpierw sprawdza czy dana opcja istnieje w Object Cache. Następnie, kiedy tej opcji tam nie ma, zostaje wysłane zapytanie do bazy danych.
Redis w WordPress: Object Cache nie jest trwały
Największym problemem z zaimplementowanego w WordPressie Object Cache jest to, że nie jest on trwały (jest tzw. non-persistent). Oznacza to, że obiekt Object Cache jest tworzony osobno dla każdego użytkownika. Dzieje się to przy każdym załadowaniu strony. Serwer niszczy go przy każdym opuszczeniu strony przez użytkownika.
Gdy użytkownik przechodzi na kolejne podstrony, obiekt ten jest ciągle tworzony, wypełniany danymi i niszczony. A przy każdym przeładowaniu strony ponownie trzeba wykonać zapytania do bazy danych. Często są to takie same zapytania, wysyłane wielokrotnie do bazy, podczas jednej sesji użytkownika.
Jakie mamy możliwości jeśli chcielibyśmy przechować dane w sposób trwały. Redis w WordPress pomoże.
Transients API
WordPress natywnie oferuje nam mechanizm trwalszego przechowywania danych za pomocą Transients API. Jest to po prostu możliwość tymczasowego przechowania danych, w postaci osobnego rekordu w tabeli wp_options().
Transienty często wykorzystuje się do przechowywania np. wyników kosztownego zapytania do bazy czy danych pobranych z zewnętrznego źródła (np. poprzez zewnętrzne API).
Dzięki temu, zamiast wysyłać do bazy skomplikowane zapytanie za każdym razem kiedy ktoś wejdzie na stronę, możemy na określony czas przechować wynik tego zapytania w transiencie.
Pozwala to znacznie skrócić czas dostępu do danych. Zamiast wykonać skomplikowane i długotrwałe zapytanie do bazy, uzyskujemy szybsze zapytanie, do tabeli wp_options.
Warto korzystać z Transients API, szczególnie, że po podłączeniu WordPressa do Redisa lub Memcached, przejmą one przechowywanie danych z transientów.
Redis vs Memcached
Redis i Memcached są to mechanizmy przechowywania danych w pamięci RAM. Dane zapisuje się w formie klucz -> wartość. Redis jest rozwiązaniem nowszym i bardziej bezpiecznym. Ma lepsze mechanizmy autoryzacyjne i dlatego właśnie polecam Ci przede wszystkim Redisa.
Po podłączeniu WordPressa pod Redis, przejmuje on przechowywanie danych z obiektu klasy WP Object Cache. Od tego momentu Object Cache staje się trwały (persistent).
Gdy pierwszy użytkownik załaduje stronę, wykonają się zapytania do bazy i serwer zapisze wynikowe dane w Redisie. Dla kolejnych użytkowników serwer dane pobierze bezpośrednio z Redisa i nie będzie już konieczności łączenia się bazą danych. Czyli teraz dane będą nam się pobierać z pamięci podręcznej, a nie z bazy, co jest znacznie, znacznie szybsze.
Co ciekawe, transienty również są przechwytywane przez Redis, także nadal możemy czerpać korzyści z tymczasowego zapisania wyników kosztownych zapytań. Równocześnie możemy zyskać na tym, że teraz transient jest szybko dostępny w pamięci i nie ma już potrzeby wyciągania go z bazy za każdym razem kiedy ktoś ładuje stronę.
W cyberfolks.pl w pakietach hostingowych WordPress – WP Enduser i WP Developer, można w łatwy sposób podłączyć stronę pod Redis, za pomocą wtyczki LiteSpeed Cache. Więcej o tym w artykule 3 kroki do lepszej wydajności na hostingu WordPress.
Kiedy uzyskasz największe korzyści z włączenia Redisa w WordPress?
Największy wpływ na przyspieszenie strony po włączeniu Redis w WordPress odczujemy w sytuacjach, gdy na stronie mamy kosztowne zapytania do bazy. Przykładowo gdy wielokrotnie korzystamy w WP Query czy przeszukujemy bazę po danych z tabeli wp_postmeta.
Pamiętaj, że w Redisie nie przechowujemy kopii całej bazy danych, a jedynie wyniki zapytań do bazy, wykonywanych podczas ładowania WordPressa.
Jeśli na stronie mamy wyszukiwarkę, w której użytkownik może zdefiniować własne parametry wyszukiwania, to Redis w WordPress niewiele tu pomoże. Wówczas wyniki wyszukiwania za każdym razem będą inne i ciężko byłoby je cache’ować do ponownego wykorzystania.
Natomiast jeśli np. tworzymy archiwa, które wymagają bardziej złożonych zapytań do bazy, np. po kilku parametrach zapisanych w tabeli wp_postmeta i wyniki tych zapytań nie zmieniają się często, to ma duży sens cache’ować je w Redisie.
Redis w WordPress może też bardzo poprawić prędkość ładowania strony. To użyteczne, kiedy (np. przez źle napisaną wtyczkę), mamy dużo rekordów w tabeli wp_options. Pierwsze zapytanie do bazy w WordPressie skierowane jest właśnie do tej tabeli. Jeśli ma ona dużo rekordów, to jej przeszukanie może trwać długo. Dzięki przechowaniu wyników tego zapytania w Redisie unikamy przeszukiwania tabeli wp_options przy każdym załadowaniu strony.
Redis w WordPress. Jak sprawdzić liczbę zapytań SQL do bazy danych na naszej stronie „przed i po”?
WordPress API udostępnia nam funkcję get_num_queries(), dzięki której możemy wyświetlić liczbę zapytań do bazy danych, wykonanych podczas ładowania strony.
Wstawiam więc na czas testów, w pliku footer.php niniejszą linijkę kodu:
<p>Liczba zapytań do bazy: <?php echo get_num_queries();?></p>I w przypadku domyślnej instalacji WordPressa, w motywie potomnym Twenty Seventeen, uzyskuję poniższe wyniki:
WordPress & motyw Twentyseventeen
W tym przypadku, podłączenie strony pod Redis pozwoliło zmniejszyć liczbę zapytań do bazy danych o ok. 80%.
WooCommerce & motyw Storefront
Testuję jeszcze jak sprawa wygląda w sklepie internetowym opartym o wtyczkę WooCommerce i jej domyślny motyw Storefront. Wyniki wyglądają jeszcze bardziej obiecująco.
WooCommerce & Storefront
W przypadku WooCommerce Redis przechwycił aż 94% zapytań do bazy danych!
Zapytania do bazy możemy też sprawdzić za pomocą wtyczki Query Monitor. Wskaże ona m.in. ile i jakie zapytania SQL wykonano podczas ładowania strony. Uzyskasz także informację, ile trwało wykonanie wszystkich zapytań łącznie i każdego z osobna. Jest to bardzo przydatne gdy chcemy namierzyć bardzo wolne zapytania do bazy.
W sekcji Object Cache wtyczka wykaże, czy na naszym serwerze funkcjonuje Redis lub Memcached. Jeśli zatem otrzymamy tutaj informację, że jedno z nich jest dostępne, to warto skontaktować się ze swoim hostingodawcą aby uzyskać dane do połączenia.
Redis w WordPress na hostingu cyberfolks.pl
W cyber_Folks w pakietach hostingowych dla WordPress, można w łatwy sposób podłączyć stronę pod Redis, za pomocą wtyczki LiteSpeed Cache. Przewodnik jak to zrobić znajdziesz w artykule 3 kroki do lepszej wydajności na hostingu WordPress.
Zapraszam Cię do skorzystania z 14 dniowego okresu testowego. Podczas niego możesz bez żadnych zobowiązań podłączyć swoją stronę pod Redis i sprawdzić jak to wpłynie na przyspieszenie strony. Jeśli nie wiesz jak przetestować stronę, odezwij się do naszego Biura Obsługi Klienta. Nasi admini pomogą Ci przekopiować i skonfigurować Twoją stronę internetową tak, żeby Redis WordPress pokazał pazury!
Częste pytania o Redis
Redis to mechanizm nowszy, zapewnia lepszą autoryzację użytkownika. Zdecydowanie polecam Redis.
Będą potrzebne: adres serwera redis, port oraz hasło uwierzytelniające. Wszystkie te dane uzyskasz w panelu cyberfolks.pl po kliknięciu opcji Serwer Redis, dostępnej w planach hostingu WordPress.
Serwer Redis jest dostępny bez dodatkowych opłat w planach hostingu WordPress oraz hostingu PrestaShop.
Tylko zapomnialas napisac, ze mozna podgladac co inni klienci maja w redisie 😀
Kuba M Aby podejrzeć co inni użytkownicy mają w Redisie trzeba by najpierw wejść w posiadanie ich haseł do Redisa. A każdy użytkownik ma ustawione inne hasło. 😉
a można coś takiego w joomla, by była szybsza?
Nie tylko WordPress korzysta z mechanizmów cacheowania obiektowego. Inne systemy, jeśli współpracują z Redisem, także mogą z tego korzystać. Zdaje się, że do Joomla! istnieją także odpowiednie, gotowe wtyczki.
Warto sprostować, że Joomla 3 już obsługuje Redis’a – bez dodatkowych wtyczek.
da się 🙂 w najnowszej joomli są ustawienia cache i tam Redis do wyboru
Jak wordpress hosting wypada w porównaniu z histingiem SSD gdzie jest Lite Speed Cache. ?
Są to dosyć porównywalne konta, w pakiecie Hosting SSD nie jest zainstalowany Redis, a tylko Memcached, no i nie masz dostępu do innych, specyficznych dla WordPressa, dodatków.
Dobra opcja, nie wiedziałem, że to macie. Wykorzystam na pewno.
Michał zapraszamy 🙂
Miałem ostatnio sytuację, że wpadło mi kilka pustych zamówień – woocommerce zwrócił komunikat, że zabrakło pamięci. Nie chciałem by sytuacja się powtórzyła, więc wyłączyłem cache obiektowy.
Nie wiem czy o tej samej pamięci mowa, ale przy Redis oferujecie 128MB a przy Memcached 512 MB – do czego odnoszą się te wartości, i czy skoro zdarzyło się, że zabrakło u mnie pamięci, powinienem wybrać Memcached bo więcej jej oferuje?
Jako laik zapytałbym czym różni się Redis od Memcached – Wasz support odpisuje, że są to inne mechanizmy i można ich używać równolegle – niestety wtyczka, którą polecacie do WordPress, pozwala tylko na wybranie jednego rodzaju cachowania obiektowego – można to jakoś obejść?
Osobiście sam dzisiaj doświadczyłem problem z zapełnieniem się pamięci w Redisie (WordPress zwracał komunikat „Krytyczny błąd). Przełączyłem się na Memcached i będę obserwował.
Bardzo interesujące. Wdrożymy u siebie na pewno. LiteSpeed Cache to dobre rozwiązanie. Warto także pamiętać o podbijaniu wersji PHP.
Dla mnie to jakaś fantastyka, nawet nie wiedziałem że takie coś jest. Muszę dokładniej wczytać się w ten temat. Wydaje się bardzo przydatne szczególnie jeśli strona nadal tworzy około 60% szybkości i nic więcej przez samą architekturę wordpressa. Dziękuję za te wskazówki.
Bardzo przydatny artykuł..Szkoda jednak że nie ma porównania jeżeli odnośnie szybkości strony w narzędziu Google speed test.
Czy ktoś mógłby się wypowiedzieć na temat Memcached w porównaniu do Redisa? Osobiście korzystam obecnie z Memcached w cyberfolks.pl, a podobno Redit jest wydajniejszy.
Raczej chodzi o to, że Redis to nowsza technologia, zapewniająca lepszą funkcjonalność, przykładowo lepsze wsparcie dla danych typu „geospatial”, ma w ogóle możliwość definiowania typów danych, czego nie ma w Redis, klucze w Memcached są znacznie krótsze niż w Redis, Redis może też replikować dane na nośniki trwałe. Redis tak ogólnie jest bardziej funkcjonalny, podczas gdy memcached to rozwiązanie prostsze, starsze. Dla prostych stron prawdopodobnie nie poczujesz szczególnej różnicy w szybkości, choć bywa, że jedno z rozwiązań jest nieco szybsze niż drugie.
Jak się ma redis do armember w panelu administracyjnym ? mamy około 20 tys użyszkodników i bardzo często zapytania do bazy trwają po 15s. Jak ma się redis do treści płatnych zablokowanych dla użytkowników ? mam opcję tylko dla niezalogowanych czy jeśli włączę dla zalogowanych nie wypłyną treści płatne ?
Ostatnio otrzymałem informację od suportu pewnej wtyczki taką informację:
„Redis Cache nie jest tak naprawdę kompatybilny z WooCommerce – ponieważ nie pozwala wykluczyć niektórych stron lub obiektów z pamięci podręcznej. Może więc zakłócać lub zakłócać szereg funkcji oferowanych przez WooCommerce (nie tylko naszą wtyczkę, ale także podstawowy produkt).”
Czy w takim wypadku jest sens w ogóle używać redisa?
Czy włączenie Redisa w LS Cache z domyślną wartością 128MB może powodować problem z dodawaniem dużych galerii (ponad 100 miniatur)? W adminie zawiesza się na wyborze rozmiaru miniatury, na froncie brak linku do dużego obrazka.