ТС, очевидно, не знает об этом ничего и ей надо пойти взять вебмастера чтобы он разобрался. Любые другие советы - вредные.
Я о том что "кеширование создаёт нагрузку на камень" (что дичь и дурь в общем случае) и далее о двух форумных военах CMS и кеша, которые боги и всё знают. Всё остальное - о кешировании, а не о ТС. Имеющий мозг прочитает и запомнит ключевые слова из которых нагуглит.
По теме ТС ничего сказать нельзя, пока не пойдёшь и не посмотришь что там происходит на хостинге.
Вызов stat замечательно кешируется уже на уровне операционной системы. TTL кеша на файлах эффективнее делать через stat/touch. Это убирает необходимость читать данные и проверять валидность с т.з. TTL. Это же позволяет эффективно чистить кеши. Если кеш невалиден - можно его всухую перезатирать.
Понятно, что если файловый кеш и 1М файлов в одном каталоге - это приговор почти всегда. Но, в первую очередь, это приговор автору системы кеширования, который не понимает с чем работает.
Расход RAM, кстати, при таком кешировании будет заметный, но не критичный. Расход CPU тоже, в рамках общего потребления будет три копейки. Iowait может всё попортить (особенно когда много файлов в каталоге), но это лечится переставлением рук в плечи.
Добавление второго сервера для обработки запросов делает файловый кеш тем, что использовать нельзя - любая сетевая файлуха вносит весьма заметные задержки, а держать на каждом сервере свой кеш - быстро прогрессирующая боль с инвалидацией.
Первая плохая новость в том, что редис - не самое хорошее решение для организации большого кеша в силу неэффективности выделения памяти в типе string. На большом количестве мелких ключей оверхед по памяти может быть в разы.
Однако, в силу того, что доступ данных по ключу что в редисе что в мемкеше по хэш-таблице - алгоритмическая сложность поиска по ней всегда константна ( О(1) ) и время поиска не зависит от количества ключей.
Большую сложность являет собой эластичность серверов кеширования алгоритмов диструбуции ключей, когда добавление/удаление серверов на лету приводит к инвалидации большого количества данных и по-сути приводит к т.н. "холодному старту", что для больших систем весьма болезненно.
Решение - консистентное хэширования области ключей.
Сравнивать это с файловым кэшем средствами CMS - за гранью добра и зла.
Если говорить о встроенном в мускул кеше запросов - то это та штука, на которую не надо возлагать больших надежд (ключом выступает особенность инвалидации всей таблицы при изменении строки. Однако, эти данные достаточно старые и, возможно, в мире MySQL все поменялось.
Есть ещё подход с хранением данных кеша в таблице с индексом по ключу. Но это такое... Такие таблицы - обычно write-intensive, что быстро приводит к деградации индексов и росту грязных страниц. Лучше уж в файлы.
Во-первых, автор темы не упоминал вордпресс.
Во-вторых, генерация on-demand кеша как отдельный подпроцесс почти ничего не стоит: всё что должно быть в кеше должно генерироваться и без кеша: осталось сериализовать и записать. Как конкретно реализовано оно wp - мне плевать, у меня этого в продакшне нет (слава богу).
В-третьих, я не услышал как конкретно процесс генерации кеша может вызывать всплески использования "камня".
В-четвертых, любое кеширование по своей сути устроено одинаково. Хоть где и хоть на каком языке. (Пока мы говорим про веб-приложения).
Так что, у меня с матчастью хорошо, как и с практикой.
И, да, я всё ещё жду ответа: как файловый кеш на хостинге на локальном диске может нагенерить много cpu time?
Ничего не знаю, конечно.
Расскажи мне, о великий гуру, как файловый кеш на хостинге на локальном диске может нагенерить много cpu time?
Любая сериализация на объёмах до нескольких мегабайт стоит пренебрежимо мало в случае однократных вызовов на строку (понятно что бывают рукожопы, которые в цикле в цикле в цикле это делают).
Куда ты положишь свои нагенеренные кеши - неважно. Хоть в /dev/null, хоть в редис, хоть в файлы - неважно совершенно везде будет iowait.
В самом плохом случае ты просто напишешь кеш и никогда им не воспользуешься.
Но стоимость исполнения любого адекватно реализованного механизма кеширования - несоизмерима мала в сравнении со стоимостью получения объекта из нижележащих слоёв.
Вся маковка кеша в инвалидации/актуализации, но это ж думать надо про это, а не плагин кнопочкой включить :)
Я типа знаю и умею и обслуживаю несколько тысяч rps, друк)
И работал с кешами от in-process-memory в рамках аппсервера до банального кеширования рендеров на файликах в post-ssi-stage.
(И это мы ещё не касались клиентского кеширования)
Так что иди и учи сам 🤣 🤣 🤣
Шта? Как кеш может создавать нагрузку на камень? Кеш - это по определению размен времени (io,net,cpu) на память.
Поспрашивал по знакомым - говорят оптику порвали им.
Private networks же для облака, не для дедов. А vSwitch работает уже давно и успешно (ограничения только, что нельзя дозаказать второй аплинк на сервер и MTU надо делать 1400)
А вот про связность vSwitch и private networks пока ничего не увидел :(
А что с риалтеками не так?
потому что они - полное Г под серверной нагрузкой)
полторы тыщи иопсов в режиме журнала же, просто выкинуть нахрен; прошные самсунги - сравнимый отстой
(у SM863, например, 32к iops в таком режиме)
но, справедливости ради, видео стримить с них - вполне приемлемо
