Выше я отвечал, что есть один такой сайт, с теми же симптомами. Нашел время побольше и написал всё-таки в поддержку, в чат. Сначала ответили, что отправляют к специалисту. Потом прислали ответ, что запросы некоторые ушли ( изменились и тд)... попросили прислать конкретные примеры, если по ним явно и не объективно провал. Я попросил еще раз проверить на предмет санкций и фильтров, на что получил однозначное нет, ни фильтров, ни санкций. Вопрос с запросами, но выше уже описал, что надо прислать, если обнаружится. После переписки, не могу сказать, что траф подрос существенно, но +20 процентов, цифра не показательна.
У меня тоже по одному сайту такая фигня, пока не было времени заморачиваться. Может выберу момент и напишу в чат поддержки яндекса. Хотя сейчас не сильно много надежды на какой-то ответ.
Да, желательно. Но наверно есть в плагине кеширования возможность отключить одну страницу, что бы весь сайт не отключать, но надо выбрать нагруженную страницу. В смысле обычной записи или что у вас. Но и они скорее больше скажут вам, чем тут. Надо знать и видеть, что грузится на странице и как. Что можно в предзагрузку, а что мешает или нельзя и тд. Более информативными будут срины из монитора, по крайней мере понятно будет, тормозит что-то кроме кучи стилей и js, рекламы и счетчиков. И да, не все из стилей надо объединять, а то у некоторых просто гигантские объединенные файлы, что уже давно не актуально.
Насчет метрику обернуть, через пс по запросу выдаст кучу вариантов, кстати помнится плагин был для отложки счетчиков, включая метрику.
Если есть такие запросы у 22 плагинов, то сайт даже не дернется, не дойдет дело до контента, 0.00** надо уже начинать думать 😀. Насчет структуры, да не так все плохо, норм для большинства проектов.
Насчет плагинов согласен, есть куча не ужасных, а сверх ужасных. Например при выводе последних или рандомных или каких угодно постах перебирается вся таблица, а там может быть и не 500 и не тысяча тех же постов. Если добавить в запрос плагина или сниппеета простой интервал времени, скажем за месяц, нагрузка и скорость в разы снизятся 😎
Под такую БД в пору пару отдельных серверов ставить.
Инфа очень интересная, утром на свежую голову изучу.
Спасибо за ссылку!
Это работает на базах любых размеров, так как опция зависит от других критериев, просто проведя эксперимент и убрав ее из автозагрузки, можно действительно удивиться ;)
Выполните в базе и посмотрите, что там творится (всегда полезно сначала сделать дамп) прификс ниже стандартный:
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes'; - выведет общий размер автозагрузки, он может быть очень большим и содержать давно не нужные опции.SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10; - отсортирует по размеру 10 самых больших.
Я бы не стал так категорично про базы утверждать, сейчас на скрине ТС боту отдана кешированная версия, а она не дает картину, нет ни реальности, ни стабильности. Плюс...ну отрисовался экран, а wp и PHP дальше работает( это я упрощаю, слишком много букововк писать). Вот если бы тс привел скрин или несколько скринов из плагина Query Monitor, можно уже хоть какое-то представление получить. Скажем общий результат и с раздела запросы по компонентам. Плюс скрин с попугайчиками от PageSpeed Insights без кеша на сайте и без первого блока рекламы. Я к тому, что тут мы можем только общие рекомендации дать, инфы представленной не хватит даже на вменяемый ответ по блокам рся, так как они могут и не влиять столь серьезно на скорость. Если появится больше инфы от ТС, со скринами из плагина Query Monitor, может тема и продолжит развитие в более конкретном направлении. webinfo, все что написал, не для спора или утверждения, что это не правильно или правильно, влияет или нет, база виновата или не база и не опровергаю ваши слова или утверждаю свои как истина. От недостатка инфы, мы может всю тему превратить в бесполезные размышления, а в итоге все окажется совсем не так.
Да, но он поможет если действительно много всего... Не уверен, что он нужен для mysql 8.2+, но я не тестировал.
Есть смысл сделать вот это, о чем писал выше выставить опции автозагрузки _transient_dirsize_cache: autoload no. Вот это реально ускоряет, в некоторых случаях в десяток раз. Тут самое доступное обсуждение и есть ссылочка на патч, конечно по желанию https://core.trac.wordpress.org/ticket/54221
ну вот и причина... плагинов должно быть как можно меньше..
Не факт, все зависит не от количества, а что хотят эти плагины от базы. На скрине 25 плагинов, но как видите скорость и нагрузка норм. Объектный кеш, оптимизация запросов и тд. И это скорость для зарегистрированного. Как писал выше, ставить плагин монитор и уже смотреть, что можно сделать и на что хватит сил. Скрин с рабочего сайта, сделал для контроля небольшую стату для себя.
Тут однозначно не просто сказать, но все не плохо на 5.7.27. Если есть чего-то слишком много в базе, можно плагин добавления индексов поставить и будет все шустренько даже с условным лямом постов, товаров.
