Ускорение ajax запросов в WordPress
Работая над своим плагином BuddyPress Group Chat (BGC), я столкнулся с проблемами производительности ajax запросов – она оставляет желать лучшего. К сожалению, достаточно тяжело быстро и бесплатно внедрить технологию, которая не будет так нагружать ваш сервер, так что пришлось искать пути ускорения ajax запросов в WordPress.
Собственно, вариант, который я вам предлагаю, на самом деле известен достаточно давно, просто нигде толком не описан. Фактически у нас 2 альтернативы:
- использование движка WP для обработки всех ajax запрос (и тут описано, как это делать правильно);
- использование своего собственного голого php файла, в котором мы делаем все, что нам нужно.
Первый вариант хорош, когда нужно получить доступ к WordPress API (все его плагины, расширения, темы, классы – вроде $wpdb для взаимодействия с базой). Но у него огромный минус – при каждом ajax запросе вы полностью загружает весь движок – а это минимум 25Mb памяти сервера + постоянная чрезмерная (в сравнении с необходимостью) нагрузка.
Второй варинт как раз наоборот – отлично показывает себя по скорости и потребляемой памяти (все зависит от вашего кода, может быть всего несколько миллисекунд и пару килобайт соответственно). Но минус в том, что вы полностью изолированы от WP – нет ничего, что с ним связано, даже данных для коннекта к базе (по-крайней мере, получить их уже маленькая проблемка). Именно поэтому 99% всех шаблонов/плагинов используют первый вариант.
Ну а что, если нам все же нужен интерфейс работы с базой, к примеру, но не нужен весь шлак в виде тем, плагинов и прочего? Вот в таком случае я предлагаю вам объединить указанные способы.
Что мы делаем:
1) создаем файл ajax.php (например) в нужно нам месте – если свой сайт, не плагин, то можно даже в корне сайта, если плагин – то в папке плагина было бы логично его разместить;
2) прописываем в начале этого файла:
define('SHORTINIT', 'faster');
3) далее подключаем файл wp-config.php (к примеру, указанный в пункте 1 файл у нас лежит в корне сайта):
require('./wp-config.php');
Это все. Мы загрузили WP – но далеко не весь. Из его 20 метров только 2 оказались в памяти, повторюсь – нет таксономии, почти всего из папки /wp-includes/, локализации, нет всей папки /wp-content/. Зато у нас есть и работает глобальный класс $wpdb. И некоторые другие вещи, которые можно использовать.
Вывод
Все запросы будут работать в 10 раз быстрее (проверено тестами), потребляемая память такого обрезанного WP будет на уровне 2-2,2 Mb. Что весьма неплохо, я вам скажу. И это без серверного кеширования, без кеширования php.
Такое решение будет полезно, когда надо совершить простую операцию (записать результат голосования, рейтинга, даже комментирования, или получения этих данных). Хотя при определенных навыках программирования, вы вообще все, что угодно, сможете сделать.
Дерзайте! И не забывайте делиться идеями и/или замечаниями!
Я когда делал аякс обработчики то тоже долго думал, как сделать реализацию. По-быстрому или по-правильному. В итоге пришел к выводу, что все что нужно должно грузиться, чтобы можно было работать с API и можно было на аякс запросы влиять сторонне, подключив какой-то плагин, который может расширить обработку аякс запроса или ввести роверки и тд. Но вопрос с памятью немного более остро стоял, т.к. использовался автолоад, который все что не нужно аякс запросу не грузил (плагины и темы), но ядро все равно все прогружалось.
Вот теперь думаю, стоит ли вводить shortinit или нет, после вашей статьи. С одной стороны это усложнит код, но с другой стороны это даст небольшой прирост.
А как обстоят дела с самим чатом для групп, который вы упоминаете в статье? Очень нужен он)
Да есть рабочая бета-версия. Но как всегда хочется чего-то очень быстрого :) В общем, постараюсь в скором времени его выпустить, но не обещаю.
Спасибо, ждем с нетерпением)
define('SHORTINIT', 'faster');– это для защиты файла-обработчика? Когда реализовывал подобное, не мог понять как защитить этот файл от прямого вхождения. В итоге с аякс-запросом передавал ещё одну переменную и проверял, если её нет, то редиректил на главную. Вроде как от прямого вхождения закрыл, но если ваша срочка для этого, то это как раз то, что нужно.Это строка вообще не об этом – она помогает ускорить выполнение ajax запросов за счет отключения загрузки темы и плагинов. Ничего не защищает, уменьшает количество кода, которое будет выполняться сервером, и количество памяти, которое выделится сервером на выполнение вашего запроса.
Для защиты используйте nonce.
Кстати, попал сюда по запросу “плагин BuddyPress FollowMe”. Поставил его и совсем пока не понял его назначение. Ну прифолловил кого-то и что дальше? Может разъясните, а то в выдаче инфы практически нет, а на тесты времени нет)).
тоже самое что и дружба, только без подтверждения запроса, пользователь будет получать видеть активность зафоловинного пользователя через свой профайл..
А, пардон, это не ваш плагин…
Спасибо, сделала таким способом – AJAX намного быстрее начал работать!
Содержимое в таком виде будет?
<?php
define('SHORTINIT', 'faster');
require('./wp-config.php');
<?php – нужно?
Да, в таком. И да – нужно.
ну создал файл в корне ajax.php с содержимым:
<?php
define('SHORTINIT', 'faster');
require('./wp-config.php');
А ДАЛЬШЕ ТО ЧТО???(
А дальше все свои ajax запросы отправлять на этот файл. Но это решение хорошо только при разработке своих продуктов/сайтов, когда есть контроль, что нужно получить от WordPress. В посте написано – много чего в таком варианте будет недоступно. Но если надо просто сходить в базу за какими-то данными, или записать туда что-то – то такое решение ускорит выполнение запроса.
Типа как если в плагине указан admin-ajax.php то просто заменить на ajax.php ?
У меня на сайт 60 000 уников в сутки заходит, все никак не могу решить вопрос с регистрацией на сайте, ставил плагины типа userpro, userprofilesmadeeasy и т.д. но от них все глючило, так же как и от buddypress… Сервак свой в германии, 3 ssd, Intel(R) Xeon(R) E5-2620 v2 @ 2.10GHz X 24, 96 Gb оперативки, 200 мбит порт.. Можешь ли мне помочь немного? за денежку естественно..