Достаточно ли просто включить привязку к сеансу, чтобы обеспечить подключение к правильному процессу при использовании кластеров и нескольких динамиков?

#node.js #heroku #socket.io #session-affinity

#node.js #heroku #socket.io #сеанс-аффинити #привязка к сеансу

Вопрос:

Я включил привязку сеанса на Heroku через интерфейс командной строки — достаточно ли этого, чтобы убедиться, что трафик от пользователя попадает в один и тот же процесс (кластеризация с использованием throong) на правильном динамике (несколько динамиков)?

Чтобы было ясно, у меня нет кода для обработки этого. Я просто использую socket io как есть, я не использую липкие сеансы или что-то еще. Все, что я сделал, это включил привязку к сеансу.

Этого достаточно? Как я могу протестировать это локально?

1. Вы получили ответ на этот вопрос? Нужно ли вносить какие-либо изменения в свой код, чтобы это работало?

2. Нет, у меня все еще нет ответа на этот вопрос. Кажется, трудно найти информацию по «продвинутым» проблемам, специфичным для Heroku.

Ответ №1:

Не уверен, что вы когда-либо получали ответ на этот вопрос, но сам обдумывал эту проблему. Однако потенциально может быть достаточно сокета.io вызывает:

«если вы находитесь в ситуации CORS (домен front отличается от домена сервера) и привязка к сеансу достигается с помощью cookie, вам необходимо разрешить учетные данные:»

Источник

Учитывая, что вы используете длительный опрос по умолчанию, а затем порядок подключения ws, я думаю, что сеансы Heroku sticky должны иметь возможность направлять ваш первоначальный запрос на длительный опрос на правильный динамик. Две вещи, которые мне неясны:

Как только запрос на длительный опрос распространяется на назначенный динамик, подключается ли обновление до соединения websocket к тому же динамику?
Учитывая, что автоматическое масштабирование Heroku не учитывает подключения к websocket (источник, поиск по websocket), как бы вы автоматически масштабировали динамические модули для учета трафика?

Под номером 2 это потенциально может работать через время p95 запроса API с длительным опросом, используемое для определения загрузки сервера, но не уверен, увеличится ли задержка API из-за подключений / рабочей нагрузки websocket.

1. Попробовал вышеуказанные шаги: включил «session_affinity» для сервера heroku, передал учетные данные через сокет. ввод-вывод для подтверждения связи CORS и масштабирование до 2 динамиков. Это работает… периодически. Иногда это отлично работает, подключаясь с помощью длительного опроса и обновления до ws-соединения. В других случаях он застревает в цикле опроса dyno 1, затем 2 без обновления соединения ws. Любопытно, решил ли кто-нибудь еще здесь эту проблему?

2. В итоге получилось заставить его работать без привязки к сеансу, указав транспорт только как websocket. При обновлении длинного опроса по умолчанию до поведения websocket нарушалась маршрутизация на один и тот же сервер даже при включенной привязке к сеансу. Пока не наблюдалось снижения производительности при прямом подключении ws.