@LawrenceRUS

Здравствуйте. Есть проект, в котором лайв-события реализованы на ws. По вечерам, когда онлайн вырастает до 5-6 тысяч, эмиты приходят с задержкой в 5-15 секунд, часто вразнобой. При этом ресурсы сервера задействованы на 20-50%, а интернет-канал загружен не более 10%.

Немного цифр:
Активных пользователей: 5500
RPS: 1500
TPS: Почти что 0
Event loop lag: 20-24ms
Если нужны ещё какие-то данные, могу добыть.



Из интересного. У меня часть эмитов отправляется через php - и они работают шустро и вообще без проблем.
А вот эмиты, отправленные напрямую с javascript на сервер node.js - тормозят.

0

@MrOnlineCoder

LawrenceRUS, не силен в масштабировании websocketов, но сколько процессов ноды у вас запущено (т.е. используете ли cluster)?

0

@kidASM

Без кода сложно что-то сказать, но есть несколько нюансов.
1. Приложение на Node.js очень быстрое (самое быстрое для скриптовых языков), но речь идёт о приложение написанном для чистого Node.js. Если используется Node.js + ExpressJs, то такое приложение значительно медленнее чем для чистого Node.js. Со временем ExpressJs стал "толстым" и медленным (хотя в большинстве случаем быстрее конкурентов).
2. Модуль WS не самое быстрое решение для работы с WebSocket'ом. Вот к примеру uWebSockets.
3. При не правильном использовании EventEmitter'a, может забиваться EventLoop, что может тормозить всё приложение.

1

@LawrenceRUS

Нет, не используется. Запущен один скрипт index.js, но в процессах висит 2 процесса (если это важно)
Разве Нода сама не распределяется по ядрам равномерно? К счастью, не использую експресс) Возьму на заметку, спасибо. А можно тут подробнее, что значит "правильно" и "неправильно"? В общих чертах.

0

@LawrenceRUS

Проблема частично решена - выключил запись логов и нагрузка упала, и теперь выдерживается RPS до 2000-2200, после чего начинаются задержки по 3-10 секунд.
Но всё равно, на сколько я понимаю, это не предел возможности вебсокетов.

0

@muxahuk1214

запустите профайлер и нагрузите (имеется ввиду мануально, есть тулы для имитации деательности и т.п.), далее исследуйте логи профайлера и увидите какие функции занимают больше всего времени на выполнение..

Как уже подметили выше, без кода трудно что-то сказать.

нет.

допустим создавать такие условия когда в каждой обработке эвента происходит подписка на какой-то эвент (и потом не чиститься никак), хотя вы сказали что память не ростёт, значит тут чисто вычислительные операции (как запись в логи [тут не вычисление, а работа с файловой системой, что не быстро], так и например парсинг json или любые другие операции которые занимают много время (запись в базу, запросы на другие ресурсы и т.п.)).
см. начало сообщения, что бы понять как это можно найти.

ну и собственно можете (если приложение написано так, что это будет работать) запустить несколько раз вашу аппликацию в режиме форка (балансировки запросов на разные процессы) [pm2 и подобные тулы], это может помочь с производительностью.

0

@LawrenceRUS

Как раз им и запускаю, и как мне кажется, он распределяет нагрузку по ядрам, но тут не уверен.

Я могу покидать код, но точно не знаю, что именно интересно. По сути у меня через php обрабатываются разные конкретные действия пользователя, и потом php отправляет их на Ноду - это работает без проблем, видимо из-за того что таких действий не так много.
Но на js у каждого активного пользователя с интервалом в 2 секунды отправляется один эмит, передающий текущее состояние пользователя (проект это нечто вроде игры). Просто передаёт, без всяких вызовов в БД и прочих операций. И объём данных небольшой: 4-7 интовых значений и 2 текстовые строки длинною в 10-30 символов кириллицы. И вот этот эмит подвисает при высоком числе РПС. Пробовал и его вешать на php, но тогда в миг умер Апач))

Вот это интересно. Не слышал про такую приблуду. Погуглю и применю, спасибо.

0