Подтвердить что ты не робот

Производительность сервера Socket.IO и использование полосы пропускания

Я собираюсь разместить небольшой сервер сокетов на локальном компьютере, и я хотел бы знать, какую пропускную способность он будет использовать. В большинстве дней он будет иметь не более 50 клиентов, подключенных сразу, но один или два раза в неделю он может одновременно иметь до 5000 клиентов. Тем не менее, единственные отправленные сообщения будут случайным единственным сообщением для всех подключенных клиентов одновременно без каких-либо дополнительных данных или чего-либо еще.

Повлияет ли сервер на значительное снижение производительности на компьютере, на котором он размещен, или замедляет скорость моего интернета?

Server.js:

var app = require('http').createServer(handler)
   , io = require('socket.io').listen(app)
   , fs = require('fs')

 app.listen(8001);

function handler (req, res) {
fs.readFile(__dirname + '/index.html',
  function (err, data) {
    if (err) {
      res.writeHead(500);
      return res.end('Error loading index.html');
    }

    res.writeHead(200);
    res.end(data);
  });
}

io.sockets.on('connection', function (socket) {
  socket.on('SendDefault', function(data) {
    socket.broadcast.emit('GetDefault');
  });
});

Client.js:

setTimeout( function( ){ 
  socket = io.connect('[IP Address]:8001');
  socket.on('GetDefault', function(data) {
    DoStuff( );
  );
} ); }, 10000 );
4b9b3361

Ответ 1

Объем полосы пропускания будет в значительной степени зависеть от объема данных, которые вы собираетесь отправлять с сервера, и количества данных, которые отправит клиент. Использование полосы пропускания также будет зависеть от того, какой транспорт Socket.IO вы используете, и интервала времени вашего приложения.

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

Я сделал некоторые измерения, используя прокси. Вот результаты:

Исходя из клиента: socket.emit(event, args)

  • Если event и args не указаны, на сервер отправляется 12 байт.
  • Если args опущено, но поставляется event, общий размер составляет 22 байта, а длина event.
  • Если указаны args и event, применяются те же правила, но результаты могут меняться в зависимости от типа данных args.

Исходя из сервера: тот же формат, что и у клиента

  • Если event и args не поставляются, на клиент отправляется 8 байт.
  • Если args опущено, но поставляется event, общий размер составляет 17 байтов, а длина event.
  • Если указаны args и event, применяются те же правила, но результаты могут меняться в зависимости от типа данных args.

Сердце от сервера к клиенту: каждые 25 секунд на клиента

  • 5 байт с сервера
  • Ответ клиента на 9 байтов

Handshaking: один раз на клиента

  • 216 байт с сервера
  • 431 байт ответа от клиента
  • 129 байт отслеживаются с сервера

Таким образом, при нагрузке 5000+ клиентов ожидайте не менее 3,7 МБ для установления связи, 3 КБ/с для пульса и не менее 107 КБ полосы пропускания для socket.emit(). Это не точные цифры, так как клиенты могут потерять данные, сбросить соединения, повторно подключиться и т.д.

Наконец, ваша сеть, вероятно, задержит, но главная проблема должна заключаться в количестве параллельных подключений, которые ваша сеть будет обрабатывать. Многие параллельные соединения также могут быть интенсивными в ЦП, поэтому вам следует подумать о кластеризации по всем ядрам. Также имейте в виду количество пульса, которое должен обрабатывать сервер Socket.IO. С 50 одновременными пользователями, что в среднем 2 сердечных удара в секунду. У 5000+ одновременных пользователей, что 200+ сердечных сокращений в секунду, которые, как я полагаю, более интенсивно работают в ЦП, чем интенсивность сети (2,8 КБ/с).

Ответ 2

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

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

(Обратите внимание, что пропускная способность, вероятно, не должна быть проблемой - вообще говоря, если вы отправляете много сообщений через WebSockets или REST, вы будете отправлять меньше данных из-за заголовков, файлов cookie и т.д.)