Меню
Что нового?

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

  • Автор темы Автор темы grigori
  • Дата начала Дата начала
Я на всякий случай повторюсь: your mileage may vary, возможно у вас получились эти вещи стабильней и лучше, чем у меня — если это так, расскажите, как это сделать лучше.
 
grigori написал(а):
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-пакетами.
 
Последнее редактирование:
наткнулся на такую любопытную штуку: Aerys - web/application server на php 7 на базе какого-то фреймворка по имени Amp https://github.com/amphp/amp
с поддержкой web socket

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

жаль только, что libevent, libev, memcache/d, и большая часть pecl под 7ку не собираются, иначе я б на нее уже перешел
 
Последнее редактирование:
А асинхронные драйверы к базам, асинхронный curl и fs (в общем все IO) появились под php? Потому что в node, надо очень сильно следить за этим в чужих библиотеках, да и в своем коде.
 
curl_multi, mysqli, postgres реализуют асинхронность еще с 4ки, вопрос в поддержке ее фреймворками
в pdo пока не заморочились, но с такой тенденцией это могут сделать достаточно быстро, если rfc кто-нибудь напишет
 
hell0w0rd написал(а):
А асинхронные драйверы к базам, асинхронный curl и fs (в общем все IO) появились под php? Потому что в node, надо очень сильно следить за этим в чужих библиотеках, да и в своем коде.
Нажмите для раскрытия...
большинство есть - http, mysql, redis, memcached... Для постгреса пока нет, скоро свой выложу на гитхаб

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

postgres реализуют асинхронность еще с 4ки
Нажмите для раскрытия...
там интерфейс, требующий явного поллинга. не катит
 
Последнее редактирование:
хм, я так детально не вникал, видимо, требует реализации через опрос в основном цикле приложения, что, безусловно, overhead
в таком случае, с pg будет тяжко, там даже маппинг типов никто не сделал
 
grigori написал(а):
хм, я так детально не вникал, видимо, требует реализации через опрос в основном цикле приложения, что, безусловно, overhead
в таком случае, с pg будет тяжко, там даже маппинг типов никто не сделал
Нажмите для раскрытия...
Там не очень сложный протокол. :) Я уже почти весь реализовал, остались редко нужные мелочи типа copy, и что-то удобное для транзакций - в стиле nodejs domains.

Маппинг типов - ну не знаю, это явно скорее область data mapper. На уровне протокола всё есть строки.
 
Последнее редактирование:
Есть, уместно прежде всего для задач типа "отдать клиенту огромный файл". В freebsd - aio, вполне полноценный. В линуксе бардак -три разных API и все неполноценные, не совместимые с sendfile, плюс куча требований типа "размер блока оффсет должен быть выровнен аналогично блокам ФС" и подобное, в целом можно сказать что не работают - именно поэтому в nginx сделали тредпул.
 
интересная статья
да, через тредпул можно забить вообще на все, а как решается concurrency? никаких атомарных операций в php thread нет, синглтоны городить?
можно подумать над связью потоков и корутин
 
В php я, если честно, не знаю, на кой это. :) Простейшие операции с файлами на локальной ФС очень быстрые, от тредов и семафоров только оверхеда больше будет. А с отдачей статики прекрасно справляется nginx.
 
@Redjik давай твою либу с отловом всех ошибок ФС сделаем асинхронной в тредпуле и подключим к реакту ;)
 
ты это к тому, что в ноде проблемы асинхронного доступа и 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.
 
Последнее редактирование:
Я не против питона, против php в этом контексте. Просто изначально считал бредом проекты вроде reactphp, ну не создан php для этого. Конечно интересно, как это развивается, но ровно на стадии интереса. Как для ноды нет удобной инфраструктуры, с большими фреймворками, так и для php асинхронность.
thumbor - это же сервис, а не библиотека. Ты можешь остальное на любом языке писать, вообще привязку не вижу.
grigori написал(а):
Вот в http://blog.kelunik.com/2015/09/20/getting-started-with-amp.html показывают как генераторы упрощают асинхронные задачи на php.
Нажмите для раскрытия...
Да, генераторы упрощают работу с асинхронностью в любом языке.
PS а для php можно написать аналог Promise.all? То есть чтобы асинхронные таски решались не последовательно, а параллельно.
 
Не вижу абсолютно никакой разницы в написании 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.
 
Последнее редактирование:
setImmediate в php разве есть?
PS есть https://github.com/reactphp/promise/issues/43
PHP: 
$loop = React\EventLoop\Factory::create();

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

Нуу оок)
 
Последнее редактирование:
Войдите или зарегистрируйтесь для ответа.
Сверху