Acabamos de ter um pico de tráfego de aproximadamente 1.500 usuários concorrentes (na maioria anônimos) acessando uma única página.
O fórum entrou em um modo onde um aviso é exibido a todos os membros sobre a alta carga.
Droplet Digital Ocean otimizado para CPU
CPU dedicada: 4 vCPUs
RAM: 8 GB
Trabalhadores Unicorn: 10
Considerando que apenas cerca de 50% da RAM e da CPU estão sendo utilizadas, aumentaria o número de trabalhadores Unicorn para lidar com esses picos de tráfego de visitantes anônimos ou não?
Aumentei os workers para 24. Sem diferença (ainda aparece a mensagem: “Devido à carga extrema, isso está sendo temporariamente exibido para todos como um usuário deslogado veria.”), com um pico semelhante de visitantes simultâneos (99% anônimos) agora:
@sam Alguma ideia de como otimizar ainda mais para picos de tráfego vindos de usuários anônimos (por exemplo, se um único tópico viralizar nas redes sociais)? Em ambos os casos descritos acima, a memória e a CPU ainda têm bastante folga (de acordo com a Digital Ocean), e nem sequer atingimos uma carga de 4; mesmo assim, o fórum entra no modo de “carga extrema”, apesar de termos triplicado o número de workers.
Acabei de entrar novamente no “modo de carga extrema” com apenas 600 visitantes simultâneos no total (99% anônimos) e uma carga de carga de menos de 1.
Acredito que o monitor de dados da DO não seja sensível o suficiente e seja um tanto enganoso. Fiz testes com carga extrema na Hetzner e na Digital Ocean. Com a Hetzner, quando a mensagem de carga extrema apareceu, houve um pico curto e agudo em que a CPU chegou a 120%.
Isso durou talvez um segundo, antes de cair para a faixa de 40-50%.
Repliquei o mesmo cenário na Digital Ocean e, pelo que me lembro, o uso da CPU nunca ultrapassou 50%. (mas não era possível ajustar o eixo X para o nível de segundos)
Minha suposição é que o nível de CPU da DO seja talvez uma média de 5 ou 15 segundos. Por isso, você não vê os picos curtos e agudos.
Vamos precisar de relatórios do exportador Prometheus para investigar mais a fundo.
Se você tiver RAM e CPU suficientes, sempre pode adicionar mais workers do Unicorn, o que permitirá escalar durante esses picos. Apenas evite usar swap de memória, pois o desempenho cairá drasticamente.
Parece que, nesse caso, a página desse único tópico deveria poder ser armazenada em cache e servida estaticamente por um curto período, sem precisar acessar o back-end. Não faço ideia se o Discourse consegue fazer isso (ou seja, definir cabeçalhos de controle de cache sob carga e ao servir conteúdo para usuários anônimos) e se a configuração da DigitalOcean inclui um proxy de cache capaz na cadeia, mas é uma ideia de desenvolvimento que pode valer a pena considerar, caso eu não esteja totalmente errado e isso ainda não tenha sido feito.
Talvez o @sam já tenha pensado ou feito isso, ou saiba por que seria uma má ideia!
Sim, mas minha sugestão é redirecionar apenas os usuários anônimos para uma página em cache com um tempo de expiração curto (60s?) para aliviar a carga, na esperança de que o restante do site possa continuar operando no modo de leitura e gravação.
Isso seria ótimo. Atualmente, quando destacamos um tópico em nosso canal do Telegram com mais de 200.000 seguidores, todo o site Discourse entra no modo “somente leitura” por quase uma hora. Embora o número de usuários logados seja de apenas cerca de 50 (99% é tráfego anônimo).
Isso já acontece: temos um cache bastante agressivo diretamente no Redis para usuários anônimos nas páginas de lista de tópicos e nas páginas de tópicos, com um tempo limite de 60 segundos.
Vou tentar colocar o Prometheus em funcionamento para identificar o gargalo, mas provavelmente é o monitoramento da DigitalOcean que está com atraso, como mencionado por @Alec. Se for esse o caso, acredito que uma máquina maior seja o caminho a seguir?
