Obrigado. Você provavelmente me economizou muitas horas de depuração, tentativa e erro.
Essa diferença de comportamento me levou à conclusão de que se trata de alguma correlação aplicacional derivada de um problema do tipo FrontEnd “travando” o aplicativo (sendo que FrontEnd não é minha área de especialização, ao contrário de BackEnd) e das operações em questão ao postar e as pessoas permanecerem em um tópico aguardando que ele se “atualize sozinho” com dezenas de mensagens em um único minuto.
Para resumir essa megassentença: sua conclusão é que o “sufocamento” de discussões em tempo real rápidas é um problema de front-end?
Não avancei muito em nossa análise, mas observei que a carga da CPU estava longe do máximo, apenas em torno de ~25%. Ao longo dos anos, já atingimos 100% da CPU muitas vezes, mas não foi esse o caso no último incidente, no sábado passado. Tivemos apenas cerca de 150 usuários simultâneos.
O que me levou a suspeitar do back-end foi o fato de termos executado esses chats de jogos por anos e eu nunca ter visto esse “sufocamento” antes. Ao longo dos anos, o banco de dados cresceu e agora temos mais de 800.000 posts.
Quando foi a primeira vez que você viu isso? Poderia ser uma regressão com a última atualização importante? Nosso site e desempenho estavam bem na primavera e não crescemos tanto durante o verão.
O Babel é um plugin espetacularmente ineficiente, então, se você estiver usando o Babel, vai passar por um momento ruim… especialmente sob cargas de muitos usuários ativos simultaneamente.
Temos uma tarefa pendente em nosso backlog agora para melhorar o desempenho em casos onde 1000 pessoas estão visualizando o mesmo tópico e uma pessoa faz uma postagem.
Como projetado hoje, publicamos para todas as 1000 pessoas: “Olá, há uma nova postagem para este tópico” e, em seguida, todas as 1000 vão ao servidor (principalmente ao mesmo tempo) perguntando… “ei, qual é esse novo tópico que você está pedindo?”
Vamos analisar a limitação de taxa mínima de forma mais limpa para que os clientes não sobrecarreguem o servidor, mas há várias otimizações que podemos fazer para esse caso atípico.
Ótimas notícias de que isso está sob sua atenção. Você pode confirmar se isso regrediu desde a primavera passada?
Nossa liga local de hóquei tenta iniciar os jogos em 1º de outubro. Isso significa que nosso site pode gerar picos de tráfego em tempo real semanalmente, caso você precise ou queira estudar o comportamento conforme ele ocorre em um ambiente real (não simulado).
Mande uma mensagem direta se estiver interessado. Estamos felizes em apoiar.
Do ponto de vista de UX, o usuário final deveria de alguma forma saber que a discussão está ativa, mesmo quando o sistema começa a apresentar problemas. Isso pode evitar atualizações desnecessárias do navegador.
O primeiro jogo acabou e definitivamente temos um problema que não tínhamos em março. A razão ainda é desconhecida.
O chat do jogo trava no frontend, enquanto a carga do servidor deveria estar bem abaixo de 100%.
Alguns de nossos usuários notaram várias respostas de servidor 429 durante os travamentos, mas não posso dizer se isso é “normal”, pois nunca fizemos essa análise antes, durante os jogos.
Vi um desses enquanto investigava um totalmente irrelevante ‘500’
O servidor não estava ocupado de forma alguma, mas eu estava mexendo em uma configuração front-end do nginx (http2)
De fato. Houve cerca de 900 respostas reacionárias em um período de algumas horas. @ljpp tem números mais precisos de usuários, mas estamos falando de centenas de usuários navegando no tópico a qualquer momento durante a partida.
Estranhamente, isso não afeta todos os usuários. Eu, por exemplo, não encontrei nenhum problema em nenhum dispositivo. Mas, de acordo com os relatos, o problema é de larga escala.
Não é tão óbvio perceber, especialmente se você não estiver prestando muita atenção.
Primeiro, há uma pausa de 30 a 60 segundos sem respostas. Nada parece “errado”, apenas fica silencioso. Você pode até mesmo escrever sua própria postagem. Então, de repente, você recebe dezenas de mensagens em um instante e percebe que ficou para trás. Já vi isso no iOS Safari e no Android Chrome.
Nossos chats de jogos em tempo real estão movimentados, mas não em casos extremos. Ontem, tivemos 972 mensagens ao longo de cerca de 3 horas.
O próximo chat de jogo ocorrerá hoje às 14:00 UTC. Devido à pandemia, espero números semelhantes, mesmo sendo um jogo em casa.
Você não está tentando impor um caso de uso de chat em uma plataforma de fórum?
Por que não integrar um serviço de chat como Mattermost ou Discord à interface do seu site Discourse e usar esse meio para discussões durante o jogo?
Você poderia encontrar outra forma de abordar o jogo em um tópico do fórum, como discussões antes ou depois do jogo, onde a carga de uso pode ser menos exigente, mas talvez contenha informações de resumo úteis que muitos usuários possam querer consultar em uma data posterior.
Também não vejo benefício em armazenar um grande volume de conversas espontâneas em um fórum. Alguém vai reler isso? É útil?
Bem, ele usa a palavra ‘chat’ para isso, mas a configuração Discourse dele não consegue lidar com ‘972 posts ao longo de ~3 horas’ em um tópico, segundo o usuário… Na minha opinião, deveria conseguir; até mesmo um phpBB simples consegue lidar com várias vezes mais posts em 3 horas do que isso.
Então, 1 post a cada 10 segundos? Por si só, isso não parece irracional. Mas aí você faz o tópico ter 1000 posts e tem várias centenas de usuários participando, além disso, você tem picos de postagens. Consigo ver o desafio!
Mas qual é realmente o culpado/gargalo aqui? O número de usuários participando, a taxa de 1 post a cada 10 segundos, a renderização do conteúdo alterado para (demasiados) usuários anônimos/não anônimos ou o número de conexões necessárias para atender a muitos usuários logados?
Ele terá o mesmo problema se apenas 2 usuários produzirem a mesma quantidade de posts em um tópico no mesmo intervalo de tempo?
Mesmo com apenas 972 usuários logados fazendo apenas um post naquele tópico, o Discourse não seria capaz de lidar com isso? E, se não, por quê? O Discourse é apenas a escolha certa para comunidades muito pequenas com um baixo número de usuários logados simultâneos?
Estou apenas curioso, pois já chegamos a ter até 400 usuários logados simultaneamente às vezes, produzindo até 3000 posts por dia… até agora, sem problemas.
Você claramente precisa levar em consideração as especificações do servidor e o número de unicórnios em execução, caso contrário, os resultados desse cenário de estresse têm menos significado.
Acredito que o Blenderartists (@bartv) tenha um servidor de 64 GB e cerca de uma dúzia de unicórnios em execução? Um monstro
Com certeza, atualmente estamos rodando com 8 GB de RAM e 4 vCPUs na DigitalOcean e não temos tido nenhum problema no momento. Então, se a solução for simplesmente aumentar os recursos (RAM e CPU), estou de acordo. No pico desde o relançamento com o Discourse, tivemos cerca de 2000 visitantes simultâneos em um post que viralizou, e a carga ficou logo acima de 1, com a CPU em 60-70%. Com uma média de aproximadamente 200-250 usuários simultâneos logados, a CPU está ociosa em torno de 15%-20% atualmente.
Você poderia fazer esse argumento, mas eu realmente não gosto da ideia de fragmentar as conversas em duas plataformas. A capacidade de resposta em tempo real é, na verdade, uma das principais vantagens do Discourse, que os usuários finais valorizam. Nossas conversas durante o tempo de jogo são um grande sucesso e uma parte importante da cultura da comunidade.
Note que temos executado isso há quatro anos e este é um problema novo que estamos enfrentando. Então, centenas de jogos ocorreram sem problemas, sem “forçar” nada.
Um de nossos membros mais experientes teve uma teoria — será que estamos atingindo os limites globais do Discourse e talvez o CloudFlare esteja tendo algum impacto.
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: número de solicitações por IP por minuto (o padrão é 200)
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: número de solicitações por IP a cada 10 segundos (o padrão é 50)
O próximo jogo será em 1 hora e vamos testar isso com o cache do CF desativado.
Note que também estamos usando o CloudFlare há 4 anos, mesmo não sendo geralmente recomendado aqui. Houve apenas um ou dois problemas ao longo do caminho, sendo o Brotli um deles e o modelo desatualizado outro.
