Numero massimo di connessioni Socket.IO simultanee


123

Questa domanda è stata posta in precedenza ma non di recente e non con una risposta chiara.

Utilizzando Socket.io, esiste un numero massimo di connessioni simultanee che si possono mantenere prima di dover aggiungere un altro server?

Qualcuno sa di ambienti di produzione attivi che utilizzano websocket (in particolare socket.io) su vasta scala? Mi piacerebbe davvero sapere quale tipo di configurazione è migliore per le connessioni massime?

Poiché i Websocket sono costruiti su TCP, la mia comprensione è che, a meno che le porte non siano condivise tra le connessioni, sarai vincolato dal limite di 64K. Ma ho anche visto rapporti di 512K connessioni usando Gretty . Quindi non lo so.


3
Trello utilizza prese su vasta scala (in particolare socket.io).
James

Ho letto che Trello ha dovuto modificare il codice Socket.io a causa di un limite di 10.000 connessioni ed è stato in grado di mantenere "molte migliaia" di connessioni prima di aggiungere server. Ancora un enorme divario tra quello e 512K di altri sistemi server.
Andrew

1
Quanti anni ha quell'articolo però? Trello ha recentemente raggiunto oltre 1 milione di utenti attivi al mese, quindi immagino che ora stiano eseguendo più di 10.000 socket attivi. Trello usa Redis per sedersi su socket.io per la scalabilità
James

2
Trello ora ha apparentemente oltre 4 milioni di utenti, ma sicuramente lo stanno eseguendo su un gran numero di server, giusto? Questo mi riporta alla mia domanda originale: qual è il loro numero di utenti simultanei di picco (o di chiunque altro) per server? Sarebbe anche utile sapere che tipo di server / container usano. E stanno ancora eseguendo il proprio fork o sono tornati all'origine / master? Il mio unico scopo nel porre questa domanda era cercare di valutare se la mia azienda (all'epoca) poteva permettersi di mantenere un'applicazione Socket.io probabilmente per 120.000 connessioni simultanee.
Andrew

1
Per quanto riguarda il limite di porta, penso che la spiegazione del perché questo non è un problema sia spiegata qui . Fondamentalmente, l'unica porta utilizzata sul tuo sistema è quella su cui stai ascoltando. I socket vengono creati per ogni connessione e quelli usano descrittori di file, ma non usano le porte sulla tua macchina.
Paul Lynch

Risposte:


77

Questo articolo potrebbe aiutarti lungo il percorso: http://drewww.github.io/socket.io-benchmarking/

Mi sono posto la stessa domanda, quindi ho finito per scrivere un piccolo test (usando il polling XHR) per vedere quando le connessioni hanno iniziato a fallire (o rimanere indietro). Ho scoperto (nel mio caso) che i socket hanno iniziato a funzionare intorno alle 1400-1800 connessioni simultanee.

Questo è un breve riassunto che ho fatto, simile al test che ho usato: https://gist.github.com/jmyrland/5535279


7
Mi rendo conto che questo è un argomento più vecchio ma l'ho trovato per primo durante la ricerca di una domanda alla mia risposta e alla fine ho scoperto che questo è utile: rtcamp.com/tutorials/linux/increase-open-files-limit Il limite di file aperti per processo può il valore predefinito è un limite flessibile di 1024 e un limite rigido di 4096 e poiché ogni porta TCP aperta rappresenta un file, è importante considerare questi limiti quando si determina il numero di socket aperti consentiti da una macchina prima di provare a massimizzare la libreria.
DeeperID

2
@JAM Hai mai scoperto perché i tuoi socket web agivano intorno alle 1400-1800 connessioni? Sto riscontrando lo stesso problema e il limite dei miei file è impostato su 100.000, quindi so che non è questo il problema. Qualsiasi aiuto sarebbe molto apprezzato. Grazie.
Seth

@seth: è passato un po 'di tempo dall'ultima volta che l'ho esaminato, ma penso che questa sia stata la conclusione: il sondaggio XHR ha assorbito troppe risorse (in relazione ad altri metodi di trasporto). Quando si utilizzano websocket, il numero di connessioni simultanee era più alto.
JAM

@ JAM grazie per la risposta. Sto riscontrando gli stessi problemi utilizzando il modulo ws, non socket.io, quindi non dovrebbe esserci alcun polling XHR con il modulo ws. È qui che ho problemi con la risoluzione dei problemi. La ricerca continua.
Seth

Questa è una buona risposta pulita .. Corretta anche come è caso per caso .. Personalmente suggerisco a ppl di scrivere i propri benchmark o simulatore di connessione. Anche se un test per qualcun altro potrebbe essere buono, non rappresenta l'ambiente del mondo reale ... Una volta che hai un simulatore di client in grado di gestire un numero qualsiasi di client con vari errori del mondo reale .. Puoi fare un benchmark dopo grandi cambiamenti e anche aggiorna il tuo simulatore mentre procedi. Il funzionamento di un'interfaccia di chat utente sarebbe diverso per monitorare il browser degli utenti e così via .. Python ho trovato molto utile per creare script per un simulatore ...
Arrabbiato 84

16

Ho provato ad utilizzare socket.io su AWS, posso mantenere stabili al massimo circa 600 connessioni.

E ho scoperto che è perché socket.io ha utilizzato prima il polling lungo e successivamente è stato aggiornato a websocket.

dopo aver impostato la configurazione per utilizzare solo websocket, posso mantenere circa 9000 connessioni.

Imposta questa configurazione sul lato client:

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

2
hai usato EC2, che tipo di istanza? t2.micro, t2.nano?
bvdb

2
Hai notato una differenza nella reattività quando imposti i websocket?
Lauren

Sai qual era la dimensione della tua istanza? Anche solo così chiunque in futuro saprà che alcuni vecchi browser non supportano WebSocket, motivo per cui l'aggiornamento potrebbe essere importante per alcuni.
Ryan Soderberg,

Come possiamo testare la quantità di connessione supportata dal server? Come hai misurato 9000 connessioni? Si prega di suggerire ..
Curious Developer


6

Per + 300k connessione simultanea:

Imposta queste variabili in /etc/sysctl.conf:

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

Inoltre, modifica queste variabili in /etc/security/limits.conf:

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

E infine, aumenta anche i buffer 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

per ulteriori informazioni, fare riferimento a https://www.linangran.com/?p=547


come verificare se le nostre modifiche stanno funzionando?
Curious Developer
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.