Comments 34
А Toredis надеюсь используется для событий в каналах? Просто для set/get и много чего ещё лучше использовать блокирующий Redis (и тут стандартный py клиент более чем подходит).
А так, у меня проекты изначально на Tornado по этому и что то с боку прикручивать смысла мало. К слову сколько строк кода получилось в Go и Python?
А так, у меня проекты изначально на Tornado по этому и что то с боку прикручивать смысла мало. К слову сколько строк кода получилось в Go и Python?
Нет, Toredis используется для всех операций. А почему лучше, есть какие-то сравнения или опыт? Ведь малейший таймаут заблокирует весь поток в таком случае?
В случае проектов изначально на Торнадо – да, лучше сбоку ничего не прикручивать, если есть время на разработку. Если не учитывать тесты, которых в Go-версии прилично, в отличие от питоновской – то 3740 (Python) и 4450 (Go).
В случае проектов изначально на Торнадо – да, лучше сбоку ничего не прикручивать, если есть время на разработку. Если не учитывать тесты, которых в Go-версии прилично, в отличие от питоновской – то 3740 (Python) и 4450 (Go).
Нет, Toredis используется для всех операций. А почему лучше, есть какие-то сравнения или опыт? Ведь малейший таймаут заблокирует весь поток в таком случае?
Об этом сами разработчики писали. Там оверхед от event loop выходит больше чем сама операция. Особенно актуально если с Redis по unix socket соединять.
На практике то же заметил повышение отзывчивости. Вот для SQL БД уже в целом нужен.
То что выполнять блокирующие запросы в Торнадо не зазорно, если они быстрые, я тоже знаю, да. Но что делать если обычно быстрый запрос стаймаутит и превратится в 2 секунды блокировки всего сервера? Понятно, что можно вынести это в ThreadPool, но тогда скорее всего потеряется выигрыш в скорости по сравнению с асинхронным запросом.
упс, забыл учесть пару файликов на верхнем уровне в Go-версии – ~5000 строк в итоге
что же выбрать для интеграции с проектом на django. Я вот недавно искал и наткнулся на swampdragon, а тут вот еще одна новая подобная штука вылезла. Вот бы сравнил кто и показал примеры интеграции. Задача простая — много разных «чатиков» завязанных на конкретные записи в БД определенных таблиц (и используемых через модели django)
ИМХО легче самим на Tornado написать.
ЗЫ в целом с батарейками на Tornado можно писать не хуже чем с другими фреймворками где нету админки.
ЗЫ в целом с батарейками на Tornado можно писать не хуже чем с другими фреймворками где нету админки.
В одном из наших проектов на Django есть как раз такая задача — у нас чатики-обсуждения привязаны к вопросам теста. В другом проекте реал-тайм комментарии, которые можно привязать к любому объекту через GenericForeignKey. Все использует Centrifugo. Для меня ответ очевиден, конечно:) Вот замечательная ссылка, кстати, чтобы сделать ваш выбор еще сложнее — REAL-TIME WEB TECHNOLOGIES GUIDE:)
а это работает например если у тебя 5 таких машин? например поставили редис общий, каждая машины получает пачку клиентов на websocket. Кидаю сообщение в очередь в редисе, откуда мне знать что это сообщение возьмет из редиса имена та машина на которой подлючин этот клиент? а как быть если это xhr-poll?
можешь обьяснить как это может работать кластером?
можешь обьяснить как это может работать кластером?
Не важно, какая машина возьмет сообщение. После того как какая-то машина взяла сообщение из очереди в Редисе — она публикует его в канал в Редисе, на который подписаны все ноды (PUB/SUB механизм Редиса) – соответственно все ноды в итоге это сообщение получают и отсылают нужным клиентам, которые на них висят.
ок
а какая проблема с мобилными клиентами? они могут обращатся по http polling
просто нет готового решения? надо каждому самому писать?
а какая проблема с мобилными клиентами? они могут обращатся по http polling
просто нет готового решения? надо каждому самому писать?
Дело в протоколе общения с Центрифугой — соединение и авторизация, подписка на каналы, реакция на различные типы сообщений от сервера — это желательно иметь в клиентской библиотеке. Чтобы по xhr-polling общаться нужно сообщения обернуть дополнительно в SockJS протокол. Ну или использовать вебсокеты.
Интересное решение, давно слежу. У нас сейчас используется два контура для данных — dklab_realplexor (http-long polling) и свое решение на базе Flash Socket (сервер NodeJS, plain TCP socket). есть большое желание унифицировать все и перейти на один транспорт
Я вижу возможное будущее Центрифуги как отказ от SockJS в определенный момент, когда не останется проблем с подключением из браузера через Websocket и возможно добавление какого-либо TCP транспорта для более удобного общения из небраузерной среды. Но пока это только теория:) А как у вас по plain TCP общение происходит? как сериализуете данные?
Ну сам по себе sockjs отличное решение, думаю еще многие годы понадобятся, чтобы вообще отказаться от него.
У нас гоняются просто строки JSON поверх флешового сокета и дальше они идут в JS через мост externalinterface. На момент внедрения это было единственное решение для полноценного двухстороннего реалтайма для всех браузеров, где надо именно постоянно готовое соединение
У нас гоняются просто строки JSON поверх флешового сокета и дальше они идут в JS через мост externalinterface. На момент внедрения это было единственное решение для полноценного двухстороннего реалтайма для всех браузеров, где надо именно постоянно готовое соединение
А где тот чувак, который приходит во все посты о Go и говорит, что на Rust можно сделать тоже самое куда проще и лучше?
это видимо тот случай, когда речь о большом количестве постоянных соединений и сбегаются фанаты Эрланга:)
> Centrifugo: 350 миллисекунд, когда в канале 100 пользователей (x49)
Это позор. Просто позор. Это минимум в 20 раз дольше, чем на эрланге такой же код отрабатывает.
Это позор. Просто позор. Это минимум в 20 раз дольше, чем на эрланге такой же код отрабатывает.
А компилятор эрланга за последние 20 лет уже успели отдебажить или еще нет?
эрланг как бы в виртуальной машине работает, а не компилируется, причем без JIT. Логично было бы ожидать обратной картины, но видим скорость на уровне руби.
ну руби как бы не самое быстрая вещь. Если ерланг по скорости похож на руби то это явно медленнее ГО.
Я имел ввиду, что Go по скорости мягко говоря не впечатлил. Треть секунды на рассылку сообщения — это немыслимо медленно.
Возможно там производительность не в язык упирается. Или алгоритмы где то то кривые, это ведь нужно исследовать.
я честно говоря думал, что это просто вброс, на который не нужно отвечать:) Во-первых – это 1000 сообщений, а не одно, во-вторых — на каждое из 1000 отправленных сообщений в реквесте формируется результат выполнения в JSON-е ответа. И я сравниваю реализацию Центрифуги на 2-х разных языках, а не языки.
это. все разговоры… вот тесты с цифрами.http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=hipe
Спасибо за пост! Узнал про Centrifugo впервые. Выглядет очень привлекательным. Сразу возник вопрос: какая разница между ним и SocketIO?
Пожалуйста:) На самом деле не совсем корректно сравнивать Centrifugo с Socket.IO – Центрифуга использует SockJS (аналог Socket.IO) как транспорт для сообщений между браузером и Centrifugo, используя всевозможные HTTP транспорты, когда не удается установить Websocket соединение, ну и все на этом. В остальном это отдельный продукт со своей внутренней механикой и встроенными возможностями.
В случае приличной нагрузки следует ли ставить Centrifugo за nginx или, наоборот, лучше не надо?
Сложно сказать, у нас нагрузки на Центрифугу практически нет — так что отвечаю из каких-то абстрактных соображений. В производительности скорее всего немного потеряете, если поместите за Nginx, но зато приобретете некоторый набор опций, которые можно будет подкрутить, ну и балансировку, если нужна. Еще так или иначе нужен какой-то прокси, чтобы проксировать клиентов, использующих polling-транспорты SockJS на один и тот же инстанс Центрифуги (возможно вам хватит одного инстанса или можно polling-транспорты не использовать, если не нужна поддержка совсем старых браузеров). Единственный случай серьезной нагрузки, который пока на данный момент есть — это 50 тыс. пользователей онлайн — там 2 инстанса Центрифуги за ELB. И есть небольшой race condition, который при нагрузке вылезает, приводящий к дисконнектам клиентов, – он починен в мастере, на днях сделаю релиз.
Sign up to leave a comment.
Centrifuge + Go = Centrifugo – harder, better, faster, stronger