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.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.global variable
pojęcie i założyłem, że to obiektyglobal $post
globalne$wp_query
, dzięki za wyjaśnienie!fields => 'ids'
ustawia zarówno do pamięci podręcznejfalse
. 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ę: DGłównym punktem zainteresowania jest tutaj
update_post_caches
funkcja. 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.
źródło