Можно ли передать файлдескриптор сокета из Go в Node.js?
Есть веб-сервер написанный на Go
На сервер могут приходить http запросы и вебсокеты
Часть http запросов сервер обрабатывает сам, а часть отдает процессу на node.js, все веб-сокеты отдаются в node.js
Сейчас это все реализовано как реверси-прокси, что удваивает количество соеденений + издержки на проксирование.
Можно ли отдать непосредственно сам сокет процессу на node.js через пробрасывание файл-дескриптора?
Задача:
Есть приложение на ноде, написано не мной, работает в 1 процесс.
Передо мной задача во-первых, запустить его на всех ядрах процессора, во-вторых сделать кэширование статики в памяти.
Сначала я думал просто сделать балансировку через ngnix или cluster, но есть проблема в том, что нужна более умная балансировка - session-stiky + у новых сессий есть некоторые условия распределения
Для решения написал несложный балансировщик с нужной логикой на go, который выдает статику из своей памяти и переодически проверяет необходимость обновления кэша, а запросы к динамике проксирует на один из процессов приложения, а теперь нужно все это дело оптимизировать, чтоб "долгосрочные" запросы, такие как вебсокеты не проксировать, а просто отдавать открытый конект ноде
Нет. А что вообще значит "Часть http запросов сервер обрабатывает сам, а часть отдает процессу на node.js", кто отдает, кто обрабатывает ? У вас перд go/node стоит nginx и на уровне location проксирует часть на go, а часть на node или в go прилетает все, а он дальше куда-то еще засылает ?
bingo347: дак это aлгоритм маляра Шлемиля ) Во первых кэширование статики отдайте на nginx, во вторых в томже nginx есть lua-upstream-module (https://github.com/openresty/lua-upstream-nginx-module, а сейчас и nginScript) для вашей логики условия распределения новых сессий.
Написано
Дмитрий Беляев
@bingo347 Автор вопроса, куратор тега Node.js
Кирилл: проблема в том, что мне нужно не проксировать, а отдавать сокет для долгих соединений, так что ngnix мне не подходит.
Да и с кэшем статики не все так просто, у меня кэшируется так как я запланировал, а не так как решили оптимизационные алгоритмы ngnix
Дмитрий Беляев
@bingo347 Автор вопроса, куратор тега Node.js
Кирилл: ngnix может проксировать ws и это у меня уже есть, а мне нужна прямая работа с ws без посредников в виде ngnix или go так как это создает издержки и по памяти и по скорости.
ps: как меня убивают теоретики считающие, что если у Вас на сайте есть 20к онлайна, то вы можете позволить себе арендовать еще несколько машин под сервер. Не можете! Выжимайте максимум из той единственной машины, которая у вас есть.
короче, у вас есть клиент у которого что-то там написанно на ноде, оно работает в одном процессе и "это боль", клиент хочет "быстро" и не требовательно. Вы ему предлагаете, хотя нет, не предлагаете, вы пока не знаете как, но что-то сделать. Предлагаете вы следующее: в итак "шатко-валко" работающую систему запихнуть еще одно звено, которое потенциально SPOF, в этом звене вы что-то хотите запихнуть в память чтоб оно отдавало быстрее, при том что там GC, ок, в том же звене, которое не особо может "достучаться" до ядра ОС вы хотите принять tcp соединение, "нежно" его передать в совершенно другой процесс и при этом его не разорвать, причем после передачи "схлопнуть" соединение со "звеном", ок
что вам предлагают, теоретически:
* взять проверенное решение для балансировки nginx, т.к. он L7, то позволяет нафигачить логики проксирования чуть более чем достаточно
* поднять n-е количество процессов на node.js
* отдавать данные темже балансировщиком, ну охота вам в пямять что-то засандалить и отдавать оттуда, пихните ее в tmpfs и синкайте когда надо
* 20к онлайна это хорошо, но вот такими решениями "выжать" что-то из железа, хм. О sysctl слышали, вот туда копайте чтоб из железа выжимать, а то оно в "линуксах" под "пылесос" заточено (самый минимум)
* издержки nginx по памяти и скорости на соединение ничтожно малы, о них даже говорить не стоит. "Скорость" на проксировании падает только тогда, когда соединение постоянно нужно открывать (резолвы, хендшейки. теоретически), в случае уже открытого оно вообще "ниочем"
Средний
Средний
