Size: a a a

NodeUA - JavaScript and Node.js in Ukraine

2020 July 02

VM

Vladimir Mironov in NodeUA - JavaScript and Node.js in Ukraine
Alexander
Это норма для сокетио.
Локально же все ок. И не 4гб же за 20 минут
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Vladimir Mironov
Локально же все ок. И не 4гб же за 20 минут
Да, так и есть в большинстве случаев. Сча постараюсь вспомнить все что я делал для того, чтобы это фиксить
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Вот несколько основных
1) Помнить что библиотека soket.io - ваш враг, врагу нельзя ничего давать, хранить и т.п.
2) Что-то сохраняеть в объект сокета - нельзя. Используйте для этого WeakMap с soket-ом в качестве ключа.
3) Не используйте async в обработчиках ивентов, есть вероятность что сокетио єто не понравится
4) Отключите http транспорт везде.
5) ОТключити perMessageDeflate
источник

VM

Vladimir Mironov in NodeUA - JavaScript and Node.js in Ukraine
Спасибо. В объекте сокета храню некоторые данные и асинхронные функции тоже
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
4 и 5 пункт - гарантированный меморилик
источник

VM

Vladimir Mironov in NodeUA - JavaScript and Node.js in Ukraine
Что такое perMessageDeflate?
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
источник

VM

Vladimir Mironov in NodeUA - JavaScript and Node.js in Ukraine
Оу. Понял, спасибо. Попробую сделать
источник

KZ

Kostya Zgara in NodeUA - JavaScript and Node.js in Ukraine
Alexander
Это норма для сокетио.
Я так понимаю единственная альтернатива socket.io для ноды это библы ws или websocket. А вы случайно никогда не сталкивались как можно масштабироваться с использованием этих библ? Я имею ввиду ситуацию, когда у нас есть несколько экземпляров одного приложения, а перед ними стоит лоадбалансер и неизвестно кому и когда он передаст поступивший реквест. Для socket.io есть redis адаптер, но для библиотек выше я не встречал похожих решений (или плохо гуглил). Я так понимаю надо все реализовывать ручками, но у меня даже нет идей как это можно сделать, возможно у вас уже был похожий опыт?
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Kostya Zgara
Я так понимаю единственная альтернатива socket.io для ноды это библы ws или websocket. А вы случайно никогда не сталкивались как можно масштабироваться с использованием этих библ? Я имею ввиду ситуацию, когда у нас есть несколько экземпляров одного приложения, а перед ними стоит лоадбалансер и неизвестно кому и когда он передаст поступивший реквест. Для socket.io есть redis адаптер, но для библиотек выше я не встречал похожих решений (или плохо гуглил). Я так понимаю надо все реализовывать ручками, но у меня даже нет идей как это можно сделать, возможно у вас уже был похожий опыт?
Адаптер для таких целей не нужен. Это костыль для сокетио. Все что нужно - единый "event source" или "event bus". По сокету пришел некий запрос, вы делаете действие, если результат этого действия должны получить больше чем один то он паблишиться в этот ивентбас и его получают все инстансы.

Реализовывать его можно как сторонней штукой типа редиса, mq, так и например можно использовать месседжинг внутри ноды, если кластер сделан через воркер треды.
источник

KZ

Kostya Zgara in NodeUA - JavaScript and Node.js in Ukraine
Alexander
Адаптер для таких целей не нужен. Это костыль для сокетио. Все что нужно - единый "event source" или "event bus". По сокету пришел некий запрос, вы делаете действие, если результат этого действия должны получить больше чем один то он паблишиться в этот ивентбас и его получают все инстансы.

Реализовывать его можно как сторонней штукой типа редиса, mq, так и например можно использовать месседжинг внутри ноды, если кластер сделан через воркер треды.
окей, а если по сокету пришел запроса от одного клиента и мне нужно взять его инфу (к примеру у менять есть где-то map объектов сокет => пользователь) то мне этот объект нужно тоже хранить где-то в редисе? А если мне нужно будет периодически отвечать этому клиенту с течением работы условного алгоритма? То где мне достать его сокет соединения, если коннекш произошел на другом инстансе?
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Kostya Zgara
окей, а если по сокету пришел запроса от одного клиента и мне нужно взять его инфу (к примеру у менять есть где-то map объектов сокет => пользователь) то мне этот объект нужно тоже хранить где-то в редисе? А если мне нужно будет периодически отвечать этому клиенту с течением работы условного алгоритма? То где мне достать его сокет соединения, если коннекш произошел на другом инстансе?
Сокетов на одного клиента может быть всегда несколько. Все должно происходить через пабсаб. Т.е. клиент пришел и подписался на некий топик типа  client/>client_id>. Вся информация, которая нужна єтому клиенту должна паблишиться в єтот топик.

> объектов сокет => пользовател

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

KZ

Kostya Zgara in NodeUA - JavaScript and Node.js in Ukraine
Alexander
Сокетов на одного клиента может быть всегда несколько. Все должно происходить через пабсаб. Т.е. клиент пришел и подписался на некий топик типа  client/>client_id>. Вся информация, которая нужна єтому клиенту должна паблишиться в єтот топик.

> объектов сокет => пользовател

как угодно, можно хранить на локальном инстансе и подставлять данные на при получении сообщений по подписке, либо хранить в некой базе, не важно какой.
В принципе теперь все более и менее разъясняется. Спасибо! Буду дальше смотреть и думать
источник

KZ

Kostya Zgara in NodeUA - JavaScript and Node.js in Ukraine
Alexander
Сокетов на одного клиента может быть всегда несколько. Все должно происходить через пабсаб. Т.е. клиент пришел и подписался на некий топик типа  client/>client_id>. Вся информация, которая нужна єтому клиенту должна паблишиться в єтот топик.

> объектов сокет => пользовател

как угодно, можно хранить на локальном инстансе и подставлять данные на при получении сообщений по подписке, либо хранить в некой базе, не важно какой.
Правда еще один маленький вопрос. Чтобы клиент имел несколько сокетов, этот клиент сам должен хендлить на своей стороне? То есть условно на html страничке делать несколько new Websocket(), чтобы каждый инстанс хранил сокет этого клиента? Но тогда непонятно как клиент узнает сколько доступно инстансов бекенда к которым можно приконнектиться? Есть у вебсокетов какой-то способ сериализации, чтобы копировать его между всеми свободными инстансами? Или я несовсем правильно понял о чем идет речь, когда говорится об несколько сокетов на одного клиента
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Kostya Zgara
Правда еще один маленький вопрос. Чтобы клиент имел несколько сокетов, этот клиент сам должен хендлить на своей стороне? То есть условно на html страничке делать несколько new Websocket(), чтобы каждый инстанс хранил сокет этого клиента? Но тогда непонятно как клиент узнает сколько доступно инстансов бекенда к которым можно приконнектиться? Есть у вебсокетов какой-то способ сериализации, чтобы копировать его между всеми свободными инстансами? Или я несовсем правильно понял о чем идет речь, когда говорится об несколько сокетов на одного клиента
так по идее должно хватать одного вебсокета на бекенд
источник

RT

Roman Terentev in NodeUA - JavaScript and Node.js in Ukraine
Kostya Zgara
Правда еще один маленький вопрос. Чтобы клиент имел несколько сокетов, этот клиент сам должен хендлить на своей стороне? То есть условно на html страничке делать несколько new Websocket(), чтобы каждый инстанс хранил сокет этого клиента? Но тогда непонятно как клиент узнает сколько доступно инстансов бекенда к которым можно приконнектиться? Есть у вебсокетов какой-то способ сериализации, чтобы копировать его между всеми свободными инстансами? Или я несовсем правильно понял о чем идет речь, когда говорится об несколько сокетов на одного клиента
Здесь больше про клиента как пользователя со своим ID. И этот клиент может с разных девайсов подключаться(или браузеров/вкладок)
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Roman Terentev
Здесь больше про клиента как пользователя со своим ID. И этот клиент может с разных девайсов подключаться(или браузеров/вкладок)
Тут обычно все решается пабсабом. С одного сокета приходит екшн, а ответ на это дело отправляется всем
источник

KZ

Kostya Zgara in NodeUA - JavaScript and Node.js in Ukraine
Alexander
так по идее должно хватать одного вебсокета на бекенд
ну я имел ввиду, что при коннекшине какой-то экземпляр примет сокет соединение и сохранит его в условном WeakMap. Дальше, если мы говорим об event bus, то если этот клиент после коннекшина к одному экземпляру, следом отправит запрос на какой-то экшн, допустим check-plan, то этот запрос может принять другой экземпляр у которого еще нет сокета клиента. Получается нужно создать еще один топик check-plan-reply в который будет паблишиться ивент с ответом на экшн check-plan и каждый экземпляр приложения будет слушать этот ивент и потом будет искать у себя есть ли у них сокет клиента, которому нужно ответить? Такой должен быть флоу?
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Не может. Он установил коннекшн и в другой инстанс сообщение не прийдет
источник

KZ

Kostya Zgara in NodeUA - JavaScript and Node.js in Ukraine
Alexander
Не может. Он установил коннекшн и в другой инстанс сообщение не прийдет
тогда получается это потенциальный мисс реквест? Или не может быть такой ситуации, когда пользователь приконектился к одному экземпляру, но сообщения могут поступать, хоть и не хендлиться, на другой экземпляр? Просто если правильно понимаю как работает лоадбалансер и вебсокеты, то они все работают поверх TCP и любое сообщение через вебсокет пойдет также поверх TCP, но решение на какой экземпляр направить сообщение принимает же лоадбалансер?

P.S. Сорри, если уже пошел флуд, но очень интересная и больная тема для меня)
источник