Wszędzie pamięć podręczna obiektów
WordPress stara się maksymalnie ograniczyć liczbę zapytań do bazy danych.
Na przykład, za każdym razem, gdy pojawi się pole meta lub pole taksonomiczne, przed zapytaniem do bazy danych, WordPress sprawdza, czy to było już sprawdzone i zapisane w pamięci podręcznej, i zwraca je stamtąd zamiast zapytania do bazy danych.
„Zadanie pamięci podręcznej” jest wykonywane przez WP_Object_Cache
klasę i wp_cache_*
funkcje (które są opakowaniem w metody tej klasy).
Gdzie mieszka pamięć podręczna
Domyślnie „pamięć podręczna” jest jedynie globalną zmienną PHP. Oznacza to, że jest w pamięci, ale także, że znika na każde żądanie.
Jednak poprzez dropins ( advanced-cache.php
i / lubobject-cache.php
) można ustawić niestandardowy sposób obsługi tego bufora.
Zwykle te dropiny są używane do skonfigurowania pewnego rodzaju mechanizmu buforowania, który „przetrwa” pojedyncze żądania.
Z tego powodu wśród osób WP są one znane jako wtyczki „trwałej pamięci podręcznej” (nawet jeśli poza bańką słowa „pamięć podręczna” i „trwałe” nie mają większego sensu).
Obecnie popularne opcje to Memcached lub Redis .
Tak więc używając wtyczek „trwałej pamięci podręcznej” możesz drastycznie zmniejszyć liczbę zapytań do bazy danych, ponieważ pamięć podręczna nie jest aktualizowana przy każdym żądaniu.
Kilka przykładów
$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);
Powyższe 2 wiersze kodu wywołają maksymalnie 1 zapytanie do bazy danych.
W rzeczywistości, gdy przeszukujesz niestandardowe pole, wszystkie pola dla tego postu są pobierane z bazy danych, buforowane za pomocą pamięci podręcznej obiektów, a kolejne żądania pobierają dane z pamięci podręcznej, a nie z bazy danych.
To samo dzieje się w przypadku terminów taksonomicznych: WordPress raz pobiera wszystkie terminy dotyczące taksonomii, a następnie zwraca je z pamięci podręcznej.
Pamięć podręczna obiektów jest bardzo szeroko stosowana w WordPress. Nie tylko dla postów, meta wartości i taksonomii, ale także dla użytkowników, komentarzy, danych motywów ...
Co WP_Query
ma z tym wszystkim wspólnego?
Kiedy przeszukujesz niektóre posty za WP_Query
pomocą domyślnie, WordPress nie tylko pobiera je z bazy danych (lub z pamięci podręcznej, jeśli są buforowane), ale także aktualizuje pamięć podręczną dla wszystkich niestandardowych pól i taksonomii związanych z pobranymi postami.
Na przykład, kiedy dzwonisz get_the_terms()
lub get_post_meta()
gdy zapętlasz posty WP_Query
, nie uruchamiasz żadnych zapytań do bazy danych, ale pobierasz informacje z pamięci podręcznej.
Fajnie, nie jest?
No tak, ale wiąże się to z pewnymi kosztami.
Aktualizacja „pamięci podręcznej” „magii”, którą robi WordPress, gdy ściąga posty za pośrednictwem WP_Query
zdarza się w update_meta_cache
przypadku meta i update_object_term_cache
taksonomii.
Jeśli spojrzysz na kod źródłowy tych funkcji, zobaczysz, że WordPress wykonuje tylko jedno zapytanie db w każdej funkcji, ale także dużo przetwarza. Na przykład, update_object_term_cache
istnieje 7 zagnieżdżonychforeach
... jeśli masz dużo taksonomii, a liczba postów na stronie jest wysoka, nie jest to zbyt wydajne.
WP_Query
Wreszcie o tych argumentach
Co zrobić 'update_post_meta_cache'
i 'update_post_term_cache'
zrobić, gdy jest ustawiony na false
to, aby WordPress nie aktualizował pamięci podręcznej odpowiednio dla pól niestandardowych i systematyk.
W takim przypadku przy pierwszym zapytaniu o pole niestandardowe lub taksonomię uruchamiane jest zapytanie do bazy danych i dane są buforowane.
Warto kłopotać się?
Jak zwykle odpowiedź brzmi: to zależy . Większość czasu, aby ustawić te wartości false
, jest dobrym wyborem, ponieważ zapobiega niepotrzebnemu przetwarzaniu i zapytaniom do bazy danych, jeśli nie są potrzebne, a pamięć podręczna jest aktualizowana mimo to po raz pierwszy, gdy wymagane są niestandardowe warunki pola / taksonomii.
Jeśli jednak zamierzasz zadzwonić, nawet raz, get_post_meta()
podczas pętli i zamierzasz zadzwonić get_the_terms()
do wszystkich (lub większości) taksonomii obsługiwanych przez posty, wówczas aktualizacja pamięci podręcznej zostanie uruchomiona i może nie być rzeczywistej korzyści z ustawienie tych argumentów zapytania na false
.
wp_reset_postdata()
jest zresetowanieglobal $post
i zresetowanie pamięci podręcznej obiektów? Wygląda na to, że gdybym zrobił niestandardową WP_Query, utworzyłby nowy obiekt w pamięci podręcznej, ale zresetowanie go również wymagałoby ponownego uzyskania oryginalnej pamięci podręcznej. A może zbyt daleko idę w kontekście tego pytania.