Objaśnienie bufora aktualizacji_post_ (meta / term) _cache

23

Czytałem niektóre najlepsze praktyki z 10up i wspominają o ustawieniu tych dwóch flag na false w WP_Query (w zależności od tego, o co pytasz):

  • 'update_post_meta_cache' => false: przydatne, gdy meta post nie będzie używana.
  • 'update_post_term_cache' => false: przydatne, gdy warunki taksonomiczne nie będą stosowane.

Jestem zakładając go wykorzystując coś podobnego update_post_caches(), ale nie jestem jeszcze w 100% pewien, co to znaczy. Czy ktoś mógłby wyjaśnić, co oznaczają te dwie flagi w WP_Queryi jak są one użyteczne? Im więcej informacji, tym lepiej, ponieważ nie wiem wiele o tym, jak WordPress buforuje rzeczy, ale dobrze przemyślana odpowiedź dotycząca tych dwóch flag jest również akceptowalna.

Howdy_McGee
źródło

Odpowiedzi:

30

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_Cacheklasę 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.phpi / 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_Querypomocą 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_Queryzdarza się w update_meta_cacheprzypadku meta i update_object_term_cachetaksonomii.

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_cacheistnieje 7 zagnieżdżonychforeach ... jeśli masz dużo taksonomii, a liczba postów na stronie jest wysoka, nie jest to zbyt wydajne.

WP_QueryWreszcie o tych argumentach

Co zrobić 'update_post_meta_cache'i 'update_post_term_cache'zrobić, gdy jest ustawiony na falseto, 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.

gmazzap
źródło
Schludny! Jak zawsze twój wgląd jest zawsze doceniany przez GM. Czy transjenty będą uważane za „trwałe buforowanie”? Aby przejść dalej, podczas WP_Query powodem wp_reset_postdata()jest zresetowanie global $posti 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.
Howdy_McGee
1
@Howdy_McGee Pamięć podręczna obiektu i obiekt post nie są powiązane. Więc wp_reset_postdata()nie rób nic w odniesieniu do pamięci podręcznej obiektów. wp_reset_postdata()resetuj tylko globalny obiekt pocztowy, który jest kolejną zmienną globalną, która nigdy nie jest buforowana ... Transjenty to hybryda: kiedy masz zainstalowaną trwałą wtyczkę pamięci podręcznej, używaj jej przejściowo, ale jeśli nie masz stałej wtyczki pamięci podręcznej, to transjenty użyj bazy danych.
gmazzap
Ach, właśnie wpadłem na global variablepojęcie i założyłem, że to obiekty global $postglobalne $wp_query, dzięki za wyjaśnienie!
Howdy_McGee
Na marginesie , fields => 'ids'ustawia zarówno do pamięci podręcznej false. Wydaje mi się, że to ma sens, że pamięć podręczna obiektów działa tylko na obiektach, ale pomyślałam, że po prostu wspomnę: D
Howdy_McGee
3

Głównym punktem zainteresowania jest tutaj update_post_cachesfunkcja. Jest wywoływany po tym, jak WP_Query ma wszystkie posty z bazy danych. Zwykle powodem, dla którego chcesz, aby posty były w pierwszej kolejności wyświetlane, co zwykle oznacza wyświetlanie terminów i czegoś opartego na metadanych, dlatego WP_Query domyślnie również zapyta DB o dane meta i terminów związane ze zwróconymi postami i zapisuje w pamięci podręcznej *. Informacje te nie są wyraźnie dostępne w danych zwróconych z WP_Query, ale gdy zadzwonisz do odpowiednich interfejsów API, aby uzyskać termin i meta informacje o konkretnym poście, będzie on już dostępny w pamięci i nie będzie potrzeby wysyłania nowego zapytanie do bazy danych.

Umożliwia to wordpressowi zmniejszenie narzutu związanego z wysyłaniem żądań do bazy danych przez wysłanie tylko jednego żądania uzyskania informacji dla wszystkich postów zamiast wysyłania żądania dla każdego postu.

W tej chwili nie mogę znaleźć żadnego nietrywialnego przykładu, kiedy nie chcesz aktualizować pamięci podręcznej, ale trywialny może być, jeśli chcesz tylko listę tytułów wszystkich postów. Do tego nie potrzebujesz danych ani metadanych.

* pamięć podręczna - Najważniejsza jest pamięć podręczna oparta na pamięci, w której WP przechowuje prawie wszystko, co otrzymuje z bazy danych, nawet bez aktywnej wtyczki buforowania obiektów. Oczywiście, gdy masz buforowanie obiektów, informacje również tam będą przechowywane.

Mark Kaplun
źródło