“Devido à carga extrema, isso está sendo exibido temporariamente para todos da mesma forma que um usuário deslogado veria.”
Eu administro um site que exibe threads ao vivo durante jogos de basquete e tenho tido problemas com o servidor ficando sobrecarregado e mostrando essa mensagem durante os jogos (período de pico de atividade).
Existe alguma maneira de identificar a melhor forma de resolver o problema? É a velocidade de armazenamento? Memória? CPU? Existe algo que eu possa fazer além de melhorar meu servidor, ou, se eu fizer isso nesses momentos… o que devo melhorar?
Ter menos pessoas usando o fórum? Melhor ainda seria fazê-las espalhar o uso ao longo do tempo, em vez de todas usarem durante o jogo.
Mas nada disso é realmente útil. Já que você sabe quando os jogos acontecem, poderia melhorar seu servidor apenas durante o jogo ou rodar múltiplos servidores durante o jogo atrás de um balanceador de carga.
Você precisa de mais núcleos de CPU e mais rápidos, além de mais RAM, para poder aumentar o número de processos web (Unicorn Workers) e lidar com o pico de tráfego.
É uma área em que @sam está trabalhando ativamente. Parece que versões mais recentes do Discourse regrediram nesse aspecto, em termos de desempenho.
Dito isso, a verdadeira solução é usar uma ferramenta de chat ao vivo se você precisar de interações em tempo real para centenas de pessoas ao mesmo tempo — embora eu continue questionando como e por que o chat é “útil” quando rola tão rápido que ninguém consegue realmente ver nada, como em transmissões do Twitch e do YouTube.
Este tópico aqui descreve o problema bastante bem.
Esta foi a minha experiência em um fórum de futebol durante partidas, antes que os problemas começassem:
Digital Ocean
1 CPU, 1 GB = 30 a 40 usuários em situação de chat
2 CPUs e 2 GB = 70 a 80 usuários em situação de chat
4 CPUs e 8 GB = adequado para 120 usuários e 1000 posts em 2 horas. Não atingimos o limite.
Com Hetzner (site espelhado)
Minha experiência foi:
3 CPUs (chip AMD CPX 21) e 4 GB = com dificuldades para 20 usuários
2 CPUs (Intel) e 8 GB = sem problemas com 20 usuários.
Nunca cheguei a testar com mais usuários.
O ponto principal é melhorar a CPU e a RAM. E TAMBÉM editar o arquivo app.yml.
Adicione mais unicorns aqui e também altere db_shared_buffers.
Para fóruns esportivos, isso se aproxima mais de atualizações em texto ao vivo para partidas. As pessoas não estão tanto conversando (embora isso ocorra em certa medida, especialmente no intervalo), mas sim recebendo comentários em texto ao vivo de outros torcedores.
Muitas pessoas acessam o fórum apenas para ler o texto ao vivo, vendo os pensamentos e opiniões de pessoas-chave sobre os principais eventos da partida. Desde reações engraçadas até análises sérias.
Se você perdeu a partida, as pessoas acessam apenas para ler o comentário evento por evento. É ótimo para quem está no trabalho É mais pessoal e tendencioso do que os comentários em texto de jornais ou canais de TV.
Entendo, é algo que @sam, @eviltrout e eu temos observado de perto .. a situação de “centenas de usuários conectados e navegando no mesmo tópico ao mesmo tempo” tem surgido com bastante frequência recentemente, conforme o Discourse se torna mais popular.
Podemos precisar incentivar um novo modo de comportamento quando isso acontecer; sinais de “pista rápida” provavelmente começarão a aparecer na interface do tópico de alguma forma…
Uma coisa importante a ter em mente aqui é que as implementações de “chat” geralmente transmitem o conteúdo real para os assinantes.
No Discourse, temos um pipeline bastante complexo, o que torna a implementação ingênua complicada e resulta em grandes volumes de tráfego.
O usuário publica uma resposta
Todos os usuários visualizando o tópico descobrem via transmissão que há novo conteúdo
Todos os usuários solicitam o conteúdo da postagem ao servidor (100 visualizadores = 100 solicitações)
Extraímos imagens / otimizamos imagens
Todos os usuários visualizando o tópico descobrem via transmissão que há novo conteúdo
Todos os usuários solicitam o conteúdo da postagem ao servidor (100 visualizadores = 100 solicitações)
(Temos várias otimizações, limites de taxa, tentativas de reenvio e assim por diante, mas essa é a essência)
Todas essas solicitações precisam passar pelo nosso pipeline de segurança para garantir que o usuário tenha permissão para ver a postagem e assim por diante.
Se o conteúdo fosse relativamente curto e pudéssemos de alguma forma descobrir como fazer a segurança de maneira mais leve para a “pista rápida”, poderíamos distribuir as mensagens de chat via transmissão. Isso resultaria em um desempenho significativamente melhor; provavelmente poderíamos atender 10.000 usuários em um único droplet Digital Ocean de baixo custo com 2 GB de RAM com esse design.
A segurança é muito complexa. O cache também é complexo devido a problemas de invalidação de cache.
Portanto, sim, estamos absolutamente pensando nesse problema. Mas, no momento…
Muitos visualizadores logados em um único tópico + muito conteúdo novo em um único tópico = contas de servidor caras.
Para ser honesto, só tenho conhecimento suficiente para ser perigoso. Sou do tipo que aprende jogando (e quebrando). Aprecio totalmente o esforço fantástico em criar essa plataforma. Quando criei meu primeiro fórum há 12 meses, criei 12 versões diferentes Vanilla, MyBB, SMF, Flarum etc. O Discourse foi, de longe, o melhor.
Uma das maiores vantagens é o desenvolvimento ativo. É ótimo ver como vocês ouvem a comunidade e continuam melhorando.
Olá pessoal, meu site parece ter regredido, com o mesmo pacote DO (8gb, 4CPUs), meu site está começando a ter dificuldades com 60-70 usuários postando 1000 posts.
Estou apenas me perguntando duas coisas.
É possível remover a mensagem de carga extrema? Parece alarmar os usuários mais do que ser útil.
Algum progresso no tratamento de um grande número de usuários?
Enquanto isso, vou explorar a modificação de unicórnios e a desativação de plug-ins, etc., para ajudar a liberar recursos.