Com essas configurações, a UX ficou melhor. Sim, houve vários “engarrafamentos” e um monte de erros 429 registrados no inspetor do Chrome. A carga da CPU estava baixa. Mas, por outro lado, era um jogo doméstico relativamente tranquilo (muitos membros ativos estavam no local, sem conversar).
Não consigo indicar exatamente quais parâmetros ajustar, mas, com base na minha experiência bastante subjetiva:
A funcionalidade de código ainda é excessivamente protetora em relação à carga do servidor. Talvez fosse possível permitir um nível de estresse do servidor um pouco maior.
Quando o cliente reduz a frequência, o atraso é muito longo do ponto de vista da UX. O jogo continua e muita coisa pode acontecer em um minuto. O chat fica dessincronizado, com pessoas se referindo a eventos diferentes do jogo. (Isso agrava o problema dos diferentes atrasos entre tempo real, TV a cabo, IPTV e o buffer de 20 segundos do Chromecast, etc.)
O usuário só percebe que o chat travou, mas não recebe nenhuma indicação de que o site ainda está online e ativo. Isso o leva a atualizar a página ou fazer outras ações que aumentam ainda mais a carga.
Apenas para descartar possibilidades, atualizei o servidor para 8 vCores e 32 GB de RAM. Configurei os buffers do banco de dados para 16 GB e os Unicorns para 16. As demais otimizações foram redefinidas para os padrões.
Infelizmente, a atualização não surtiu grande efeito. Discussões rápidas estão congelando constantemente, mesmo com atividade mediana.
O desempenho está miserável atualmente. Acho que preciso começar a analisar ferramentas como o Prometheus etc. Tenho 95% de certeza de que o desempenho do software regrediu seriamente desde a versão 2.3.
O comentário do irmão @Iceman foi amplamente negligenciado em setembro. Ele relata que os travamentos ocorrem independentemente do hardware que ele está utilizando?
Suspeito que você possa estar enfrentando um gargalo no Redis, mas, como já disse várias vezes, só podemos ter certeza se você coletar essas estatísticas. Sem isso, é como usar astrologia.
Se minha suspeita estiver correta, isso também explicará por que adicionar mais núcleos lentos e RAM ao problema não faz diferença, já que o Redis é single-thread; você só conseguiria escalar usando núcleos de alto desempenho.
Lançaremos uma nova imagem com o lançamento final da versão 2.6 até o final do mês, que virá com o Redis 6 e novas variáveis no app.yml para aproveitá-las. Me avise se quiser testar isso antes; posso te dar instruções para isso.
Mais uma vez, não temos nenhum cliente relatando esse comportamento (de milhares, e muitos muito mais ativos do que seu site), então qualquer discussão adicional neste momento é basicamente inútil — não temos visibilidade sobre qualquer situação de configuração estranha ou problema de desempenho de hardware que você possa ter aí.
No futuro, esperamos que isso mude e que tenhamos melhor visibilidade do problema real.
Então, se o Redis é o gargalo, como você escalaria horizontalmente?
Ainda me intriga o que mudou desde a última temporada. Não consigo ver muito crescimento orgânico ou aumento na popularidade do chat do jogo. Mesmo assim, nossa capacidade de atendimento reduziu drasticamente e está sufocando até mesmo nos jogos mais tranquilos.
Até que você possa coletar métricas na sua instância histórica do Discourse e depois compará-las com as métricas coletadas na sua instalação atual, mantendo exatamente o mesmo hardware, isso continuará sendo um mistério.
A diferença inteira poderia ser que seu provedor de VPS o moveu de uma máquina física para outra, ou que você adquiriu um vizinho barulhento, ou que seu VPS agora está executando uma média de 17 serviços hospedados em conjunto por máquina, em vez de 13.
Por favor, não especule sobre levar o problema ao provedor de VPS. A UpCloud é uma das melhores do mercado, e eles já verificaram o lado deles para qualquer coisa fora do comum. Eles anunciam em nosso site, e não seria muito boa publicidade ter o site apresentando falhas
Mas não há dados históricos e, para ser sincero, eu não estava prestando tanta atenção assim, já que tudo funcionava perfeitamente até que os primeiros jogos de exibição ocorressem em agosto. Claro, os padrões de comportamento das pessoas mudaram graças à COVID, e quem sabe mais o quê. No entanto, não consigo ver isso nas métricas do nosso site ou servidor.
Mas isso é material de teste excelente. Acabei de fornecer ao @riking alguns prints do que acontece quando a sobrecarga do servidor começa. Acho que vocês não veem isso com tanta frequência.
Note que ninguém está discordando de você — estamos apenas destacando que um médico só pode fazer o possível para diagnosticar um paciente quando está limitado a vê-lo por meio de uma câmera de vídeo na internet.
Apenas queria dizer que foi exatamente assim que eu experimentei quando configurei meu site pela primeira vez (então não é algo exclusivo do seu site).
Aqui está um tópico que criei sobre isso na época:
Foi isso que me fez pular para diferentes opções de CPU/Memória descritas aqui:
Infelizmente, ainda não tive a chance de trocar adequadamente para a Hetzner a partir da Digital Ocean como descrevi (comecei um novo emprego). Mas farei assim que tiver oportunidade este mês.
A experiência do usuário final de ser expulso do tópico ou permanecer no tópico (com a mensagem de desconectado) parecia depender da carga. (mais usuários foram enviados para o índice do site após um gol marcado)
Não tenho conhecimento técnico suficiente para ser útil, mas achei que poderia ajudar saber que um site esportivo com picos de comportamento de chat semelhantes também leva a um problema similar. Mas o meu (site menor e mais novo) foi resolvido com uma nova atualização do servidor.
Instalado um novo ambiente de 2 containers em 2 servidores VPS (web_only, data).
Surpreendentemente (para mim), o servidor web_only está esgotando recursos, enquanto o data está relativamente pouco carregado. Ambos executando um plano UpCloud.com de 4x vCore e 8GB de RAM.
Atualizado o web_only para um plano UpCloud.com de 6x vCore / 16GB de RAM. Aumentado o número de Unicorns para 18.
Ainda assim, estamos atingindo vários limitadores 429. O modo system under high load não foi acionado, no entanto.
A temporada de hóquei foi arruinada pela COVID, e agora estão jogando algumas partidas aleatórias sem público. Como temos créditos de hospedagem com a UpCloud.com, estamos nos esforçando para melhorar a experiência com o que temos. No momento, estamos executando 6x vCore 16GB para web_only e 4x vCore 8GB para data, unicórnios no nível 18.
Mais uma vez, desativamos o limitador de taxa…
DISCOURSE_MAX_REQS_PER_IP_MODE: none
…o que ajuda, mas ainda recebemos erros 429 das POLLs, que causam longos atrasos/travamentos para o usuário final. Vamos continuar ajustando aumentando o DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS.
Mas antes de fazermos isso, uma pergunta para @sam / equipe:
Talvez seja, mas gostaríamos de ser um pouco menos protetores com o servidor, pois os picos de atividade naturais são muito curtos e geralmente se estabilizam em cerca de um minuto. Portanto, ajustar os limiares um pouco mais para cima pode melhorar a experiência do usuário enquanto aguardamos a mudança.
Os jogos têm sido escassos (graças à COVID), então tivemos muito poucas oportunidades de medir e fazer ajustes nisso.
Descobrimos que, mesmo com nossos recursos de hardware aprimorados (6+4 vCores e 16+8 GB de RAM), até uma plateia moderadamente ativa consegue gerar 429 erros de congelamento no cliente. Vimos isso nos jogos da U20 WC, que atraíram cerca de ~50% do nosso público habitual de jogos para os chats.
Após medições, testes e erros, chegamos às seguintes configurações:
Isso parece eliminar 80% dos erros 429, permitindo uma experiência relativamente suave para a maioria dos usuários.
O próximo passo teria sido adquirir recursos de hardware diferentes, seja usando servidores dedicados para velocidade de thread única ou migrando para um provedor de VPS que ofereça planos com gazzillion vCores. No entanto, para nós, o próximo passo é trabalhar com a equipe de hospedagem do Discourse, como @sam sugeriu anteriormente.
Esperamos que esses ajustes sejam úteis para @iceman, @alec ou qualquer outra pessoa. Fique atento ao uso da CPU e às filas. Além disso, o que aprendi com essa experiência é que 2 containers são muito melhores do que um — os ajustes podem ser aplicados com tempo de inatividade quase nulo e os recursos de hardware podem ser explorados de forma mais granular.
Ainda estou interessado em quaisquer novos ajustes ou descobertas que possam ajudar a melhorar o desempenho e a experiência do usuário em discussões dinâmicas impulsionadas por eventos do mundo real.
