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

Робот яндекс дрючит твой сайт )) У меня есть десять сайтов. два из них яндекс просто грузит ого го го...сошел с ума...настройки вебмастер и директивы - до лампочки...он игнорит все.

Вызов stat замечательно кешируется уже на уровне операционной системы. TTL кеша на файлах эффективнее делать через stat/touch. Это убирает необходимость читать данные и проверять валидность с т.з. TTL. Это же позволяет эффективно чистить кеши. Если кеш невалиден - можно его всухую перезатирать.

Понятно, что если файловый кеш и 1М файлов в одном каталоге - это приговор почти всегда. Но, в первую очередь, это приговор автору системы кеширования, который не понимает с чем работает.

Расход RAM, кстати, при таком кешировании будет заметный, но не критичный. Расход CPU тоже, в рамках общего потребления будет три копейки. Iowait может всё попортить (особенно когда много файлов в каталоге), но это лечится переставлением рук в плечи.

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

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

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

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

Решение - консистентное хэширования области ключей.

Сравнивать это с файловым кэшем средствами CMS - за гранью добра и зла.

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

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

lonelywoolf, почти со всем, что ты написал неучам я согласен, но на паре моментов остановлюсь поправить/внести ясность.

Где "там" и какой кеш в дурацких и опасных советах "включи кеш" совершено не ясно.

Ни что имеет ввиду советчик ни как поймёт его слушатель.

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

Да и плагины могуть быть разные - есть для страничного кеша, есть для объектного, есть для работы с серверным кешированем.

Так что "обычно" - понятие довольно широкое.

Если целом - да, разные вещи. Но на том же ВП на уровне ядра реализованы 3 разных типа кеширования. И даже с движка можно также работать и со взрослыми вещами. Если интересно см старенький пост https://wpmag.ru/2013/keshirovaniye-wordpress/. В новых версия вроде ещё что-то улучшили, но в это я уже не вникал.

У ТС "просто хостинг", какой второй сервер?..

Не исключено, что ТС не в курсе, кто автор системы и как "оно" работает.. Есть ли там вообще кэш.. и "какое там CMS"..

Как минимум, поэтому считаю, что советовать "включить кэш", без понимания "что и где там".. слегка опрометчиво.. Хотя.. может ведь и прокатит ))

---------- Добавлено 21.08.2019 в 00:14 ----------

там хостер письмо прислал про "какой-то лимит CPU".. Вы о чём? )))

ТС, очевидно, не знает об этом ничего и ей надо пойти взять вебмастера чтобы он разобрался. Любые другие советы - вредные.

Я о том что "кеширование создаёт нагрузку на камень" (что дичь и дурь в общем случае) и далее о двух форумных военах CMS и кеша, которые боги и всё знают. Всё остальное - о кешировании, а не о ТС. Имеющий мозг прочитает и запомнит ключевые слова из которых нагуглит.

По теме ТС ничего сказать нельзя, пока не пойдёшь и не посмотришь что там происходит на хостинге.

Прочитала все советы и комментарии (эээ.. процентов 50 поняла 😆 ) Спасибо, что откликнулись 🍻

Из того, что поняла:

1) самостоятельно с проблемой справлюсь только путем увеличения тарифа.

2) Написала вчера в поддержку. Предложили провести бесплатную диагностику и дальше дать детальные рекомендации. Думаю согласиться, раз денег не берут :kozak:

3) Тут разгорелась профессиональная дискуссия. Потому отвечаю на дополнительные вопросы:

у меня сайт - визитка на wordpress, был куплен шаблон.

Хостер - https://www.foxcloud.net . Выбирала по рекомендации.

Чем дело закончится - отпишусь, если интересно..

Сложность в том, что понятие "кэширование" (в общем случае) достаточно широко.. А в случае "веб-хостинга" на него ещё и накладывается ряд ограничений..

Лично сталкивался с ситуацией, описанной на первой странице:

что банально приводило к повторной загрузке и разбору данных при каждом открытии страницы..

ддос может быть?

сайт визитка может нагрузить CPU только есть там траф попёр откуда-то.

Или если шаблон "дырявый" (пусть и купленный), плагин или сам WP (не обновлённый за древностию лет) взломали..

Дичь - это давать такие советы.

Не меньше дичь - спорить, не зная матчасти.

Часто достаточно только "куплен". (а в сочетании с "шаблон", а не "тема" ещё больше может усугубить ситуацию)