Если есть такие запросы у 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. Если есть чего-то слишком много в базе, можно плагин добавления индексов поставить и будет все шустренько даже с условным лямом постов, товаров.
Чуть медленнее (читать как хуже) становятся запросы mysql 8.2+. Но наверняка можно оптимизировать, индексы или просто посмотреть почему данных больше становится в опциях и тд. Я не заморачивался, время пока нет.
Ставите плагин Query Monitor и курите его до полного понимания, какие плагины и сколько запросов выдают на странице, какие медленные, дублирующие и тд и тп. Находите в себе силы и грохаете то, что не можете сами исправить или нет альтернативы менее прожорливой, либо смирится.
Используйте объектный кеш, тут вам надо выбрать исходя из функционала сайта Memcache или Redis. Возможны еще манипуляции с базой, конкретно автозагрузкой, но думаю без специалиста не разберетесь, хотя там не сложно. Причем там есть один косяк, который закидывает в автозагрузку мего наполненную опцию и на некоторых сайтах это приводит к очень серьезным проблемам со скоростью. Косяк будет исправлен, но только в следующем большом релизе WP, а это не скоро. Сам проверял и использую на нескольких сайтах, существенно увеличивается скорость и падает нагрузка.
Все очень хорошо себя чувствует на php8+, но если подключить mysql 8.2+, надо разбираться, автозагрузка и некоторые другие запросы чуть медленнее становятся.
Можно бекапчик добавить файла и проблем меньше)
Хорошее дело, можно в итоге полезный плагин сделать. А в этом апи подсеть или диапазон не определят, скажем накинулась бетерика и сразу ее в бан. Города наверно не слишком нормально это апи определяет. Может не все писать а только прямые.
