Коэффициент попаданий в кэш объектов WordPress: значимость и целесообразные целевые значения

Что сохраняет кэш объектов WordPress

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

Встроенная реализация Core по умолчанию связанный с запросом: Он сохраняет записи на время одного запроса. Таким образом, при последующем обращении к странице ранее сохраненные значения не становятся автоматически доступными. Тем не менее кэш позволяет избежать повторных обращений даже в рамках одного запроса.

Функция drop-in может заменить базовую реализацию на постоянный кэш объектов заменить. Тогда соответствующие записи могут сохраняться не только в рамках отдельных запросов. Redis — один из возможных вариантов бэкэнда, но он не является обязательным условием для WordPress; возможны и другие подходы к реализации бэкэнда. Даже при использовании постоянного модуля определенные группы по-прежнему могут применяться только к текущему запросу.

Транзиенты — это ещё один способ хранения данных, необходимых в течение ограниченного периода времени. С помощью постоянного объектного кэша их можно сохранять там, а не в базе данных, как обычно. Срок их действия не означает гарантированной минимальной доступности: значение может исчезнуть раньше. Поэтому код приложения должен быть готов к отсутствию транзиента и иметь возможность восстановить значение при необходимости.

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

Различия между кэшем объектов и кэшем страниц

При просмотре страницы может Кэш страниц предоставить уже сгенерированный ответ страницы. Если запрос обрабатывается там, ему не нужно проходить тот же путь в приложении WordPress, что и запросу, не сохраненному в кэше. Объектный кэш, в свою очередь, работает внутри приложения с отдельными кэшированными данными, а не с полным ответом страницы.

Представьте себе общедоступную страницу статьи: если её содержимое находится в кэше страниц, оно может быть сразу же предоставлено пользователю. Если же WordPress должен сгенерировать эту страницу, кэш объектов может помочь при повторных запросах данных. То, какой объём работы благодаря этому действительно удаётся сократить, зависит от запроса, сохраненных записей и конкретной реализации.

Это влияет на интерпретацию данных: хороший показатель «Object Cache» отражает лишь зарегистрированные обращения к кэшу. Он не дает непосредственного представления о том, сколько посетителей уже получили готовый ответ из кэша страниц или насколько быстро реагирует весь сайт в целом. При интенсивном кэшировании страниц преимущества объектного кэша становятся заметны, прежде всего, по оставшимся запросам WordPress.

Кроме того, кэш браузера и кэш опкодов выполняют другие задачи. Кэш браузера хранит ресурсы у посетителя; кэш опкодов PHP хранит скомпилированный код PHP. Ни один из них не заменяет ни хранение отдельных данных приложения в объектном кэше, ни выдачу полного ответа из кэша страниц.

Константа WP_CACHE Само по себе это не активирует объектный кэш Redis. Для создания постоянного объектного кэша вам понадобится соответствующая реализация и поддерживаемая ею конфигурация. Дополнительный пример взаимодействия нескольких уровней вы найдете в статье о Механизм кэширования AccelerateWP.

Что говорят успехи и неудачи

A Хит имеет место, когда искомая запись обнаруживается на рассматриваемом уровне кэша. Один Мисс означает, что его там не найдено. Коэффициент попаданий рассчитывается как отношение числа попаданий ко всем подсчитанным попаданиям и промахам: попадания / (попадания + промахи) × 100. Если ни попаданий, ни промахов нет, коэффициент за этот период не определяется.

Ошибка не всегда означает технический сбой. При первом обращении запись может ещё отсутствовать; даже после истечения срока её действия её, в некоторых случаях, необходимо заново получить или создать. Решающим фактором является то, какие последствия имеют такие неудачные попытки в конкретном процессе и имеет ли смысл вообще повторять обращение.

В своей собственной реализации метод Core WordPress подсчитывает попадания в кэш и неудачные попытки. Однако эту реализацию можно заменить с помощью плагина. Поэтому на основе статистики ядра невозможно с уверенностью определить, что именно учитывает плагин: проверьте для используемой версии, какие запросы и какой период времени охватывает её показатель.

Redis выдает сообщение keyspace_hits и keyspace_misses удачные или неудачные поиски ключей в пространстве ключей Redis. Даже неудачный EXISTS-Такой бросок может быть засчитан как фол. Это Коэффициент успешности Redis поэтому не следует автоматически приравнивать к квоте WordPress или плагинов.

Если один экземпляр Redis обслуживает несколько веб-сайтов или приложений, его счетчики могут отражать совокупный трафик всех этих ресурсов. В таком случае без соответствующей отдельной телеметрии невозможно достоверно отнести глобальный лимит к отдельному веб-сайту WordPress. Поэтому при любом сравнении следует указывать, какой уровень и какой экземпляр описывают эти цифры.

Тщательно проверить диапазон измерения и доступ

Перед началом измерений выясните, какую реализацию кэша объектов использует WordPress. Если WP-CLI доступен и у вас есть доступ к каталогу WordPress, вы можете запустить там проверку содержимого в режиме чтения с помощью следующей команды:

wp cache type

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

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

В случае Redis, при наличии подключения и соответствующих прав доступа, в сеансе Redis CLI можно в режиме чтения запросить статистику и информацию о памяти. В приведённых ниже командах умышленно не указаны учетные данные:

INFO stats
INFO memory

Задокументируйте Диапазон измерения: Какие инстансы или узлы были проверены и какие другие веб-сайты или приложения их используют? Глобальные счетчики Redis при совместном использовании не всегда можно однозначно отнести к отдельному веб-сайту. Перед передачей данных проверьте вывод на наличие конфиденциальной эксплуатационной информации; для проведения этой инвентаризации не требуется ни сброс данных, ни нагрузочное тестирование.

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

Расчет коэффициента попадания Redis за интервал времени

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

Затем для каждого счетчика вычти начальное значение из конечного. Частота попаданий в интервале равно: ΔHits / (ΔHits + ΔMisses) × 100. Символ Δ обозначает соответствующую разницу. Если обе разницы равны нулю, это означает, что в данном окне не было зарегистрированных запросов; в таком случае коэффициент не определён, а не равен нулю процентам.

Наглядный расчетный пример, а не результаты измерений: если количество успешных запросов увеличивается на 900, а количество неудачных — на 100, то при общем количестве 1 000 учтенных запросов получается 90 процентов. Это не означает ни того, что страницы стали на 90 процентов быстрее, ни того, что было сэкономлено ровно 900 запросов к базе данных. Redis подсчитывает количество обращений к ключам; их значение для приложения зависит от конкретного доступа.

Если один из счетчиков между считываниями уменьшается, простая разность, рассчитанная с учетом этого спада, будет неверной. Это может быть вызвано перезапуском или сбросом статистических данных. Начните измерение заново или разделите его на отрезки на основе надёжных эксплуатационных данных, вместо того чтобы вводить отрицательное значение в формулу.

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

При этом обратите внимание на то, какие узлы фактически учитываются и какую роль они играют в данной среде. Рассчитанный таким образом общий показатель описывает только выбранные счетчики и их пользователей; он не является результатом простого суммирования, дающего конкретный показатель кэша объектов WordPress.

Протокол измерений и показатели Redis

Помимо показателей «хитов» и «промахов», в классификации помогают и другие счетчики Redis. И в данном случае различия в выбранном периоде времени носят более информативный характер, чем отдельные итоговые показатели. В приведенной ниже таблице проведено разграничение между значением самих значений и выводами, которые не могут быть обоснованы только ими.

Рост на expired_keys может послужить поводом для более тщательного анализа сроков хранения и моделей доступа. Однако это не показывает, потребовалась ли запись вновь вскоре после истечения срока хранения. Кроме того, evicted_keys рассматривать в контексте настроенного предела памяти и стратегии вытеснения, а не сразу делать из этого вывод о необходимости увеличения объёма памяти.

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

Одновременно фиксируйте рассматриваемый тип запроса и соответствующий показатель задержки, а также нагрузку на базу данных и частоту ошибок. Например, разделяйте просмотры общедоступных страниц и запросы от авторизованных пользователей, если для этого имеются соответствующие данные. Один только показатель Redis не позволяет определить, какой из этих типов запросов получил выгоду от попадания в кэш.

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

Холодный запуск, интернет-магазин и статический сайт

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

В случае интернет-магазина или раздела, доступного только после входа в систему, динамические запросы представляют особый интерес: кэш страниц не всегда отвечает на каждый запрос, связанный с корзиной или учетной записью. Поэтому сравнивайте, по возможности, похожие типы запросов и, помимо доли успешных ответов, обращайте внимание на время их выполнения и нагрузку на базу данных. Высокий показатель Redis Hit Rate сам по себе не свидетельствует о том, что корзина отображается быстро и с правильным содержанием.

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

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

Анализ подозрительных значений и ошибок

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

Счетчики expired_keys и evicted_keys предоставляют дополнительную информацию: первый показатель учитывает просроченные ключи, второй — ключи, вытесненные из-за ограничения объёма памяти. Их различия зависят от конкретного экземпляра Redis и должны соответствовать его конфигурации и целям использования. Наличие большого количества ключей с истекшим сроком действия не свидетельствует ни о неправильно выбранном значении TTL, ни о том, что более длительный срок хранения целесообразен; это может ухудшить актуальность сохраненных данных.

Для собственных расширений необходимо wp_cache_get параметр $found Важно: он различает найденное и сохраненное значение false из-за отсутствующей записи. Перед выполнением действий, связанных с группами, тебе следует с помощью wp_cache_supports проверить, поддерживает ли конкретный бэкенд нужную функцию. Заменяющий модуль «drop-in» может отличаться от реализации в ядре.

Предупреждение: Необдуманная очистка кэша может затронуть больше записей или приложений, чем предполагалось, и исказить результаты следующего измерения из-за «холодного» запуска. Прежде чем выполнять действия по удалению, уточните область воздействия и получите разрешение. Дополнительные рекомендации по Устранение неполадок при медленной работе кэша объектов WordPress помочь учесть в исследовании также возможные накладные расходы, связанные с кэшем.

Самостоятельно определять целевые показатели, отвечающие конкретным задачам

Универсальная минимальная квота в 90 процентов не является обоснованным техническим требованием. Более целесообразно установить целевой диапазон с учетом особенностей конкретного места расположения, который соответствует ожидаемому распределению нагрузки и приносит пользу приложению. Redis рекомендует оценивать наблюдаемый показатель в контексте конкретной модели нагрузки; одно лишь значение в процентах само по себе не объясняет производительность WordPress.

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

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

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