Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Есть nginx-push-stream модуль, который может работать через вебсокет
Ratchet и Aerys на чём написаны? Пост про то, чтобы избавится от оверхеда, а не про то, что есть другие решения на php.
Простите, я реально не понимаю в чем оверхед решения в схеме nginx + aerys.
Получаем чистый, не блокирующий код на PHP без Lua прослойки.
Получаем чистый, не блокирующий код на PHP без Lua прослойки.
PHP не многопоточный. Каждый поток php — отдельный процесс со всеми вытекающими оверхедами. Плюс сам php в отличие от lua намного медленнее. PHP пусть занимается тем, для чего он нужен — обслуживание бизнес логики, а демоны должны работать как можно быстрее. Я так себе представляю.
Что простите? PHP 7+ медленнее чем Lua? Это в чем же он более медленный?
Я думаю, об этом даже спорить не нужно. А по потребляемым ресурсам так тем более.
Ясно) На самом деле проверяется очень легко, берешь и сам пишешь тесты на сравниваемых языках и проверяешь скорость, и тогда ты увидишь правду, что быстрее, а что нет, и что сколько ресурсов поедает тоже. Я когда-то тоже доверял тестам из интернета, а потом начал сам перепроверять и результаты меня удивили. С тех пор любая проверка скорости, ресурсов и т.п, только самому, а не с помощью непонятных статей.
Можешь взять и элементарно сравнить:
1) Скорость наполнения массива
2) Скорость склеивания строк
3) Скорость чтения/записи файлов
4) Обход массива через foreach и через for
5) Серелизацию данных в JSON / из JSON'a
Это основная работа бэкендов, не считая обращения в базы данных.
Серьезно, не поленись, эти тесты на PHP и на Lua ты напишешь максимум минут за 20-30, а результаты тебя сильно удивят. Проверь именно скорость PHP 7.1 или 7.2 vs Lua
Можешь взять и элементарно сравнить:
1) Скорость наполнения массива
2) Скорость склеивания строк
3) Скорость чтения/записи файлов
4) Обход массива через foreach и через for
5) Серелизацию данных в JSON / из JSON'a
Это основная работа бэкендов, не считая обращения в базы данных.
Серьезно, не поленись, эти тесты на PHP и на Lua ты напишешь максимум минут за 20-30, а результаты тебя сильно удивят. Проверь именно скорость PHP 7.1 или 7.2 vs Lua
Вот даже результат из вашей статьи, где Lua проигрывает PHP разгромно.
Под многопоточностью вы имеете в виду thread'ы? Если да, то в nginx'е воркеры это тоже не thread'ы, а процессы. Thread'ы внутри nginx'а, насколько я помню, используются только для доступа к файловой системе.
Так и не увидел преимущества решения над тем же nodejs. Разве что, нода может давать небольшой оверхед, кмк. Можете прояснить?
Если основная проблема, что php работает per request, почему бы не запустить его в режиме демона и не обрабатывать запросы по событиям?
Не очень понятно как в этой схеме решается ожидание событий от бекэнда (php в данном случае)
Нужна прослойка которая будет держать открытыми вебсокеты и при поступлении данных соединяться с php (через тот же fastcgi) и отправлять обратно ответ.
В чём преимущество отправки сообщения в вебсокет, которое будет позже направлено в php? Не проще ли сразу через ajax отправлять запросы на сервер, а вебсокеты использовать для доставки сообщений с сервера в клиент а не на оборот.
Я делаю свой проект комет сервера на C++ который именно даёт апи для отправки сообщений от сервера клиенту. И не могу придумать ситуации где имеет смысл делать на оборот отправку от клиента на сервер не простыми ajax запросами а через вебсокеты добавляя ещё одну лишнею прослойку между отправителем и адресатом.
Хорошо написанный PHP код, чаще всего, работает медленно из-за разворачивания окружения по каждому запросу. (Имеется ввиду загрузка классов в память, сборка DIC и соединение с базами данных). Если вы хотите ускорить этот процесс — выходом может быть только демонизация приложения на PHP. Вопрос медленности AJAX запросов (установка соединения, отправка запроса, ожидание ответа, получение данных и закрытые соединения) решается созданием постоянного соединения WebSocket. Подход автора решает связь от клиента к серверу. Но WebSocket дает неоспоримое преимущество со связью от сервера к клиенту. Тут осмелюсь предложить решение написанное на pyton и использующий протокол WAMP — crossbar.io; С набором всевозможных библиотек (SDK) на разных языках (и PHP в часности github.com/voryx/Thruway)
чтобы не использовать разные довольно медленные php библиотеки (раз и два)У вас тут обе ссылки на одну и ту же статью. К слову сказать, статья моя и в ней я не говорил, что библиотеки «довольно медленные». У меня есть и другая статья, в которой я сравнивал php, node.js и go и говорил, что node.js работает медленнее. Сам по себе «код на js в вакууме» работает в среднем быстрее php, но сетевая подсистема реализована хуже и работает сильно медленнее. Из-за чего итоговый код на js работает в полтора раза медленнее и к сожалению под высокими нагрузками не удалось избавиться от падений ни мне ни другим участникам конкурса. А при средних нагрузках лучшее решение на node.js было опять же в полтора раза медленнее чем моё решение на swoole.
В моей статье есть примеры кода на swoole, workerman + libevent, node.js — так что вы можете самостоятельно запустить тесты и убедиться что php может работать быстрее чем node.js, особенно для задач связанных с сетью.
Я не сильно понял смысл замера времени голого хендлинга сокетов на php без связки с ответами nginx, который обычно стоит за любым бэкэндом. У меня разогретый nginx+lua+php7 выдаёт 50-80ms в текущем примере.
Тест: 30 потоков по 50 повторов.
php 5 потоков
nginx 100 потоков
результатом просто вывод
Тест: 30 потоков по 50 повторов.
php 5 потоков
nginx 100 потоков
результатом просто вывод
json_encode([$_REQUEST,$_SERVER]);Да, обычно nginx используется для бекенда, но он не обязателен ни для node.js, ни для swoole, ни для go. И не удивительно, что в топ100 не вошло ни одного решения на нём. Для хайлоад задач он может быть избыточен.
«30 потоков по 50 повторов» — это не хайлоад, в хайлоадкапе нагрузка была 10к повторов в секунду при 2к соединениях при этом ответ был порядка 0.1 милисекунды, что в 500-1000 раз быстрее вашего примера.
Дело в том что в вашем примере nginx+lua просто держит соединения, а php используется для обработки сообщений от клиентов, и php-скрипт запускается каждый раз заново, а это очень большие накладные расходы.
При написании обработчика на swoole, php-скрипт будет запущен только один раз, поэтому такой подход работает гораздо быстрее, чем на каждое сообщение запускать php-скрипт заново, даже если перед ним поставить nginx. В вашем случае для увеличения производительности лучше либо отказаться от php и делать всю обработку на lua, либо использовать библиотеки swoole/workerman.
Песочница работает ещё две недели, вы можете написать своё решение и сравнить результаты с другими.
«30 потоков по 50 повторов» — это не хайлоад, в хайлоадкапе нагрузка была 10к повторов в секунду при 2к соединениях при этом ответ был порядка 0.1 милисекунды, что в 500-1000 раз быстрее вашего примера.
Дело в том что в вашем примере nginx+lua просто держит соединения, а php используется для обработки сообщений от клиентов, и php-скрипт запускается каждый раз заново, а это очень большие накладные расходы.
При написании обработчика на swoole, php-скрипт будет запущен только один раз, поэтому такой подход работает гораздо быстрее, чем на каждое сообщение запускать php-скрипт заново, даже если перед ним поставить nginx. В вашем случае для увеличения производительности лучше либо отказаться от php и делать всю обработку на lua, либо использовать библиотеки swoole/workerman.
Песочница работает ещё две недели, вы можете написать своё решение и сравнить результаты с другими.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Быстрый пул для php+websocket без прослойки nodejs на основе lua+nginx