Как оптимизировать Wordpress с большой базой (запросы выполняются по 7 и более сек.)?

Question

[Максим Вязников]

Приобрел готовый сайт на Wordpress, но после развертывания БД и файлов столкнулся с проблемой очень медленной работы, в базе данных сейчас 362,713 постов.

При входе на главную страницу, выполняется такой запрос, и время его выполнения примерно 7 секунд:

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  WHERE 1=1  AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish')  ORDER BY wp_posts.post_date DESC LIMIT 0, 10;

А при входе в админку вообще 25 секунд выполняется запрос:

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  LEFT JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_
key = '_yoast_wpseo_focuskw' ) WHERE 1=1  AND (
  wp_postmeta.post_id IS NULL
) AND wp_posts.post_type = 'post' AND ((wp_posts.post_status = 'publish')) GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0
, 10;

В wp_postmeta сейчас 695,632 записей.

Да этого как-то особо не имел дел с Wordpress, подскажите, подобное нужно пробовать оптимизировать исключительно на стороне CMS, или нужно что-то подкрутить в конфигурации сервера MySQL (имею ввиду, где именно нужно крутить больше, а не сам факт, или там, или там, понятно, что и там, и там)?

Comments

[alex-1917]

зачем этот подсчет количества постов? ищи, в каком скрипте эта хрень вызывается.
В любом случае ни одному пользователю сайта вычисляемая информация нахрен не нужна))))

Answer 1

[Sanes]

Нагрузка на Wordpress?

Answer 2

[Тарас Лабяк]

А индексы там есть?

Comments

[ThunderCat]

все там есть, корме нормальной структуры. Т.к. вп писался как блоговый движок, а потом рос до "всеумеюцмс", универсализация кода/базы приводит к вот таким ментальным выкидышам, когда на 500к записей выборка до 7 секунд.
Мое мнение - если у продавца изначально было понимание объемов работы с данными на сайте - бить морду и требовать мани бэк на бочку или рефакторинг/тюнинг. В идеале - вернуть потраченные средства и написать нормально.

Answer 3

[ThunderCat]

Вариантов несколько, и все они не решат проблемы мгновенно.
1) Бить морду продавцу и заставить либо деньги вернуть, либо тюнить до нормальной работы. Это в случае если продавец знал какой объем данных будет на сервере обрабатываться.
2) Самостоятельные действия. Тут интереснее конечно, особенно если вы не очень в теме.
а) Переносим данные/код на локальный сервер и ищем проблемы на уровне производительности железа. Если на локале все работает шустро - скорее всего не хватает ресурсов хостинговых машин/виртуалок.
б) Подключаем системы кэширования. Это может серьезно ускорить работу, но, как и любое решение, имеет ряд минусов.
в) Тюнить код руками - в вп это конечно не так просто и прозрачно, больше похоже на ремонт канализации, затопленной толстым слоем ... отходов.
В целом - сочувствую, вам предстоит квест )

Answer 4

[Site Developer]

но после развертывания БД

Возможно, причина в некорректном развертывании.
Если бекап был простой - дамп базы из PMA, то нужно воспользоваться скриптом и заменять вначале пути, а затем и домен.
В будущем использовать плагины для миграции.

При входе на главную страницу, выполняется такой запрос

Для начала стоит разобраться кто порождает эти запросы. И вообще зачем. Судя по _yoast_wpseo_focuskw это может быть от этого плага. Или же кто-то ещё пытается прочесть данные от него.

Что стоит сделать.
1. Оптимизировать БД. Лучше это делать спец плагами - они очистят и лишку в базе. Но осторожно и забекапившись.
2. Убедиться и при необходимости исправить кодировки и тип сопоставления таблиц.
3. Рекомендую поставить плаг для мониторинга QM или другой и там уже можно будет видеть детальнее что где происходит. И кто виноват.
4. Послушать доклады раз и два от разрабов ВП и использовать упомянутые методы и инструменты (они не только для ВП будут полезны).