Я читал некоторые лучшие практики из 10up, и они упоминают установку этих двух флагов в false в WP_Query (в зависимости от того, что вы запрашиваете):

• 'update_post_meta_cache' => false: полезно, когда post meta не будет использоваться.
• 'update_post_term_cache' => false: полезно, когда не используются термины таксономии.

Я предполагаю, что это что-то вроде, update_post_caches()но я даже не уверен на 100%, что это значит. Может ли кто-нибудь объяснить, что означают эти два флага WP_Queryи насколько они полезны? Чем больше информации, тем лучше, поскольку я не очень много знаю о том, как WordPress кэширует вещи, но хорошо продуманный ответ относительно этих двух флагов также приемлем.

Кэш объектов везде

WordPress старается максимально сократить количество запросов к базе данных.

Например, всякий раз, когда вы получаете мета-поле или поле таксономии, перед запросом к базе данных WordPress проверяет, было ли это уже запрошено и сохранено в кеше, и возвращает его оттуда вместо запроса к базе данных.

«Кэширование» выполняется с помощью WP_Object_Cacheкласса и wp_cache_*функций (которые являются оберткой для методов этого класса.)

Где живет кеш

По умолчанию «кеш» - это не более чем глобальная переменная PHP. Это означает, что он находится в памяти, но также означает, что он исчезает при каждом запросе.

Тем не менее, через dropins ( advanced-cache.phpи / или object-cache.php), можно настроить собственный способ обработки этого кэша.

Обычно эти dropins используются для установки какого-то механизма кэширования, который «выживает» в единичных запросах.

По этой причине среди разработчиков WP они известны как плагины «постоянный кеш» (даже если вне пузыря слова «кеш» и «постоянный» не имеют большого смысла).

В настоящее время популярным выбором являются Memcached или Redis .

Таким образом, с помощью плагинов «постоянный кеш» вы можете значительно сократить количество запросов к базе данных, поскольку кеш не обновляется при каждом запросе.

Некоторые примеры

$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);

Приведенные выше 2 строки кода инициируют, как правило, 1 запрос к базе данных.

Фактически, когда вы запрашиваете пользовательское поле, все поля для этого сообщения извлекаются из базы данных, кэшируются через кеш объекта, а последующие запросы извлекают данные из кеша, а не из базы данных.

То же самое происходит с терминами таксономии, WordPress извлекает все термины таксономии один раз, а затем возвращает их из кэша.

Кэш объектов очень широко используется в WordPress. Не только для сообщений, мета-значений и таксономий, но и для пользователей, комментариев, данных тем ...

Что WP_Queryобщего со всем этим?

При запросе некоторых сообщений WP_Queryпо умолчанию WordPress не только извлекает их из базы данных (или из кэша, если они кэшируются), но также обновляет кэш для всех настраиваемых полей и всех таксономий, связанных с извлеченными публикациями.

Так, например, когда вы звоните get_the_terms()или get_post_meta()зацикливаете сообщения, полученные через WP_Query, вы фактически не запускаете какой-либо запрос к базе данных, а извлекаете информацию из кеша.

Хорошо, это не так?

Ну, да, но это идет с оплатой.

Обновление кэша "магия", которую делает WordPress, когда получение сообщений WP_Queryпроисходит через update_meta_cacheмета и update_object_term_cacheтаксономии.

Если вы посмотрите на исходный код этих функций, то увидите, что там WordPress выполняет только один запрос БД в каждой функции, но также выполняет большую обработку. Например, update_object_term_cacheесть 7 вложенныхforeach ... если у вас много таксономий и количество постов на странице велико, это не очень эффективно.

О тех WP_Queryаргументах, наконец,

Что 'update_post_meta_cache'и 'update_post_term_cache'делать, когда установлено, чтобы falseзапретить WordPress обновлять кеш для пользовательских полей и таксономий, соответственно.

В этом случае при первом обращении к пользовательскому полю или таксономии запрашивается запрос к базе данных и данные кэшируются.

Это стоит хлопот?

Как обычно, ответ - это зависит . Большую часть времени для установки этих значений falseявляется хорошим выбором, поскольку он предотвращает ненужную обработку и запросы к базе данных, если они не нужны, а кэш-память обновляется в любом случае при первом использовании условий настраиваемого поля / таксономии.

Однако, если вы собираетесь звонить, хотя бы один раз, get_post_meta()во время цикла, и вы собираетесь звонить get_the_terms()для всех (или большинства) таксономий, поддерживаемых постами, тогда обновление кеша инициируется в любом случае, и на самом деле не может быть никакой реальной выгоды установка этих аргументов запроса в false.

Главной достопримечательностью здесь является update_post_cachesфункция. Он вызывается после того, как WP_Query получил все сообщения из БД. Обычно причина, по которой вы хотите, чтобы посты были в первую очередь, заключается в том, чтобы отображать их, что обычно означает отображение терминов и чего-либо на основе метаданных, поэтому WP_Query также по умолчанию запрашивает в БД мета-данные и данные терминов, относящиеся к возвращаемым постам и хранит его в кеше *. Эта информация явно недоступна в данных, возвращаемых из WP_Query, но когда вы вызовете соответствующие API для получения термина и метаинформации определенного поста, она уже будет доступна в памяти и не будет необходимости отправлять новый запрос в БД.

Это позволяет WordPress уменьшить накладные расходы, связанные с отправкой запросов в БД, отправляя только один запрос для получения информации для всех сообщений вместо отправки запроса для каждого сообщения.

Прямо сейчас я не могу найти ни одного нетривиального примера того, когда вы не хотите обновлять кеш, но тривиальным может быть, если вы просто хотите получить список заголовков всех сообщений. Для этого вам не нужны термин или метаданные.

* cache - наиболее важным здесь является кэш на основе памяти, в котором WP хранит почти все, что получает от БД, даже без использования какого-либо активного плагина кэширования объектов. Очевидно, что когда у вас есть объектное кэширование, информация также будет храниться там.