Как кэшировать/ускорять запросы Wordpress для зарегистрированных пользователей?

Wordpress генерирует очень много sql-запросов.

Мы использовали «WP Fastest Cache», который создает статические HTML-страницы с вашей платформы и кэширует их. Однако для зарегистрированных пользователей статические страницы не будут работать.

Вот что я вижу. 122 запроса, 7,8 с потрачено в БД! Кроме того, как вы можете видеть, все запросы выполняются довольно быстро (~ 0,05 с). Следовательно, кеширование запросов не поможет

введите здесь описание изображения

Я использую bluehost для развертывания и mysql db.

Какой лучший способ оптимизировать это. Есть ли способ запускать все запросы параллельно на mysql или каком-либо другом элегантном решении?

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


mysql wordpress php bluehost database-performance
person codeObserver    schedule 15.07.2015    source источник
comment
Видя, что запросы, которые вы показываете, считывают одну и ту же таблицу с разными параметрами option_name, все LIMIT 1 заставляет меня задуматься: почему вы запрашиваете эту таблицу для одной вещи за раз? Почему бы вам просто не отправить ОДИН запрос, чтобы спросить обо всем. Это, вероятно, избавит вас от множества бесполезных запросов и связанных с ними накладных расходов: нужно проанализировать только один запрос, прочитать данные таблицы, отправить данные в PHP...   -  person Sven    schedule 15.07.2015
comment
Это небольшой снимок всех 122 запросов. Мы используем тему pluginhunt, и код довольно сложен, чтобы начать настройку. Ищу серебряную пулю, но кажется, что ее нет. Если мы кэшируем 122 запроса для всех пользователей с идентификатором пользователя в качестве ключа, то кэшировать придется много. + мы не знаем, возможно ли это.   -  person codeObserver    schedule 15.07.2015
comment
122 запроса на создание страницы - это безумие :-S   -  person zerkms    schedule 15.07.2015

Ответы (1)


arrow_upward
1
arrow_downward

Кроме того, как вы можете видеть, все запросы выполняются довольно быстро.

Эти запросы не такие быстрые. 0.1s для простого поиска в таблице опций работает очень медленно.

Все запросы на изображении, которое вы разместили, находятся в таблице параметров. Я не уверен, являются ли большинство ваших запросов дополнительными запросами или нет, но если вы хотите уменьшить общее количество дополнительных запросов, вы можете использовать параметр autoload на update_option или add_option. Из документации:

$autoload
(строка) (необязательно) Должен ли этот параметр автоматически загружаться функцией wp_load_alloptions() (помещает параметры в кеш объектов при каждой загрузке страницы)? Допустимые значения: да или нет.

Если вы автоматически загрузите свои параметры, все они будут получены в одном запросе. Это уменьшит общее количество запросов, но, как упоминалось ранее, ваши запросы не должны занимать так много времени.

Для существующих опций вам придется сначала удалить их, а затем снова добавить с помощью параметра autoload:

$val = get_option('some_option');
delete_option('some_option');
update_option('some_option', $val, true);

По умолчанию, когда вы создаете параметры, они устанавливаются на автозагрузку, поэтому немного странно, что у вас так много параметров, которые не загружаются автоматически.

person Mathew Tinsley    schedule 15.07.2015
comment
Принимаю ответ, потому что вы предоставляете хотя бы некоторые оптимизации для WordPress. Однако в итоге мы сами реализовали приложение и разместили его на Heroku вместо использования Wordpress, потому что было слишком сложно менять код различных плагинов и темы. - person codeObserver; 30.07.2015