Я читав кілька найкращих практик з 10up, і вони згадують про встановлення цих двох прапорів на false у WP_Query (залежно від того, що ви запитуєте):

• 'update_post_meta_cache' => false: корисно, коли пост-мета не буде використовуватися.
• 'update_post_term_cache' => false: корисно, коли терміни таксономії не будуть використані.

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

Кеш об'єктів скрізь

WordPress намагається максимально зменшити кількість запитів до бази даних.

Наприклад, щоразу, коли ви отримуєте метаполя або поле таксономії, перед тим, як запитувати базу даних, WordPress виглядає, якщо це вже було запитано і збережено в кеші, і повертає його звідти замість запиту до бази даних.

"Завдання кешу" виконується за допомогою WP_Object_Cacheкласу та wp_cache_*функцій (які обгортки методів цього класу.)

Де живе кеш

За замовчуванням "кеш" - це не що інше, як глобальна змінна PHP. Це означає, що воно є в пам'яті, але також означає, що воно зникає при кожному запиті.

Однак за допомогою дроплінгів ( advanced-cache.phpта / або object-cache.php) можна встановити власний спосіб обробки цього кешу.

Зазвичай ці краплі використовуються для налаштування якогось механізму кешування, який "переживає" сингулярні запити.

З цієї причини серед 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);

Дві рядки коду, що викладені вище, викликають максимум 1 запит до бази даних.

Насправді, коли ви запитуєте користувацьке поле, усі поля для цієї публікації витягуються з бази даних, кешуються за допомогою кеш-об’єктів, а наступні запити витягують дані з кеша, а не з db.

Те ж саме відбувається і з термінами систематики, 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 виконує лише один db-запит у кожній функції, але також робить багато обробки. Наприклад, 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 зменшити накладні витрати, пов’язані з надсиланням запитів до БД, надіславши лише один запит, щоб отримати інформацію для всіх публікацій, а не надсилати запит на кожну публікацію.

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

* кеш - Найважливішим тут є кеш на основі пам'яті, в якому WP зберігає майже все, що отримується від БД, навіть не активуючи жодного додатка кешування об'єктів. Очевидно, що у вас є кешування об'єктів, інформація також зберігатиметься там.