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-...

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

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