работа с WebSocket в Ratchet и PHPDaemon

[флоппик]

Я на всякий случай повторюсь: your mileage may vary, возможно у вас получились эти вещи стабильней и лучше, чем у меня — если это так, расскажите, как это сделать лучше.

 

[fixxxer]

2 реальные задачи:
1. получать файл на upload в php-fpm worker и сообщать его имя демону по сокету для обработки и отправки на S3
2. хочу получать сообщение для чата в php-fpm worker, обрабатывать с ORM, т.е. с блокирующими запросами к базе, и переваренное сообщение отдавать демону для раздачи в канале по web socket

проверять как этот демон потянет поддержку file upload не хочу, пусть этим занимаются nginx и fpm

Я ровно это делаю через redis queues (со стороны ratchet - predis async client). Две очереди - от ratchet в fpm, и обратно.

У redis протокола есть особенность - режим очереди не подразумевает возможности выполнения других команд с redis, так что, если он нужен еще для чего-то, просто держишь 2 соединения на одном евент лупе.

Насчет js-либ, если честно, не в курсе, у меня с клиентами простой самописный обмен json-пакетами.

 

[grigori]

наткнулся на такую любопытную штуку: Aerys - web/application server на php 7 на базе какого-то фреймворка по имени Amp https://github.com/amphp/amp
с поддержкой web socket

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

жаль только, что libevent, libev, memcache/d, и большая часть pecl под 7ку не собираются, иначе я б на нее уже перешел

 

[hell0w0rd]

А асинхронные драйверы к базам, асинхронный curl и fs (в общем все IO) появились под php? Потому что в node, надо очень сильно следить за этим в чужих библиотеках, да и в своем коде.

 

[grigori]

curl_multi, mysqli, postgres реализуют асинхронность еще с 4ки, вопрос в поддержке ее фреймворками
в pdo пока не заморочились, но с такой тенденцией это могут сделать достаточно быстро, если rfc кто-нибудь напишет

 

[fixxxer]

А асинхронные драйверы к базам, асинхронный curl и fs (в общем все IO) появились под php? Потому что в node, надо очень сильно следить за этим в чужих библиотеках, да и в своем коде.

большинство есть - http, mysql, redis, memcached... Для постгреса пока нет, скоро свой выложу на гитхаб

А async fs - это миф В ноде те же блокирующие системные вызовы, отличаются только интерфейсом - return либо callback. Да и нету их толком в ядрах - в универсальном виде есть только в freebsd. Псевдоасинхронную работу с fs можно эмулировать вспомогательным тред-пулом, именно так сделано в последних версиях nginx, в ноде, насколько я знаю, этого нет.

postgres реализуют асинхронность еще с 4ки

там интерфейс, требующий явного поллинга. не катит

 

[grigori]

хм, я так детально не вникал, видимо, требует реализации через опрос в основном цикле приложения, что, безусловно, overhead
в таком случае, с pg будет тяжко, там даже маппинг типов никто не сделал

 

[fixxxer]

хм, я так детально не вникал, видимо, требует реализации через опрос в основном цикле приложения, что, безусловно, overhead
в таком случае, с pg будет тяжко, там даже маппинг типов никто не сделал

Там не очень сложный протокол. Я уже почти весь реализовал, остались редко нужные мелочи типа copy, и что-то удобное для транзакций - в стиле nodejs domains.

Маппинг типов - ну не знаю, это явно скорее область data mapper. На уровне протокола всё есть строки.

 

[grigori]

@fixxxer, а что, для файлов есть какая-то асинхронность?

 

[fixxxer]

Есть, уместно прежде всего для задач типа "отдать клиенту огромный файл". В freebsd - aio, вполне полноценный. В линуксе бардак -три разных API и все неполноценные, не совместимые с sendfile, плюс куча требований типа "размер блока оффсет должен быть выровнен аналогично блокам ФС" и подобное, в целом можно сказать что не работают - именно поэтому в nginx сделали тредпул.

 

[grigori]

интересная статья
да, через тредпул можно забить вообще на все, а как решается concurrency? никаких атомарных операций в php thread нет, синглтоны городить?
можно подумать над связью потоков и корутин

 

[fixxxer]

В php я, если честно, не знаю, на кой это. Простейшие операции с файлами на локальной ФС очень быстрые, от тредов и семафоров только оверхеда больше будет. А с отдачей статики прекрасно справляется nginx.

 

[grigori]

@Redjik давай твою либу с отловом всех ошибок ФС сделаем асинхронной в тредпуле и подключим к реакту

 

[hell0w0rd]

Что люди не придумывают, чтобы node не брать))

 

[grigori]

ты это к тому, что в ноде проблемы асинхронного доступа и ipc решены, или просто болеешь за Вилларибо?

Вот мой случай:
1. Чат мне надо сделать с пред-обработкой, раздавать через wamp-роутер. Обрабатывать удобно через PHP с ORM, асинхронность здесь не нужна. Лучший роутер - crossbar, он на питоне.
2. Для обработки фоток самая интересная библиотека - http://thumbor.org , опять питон.
3. Интеграция с AWS - FUSE

Я просто не вижу зачем мне в моих задачах нода. Думаю о питоне, но не люблю зверинцы.
Выбирай, осторожно, но выбирай, php, по три, но завтра, или сегодня, python, но по пять.

Вот в http://blog.kelunik.com/2015/09/20/getting-started-with-amp.html показывают как генераторы упрощают асинхронные задачи на php. Да, питон лучше, но и php еще не perl.

 

[Redjik]

@grigori, ты думаешь Никита знает про

о три, но завтра, или сегодня, python, но по пять.

=))

 

[hell0w0rd]

Я не против питона, против php в этом контексте. Просто изначально считал бредом проекты вроде reactphp, ну не создан php для этого. Конечно интересно, как это развивается, но ровно на стадии интереса. Как для ноды нет удобной инфраструктуры, с большими фреймворками, так и для php асинхронность.
thumbor - это же сервис, а не библиотека. Ты можешь остальное на любом языке писать, вообще привязку не вижу.

Вот в http://blog.kelunik.com/2015/09/20/getting-started-with-amp.html показывают как генераторы упрощают асинхронные задачи на php.

Да, генераторы упрощают работу с асинхронностью в любом языке.
PS а для php можно написать аналог Promise.all? То есть чтобы асинхронные таски решались не последовательно, а параллельно.

 

[fixxxer]

Не вижу абсолютно никакой разницы в написании event driven FSM на js, php, python, ruby. Все они на уровне языка никаких специальных средств не предоставляют (в отличие от erlang с его гринтредами или golang с корутинами), реализация везде одинаковая - используется та или иная обертка над epoll/kqueue - libev, libuv и т.д, и везде обыкновенные колбэки.

Promise/A пишется на php ровно так же, как и на js. Вот, например: https://github.com/reactphp/promise

Лично мне по барабану, писать на js или php. Когда удобнее - пишу на js. В одном из проектов использую reactphp просто потому, что мне надо в FSM-демоне работать с уже реализованной domain model. Если бы на js существовали полноценные фреймворки, можно было бы изначально все на TypeScript написать, но, простите, для nodejs нет даже ни одной реализации data mapper ORM.

 

[hell0w0rd]

setImmediate в php разве есть?
PS есть https://github.com/reactphp/promise/issues/43

$loop = React\EventLoop\Factory::create();

$asyncPromise = new React\Promise\Promise(function($resolve) use ($loop) {
    $loop->nextTick(function() use($resolve) {
        $resolve('Async Promise');
    });
})

Нуу оок)

 

[fixxxer]

А что не так? Внутрях v8 примерно то же самое