Long poll — как делать тысячи соединений открытыми?
Слишком уж общий вопрос, ну и технология древняя, почему не сокеты?
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.
Реализация в обоих случаях была на коленке, функционал одинаковый.
Вот мой проект https://github.com/CppComet/comet-server я писал на C++
Если всё делать по уму то много одновременных соединений только память требуют. И то сравнительно не много. Так как не надо делать по отдельному потоку на каждое соединение. Гораздо сложнее обрабатывать много запросов. Так как это потребляет процессорное время.
Вот я делал замеры на 64 000 соединений https://comet-server.com/wiki/doku.php/comet:load-...
Если есть вопросы или желание поучаствовать в проекте пишите.