Ребят, такой вот вопрос. Проект вырос немного. Появились первые проблемы связанные с нехваткой опыта. Сейчас есть главная проблема. Проект на nodejs начинает отжирать одно ядро в 100% до тех пор пока forever его не перезапустит. Все бы ничего. Но юзеров выкидывает из socket соедениения, что не есть хорошо. Вопрос в том, как грамотно заставить nodejs распредеить нагрузку на разные ядра?

cluster ?

Ребят, такой вот вопрос. Проект вырос немного. Появились первые проблемы связанные с нехваткой опыта. Сейчас есть главная проблема. Проект на nodejs начинает отжирать одно ядро в 100% до тех пор пока forever его не перезапустит. Все бы ничего. Но юзеров выкидывает из socket соедениения, что не есть хорошо. Вопрос в том, как грамотно заставить nodejs распредеить нагрузку на разные ядра?

А почему просто не балансировать? Ну и ты же примерно понимаешь тип работ

Я видел. Много читал за него. Но решил перед этим спросить еще и людей. Чтобы не напоротся.

cluster ?

Ответил выше)

Вообще правильный подход начать дробить на то что есть фронт ноды принимающие задачи, а сзади там расширяется очередь задач над которыми трудятся воркеры

Ребят, такой вот вопрос. Проект вырос немного. Появились первые проблемы связанные с нехваткой опыта. Сейчас есть главная проблема. Проект на nodejs начинает отжирать одно ядро в 100% до тех пор пока forever его не перезапустит. Все бы ничего. Но юзеров выкидывает из socket соедениения, что не есть хорошо. Вопрос в том, как грамотно заставить nodejs распредеить нагрузку на разные ядра?

Оно само по себе проц отжирает или под нагрузкой?

Под нагрузкой.

Тогда кластер, да.

Ну или любое другое разбиение

Само по себе не жрет. Держится в пределах пары процентов. А когда людей становится больше - получается шляпа. Сейчас уже вынесли самую нагруженную чать проекта, которая топила на сеть. Проблемы вроде как нету. Но то что nodejs крутится на одном ядре - немного напрягает. Ибо проекту есть еще куда расти. И не охота чтобы так и было.

Само по себе не жрет. Держится в пределах пары процентов. А когда людей становится больше - получается шляпа. Сейчас уже вынесли самую нагруженную чать проекта, которая топила на сеть. Проблемы вроде как нету. Но то что nodejs крутится на одном ядре - немного напрягает. Ибо проекту есть еще куда расти. И не охота чтобы так и было.

а так у тебя даже вообще 1 ядро используется? (

Само по себе не жрет. Держится в пределах пары процентов. А когда людей становится больше - получается шляпа. Сейчас уже вынесли самую нагруженную чать проекта, которая топила на сеть. Проблемы вроде как нету. Но то что nodejs крутится на одном ядре - немного напрягает. Ибо проекту есть еще куда расти. И не охота чтобы так и было.

У тебя там Socket.io?

У тебя там Socket.io?

Да.

добавь cluster у себя на компе и проведи нагрузочное, потом в прод.

Да.

В cluster его не пихай, ему нельзя. Только на отдельные порты и сзади синхронизацию через redis.

Ему требуется sticky session, а cluster такого не умеет.

У тебя там Socket.io?

У меня там шляпа была, ибо надо было реализовать видеостримнг на  ios устройства с браузера с задержкой в пару сек(2-3). Из-за этого ложилась сеть немного. Это вынесли как отдельный сервер и переписал. Ибо писал изначально по топорному.

Если обычный http, то cluster заводи через pm2.

Там почти вся логика юзает socket.io

http там пара точек вхождения. Но они не вызывают проблем.

Просто каждый запрос socket.io в рамках одной сессии должен идти на один и тот же процесс. В cluster такого не сделаешь, так что только на отдельные порты.

https://socket.io/docs/using-multiple-nodes/

Ок. Это я понял. Т.е. мне надо сделать socket.io. на разных портах. Можно такое сделать с mongo вместо редис?

https://socket.io/docs/using-multiple-nodes/

Оно будет на разных ядрах типо работать?

А, нет, есть какая-то фигня для sticky session, раньше не видел.

Тупо поднимаешь несколько процессов NodeJS, они автоматом начинают использовать разные ядра.

И еще вопрос. У меня сейчас отдельно крутится видео-стриминговый сервер. Его можно в cluster? Там видео по webSokcet заливается на сервер. Но сокеты между собою никак не взаимодействуют.

Но из-за того, что у socket.io есть функционал типа "отправить сообщение всем клиентам", ему нужна MQ для взаимодействия между нодами.

Тупо поднимаешь несколько процессов NodeJS, они автоматом начинают использовать разные ядра.

Выходит по сути мне надо запустить проект на разных портах? И добавить синхронизацию socket.io

Но из-за того, что у socket.io есть функционал типа "отправить сообщение всем клиентам", ему нужна MQ для взаимодействия между нодами.

Отправить всем - такого точно нету. Но отправить сокету, который вероятно на другой ноде - это да

https://socket.io/docs/using-multiple-nodes/#passing-events-between-nodes

Ну в общем суть я правильно уловил?Выходит по сути мне надо запустить проект на разных портах? И добавить синхронизацию socket.io

Угу.

а впереди sticky balancer поставить

Да, это тоже важный момент.

Если nginx, то там sticky немного кривой в community версии, насколько я помню. Можно юзать IP hash.

А что там не так?

Он немного туповат. В n+ больше возможностей для балансировки. Посмотри на сайте плюсовой версии.

Но для начала - вполне решение.

Мне б скорее живые отзывы

Я обычную пока пользую и пока всё окей. Скоро на толпе гоблинов будет проверяться, вот и посмотрю. Обычная раскидывает почти 50 на 50 по IP, если два инстанса бека. Что уже неплохо.

haproxy наше все

хотя начина.ю смотреть в сторону traefik

я caddy юзать стал

Если nginx, то там sticky немного кривой в community версии, насколько я помню. Можно юзать IP hash.

чего там кривого?

хотя начина.ю смотреть в сторону traefik

самый слабый из альтернатив, смотри лучше на gobetween или caddy

чем лучше?

Он немного туповат. В n+ больше возможностей для балансировки. Посмотри на сайте плюсовой версии.

как там балансировка если ws это tcp-соединение?

чем лучше?

стандартные батарейки, возможности расширения, документация

как там балансировка если ws это tcp-соединение?

Как? Или, может, какая? Не понял вопроса.

Как? Или, может, какая? Не понял вопроса.

какая? она там не нужна просто, вся синхронизация это логика приложения

какая? она там не нужна просто, вся синхронизация это логика приложения

Речь про sticky же.

sticky это разные tcp-соединения

для того и нужен ip-hash

Всем больше спасибо. Будем смотреть в сторону масштабирования socket.io

sticky это разные tcp-соединения

Вот и надо все соединения одного юзера прокидывать в один и тот же инстанс ноды.

Вот и надо все соединения одного юзера прокидывать в один и тот же инстанс ноды.

а что ты будешь делать если у тебя прилипнут неравномерно?

какая тебе разница куда пришел клиент снова после закрытия сессии?

а что ты будешь делать если у тебя прилипнут неравномерно?

Неравномерно относительно кол-ва инстансов? Об этом я и писал, что в обычной версии туповатый (простой) механизм.

Неравномерно относительно кол-ва инстансов? Об этом я и писал, что в обычной версии туповатый (простой) механизм.

хаха, да это ты просто уничтожаешь смысл балансировки логикой своей

какая тебе разница куда пришел клиент снова после закрытия сессии?

Мне важно, куда пришёл юзер, если у него несколько соежинений по сокету.

хаха, да это ты просто уничтожаешь смысл балансировки логикой своей

Тут нет логики. sticky - это и есть гвозди. per-user гвозди.

ERROR: S client not available

балансировка для ws - это разброс постоянных соединений по выбранному критерию, там ip-hash неактуален вообще, потому что это постоянное содинение

Тут нет логики. sticky - это и есть гвозди. per-user гвозди.

sticky неактуален для http/2 и ws, только udp и http/1

Мы о разном, похоже. Куда попадёт новое (для стейта приложения) соединение от нового юзера - не важно (как раз балансировка). Куда придёт соединение от уже активного юзера - важно.

Мы о разном, похоже. Куда попадёт новое (для стейта приложения) соединение от нового юзера - не важно (как раз балансировка). Куда придёт соединение от уже активного юзера - важно.

что приходит от уже активного? если он активен значит содинение уже есть

Но от него может быть N соединений (в рамках его сессии). Да, это тоже можно раскидать по разным нодам, но мне проще все соединения одного держать в одной ноде.

Но от него может быть N соединений (в рамках его сессии). Да, это тоже можно раскидать по разным нодам, но мне проще все соединения одного держать в одной ноде.

это антипаттерн, на один сервис должно быть только одно соединение ws

А что здесь есть сервис? У нас есть сокет-бек и сокет-фронт, грубо.

это антипаттерн, на один сервис должно быть только одно соединение ws

Да ну

А что здесь есть сервис? У нас есть сокет-бек и сокет-фронт, грубо.

зачем несколько соединений от одного клиента? когда хватит одного за глаза

зачем несколько соединений от одного клиента? когда хватит одного за глаза

Давай в реальных примерах. Чатик на сокетах. Две вкладки (таба) с браузере. Сессия та же, сокет-соединения разные.

Давай в реальных примерах. Чатик на сокетах. Две вкладки (таба) с браузере. Сессия та же, сокет-соединения разные.

такое часто бывает?

такое часто бывает?

Почему бы нет?

SPA и вся хуйня, но табы никто не запрещал.

Aleksandr а ты на реакте делаешь фронт?

И ты либо во всех табах даёшь жизнь, либо говоришь юзеру, мол, только одна вкладочка, сорян, экономим серверные ресурсы.

балансировка для ws - это разброс постоянных соединений по выбранному критерию, там ip-hash неактуален вообще, потому что это постоянное содинение

Ты не вник в суть. У человека socket.io

Почему бы нет?

ну ок, разные табы не запретить, кроме этого какие еще варианты нескольких коннектов от одного клиента?

Ты не вник в суть. У человека socket.io

и что? ты про браузеры которые ws не поддерживают?

ну ок, разные табы не запретить, кроме этого какие еще варианты нескольких коннектов от одного клиента?

Мм. Несколько разных сокет-соединений, когда не хватает неймспейсов и "румов" в сокетах? Пока не знаю зачем, но думаю, что есть и такое применение.

Сука, русский язык не мой сегодня) В коде другая раскладка.

и что? ты про браузеры которые ws не поддерживают?

Там сначала хэндшейк идет а потом идет мисматч сессии сокет.ио

Там сначала хэндшейк идет а потом идет мисматч сессии сокет.ио

так это sticky на другой локейшен, он http же

Aleksandr а ты на реакте делаешь фронт?

когда как

Там сначала хэндшейк идет а потом идет мисматч сессии сокет.ио

http -> socket.io/N/?t= (sticky) ws -> socket.io/N/websocket

http -> socket.io/N/?t= (sticky) ws -> socket.io/N/websocket

Но ведь и http и ws одинаково скалируются по нодам. Или ты предлагаешь для ws только один инстанс держать?

Но ведь и http и ws одинаково скалируются по нодам. Или ты предлагаешь для ws только один инстанс держать?

я к тому что ws - это другой локейшен и там поведение другое по идее, там логика и конфигурация в общем случае другая, и там нечего прибивать, там сессия атомарная на уровне tcp, соединение там одно, а прибивать надо согласование коннекта и это http, один на получение "оффера" второй со свитчем протокола

так это sticky на другой локейшен, он http же

Там протокол такой что сначала клиент высылает список доступного транспорта по хттп и получает сессию. Затем если он умеет в ws делает запрос. Второй запрос должен прийти туда же куда и первый

Вот, @klond90 уже ответил за меня.

Там протокол такой что сначала клиент высылает список доступного транспорта по хттп и получает сессию. Затем если он умеет в ws делает запрос. Второй запрос должен прийти туда же куда и первый

скажем так ниже первого, ip-hash (sticky это левый модуль и нужен был когда хэш был платным) тут нужен только чтобы второй запрос http пришел туда же с кем был согласован (хотя это не принципиально при идентичности нод), а вот для ws ip-hash смысла не имеет

скажем так ниже первого, ip-hash (sticky это левый модуль и нужен был когда хэш был платным) тут нужен только чтобы второй запрос http пришел туда же с кем был согласован (хотя это не принципиально при идентичности нод), а вот для ws ip-hash смысла не имеет

Контекст

Контекст

а какой? если ноды одинаковые у тебя? в согласовании есть контекст важный?