Pull to refresh

Comments 26

Не думаю, что это будет удобнее, чем websocket. К тому же в данном случае, мы ограничены только одним consumer'ом
сравнивать amqp и websocket — тоже самое что солдата и балерину. Кто-то умеет танцевать, а кто-то стрелять.
тем более, что одно транспорт, а второе протокол/формат обмена данными :) AMQP через веб-сокеты это самое оно (хотя во многих случаях и STOMP достаточно). тем более что все основные MQ брокеры уже заявили что поддерживают WS как транспорт (ActiveMQ и JBoss HornetQ)
хмм… я думал это netty поддерживает websocket, а не hornetq
в HornetQ транспортный уровень (коннекторы которые, если я верно помню) работает на базе фреймворка netty, да, и уже давно. теперь можно просто в конфиге указать что использовать ws и все. а так конечно, оно через netty работает как и все остальные сетевые вещи
с чего вы решили, что я сравниваю websocket с amqp? я сравниваю websocket и rest.
надо присмотреться к websocket
спасибо за комментарий.
насколько я понял чтение сообщений через long-poll?
нет, это планируется сл. этапом.
пока идет только обкатка сервера

в настоящее время amqp запрос осуществляется методом BASIC.GET (асинхронный)
планирую разработку синхронного запроса BASIC.CONSUME
тогда без comet технологии не обойтись.
Basic.Get — синхронный метод
Basic.Consume — асинхронный
IMXO. тут трудно спорить, судя ГОСТУ — они оба синхронные:
Basic.Consume (ID=10) start
a queue consumer: Sync request, carries content
Basic.Get (ID=80) direct
access to a queue: Sync request, carries content

но по своей сущности Consume — синхронный запрос, как только сообщение появляется в очереди, оно сразу считывается (передается клиенту), коннекция держится постоянно. в этом смысле — синхронный.
методом GET ты можешь забрать сообщение в любое время из очереди (или пустое уведомление GET-EMPTY). коннекцию постоянно можно не держать. в этом смысле — асинхронный. Хотя если смотреть с иной стороны, как только мы выдаем GET, мы сразу получаем (синхронно) ответ: либо GET-OK либо GET-EMPTY, т.е. синхронный.
блин прочитал что написал и сам запутался…
а как будут синхронные запросы обрабатываться на 10к коннектов?
честно говоря хз
до 10К надо еще мне дорости.
но вроде держать 10к не проблема? вот более 50к — это проблема.
Планирую commet-consume использовать. Пока с этим есть небольшие проблемки,

я не в том смысле, я про то, что если метод синхронный, то это заблокирует текущий поток, что бы не блокировалось все приложение, надо плодить потоки, правильно? если плодить потоки — то и 1к коннектов будет сложно обработать
или я неправильно понял?

ps: я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем.
я про то, что если метод синхронный, то это заблокирует текущий поток, что бы не блокировалось все приложение, надо плодить потоки, правильно?
libevent библиотека с асинхронным ввод/выводом, т.е. использует неблокирующие сокеты. Все работает в одном потоке, только параллельно: как только приходит запрос на сокет, создается буфер и его начинает обрабатывать кэллбэк, если пришел еще один запрос, то новый буфер начинает обрабатывать следующий кэлбэк, если ответ от брокера не пришел, т.е буфер пуст, переходим к обработке следующего буфера и так проходимся по цепочке всех синициированных буферов. По окончанию работы кэлбека — буфер отдается в сокет и освобождается.

и вот еще одно мнение: amix.dk/blog/post/19414
поллинг проще реализовывать и масштабировать. Из всего что я видел, я сделал вывод – все Comet решения слишком уж хакерские, изворотливые и очень тяжело масштабируются. Они плохо масштабируются, потому что web платформы построены на модели запрос-ответ.

я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем
интересно посмотреть
ну если работа с синхронным методом асинхронная, тогда вопрос снимается ;)

см приват
ссылку посмотрю,
спасибо
идея состоит в следующем: прокси принимает сообщения amqp и складывает их во внутренние очереди (массивы) сообщений, а при подключении http клиента — проходит по всем внутренним очередям и отдает клиенту только те сообщения, которые нужны данному пользователю
а как конкретно фильтровать — прокси спрашивает по amqp у демона отвечающего за БД.

т.е. не просто трансляция amqp-http а прокси со своей бизнес логикой.
да, интересно. а брокер какой, ActiveMQ?
а кролик Websockets поддерживает? плагин?
хм. кролик = rabbitmq
а зачем ему websockets? для websockets у меня отдельная прокся ;)
хм. кролик = rabbitmq
это и ежу понятно
для websockets у меня отдельная прокся ;)
а куда эта прокся ведет?
у меня 1300 rps на ноуете 2.3 GHz 1Mg, но этого должно вполне хватить для обработки 10к
на продакшене процессор помощнее 4-8 ядер, памяти побольше, в общем должно быть еще быстрее.
сервер жрет 601К и 2 % CPU — даже смешно.
Sign up to leave a comment.

Articles