Сколько событий может обработать socket.io?

1

Я пытался Socket.io (сервер и клиент) для моего личного проекта. Так как это моя первая попытка с node.js, даже javascript и mongodb, я немного озадачен производительностью моего сервера.

Я создал сложную систему реального времени со множеством событий и множеством комнат. У сервера очень ограниченные события, но у клиентов слишком много событий. Эти события распределяются по комнатам.

Например -

  • Комната R1 >> Событие R1E1, Событие R1E2, Событие R1E3.... Событие R1EN

  • Комната R2 >> Событие R2E1, Событие R2E2, Событие R2E3.... Событие R2EN

Все данные хранятся в mongodb. Работает потрясающе.

Но проблема возникает, когда несколько клиентов (5-8) с 10-15 зарегистрированными событиями начинают отправку данных. Сервер изначально работает нормально, но через пару минут перестает отвечать. Клиенты остаются на связи, даже если сервер не отвечает. Запросы накапливаются. Когда-нибудь сервер получит последний сеанс запроса.

Все начинается, когда конечное устройство начинает регистрировать события. Итак, я хочу знать, сколько событий может обработать socket.io?

PS Вот что я думаю "событие" -

io.on('event', function(msg){
    console.log( msg);
});

Редактировать 2

Как я изучал в файле node.js, узел - это, по сути, процесс, который выполняется в одном потоке, если он требует обработки других вещей, он запускает другой узел (асинхронный поток), оставляет новый поток в покое, выполняя его обработку и возвращаясь в основной поток Бег. Если мы хотим обработать некоторые последовательности процесса, мы используем "async/await".

В моем случае я использую async только в одном месте, когда клиент впервые подключается. Здесь я запрашиваю 3 разных коллекции mongodb и возвращаю данные о событии.

Мой сервер в настоящее время работает на MacBook Pro (16 ГБ ОЗУ, четырехъядерный процессор i7 6-го поколения). Он должен обрабатывать как минимум 4-6 параллельных потоков.

Я создал нагрузочный тест, 100000 различных событий распределены по 1000 комнатам с 5 запросов в секунду, запрашивая дБ. Работало нормально. Почти 40% оперативной памяти и 250% процессора было максимально загружено.

Мое соединение с БД является постоянным, что означает, что я подключаюсь к БД, как только сервер запускается, и поддерживаю ссылку на соединение.

Так в чем же проблема?

  • 0
    У меня нет для вас однозначного ответа, но я бы предположил, что узкое место, вероятно, где-то в обработке ваших событий, а не в самом Socket.io. При этом, если вы ожидаете, что ваше приложение будет расти, я бы начал с того, как настроить несколько узлов с помощью socket.io ( socket.io/docs/using-multiple-nodes/… ). Одно это может помочь, поместив обработчики событий в отдельные циклы процесса.
  • 0
    в моем случае тогда сервер и клиенты будут иметь много "redis". Я проверил тесты производительности, это было хорошо, и текущий сценарий имеет небольшую долю этого теста. так технически это должно работать.
Теги:
iot
socket.io

1 ответ

2

Так что я просто хочу знать, сколько событий может обработать socket.io?

Во-первых, неясно, говорите ли вы о том, сколько обработчиков событий может иметь сервер socket.io или вы спрашиваете о том, сколько событий в реальном времени (как в событиях/сек) может обрабатывать сервер socket.io.,

По первому пункту нет закодированного ограничения на количество обработчиков событий, которые может обработать сервер socket.io. Сокет происходит от EventEmitter и использует возможности прослушивателя EventEmitter, чтобы позволить кому-то прослушивать события. Для этой инфраструктуры нет закодированных ограничений, и даже нет практического ограничения, так как это довольно легкая система.

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

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

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

Я также хотел бы знать, если вы создали какой-то круговой цикл сообщений, где clientA испускает msgA на сервер. Сервер получает это сообщение, обрабатывает его и отправляет msgB клиенту A. clientA получает это сообщение, выполняет некоторую обработку, и некоторый побочный эффект этой обработки заставляет его снова отправлять msgA на сервер, и вы можете получить бесконечный цикл обработки сообщений.

Кроме того, комнаты в socket.io не "имеют события" или "получают события", так что часть вашего описания на самом деле не имеет смысла. Вы можете отправить событие на все розетки в комнате. Но это на самом деле просто заставляет сервер перебирать всех членов данной комнаты и отправлять им каждому сообщение по отдельности.

Согласно вашему редактированию, если "событие" это:

io.on('event', function(msg){
    console.log( msg);
});

Затем количество событий, которые ваш сервер может обрабатывать в секунду, зависит от всевозможных переменных конфигурации системы (пропускная способность, производительность процессора, производительность базы данных и т.д.) И от того, сколько обработки вы выполняете для обработки каждого входящего события. Вот список вещей, которые нужно сделать:

  1. Убедитесь, что у вас на сервере нет синхронного ввода-вывода, кроме как во время запуска сервера, так как это мгновенно лишит вас возможности одновременного выполнения большого количества событий "в процессе".
  2. Сделайте код, который обрабатывает каждое событие максимально эффективным. Если вы обращаетесь к базе данных по каждому событию, это, скорее всего, сделает вашу базу данных узким местом.
  3. Разработайте несколько тестов, чтобы выяснить, где находится ваше первое узкое место в обработке.
  4. Улучшите рабочие характеристики этого первого узкого места.
  5. Промойте, затем повторите, пока вы не удалите/не улучшите первые N мест, где вы столкнулись с узким местом.

Имейте в виду, что в одном экземпляре node.js есть только один поток, в котором работает ваш Javascript. Таким образом, если вы хотите иметь возможность обрабатывать 100 сообщений в секунду, вы можете использовать не более 10 мс ЦП для обработки каждого сообщения (1000 мс/сек, деленное на 100 сообщений/сек = 10 мс/сообщение). Вы можете развернуть несколько процессоров, внедрив кластеризацию или запустив несколько процессов для обработки рабочей очереди, если процессор является фактическим узким местом, но вы должны сначала определить это с помощью тестирования.

Поделиться
  • 0
    Я не могу поместить весь код здесь, но я могу объяснить, как это будет работать. Подумайте о сквозной зашифрованной системе, говорящей только по одному каналу (или в комнате). Отдельно дБ, сервер, клиенты работают нормально. Сервер смог обработать 100000 событий, распределенных в 1000 комнатах с 5 запросами в секунду, запрашивая дБ. Потребовалось около 40% оперативной памяти и 250% процессорного времени.
  • 0
    Вопрос обновлен.
Показать ещё 3 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню