Превышение какого-то CPU на хостинге.

Та!

С лёгкостью!

И тебе тот же вопрос - какой кеш?

Шта?

Кто кого на что меняет?

Иди учи и что такое кеш вообще и какие ьывают и на каком уровне что посходит.

Да даже не хреново настроенный, но применённый бездумно.

Я типа знаю и умею и обслуживаю несколько тысяч rps, друк)

И работал с кешами от in-process-memory в рамках аппсервера до банального кеширования рендеров на файликах в post-ssi-stage.

(И это мы ещё не касались клиентского кеширования)

Так что иди и учи сам 🤣 🤣 🤣

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

Ничего не знаю, конечно.

Расскажи мне, о великий гуру, как файловый кеш на хостинге на локальном диске может нагенерить много cpu time?

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

Куда ты положишь свои нагенеренные кеши - неважно. Хоть в /dev/null, хоть в редис, хоть в файлы - неважно совершенно везде будет iowait.

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

Но стоимость исполнения любого адекватно реализованного механизма кеширования - несоизмерима мала в сравнении со стоимостью получения объекта из нижележащих слоёв.

Вся маковка кеша в инвалидации/актуализации, но это ж думать надо про это, а не плагин кнопочкой включить :)

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

Во-первых, автор темы не упоминал вордпресс.

Во-вторых, генерация on-demand кеша как отдельный подпроцесс почти ничего не стоит: всё что должно быть в кеше должно генерироваться и без кеша: осталось сериализовать и записать. Как конкретно реализовано оно wp - мне плевать, у меня этого в продакшне нет (слава богу).

В-третьих, я не услышал как конкретно процесс генерации кеша может вызывать всплески использования "камня".

В-четвертых, любое кеширование по своей сути устроено одинаково. Хоть где и хоть на каком языке. (Пока мы говорим про веб-приложения).

Так что, у меня с матчастью хорошо, как и с практикой.

И, да, я всё ещё жду ответа: как файловый кеш на хостинге на локальном диске может нагенерить много cpu time?

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

Понятно что написать плагин можно так что он все на свете нагружать будет.

Но в целом кэш никак не должен нагружать процессор.

suffix, Генерация. PHP выполняет дополнительные действия, чтобы положить страницу на диск (кэширование выполняется средствами PHP у веб-мастеров, кэш на стороне сервера это DevOps или админ). Потом при запросе страницы нужно проверить, а кэш истёк или нет, и если он истёк (скажем, 5 минут, а посещение раз в полчаса) - удалить старые данные из кэша, сгенерировать новые, отдать клиенту и положить снова в кэш. Если таких страниц на сайте (условно) миллион - то выигрыш от такого кэша нулевой, когда кэш истекает раньше, чем будет повторно отдан. Это заставляет CMS использовать больше ОЗУ, больше делать запросов к БД, генерировать больше обращений к диску, а так же производить дополнительные действия на CPU.

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

Дальше продолжать? Если хотите - почитайте, почему кэширование средствами MySQL не эффективно, когда кэш слишком большой и предлагается использовать кэш на уровне приложения. Не надо сравнивать взрослые вещи с кэшированием в cms.

Вот золотые слова!