Nombre maximal de connexions Socket.IO simultanées

125

Cette question a été posée précédemment mais pas récemment et pas avec une réponse claire.

En utilisant Socket.io, y a-t-il un nombre maximum de connexions simultanées que l'on peut maintenir avant que vous ayez besoin d'ajouter un autre serveur?

Est-ce que quelqu'un connaît des environnements de production actifs qui utilisent des Websockets (en particulier socket.io) à grande échelle? J'aimerais vraiment savoir quel type de configuration est le meilleur pour un maximum de connexions?

Étant donné que les Websockets sont construits sur TCP, je crois comprendre qu'à moins que les ports ne soient partagés entre les connexions, vous serez lié par la limite de port de 64 Ko. Mais j'ai également vu des rapports de connexions 512K utilisant Gretty . Alors je ne sais pas.

websocket socket.io

— Andrew
source

3

Trello utilise des sockets à grande échelle (en particulier, socket.io).

— James

J'ai lu que Trello a dû modifier le code Socket.io en raison d'un plafond de 10 000 connexions et qu'il était capable de maintenir «plusieurs milliers» de connexions avant d'ajouter des serveurs. Encore un énorme fossé entre cela et 512K d'autres systèmes de serveurs.

— Andrew

1

Quel âge a cet article? Trello a récemment atteint plus d'un million d'utilisateurs actifs par mois, donc j'imagine qu'ils utilisent maintenant plus de 10000 sockets actifs. Trello utilise Redis pour s'asseoir au-dessus de socket.io pour l'évolutivité

— James

2

Trello a maintenant apparemment plus de 4 millions d'utilisateurs, mais ils l'exécutent sûrement sur un grand nombre de serveurs, non? Cela me ramène à ma question initiale: quel est leur nombre maximal d'utilisateurs simultanés (ou celui de quelqu'un d'autre) par serveur? Il serait également bon de savoir quel type de serveur / conteneur ils utilisent. Et utilisent-ils toujours leur propre fork, ou sont-ils de retour à l'origine / maître? Mon seul but en posant cette question était d'essayer de déterminer si mon entreprise (à l'époque) pouvait se permettre de maintenir une application Socket.io pour probablement 120 000 connexions simultanées.

— Andrew

1

En ce qui concerne la limite de port, je pense que l'explication de la raison pour laquelle ce n'est pas un problème est expliquée ici . Fondamentalement, le seul port utilisé sur votre système est celui sur lequel vous écoutez. Les sockets sont créés pour chaque connexion, et ceux-ci utilisent des descripteurs de fichiers, mais ils n'utilisent pas de ports sur votre boîte.

— Paul Lynch

78

Cet article peut vous aider en cours de route: http://drewww.github.io/socket.io-benchmarking/

Je me suis posé la même question, alors j'ai fini par écrire un petit test (en utilisant l'interrogation XHR) pour voir quand les connexions ont commencé à échouer (ou à prendre du retard). J'ai trouvé (dans mon cas) que les sockets ont commencé à agir à environ 1400-1800 connexions simultanées.

Voici un bref résumé que j'ai fait, similaire au test que j'ai utilisé: https://gist.github.com/jmyrland/5535279

— CONFITURE
source

7

Je me rends compte que c'est un sujet plus ancien, mais je l'ai trouvé en premier lors de la recherche d'une question à ma réponse et j'ai finalement découvert que c'était utile: rtcamp.com/tutorials/linux/increase-open-files-limit La limite de fichiers ouverts par processus peut par défaut à une limite souple de 1024 et une limite dure de 4096 et puisque chaque port TCP ouvert représente un fichier, il est important de prendre en compte ces limites lors de la détermination du nombre de sockets ouverts qu'une machine autorisera avant d'essayer de maximiser la bibliothèque.

— DeeperID

2

@JAM Avez-vous déjà découvert pourquoi vos sockets Web agissaient entre 1400 et 1800 connexions? J'ai le même problème et mes limites de fichiers sont fixées à 100 000, donc je sais que ce n'est pas le problème. Toute aide serait grandement appréciée. Je vous remercie.

— Seth

@seth: cela fait un moment que je n'ai pas examiné cela pour la dernière fois, mais je pense que c'était la conclusion: le sondage XHR a pris trop de ressources (par rapport aux autres méthodes de transport). Lors de l'utilisation de Websockets, le nombre de connexions simultanées était plus élevé.

— JAM

@JAM merci pour la réponse. Je vois les mêmes problèmes en utilisant le module ws, pas socket.io, donc il ne devrait pas y avoir d'interrogation XHR avec le module ws. C'est là que j'ai des problèmes de dépannage. La recherche continue.

— Seth

C'est une bonne réponse claire .. Aussi correcte car c'est au cas par cas .. Personnellement, je suggère à ppl d'écrire leurs propres benchmarks ou simulateur de connexion. Bien qu'un test pour quelqu'un d'autre puisse être bon, il ne représente pas l'environnement du monde réel ... Une fois que vous avez un simulateur client capable de gérer un nombre illimité de clients avec divers défauts du monde réel .. Vous pouvez effectuer un benchmark après des changements majeurs et aussi mettez à jour votre simulateur au fur et à mesure. L'utilisation d'une interface de chat utilisateur serait différente pour surveiller le navigateur des utilisateurs et ainsi de suite .. Python j'ai trouvé très pratique pour script un simulateur ...

— colère 84

16

J'ai essayé d'utiliser socket.io sur AWS, je peux tout au plus garder environ 600 connexions stables.

Et j'ai découvert que c'était parce que socket.io utilisait d'abord une longue interrogation et était mis à niveau vers websocket plus tard.

après avoir configuré la configuration pour n'utiliser que websocket, je peux conserver environ 9000 connexions.

Définissez cette configuration côté client:

const socket = require('socket.io-client')
const conn = socket(host, { upgrade: false, transports: ['websocket'] })

— Salem Chen
source

2

avez-vous utilisé EC2, quel type d'instance? t2.micro, t2.nano?

— bvdb

2

Avez-vous remarqué une différence de réactivité lorsque vous forcez les websockets?

— Lauren

Savez-vous quelle était la taille de votre instance? Aussi juste pour que tout le monde sache à l'avenir que certains anciens navigateurs ne prennent pas en charge WebSockets, c'est pourquoi la mise à niveau peut être importante pour certains.

— Ryan Soderberg

Comment pouvons-nous tester le niveau de connexion pris en charge par le serveur? Comment avez-vous mesuré 9000 connexions? S'il vous plaît suggérer ..

— Curieux développeur le

15

Ce type semble avoir réussi à avoir plus d'un million de connexions simultanées sur un seul serveur Node.js.

http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/

Cependant, je ne sais pas exactement combien de ports il utilisait.

— Daniel Nalbach
source

13

Pas avec socket.io je pense et même pas avec des websockets. Le gars semblait utiliser de longs sondages qui, je suppose, sont moins gourmands en ressources.

— Tim 333 du

6

Pour une connexion simultanée + 300k:

Définissez ces variables dans /etc/sysctl.conf:

fs.file-max = 10000000 
fs.nr_open = 10000000

Modifiez également ces variables dans /etc/security/limits.conf:

* soft nofile 10000000
* hard nofile 10000000
root soft nofile 10000000
root hard nofile 10000000

Et enfin, augmentez également les tampons TCP /etc/sysctl.conf:

net.ipv4.tcp_mem = 786432 1697152 1945728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216

pour plus d'informations, veuillez consulter https://www.linangran.com/?p=547

— MajidJafari
source

comment vérifier si nos changements fonctionnent?

— Curious Developer

1

Après avoir effectué les configurations, vous pouvez vérifier en écrivant cette commande sur le terminal

sysctl -a | grep file

— Sithcoder
source