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, a nawet ogólna wiedza na ten temat może nam pomóc, jeśli próbujemy zoptymalizować naszą stronę.

Object cache w WordPressie zaimplementowany jest za pomocą klasy WP Object Cache i 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, chcąc je np. wyświetlać 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).

własne pola w WordPressie

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, i tylko wtedy gdy tej opcji tam nie ma, zostaje wysłane zapytanie do bazy danych.

Object Cache nie jest trwały

Największym problemem 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, przy każdym załadowaniu strony i niszczony przy każdym jej opuszczeniu 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 muszą zostać wysłane 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?

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, ponieważ 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/ Memcached

Redis i Memcached są to mechanizmy przechowywania danych w pamięci RAM, w formie klucz -> wartość.

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 dane zostaną zapisane w Redisie. Dla kolejnych użytkowników dane będą pobierane 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ń, ale 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 linuxpl.com w pakietach hostingowych pod WordPressa – 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 odniesiemy największe korzyści z włączenia Redisa

Największy wpływ na przyspieszenie strony po włączeniu Redisa 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.

Trzeba jednak pamiętać, że w Redisie nie przechowujemy kopii całej bazy danych, a jedynie wyniki zapytań do bazy, wykonywanych podczas ładowania WordPressa.

Jeśli więc na stronie mamy wyszukiwarkę, w której użytkownik może zdefiniować własne parametry wyszukiwania, to Redis niewiele tu pomoże, gdyż 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 może też bardzo poprawić prędkość ładowania strony gdy, z jakiegoś względu (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 i 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.

Jak sprawdzić liczbę zapytań SQL do bazy danych na naszej stronie

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

Przed podłączeniem do Redisa:

Po podłączeniu do Redisa:

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

Przed podłączeniem do Redisa:

Po podłączeniu do Redisa:

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 nam ona m.in. ile i jakie zapytania SQL były wykonane podczas ładowania strony, a także 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 wskaże nam także czy na naszym serwerze zainstalowany jest Redis lub Memcached. Jeśli więc otrzymamy tutaj informację, że jedno z nich jest dostępne, to warto skontaktować się ze swoim hostingodawcą aby uzyskać dane do połączenia.

wtyczka query monitor

Redis w linuxpl.com

W linuxpl.com w pakietach hostingowych pod WordPressa – WP Enduser i WP Developer, 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.

Zachęcamy do skorzystania z 14 dniowego okresu testowego, podczas którego 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 podpiąć Twoją stronę internetową pod Redis.

Komentarze (8)


  1. 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. 😉

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

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

Odpowiedz

Adres email nie będzie opublikowany.

*