Socket.io: Contagem de clientes / sockets conectados

Criado em 14 ago. 2011  ·  53Comentários  ·  Fonte: socketio/socket.io

Oi,

Estou usando io.sockets.clients().length para obter a contagem de todos os clientes conectados no momento, mas depois de algum tempo esse número está muito alto, muitos clientes desconectados ainda estão presentes nesta matriz.

Abaixo, uma imagem de io.sockets.clients().length , plotada a cada 5 minutos por 24 horas. Quando a contagem atingiu mais de ~ 2k, reiniciei o servidor, cerca de 200 a 300 clientes reconectados, que é a contagem correta.

Connected Clients

Essa é a maneira errada de obter a contagem de todos os clientes conectados? Também tentei contar as conexões e desconexões manualmente, mas depois de um dia houve mais desconexões do que conexões, a contagem foi negativa.

Relacionado: https://github.com/LearnBoost/socket.io/issues/349

Performance bug

Comentários muito úteis

L2C FAF IT RTFM !!!
░░░░░▄▄▄▄▀▀▀▀▀▀▀▀▄▄▄▄▄▄░░░░░░░░
░░░░░█░░░░▒▒▒▒▒▒▒▒▒▒▒▒░░▀▀▄░░░░
░░░░█░░░▒▒▒▒▒▒░░░░░░░░▒▒▒░░█░░░
░░░█░░░░░░▄██▀▄▄░░░░░▄▄▄░░░░█░░
░▄▀▒▄▄▄▒░█▀▀▀▀▄▄█░░░██▄▄█░░░░█░
█░▒█▒▄░▀▄▄▄▀░░░░░░░░█░░░▒▒▒▒▒░█
█░▒█░█▀▄▄░░░░░█▀░░░░▀▄░░▄▀▀▀▄▒█
░█░▀▄░█▄░█▀▄▄░▀░▀▀░▄▄▀░░░░█░░█░
░░█░░░▀▄▀█▄▄░█▀▀▀▄▄▄▄▀▀█▀██░█░░
░░░█░░░░██░░▀█▄▄▄█▄▄█▄████░█░░░
░░░░█░░░░▀▀▄░█░░░█░█▀██████░█░░
░░░░░▀▄░░░░░▀▀▄▄▄█▄█▄█▄█▄▀░░█░░
░░░░░░░▀▄▄░▒▒▒▒░░░░░░░░░░▒░░░█░
░░░░░░░░░░▀▀▄▄░▒▒▒▒▒▒▒▒▒▒░░░░█░
░░░░░░░░░░░░░░▀▄▄▄▄▄░░░░░░░░█░░
░░░░░░░░░░░░░░░░░░░░▀▀▀▀▀▀▀▀░░░

Todos 53 comentários

+1. Acho que no meu caso este é um último problema que causa problemas de memória (crescendo até falha de segmentação).

Sim, trava cerca de duas vezes por dia com uma falha de segmentação aqui.

está anotado na "documentação":
http://labs.learnboost.com/socket.io/

na seção Socket.IO Node.JS server / Listener (faça uma pesquisa na página por "splice"). Citar:

"Uma matriz de clientes. Importante: os clientes desconectados são definidos como nulos, a matriz não é emendada."

Passar do pensamento para o código para a documentação significa que deve haver algum motivo pelo qual os usuários desconectados não são removidos desse array, simplesmente não consigo adivinhar qual é esse motivo. O melhor cenário é que isso dificulta o acompanhamento dos usuários CONNECTED e, na pior das hipóteses, contribui para a falta de estabilidade em uma implementação de servidor node.js / socket.io.

Marcado como bug de desempenho.

Eu tenho o mesmo problema.

e faço meu número com base em algum var com i +1 durante o evento de conexão e -1 durante a desconexão. (então este não é um problema nulo)

Contagem de usuários:

https://skitch.com/tomekotomek/f4867/dock

CPU:

https://skitch.com/tomekotomek/f489w/dock

MEMÓRIA:

https://skitch.com/tomekotomek/f4eyy/graph.php-747x374

BTW.

é mais do que um problema de desempenho, basta diminuir nosso tempo de atividade para menos de uma semana.

A maneira que descobri como fazer isso foi usar um conjunto Redis de ids de cliente, adicionar o socket.io conectar e remover do conjunto ao desconectar. O comando SCARD fornece o número de clientes conectados e SMEMBERS todos os ids.

sim o array precisa ser limpo ou uma maneira melhor precisa ser encontrada para segurar os clientes.

+1

+1

+1
Isso é definitivamente mais do que apenas uma questão de comprimento de array.
Incrementar e diminuir um contador na conexão / desconexão ainda resultará em um contador sempre crescente.

+1

+1

+1

+1

+1

Alguém já tentou isolar isso dos vários transportes? IE Veja se funciona da mesma forma no
websocket, flashsocket, xhr-polling, etc.

Este é definitivamente um problema importante, pois não podemos deixar o servidor funcionando de forma consistente sem reiniciar. Não consigo passar um dia sem pelo menos uma reinicialização, pois a memória continua a crescer. NOTA: No nó 0.4. * A memória é MUITO MELHOR para mim.

+1

descobri o mesmo problema - minha memória apenas fica cheia. cerca de 1 MB / por minuto

com cerca de 1500 sockets que se reconectam devido a cliques no site havy.

tem que ser reiniciado diariamente por causa do vazamento de memória

L2C FAF IT RTFM !!!
░░░░░▄▄▄▄▀▀▀▀▀▀▀▀▄▄▄▄▄▄░░░░░░░░
░░░░░█░░░░▒▒▒▒▒▒▒▒▒▒▒▒░░▀▀▄░░░░
░░░░█░░░▒▒▒▒▒▒░░░░░░░░▒▒▒░░█░░░
░░░█░░░░░░▄██▀▄▄░░░░░▄▄▄░░░░█░░
░▄▀▒▄▄▄▒░█▀▀▀▀▄▄█░░░██▄▄█░░░░█░
█░▒█▒▄░▀▄▄▄▀░░░░░░░░█░░░▒▒▒▒▒░█
█░▒█░█▀▄▄░░░░░█▀░░░░▀▄░░▄▀▀▀▄▒█
░█░▀▄░█▄░█▀▄▄░▀░▀▀░▄▄▀░░░░█░░█░
░░█░░░▀▄▀█▄▄░█▀▀▀▄▄▄▄▀▀█▀██░█░░
░░░█░░░░██░░▀█▄▄▄█▄▄█▄████░█░░░
░░░░█░░░░▀▀▄░█░░░█░█▀██████░█░░
░░░░░▀▄░░░░░▀▀▄▄▄█▄█▄█▄█▄▀░░█░░
░░░░░░░▀▄▄░▒▒▒▒░░░░░░░░░░▒░░░█░
░░░░░░░░░░▀▀▄▄░▒▒▒▒▒▒▒▒▒▒░░░░█░
░░░░░░░░░░░░░░▀▄▄▄▄▄░░░░░░░░█░░
░░░░░░░░░░░░░░░░░░░░▀▀▀▀▀▀▀▀░░░

Acabei de desligar o lado do servidor de transporte flashsocket e o uso de memória E o uso da CPU é MUITO MELHOR. Alguém mais pode experimentar e ver se ajuda?

+1

Retiro o que disse, CPU ESTÁ MELHOR, mas a memória ainda está vazando lentamente. Presumo que seja porque o servidor de políticas flash foi desligado.

Por favor, pare de aumentar o feed com "+1", isso não é google plus ou facebook ...

cara, eu tenho que fazer isso +1 para isso

há também uma notificação de Desativar para este problema abaixo

No meu caso, socket.manager.closed, socket.manager.handshaken é mais do que socket.manager.open. e eu não sei como limpar as conexões inúteis

EXATAMENTE o mesmo aqui. Temos que reiniciar o servidor várias vezes por dia, porque as conexões consomem cada vez mais memória até que os 4 GB de memória acabem.
Ficarei muito feliz se esse problema for resolvido, porque não posso continuar usando o socket.io se tiver que reiniciar a cada poucas horas. (Temos cerca de 2.000 usuários online ao mesmo tempo, conectando e desconectando)

Estou usando socket.io 0.9.10 e o seguinte código para determinar o número de sockets:

var socketIO = require ('socket.io'). listen (.....
...
var numberOfSockets = Object.keys (socketIO.connected) .length;

Não tenho certeza de quão preciso esse número reage aos vários casos extremos, mas até agora parece exato: cada navegador conectado aumenta o número, cada navegador fechado diminui.

há algo de errado com essa abordagem?

Deixando de lado os problemas de contagem (que podem ser contornados) - os problemas de memória são bastante brutais aqui. Existe alguma esperança de que isso seja corrigido no futuro? Isso significa que as implantações de socket.io de longa duração e alta atividade são muito difíceis de gerenciar.

Como alternativa, alguém conhece os garfos que tenham esse problema corrigido?

O problema está relacionado ao código abaixo (retirado do socket.io 0.9.10):

  SocketNamespace.prototype.clients = function (room) {
    var room = this.name + (room !== undefined ? '/' + room : '');

     if (!this.manager.rooms[room]) {
         return [];
     }

     return this.manager.rooms[room].map(function (id) {
         return this.socket(id);
     }, this);
  };

o método this.socket(id) cria uma nova instância de socket, então usar isso em cada conexão de socket produziria vazamento de memória.

@dknaus forneceu uma solução excelente para isso;)

@outbounder Você pode apontar qual foi essa excelente solução alternativa? Porque tudo o que vejo neste tópico é uma contagem de soquetes ativos

@marksyzm

 Object.keys(socketIO.connected).length;

isso é válido apenas se você tiver armazenamento conectado ao socketio. caso contrário, a única maneira de contornar é contá-los pela lógica personalizada da seguinte forma:

 io.on("connection", function(s){ 
   connectedCount += 1; 
   s.on("disconnect", function(){
     connectedCount -= 1;
   });
 });

@outbounder, mas eu pensei que o objetivo desse bug é corrigir o problema de vazamento de memória com os soquetes não desconectando. Estou esquecendo de algo?

a memória está sangrando de algum lugar, veja

https://github.com/LearnBoost/socket.io/issues/1015

https://github.com/sockjs/sockjs-node/issues/81

https://github.com/joyent/node/issues/2328#issuecomment -3190337

Não tenho certeza se é relacionado a websocket ou nó

sockjs está tendo problemas semelhantes - o que significa que tanto socket.io e sockjs podem usar o mesmo ws lib, que tem um problema com o nó - ou é apenas um problema geral do nó

+1

Isso ainda está acontecendo comigo na produção. Não tenho nem tantos clientes conectados, na verdade - 100-200 no pico. Os processos estão ficando sem memória e interrompidos ou morrendo. Alguém está trabalhando neste vazamento de memória? Como posso ajudar?

Pelo que eu posso dizer, este é um problema conhecido há muito tempo e todos com aspirações de implantações reais saíram do socket.io. Não houve nenhuma mudança neste problema, e o engine.io não parece mexer com os núcleos de transporte, então não há razão para esperar que isso conserte isso também.

Honestamente, estou procurando evidências de que QUALQUER UM implanta vanilla socket.io em produção com um websocket transport ativo e não encontrei nenhum relatório confiável. Trello é um usuário de alto perfil, mas eles admitiram usar algum tipo de versão com patch que não foi lançada e só usa o transporte de websocket (em que ponto, por que usar socket.io afinal?). Mudei o socket.io inteiramente porque não parece que isso vai mudar tão cedo. Não posso prometer que sockjs não tem problemas, mas tenho certeza de que ele não falha tão rapidamente quanto o socket.io falha se você entrar / sair de alguns milhares de clientes.

Eu estava lutando com o que eu acho que é esse problema, no meu próprio aplicativo socket.io/redis, no Nodejitsu. Definitivamente parece que é a loja Redis de socket.io. Vou mudar para o SockJS e escrever meu próprio gerenciamento do Redis, eu acho.

Registros de bate-papo de como trabalhei com ele no canal de suporte #nodejitsu:
https://gist.github.com/4146668

+1

Sou eu ou o socket.io não usa mais o redis?

Que tal adicionar this.store.publish ('desconectar', id); para Manager.prototype.onClientDisconnect
conforme sugerido aqui: https://github.com/LearnBoost/socket.io/issues/831

Haverá algum problema ao adicionar esta linha ?? Eu gosto de saber.

Em segundo lugar?

+1

+1

Qualquer um?

Algum movimento sobre esse assunto? Espero implantar em um futuro próximo e realmente valorizaria qualquer percepção que as pessoas com implantações de produção tenham sobre esse problema.

A correção acima funcionou para nós ... a carga caiu significativamente
Em 4 de junho de 2013 11:01, "patrickod" [email protected] escreveu:

Algum movimento sobre esse assunto? Espero implantar em um futuro próximo e
realmente valorizaria qualquer percepção que as pessoas com implantações de produção
nesse assunto.

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/LearnBoost/socket.io/issues/463#issuecomment -18927408
.

Desativando o suporte para soquete de flash? A documentação diz que isso agora é feito por padrão.

Nunca enfrentei esse problema, mas ainda estou em desenvolvimento e benchmarking. Isso foi resolvido?

Você nos conta. Você está fazendo benchmarking. : D

Em quinta-feira, 23 de janeiro de 2014 às 7h07, Maziyar Panahi [email protected] :

Nunca enfrentei esse problema, mas ainda estou em desenvolvimento e benchmarking.
Isso foi resolvido?

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/LearnBoost/socket.io/issues/463#issuecomment -33126062
.

Você nos conta. Você está fazendo benchmarking. : D

Honestamente, não percebi uma queda grande. Tenho visto poucas conexões caindo após 5 6 minutos quando conecto 1000 usuários ao mesmo tempo, mas eles se reconectam muito rápido e tenho mais de 10K mensagens por segundo para todos os usuários. Portanto, acho que minha instância EC2 (m1.large) não é forte o suficiente para mantê-los vivos sem perder alguns.
Queria saber se vou enfrentar esse problema no futuro. O meu é apenas deixar cair alguns e reconectá-los no teste de estresse. Depois de desligar tudo que posso ver, o número de clientes cai para 0

+1

Eu não tive problemas com tudo isso desde 10.11 ... Eu poderia atribuir isso ao ubuntu 10.10? De qualquer maneira, parece bem agora.

Esta página foi útil?
0 / 5 - 0 avaliações