Comments 26
Интересно, нужно будет попробовать.
0
Не думаю, что это будет удобнее, чем websocket. К тому же в данном случае, мы ограничены только одним consumer'ом
-1
сравнивать amqp и websocket — тоже самое что солдата и балерину. Кто-то умеет танцевать, а кто-то стрелять.
0
тем более, что одно транспорт, а второе протокол/формат обмена данными :) AMQP через веб-сокеты это самое оно (хотя во многих случаях и STOMP достаточно). тем более что все основные MQ брокеры уже заявили что поддерживают WS как транспорт (ActiveMQ и JBoss HornetQ)
0
хмм… я думал это netty поддерживает websocket, а не hornetq
0
с чего вы решили, что я сравниваю websocket с amqp? я сравниваю websocket и rest.
+1
насколько я понял чтение сообщений через long-poll?
0
нет, это планируется сл. этапом.
пока идет только обкатка сервера
в настоящее время amqp запрос осуществляется методом BASIC.GET (асинхронный)
планирую разработку синхронного запроса BASIC.CONSUME
тогда без comet технологии не обойтись.
пока идет только обкатка сервера
в настоящее время amqp запрос осуществляется методом BASIC.GET (асинхронный)
планирую разработку синхронного запроса BASIC.CONSUME
тогда без comet технологии не обойтись.
0
Basic.Get — синхронный метод
Basic.Consume — асинхронный
Basic.Consume — асинхронный
0
IMXO. тут трудно спорить, судя ГОСТУ — они оба синхронные:
но по своей сущности Consume — синхронный запрос, как только сообщение появляется в очереди, оно сразу считывается (передается клиенту), коннекция держится постоянно. в этом смысле — синхронный.
методом GET ты можешь забрать сообщение в любое время из очереди (или пустое уведомление GET-EMPTY). коннекцию постоянно можно не держать. в этом смысле — асинхронный. Хотя если смотреть с иной стороны, как только мы выдаем GET, мы сразу получаем (синхронно) ответ: либо GET-OK либо GET-EMPTY, т.е. синхронный.
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, т.е. синхронный.
0
блин прочитал что написал и сам запутался…
0
а как будут синхронные запросы обрабатываться на 10к коннектов?
0
честно говоря хз
до 10К надо еще мне дорости.
но вроде держать 10к не проблема? вот более 50к — это проблема.
Планирую commet-consume использовать. Пока с этим есть небольшие проблемки,
до 10К надо еще мне дорости.
но вроде держать 10к не проблема? вот более 50к — это проблема.
Планирую commet-consume использовать. Пока с этим есть небольшие проблемки,
0
я не в том смысле, я про то, что если метод синхронный, то это заблокирует текущий поток, что бы не блокировалось все приложение, надо плодить потоки, правильно? если плодить потоки — то и 1к коннектов будет сложно обработать
или я неправильно понял?
ps: я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем.
или я неправильно понял?
ps: я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем.
+1
я про то, что если метод синхронный, то это заблокирует текущий поток, что бы не блокировалось все приложение, надо плодить потоки, правильно?libevent библиотека с асинхронным ввод/выводом, т.е. использует неблокирующие сокеты. Все работает в одном потоке, только параллельно: как только приходит запрос на сокет, создается буфер и его начинает обрабатывать кэллбэк, если пришел еще один запрос, то новый буфер начинает обрабатывать следующий кэлбэк, если ответ от брокера не пришел, т.е буфер пуст, переходим к обработке следующего буфера и так проходимся по цепочке всех синициированных буферов. По окончанию работы кэлбека — буфер отдается в сокет и освобождается.
и вот еще одно мнение: amix.dk/blog/post/19414
поллинг проще реализовывать и масштабировать. Из всего что я видел, я сделал вывод – все Comet решения слишком уж хакерские, изворотливые и очень тяжело масштабируются. Они плохо масштабируются, потому что web платформы построены на модели запрос-ответ.
я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблеминтересно посмотреть
0
ну если работа с синхронным методом асинхронная, тогда вопрос снимается ;)
см приват
см приват
0
ссылку посмотрю,
спасибо
спасибо
0
идея состоит в следующем: прокси принимает сообщения amqp и складывает их во внутренние очереди (массивы) сообщений, а при подключении http клиента — проходит по всем внутренним очередям и отдает клиенту только те сообщения, которые нужны данному пользователю
а как конкретно фильтровать — прокси спрашивает по amqp у демона отвечающего за БД.
т.е. не просто трансляция amqp-http а прокси со своей бизнес логикой.
а как конкретно фильтровать — прокси спрашивает по amqp у демона отвечающего за БД.
т.е. не просто трансляция amqp-http а прокси со своей бизнес логикой.
0
да, интересно. а брокер какой, ActiveMQ?
0
кролик
0
а кролик Websockets поддерживает? плагин?
0
хм. кролик = rabbitmq
а зачем ему websockets? для websockets у меня отдельная прокся ;)
а зачем ему websockets? для websockets у меня отдельная прокся ;)
0
у меня 1300 rps на ноуете 2.3 GHz 1Mg, но этого должно вполне хватить для обработки 10к
на продакшене процессор помощнее 4-8 ядер, памяти побольше, в общем должно быть еще быстрее.
сервер жрет 601К и 2 % CPU — даже смешно.
на продакшене процессор помощнее 4-8 ядер, памяти побольше, в общем должно быть еще быстрее.
сервер жрет 601К и 2 % CPU — даже смешно.
0
Sign up to leave a comment.
AMQP-REST