Как решить проблему с admin-ajax.php в Wordpress?

Question

[coderisimo]

После оптимизации картинок по 4Мб сам сайт стал грузиться гораздо быстрее. Раьнше грузилось 8Мб, теперь 2. Включено кэширование и сжатие файлов Можно еще заняться оптимизацией css и js , но на фоне этой штуки (см картинку) они выглядят малозначительными. Видел много тем про admin-ajax.php , но мнения сильно разнятся. Скажите, можно БЕЗ установки x debug на хостинг, понять откуда ноги растут у такого длинного запроса ? Сама страничка грузится быстрее!
спасибо


вот что я увидел в debug bar :
https://dl.dropboxusercontent.com/u/19954007/qw.jpg

Answer 1

[Игорь Воротнёв]

У вас захламлена таблица wp_options, там видимо десятки тысяч записей с флагом autoload = yes. При начале загрузки WordPress вытягивает ВСЕ опции с этим флагом. Вот вам и тормоза, и адски большой расход памяти - 90Мб, Карл!

1. Почистить таблицу от мусора
2. Посмотреть какие опции с autoload = yes и нужны ли они
3. Понадобится рефакторинг того говнокода, который эти опции создает

Бонус: Нужен объектный кеш на сервере (Memcached / Redis)

Comments

[coderisimo]

Спасибо за советы!
"Там видимо десятки тысяч записей с флагом autoload = yes" . Оказалось , что НЕТ. Буквально 300-400.
"Посмотреть какие опции с autoload = yes и нужны ли они" - задача довольно ...непростая, как и рефакторинг г..кода. Объем большой, проект работает , некоторые исправления, к сожалению, могут принести дополнительные глюки, которые не сразу станут очевидными. Кстати, читал советы что для упрощения процесса поиска узких мест просто по очереди отрубать плагины и следить за изменениями. )

"Нужен объектный кеш на сервере (Memcached / Redis)" - сайт простенький магазинчик, с небольшой нагрузкой. Не будет ли это "из пушки по воробьям" ?

Одну из причин таких тормозов, как мне кажется я обнаружил. В настройках MySQL параметр innodb_buffer_pool_size - был выставлен на 8МБ . При том что на сервере 7 + гигов оперативки. Остальные настройки так же более, чем дефолтные.

[Игорь Воротнёв]

> Оказалось , что НЕТ. Буквально 300-400.

Но у вас именно этот запрос выполняется фантастически долго и жрет много памяти. Либо запрос какой-то плагин меняет, либо сам MySQL из руко вон плохо настроен.

> "Посмотреть какие опции с autoload = yes и нужны ли они" - задача довольно ...непростая

Нет ничего проще - в PHPMyAdmin или консоли mysql выполните запрос:
SELECT * FROM wp_options WHERE autoload="yes"

> непростая, как и рефакторинг г..кода Объем большой, проект работает , некоторые исправления, к сожалению, могут принести дополнительные глюки, которые не сразу станут очевидными.

Печаль, да. Но рефакторинг штука такая интересная, что рано или поздно его придется делать. Лучше сейчас, чем в пик продаж (например, когда перед новогодними праздниками сайт ляжет под нагрузкой и вы потеряете кучу денег).

> читал советы что для упрощения процесса поиска узких мест просто по очереди отрубать плагины и следить за изменениями

Да, все правильно. Отрубаете все и начинаете включать по одному и тестить. Еще полезный плагин для отладки - P3 Plugin Performance Profiler. И вместо текущего плагина Debug попробуйте Query Monitor, он очень хорошо информацию отладочную по полочкам раскладывает.

> Не будет ли это "из пушки по воробьям" ?

Нет. А еще будет полезным запустить mysqltuner и посмотреть что нужно подкрутить в настройках БД. Проверить slow query log, в PHPMyAdmin есть целый раздел со статистикой и рекоммендациями по оптимизации настроек БД.

> innodb_buffer_pool_size - был выставлен на 8МБ

Да, в правильном направлении копаете. См выше по поводу тюнинга MySQL.

[coderisimo]

Нет ничего проще - в PHPMyAdmin или консоли mysql выполните запрос:
SELECT * FROM wp_options WHERE autoload="yes" - выполнял! выполняется быстро доли секунды. мистика! )

[Игорь Воротнёв]

coderisimo: ну было бы совсем уж странно, если бы этот запрос тормозил в PHPMyAdmin :) Смотрите в сторону плагинов. Поставьте P3 Profiler сделайте диагностику. Поможет с пониманием какие плагины являются узким местом. Дальше отключите ВСЕ плагины и по одному включайте, тестируя с помощью P3, pingdom, смотрите что пишет Query Monitor. Ну и сами аяксовые функции функции пересмотреть точно не помешает. Без xDebug будет непросто, но можно разобраться.

[coderisimo]

Что-то и рекомендованного уже делал, что-то нет. Спасибо за новые направления поиска

[Дмитрий]

coderisimo: я бы добавил
SELECT * FROM wp_options WHERE autoload="yes" ORDER BY LENGTH(`option_value`) DESC

чтоб не копать полностью всю таблицу, начните поиск с тех, которые занимают самый большой размер.

[coderisimo]

Спасибо за идею! Оказалось что результатов всего 24, и самый "тяжелый" весит в районе 30 кб . Это ведь не критично? С другой стороны таблица InnoDB , а innodb_buffer_pool_size - всего 8МБ

[Игорь Воротнёв]

dimasmagadan: +1, дельное замечание

[Дмитрий]

coderisimo: продолжим)
если самый тяжелый, это cron, откажитесь от использования встроенного в WP крона.

Если все эти 30 кб задач с крона решат стартовать одновременно (в некоторых случаях это возможно), сервер вероятно и не упадет, но поплохеет ему точно.

И отдельно, по поводу admin-ajax
Запросы, которые обрабатываются через этот файл, не кэшируются. Поэтому вам нужно:
1 либо принудительно класть результаты выполнения в кэш (используя WP Cache API или Transient API)
2 либо написать свою отдельную точку входа для ajax запросов.
Это может быть как обычная страница в WP, которая разбирает _GET запрос,
3 так и кастомный endpoint, который будет переправлять запрос к самостоятельному php скрипту. который, в свою очередь, будет подгружать только нужное от движка.

Я бы рекомендовал 1й вариант. Это будет ближе к стандартам WordPress и это проще.
Но 2й и 3й варианты так же могут в некоторых случаях найти применение.

[Игорь Воротнёв]

dimasmagadan: кеширование это must-have, а по поводу точек входа и эндпоинтов, стоит попробовать REST API.

[Дмитрий]

Игорь Воротнёв: если использовать rest api, нужно будет так же переписывать и js часть.
Если на сайте используются плагины, нужно будет править и их. А при обновлении плагинов, переписывать этот код повторно. При использовании кастомной точки входа для аякса, правок, хотя бы в части js, значительно меньше.

Ну и, честно говоря, пока не видел тестов с сравнением, что будет более прожорливо - rest api или admin-ajax. Код самого плагина так же пока не смотрел. Считаю, советовать rest к использованию можно будет, когда включат в движок.
При своем же, отдельном скрипте под обработку аякса, могу грузить только те части движка, которые нужны.

[Игорь Воротнёв]

> dimasmagadan: когда включат в движок

Так уже.

> если использовать rest api, нужно будет так же переписывать и js часть. Если на сайте используются плагины, нужно будет править и их. А при обновлении плагинов, переписывать этот код повторно

Смысл API как раз в том, чтобы быть расширяемым и гибким и ничего не надо было переписывать по десять раз. Именно для этого и делают API.

[Игорь Воротнёв]

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

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

[Дмитрий]

Игорь Воротнёв: это не "уже". это "еще" - еще бета) прямо сейчас автор топика использовать его не сможет
было уже, что в релиз некоторый функционал из предрелизных версий не включали. не с столь поздней версии, но тем не менее.
Если ставить отдельно, как плагин, там тоже не все так хорошо: у них несколько версий/вариантов работы апи. Если не путаю, в WP включат не совсем ту версию, что в стабильной ветке плагина.

>Смысл API как раз в том, чтобы быть расширяемым и гибким и ничего не надо было переписывать по десять раз. Именно для этого и делают API.
Универсальное решение всегда проигрывает узко заточенному. При этом узко заточенное решение решение всегда проигрывает универсальному. Смотря по каким параметрам подбирать)

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

И, повторюсь, тестов сравнения производительности - что быстрее, меньше грузит, кэширует ли оно и тп по api rest нет. может оно будет с такой же производительностью работать? Советовать непроверенное не хочу.
А для внедрения нужно и js будет переписывать. Смысл сейчас менять?

Я не пишу, что rest api - плохо. Я написал несколько вариантов, доступных в текущей стабильной версии WP. Которые точно снизят нагрузку. И указал, какой из вариантов предпочтительней. rest api не подходит ни под доступность в текущей версии, ни под "точно снизит нагрузку". Можно посмотреть в коде, как оно сделано, но лень) Будет релиз, буду смотреть. Пока, на мой взгляд, рабочие только 3 варианта

[Игорь Воротнёв]

dimasmagadan: Так, не надо передергивать и сравнивать с какими-то другими плагинами, которые не срослись. REST API уже давно стабильна и используется на тысячах крупных сайтов, в production. Включение в ядро официально пошло только сейчас, неофициально работа над этим (и тестирование) идет уже очень давно. Долго и частями - только потому, что это достаточно массивная склейка. Качайте плагин REST API и пользуйтесь на здоровье. В декабре часть АПИ уже будет в ядре, остальное - останется в плагине. На работу никак не повлияет.

По поводу версий вы путаетесь. Есть ветка v1, есть v2. И есть ответвление v2, которое урезано и совместимо уже с WP 4.4 - по сути, вырезали часть v2 и внедрили в ядро, остальное оставили в v2a (название мое, условное).

> Смотря по каким параметрам подбирать)

Я не про холивары и параметры. Если вам надо под каждую новую версию WP или плагина кучу всего своего переписывать - у вас большая проблема с архитектурой вашего кода.

> бывают случаи, когда подойдет только нестандартный код

Я в курсе. Но и в 9 случаях из 10 этот нестандартный код не надо изобретать.

REST API вполне подходит, зря вы его откидаете. Если вы ждете релиза - у вас действительно не очень хорошо с архитектурой и планированием. Вы должны к релизу быть готовы заранее. На крупных и сложных проектах, тем более с кучей кастомного кода, у вас уже давным давно должен быть staging сервер, на котором полная копия вашего сайта УЖЕ крутится на WP 4.4 alpha / beta.

[Дмитрий]

Игорь Воротнёв:
>Так, не надо передергивать и сравнивать с какими-то другими плагинами
пишу как раз о wp-api.org
у них, грубо говоря, две версии v1, которая стабильная, она же была в официальном репозитории как плагин, и v2, которая бета

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

версия плагина, что сейчас доступна, так же еще бета
https://github.com/WP-API/WP-API/issues?q=is%3Aope...
периодически правят дыры в безопасности. (вот тут я слегка передергиваю)) но все равно, не уверен, что стоит ставить на рабочий проект текущую версию) тем более, что правки вроде "potential XSS" и "Fix user access security vulnerability" там действительно есть.

>Но и в 9 случаях из 10 этот нестандартный код не надо изобретать.
>REST API вполне подходит
Ага, тогда возьмем текущую ситуацию. Вон, пользователь задал вопрос "тормозит ajax".
Сейчас основная масса плагинов и шаблонов rest api не используют. На сайте у него с большой вероятностью такие "старые" плагины и шаблон стоят.
Что ему будет дешевле?
Переписать все под REST API (шаблоны, чужие плагины), повторять это же при их обновлении или воспользоваться одним из моих, местами нестандартных, советов?

С тем, что я предложил, можно вообще без вмешательства в чужой код (remove_action/add_action либо редиректить нужные обращения к admin-ajax через .htaccess на свой скрипт).

Если оценивать с позиции "как в документации", конечно, лучше ваш способ.
Если же оценивать деньгами, конкретно для этого проекта можно и отдельный staging server с WP 4.4 не использовать и от документации немного отойти - это будет быстрее, дешевле и проще в обслуживании.

[Игорь Воротнёв]

dimasmagadan: вы мою позицию немного не поняли и вцепились в REST API. Я вообще-то изначально помогал автору именно с отладкой и правками *текущей* версии. А про API упомянул как один из вариантов. Полностью поддерживаю мысль о том, что надо исходить из стоимости таких правок и бизнес-логики, а не "как надо по документации". С другой стороны, расходы надо считать не тактически, на данный момент, а стратегически - с горизонтом минимум на 1 год. А при учете такого горизонта - это версии 4.4, 4.5 (уже полное включение REST API), а также 4.6 и 4.7. Автор рискует застрять на 4.3-4.4 со старым, глючным кодом, и не сможет обновляться дальше без риска поломать сайт. То есть, глобальные правки неизбежны, рано или поздно их придется делать. Так вот, чем раньше начать - тем меньше риск потерь в будущем.

[Дмитрий]

Игорь Воротнёв:
> вы мою позицию немного не поняли и вцепились в REST API.
так по остальным пунктам у нас одинаковая точка зрения

>надо исходить из стоимости таких правок и бизнес-логики
а теперь выяснилось, что и с rest api практически совпадает)

>С другой стороны, расходы надо считать не тактически, на данный момент, а стратегически
при сроках жизни некоторых проектов около года (пока домен куплен), да и при текущей стоимости разработки сайта под WP, столь долгое стратегическое планирование можно в расчет не принимать

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

по теме вопроса,
coderisimo чтоб конкретно в этом случае узнать, что грузится долго,
нужно посмотреть какой параметр action у запроса к admin-ajax.php
затем выполнить поиск по этому слову в папке с шаблоном и папке с плагинами
как найдете код функции, показывайте, можно будет понять, что так долго грузит.

возможно, у вас там обращение к стороннему сайту через wp http api

[Дмитрий]

поправка.
редактировать комментарии тут нельзя:
>надо исходить из стоимости таких правок и бизнес-логики
а теперь выяснилось, что и на rest api точка зрения практически совпадает)

Answer 2

[Александр Таратин]

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

Comments

[coderisimo]

в хроме у меня малоинформативно . 5 сек, все ок - https://dl.dropboxusercontent.com/u/19954007/chrome.jpg ,
Ну и скорость загрузки для нью-йорка в Москве хромом очень непросто увидеть.

Answer 3

[Alex]

Поищите плагины для очистки таблици опций. Возможно у вас установлены плагины которые ее "заср@ли" конкретно.

Comments

[Alex]

Чтото в этом роде www.shoutmeloud.com/clean-options-wordpress-plugin...

[Alex]

Только обязательно сделайте(!) бекап базы.

[coderisimo]

спасибо! я сегодня изучал базу. таблица опшнс огроменная. под 300.000 записей.

[Alex]

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

[coderisimo]

там еще кэшируется что-то, как я понял