Есть nginx-push-stream модуль, который может работать через вебсокет
А он делает тоже самое, что и приведённый выше код на луа?
А можно внутри lua делать запросы в Redis, MySQL, Postgres…

Тогда может и не нужен тут PHP?

А так, никакие прослойки уже давненько не нужны. Есть Ratchet, Aerys и т.д.
Ratchet и Aerys на чём написаны? Пост про то, чтобы избавится от оверхеда, а не про то, что есть другие решения на php.
Простите, я реально не понимаю в чем оверхед решения в схеме nginx + aerys.
Получаем чистый, не блокирующий код на 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
Вот даже результат из вашей статьи, где Lua проигрывает PHP разгромно.
image

LuaJit на 7 месте с 8 секундами

LuaJIT который используется в nginx, не чистый Lua
Под многопоточностью вы имеете в виду thread'ы? Если да, то в nginx'е воркеры это тоже не thread'ы, а процессы. Thread'ы внутри nginx'а, насколько я помню, используются только для доступа к файловой системе.
Так и не увидел преимущества решения над тем же nodejs. Разве что, нода может давать небольшой оверхед, кмк. Можете прояснить?
Многопоточность и минус оверхед, который даёт куча кода на ноде.
Ну оверхед это еще явление неподтвержденное, это лишь мои догадки. Ни тестов, ни замеров в статье приведено не было, опять же не видно преимущества луа над нодой. Алсо, нода умеет в многопоточность, пускай и немного костыльными путями.
Наверное удобство работы с привычным языком.
Или, когда сайт уже написан на PHP, цеплять к нему ноду и заного писать все механизмы, а потом поддерживать их… брр… А так все сразу работает :)
Так тут прослойка из луа получается. Да и нет смысла переписывать все на ноду, в крайнем случае, можно просто проксить на нее сокеты, собственно, как и написано у автора в общем решении вопроса. Просто мне кажется, что это какое-то шило на мыло, во всяком случае, из статьи я не вижу никаких плюсов.
Если основная проблема, что php работает per request, почему бы не запустить его в режиме демона и не обрабатывать запросы по событиям?
Скорость и потребляемые ресурсы.
Что с ними не так?
Не очень понятно как в этой схеме решается ожидание событий от бекэнда (php в данном случае)
С помощью доступных способов хранения очередей/брокер сообщений. Собственно, это в любом случае решалось бы так, используя даже демон написанный на php.
Нужна прослойка которая будет держать открытыми вебсокеты и при поступлении данных соединяться с php (через тот же fastcgi) и отправлять обратно ответ.


В чём преимущество отправки сообщения в вебсокет, которое будет позже направлено в php? Не проще ли сразу через ajax отправлять запросы на сервер, а вебсокеты использовать для доставки сообщений с сервера в клиент а не на оборот.

Я делаю свой проект комет сервера на C++ который именно даёт апи для отправки сообщений от сервера клиенту. И не могу придумать ситуации где имеет смысл делать на оборот отправку от клиента на сервер не простыми ajax запросами а через вебсокеты добавляя ещё одну лишнею прослойку между отправителем и адресатом.
WebSocket имеет смысл при уведомлениях клиента об изменениях данных на сервере мимо схемы запрос-ответ. И если клиент уже держит открытое готовое соединение, то имеет смысл это соединение и использовать вместо ajax — экономим накладные расходы на установку http соединения
Хорошо написанный 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 потоков
результатом просто вывод
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.
Песочница работает ещё две недели, вы можете написать своё решение и сравнить результаты с другими.
Извините, это решение не для чемпионата по хайлоаду, под который пишется специализированное решение.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.