Long poll — как делать тысячи соединений открытыми?

Question

[iBird Rose]

Для Long poll запросов нужно сделать тысячи соединений открытыми. На данный момент - 15к соединений.
Есть адрес. К нему нужно держать открытыми 15к http long poll соединений.
Вопрос в том какие инструменты для этого лучше всего использовать? Какой язык? Как это можно реализовать? Если у кого-то был опыт таких объемов - тоже хотелось бы услышать советы.

Comments

[Александр Аксентьев]

Щито?
Что это вообще значит?
Какой сервер, какой язык, что происходит

[iBird Rose]

Александр Аксентьев, Вопрос в том и заключается, какие вводные нужны, есть ли у кого-то опыт в таком объеме

[hOtRush]

Говорят что long polling - каменный век, есть же websocket's. Взять тот же centrifugo https://github.com/centrifugal/centrifugo

[iBird Rose]

hOtRush, выбора в технологии (longpoll или вебсокеты) нет.

[Сергей Горностаев]

hOtRush, в любому случае это не исключит необходимость решать проблему c10k.

[hOtRush]

Сергей Горностаев, да вроде уже не 1999, может вы про c10M?
Centrifugo отлично скэйлится через редис, можно сделать банальный шардинг соединений на разные сервера. Но эта проблема не должна стоять при 10к соединений.

[Сергей Горностаев]

hOtRush, как показывает опыт, даже 10k подключений классические решения на воркерах и пулах потоков просто не вывозят. Centrifugo справляется потому, что сделан на Go, а каналы Go эксплуатируют асинхронность.

Answer 1

[Александр Аксентьев]

Слишком уж общий вопрос, ну и технология древняя, почему не сокеты?

https://github.com/centrifugal/centrifugo
Имеет fallback с поллингом.
Но основной-то вебсокет канал по сути.
На хорошо нагруженном 8 ядерном сервере держит 4-5к коннектов нормально. Захлебывается при перезапуске конечно)
Общение почти только в одну сторону, без приёма данных от клиентов.

Не очень подходит для общения в две стороны, в основном для рассылки с сервера.
В две стороны обмен нагрузка сразу скачет до небес и виснет.

В целом на GO что-то изобразить можно например.
Наколеночная реализация в один процесс и один поток держала 2-3к пользователей. Опять же логики почти не было, только авторизация и проверка на наличие оповещений.
Если запилить шардинг или мультипоточность, но на 4-8 ядрах вполне можно держать 15к+.

Ну и NodeJS никто не отменял.
https://habr.com/post/123154/
Но по факту у меня в говнореализации NodeJS работал фиговее чем GO, примерно в 2 раза меньше мог держать онлайна 1500-1700, на том же одном процессе и потоке как Go.
Реализация в обоих случаях была на коленке, функционал одинаковый.

Comments

[iBird Rose]

Тут забыто уточнение, запросы исходящие, а не входящие. И выбора в технологии (longpoll или вебсокеты) нет.

[Александр Аксентьев]

iBird Rose, уууу, ничосе уточнение, это вообще в другую степь)

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

[FZambia]

Александр, 4-5k коннектов это очень мало - Centrifugo явно может больше, 50k соединений в проде на ноду без проблем должно быть. Возможно дело в специфичном характере нагрузки на Centrifugo в вашем случае? Можем попробовать понять в чем дело - напишите в gitter чат проекта (ссылка в ридми на гитхабе есть)

[Александр Аксентьев]

FZambia, внезапная тех. поддержка центрифуги?)
в моём случае из нагрузки вообще по сути ничего нет, поэтому да вообще странно конечно.
Простейший счетчик людей сидящих на странице:
Вот такая "логика" работы https://gist.github.com/S-anasol/5970d1834dcd0cded...
Много каналов создаётся и запрашиваются списки онлайн юзеров, но никакой другой логики нет.

Сервер реально сильно загружен, там видео кодируется и трафика тонны на сайте, поэтому вполне может быть что у центрифуги мало ресурсов по факту.

[FZambia]

Александр Аксентьев, ну я иногда смотрю рефереров на Github:) По такой поверхностной информации конечно сложно судить, но есть предположение, что очень много join/leave эвентов посылается - по сути на каждый коннект и релоад странички сообщение в итоге отправляется всем – это может приводить к огромному количеству сообщений. Join/Leave события плохо масштабируются на каналы с большим кол-вом пользователей. Тут все же не лучшее место раскапывать дальше, если есть желание понять реальную причину, то можно поисследовать в Gitter чате. Вот тут описаны шаги которые могут помочь понять, что происходит - https://github.com/centrifugal/centrifugo/wiki/Inv...

[Александр Аксентьев]

FZambia, отписался под гистом, вроде должно быть оповещение.
В целом у меня всё норм, нагрузки нет. 5к(уже 8к уников/14к коннектов) это скорее тот максимум что видел и который работал без проблем.

Answer 2

[Виктор]

Вот мой проект https://github.com/CppComet/comet-server я писал на C++
Если всё делать по уму то много одновременных соединений только память требуют. И то сравнительно не много. Так как не надо делать по отдельному потоку на каждое соединение. Гораздо сложнее обрабатывать много запросов. Так как это потребляет процессорное время.
Вот я делал замеры на 64 000 соединений https://comet-server.com/wiki/doku.php/comet:load-...

Если есть вопросы или желание поучаствовать в проекте пишите.

Comments

[Виктор]

ну да у меня коннекты не лонг полинг а вебсокеты но с точки зрения сервера ему всё равно так как по факту это тот не tcp протокол.

Answer 3

[Сергей Горностаев]

Для обслуживания десятков тысяч одновременно открытых соединений хорошо подходят асинхронные сервера.
Фреймворки и библиотеки для написания асинхронных серверов есть почти для каждого языка. В Java - это Netty. В Python - Twisted, Tornado или aiohttp. Node.js и Go вообще "написаны вокруг" этой функции.