Máximo de conexões Socket.IO simultâneas

123

Esta pergunta foi feita anteriormente, mas não recentemente e não com uma resposta clara.

Usando Socket.io, há um número máximo de conexões simultâneas que alguém pode manter antes de precisar adicionar outro servidor?

Alguém sabe de algum ambiente de produção ativo que está usando websockets (particularmente socket.io) em grande escala? Eu realmente gostaria de saber que tipo de configuração é melhor para conexões máximas.

Como os Websockets são construídos sobre TCP, meu entendimento é que, a menos que as portas sejam compartilhadas entre as conexões, você estará limitado pelo limite de portas de 64K. Mas também vi relatórios de conexões de 512K usando Gretty . Então eu não sei.

websocket socket.io Andrew
fonte
3
O Trello usa soquetes em grande escala (especificamente, socket.io).
James
Eu li que o Trello teve que modificar o código Socket.io devido a um limite de 10.000 conexões e foi capaz de manter 'muitos milhares' de conexões antes de adicionar servidores. Ainda existe um grande abismo entre isso e 512K de outros sistemas de servidor.
Andrew
1
Mas quantos anos tem esse artigo? O Trello atingiu recentemente mais de 1 milhão de usuários ativos por mês, então eu imagino que eles agora estejam executando mais de 10.000 sockets ativos. Trello usa Redis para sentar no topo do socket.io para escalabilidade
James
2
O Trello agora aparentemente tem mais de 4 milhões de usuários, mas com certeza eles estão executando isso em um grande número de servidores, certo? Isso me traz de volta à minha pergunta original: qual é o pico real da contagem de usuários simultâneos por servidor (ou de qualquer outra pessoa)? Também seria bom saber que tipo de servidor / contêiner eles usam. E eles ainda estão executando seu próprio fork ou estão de volta à origem / master? Meu único propósito ao fazer essa pergunta foi tentar avaliar se minha empresa (na época) poderia manter um aplicativo Socket.io para provavelmente 120.000 conexões simultâneas.
Andrew
1
Em relação ao limite de porta, acho que a explicação de por que isso não é um problema é explicada aqui . Basicamente, a única porta usada em seu sistema é aquela na qual você está ouvindo. Os soquetes são criados para cada conexão e usam descritores de arquivo, mas não usam portas em sua caixa.
Paul Lynch

Respostas:

77

Este artigo pode ajudá-lo no processo: http://drewww.github.io/socket.io-benchmarking/

Eu me perguntei a mesma questão, então acabei escrevendo um pequeno teste (usando XHR-polling) para ver quando as conexões começaram a falhar (ou ficar para trás). Eu descobri (no meu caso) que os sockets começaram a funcionar por volta de 1400-1800 conexões simultâneas.

Este é um resumo que fiz, semelhante ao teste que usei: https://gist.github.com/jmyrland/5535279

GELÉIA
fonte
7
Sei que este é um tópico mais antigo, mas primeiro o achei ao pesquisar uma pergunta para minha resposta e, finalmente, descobri que isso é útil: rtcamp.com/tutorials/linux/increase-open-files-limit O limite de arquivos abertos por processo pode o padrão é um limite flexível de 1024 e limite rígido de 4096 e como cada porta TCP aberta representa um arquivo, é importante considerar esses limites ao determinar quantos soquetes abertos uma máquina permitirá antes de tentar maximizar a biblioteca.
DeeperID
2
@JAM Você já descobriu por que seus soquetes da web estavam funcionando em torno de 1400-1800 conexões? Estou tendo o mesmo problema e meus limites de arquivo estão definidos para 100.000, então sei que esse não é o problema. Qualquer ajuda seria muito apreciada. Obrigado.
Seth,
@seth: já faz um tempo desde a última vez que revisei isso, mas acho que esta foi a conclusão: a pesquisa de XHR consumiu muitos recursos (em relação a outros métodos de transporte). Ao usar websockets, o número de conexões simultâneas era maior.
JAM
@JAM obrigado pela resposta. Estou vendo os mesmos problemas ao usar o módulo ws, não o socket.io, portanto, não deve haver nenhuma pesquisa XHR com o módulo ws. É aí que estou tendo problemas para solucionar problemas. A busca continua.
Seth
Esta é uma boa resposta limpa .. Também correta, se for caso a caso .. Pessoalmente, sugiro que o ppl escreva seus próprios benchmarks ou simulador de conexão. Embora um teste para outra pessoa possa ser bom, ele não representa o ambiente do mundo real ... Uma vez que você tem um simulador de cliente capaz de lidar com qualquer número de clientes com várias falhas do mundo real .. Você pode fazer benchmark após grandes mudanças e também atualize seu simulador conforme você avança. Operar uma interface de chat do usuário seria diferente para monitorar o navegador dos usuários e assim por diante .. Python eu achei muito útil para fazer um script de simulador ...
Angry 84
16

Tentei usar o socket.io no AWS, posso no máximo manter cerca de 600 conexões estáveis.

E descobri que é porque socket.io usou long polling primeiro e atualizou para websocket depois.

depois de definir a configuração para usar apenas websocket, posso manter cerca de 9.000 conexões.

Defina esta configuração no lado do cliente:

const socket = require('socket.io-client')
const conn = socket(host, { upgrade: false, transports: ['websocket'] })
Salem Chen
fonte
2
você usou EC2, que tipo de instância? t2.micro, t2.nano?
bvdb
2
Você notou uma diferença na capacidade de resposta ao forçar os websockets?
Lauren
Você sabe o tamanho da sua instância? Além disso, para que qualquer pessoa no futuro saiba que alguns navegadores antigos não suportam WebSockets, é por isso que a atualização pode ser importante para alguns.
Ryan Soderberg
Como podemos testar a quantidade de conexão que o servidor suporta? Como você mediu 9.000 conexões? Por favor, sugira ..
Curious Developer
15

Esse cara parece ter conseguido ter mais de 1 milhão de conexões simultâneas em um único servidor Node.js.

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

Não está claro para mim exatamente quantas portas ele estava usando.

Daniel Nalbach
fonte
13
Acho que nem com socket.io e nem com websockets. O cara parecia estar usando pesquisas longas, que eu acho que tem menos fome de recursos.
Tim 333 de
6

Para + 300k conexão simultânea:

Defina essas variáveis ​​em /etc/sysctl.conf:

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

Além disso, altere essas variáveis ​​em /etc/security/limits.conf:

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

E, finalmente, aumente os buffers de TCP /etc/sysctl.conftambém:

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

para obter mais informações, consulte https://www.linangran.com/?p=547

MajidJafari
fonte
como verificar se nossas mudanças estão funcionando?
Curious Developer