web-dev-qa-db-fra.com

Performances du serveur Socket.IO et utilisation de la bande passante

Je suis sur le point d'héberger un petit serveur socket sur un ordinateur local et j'aimerais savoir quel type de bande passante il va utiliser. La plupart du temps, il n'aura pas plus de 50 clients connectés en même temps, mais une ou deux fois par semaine, il pourrait avoir jusqu'à 5000+ clients à la fois. Cependant, les seuls messages envoyés seront un message unique occasionnel à tous les clients connectés à la fois sans données supplémentaires ou quoi que ce soit.

Le serveur entraînera-t-il une baisse significative des performances sur l'ordinateur sur lequel il est hébergé ou ralentira-t-il mes vitesses Internet?

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 );
javascriptnode.jsperformancesocket.iobandwidth
24
Joe Boris

La quantité de bande passante dépendra fortement de la quantité de données que vous allez envoyer à partir du serveur et de la quantité de données que le client enverra. L'utilisation de la bande passante dépendra également du transport Socket.IO que vous utilisez et de l'intervalle de pulsation de votre application.

L'impact sur les performances de l'application varie également selon le type d'application que vous exécutez et la capacité de performances de votre machine et/ou réseau. Cependant, plus de 5000 clients auront un impact considérable sur les performances, quelles que soient les capacités de votre ordinateur, sauf si vous faites évoluer l'application sur plusieurs cœurs.

J'ai pris quelques mesures en utilisant un proxy. Voici les résultats:

Emission depuis un client: socket.emit(event, args)

  • Si event et args ne sont pas fournis, 12 octets sont envoyés au serveur.
  • Si args est omis mais event est fourni, la taille totale est de 22 octets et la longueur de event.
  • Si args et event sont fournis, les mêmes règles sont suivies, mais les résultats peuvent varier selon le type de données de args.

Emission depuis le serveur: même format que depuis le client

  • Si event et args ne sont pas fournis, 8 octets sont envoyés au client.
  • Si args est omis mais event est fourni, la taille totale est de 17 octets et la longueur de event.
  • Si args et event sont fournis, les mêmes règles sont suivies, mais les résultats peuvent varier selon le type de données de args.

rythme cardiaque du serveur au client: toutes les 25 secondes par client

  • 5 octets du serveur
  • Réponse du client de 9 octets

Handshaking: une fois par client

  • 216 octets du serveur
  • Réponse de 431 octets du client
  • 129 octets de suivi depuis le serveur

Par conséquent, avec une charge de plus de 5000 clients, attendez au moins 3,7 Mo pour la prise de contact, 3 Ko/s pour les pulsations et au moins 107 Ko de bande passante pour une socket.emit(). Ce ne sont pas des chiffres exacts, car les clients peuvent perdre des données, interrompre les connexions, se reconnecter, etc.

En conclusion, votre réseau résistera probablement, mais la principale préoccupation devrait être la quantité de connexions simultanées que votre réseau devra gérer. De nombreuses connexions simultanées peuvent également être gourmandes en CPU, vous devez donc penser à la mise en cluster entre les cœurs. Gardez également à l'esprit la quantité de pulsations que le serveur Socket.IO devra gérer. Avec 50 utilisateurs simultanés, cela représente en moyenne 2 battements de cœur par seconde. À plus de 5000 utilisateurs simultanés, c'est plus de 200 battements de cœur par seconde, ce qui, j'imagine, est plus gourmand en ressources processeur qu'en réseau (2,8 Ko/s).

60
hexacyanide

Les WebSockets peuvent rester ouverts très longtemps, donc la gestion d'un grand nombre de connexions simultanées signifie généralement que vous devrez étendre ce service pour s'adapter à la charge accrue. C'est la même chose pour presque toutes les technologies, mais il y a généralement une limite au nombre maximal de connexions ouvertes qu'un serveur peut gérer avant que les choses ne dégénèrent rapidement. Si vous êtes susceptible d'avoir de tels pics de trafic, j'envisagerais de rechercher un service tiers comme pousseur ou kaazing (avertissement: je n'ai pas encore essayé .)

Vous avez posé une question assez vague (nous ne savons rien de votre application, de votre architecture, etc. - juste du trafic attendu), mais j'espère que cela vous aidera à vous orienter dans la bonne direction. Cela étant dit ... en fonction de votre cas d'utilisation (diffusion d'un ou deux petits messages, parfois), mon instinct me dit que les WebSockets ne sont pas la bonne technologie pour vous.

(Notez que la bande passante ne devrait probablement pas être un problème - en règle générale, si vous envoyez de nombreux messages via WebSockets vs REST vous enverrez moins de données en raison des en-têtes, des cookies, etc. )

1
Jesse Fulton