Nosso site Discourse tem mais de 10 mil usuários e cerca de 700 usuários ativos por dia, enviando em média 10 mil posts diários. Nossa comunidade registra mais de 160 mil visualizações de página por dia, incluindo crawlers e usuários anônimos. Quase todos os nossos usuários se conectam por meio de dispositivos móveis.
Executamos a comunidade em modo de configuração standalone em um único VPS com 16 núcleos de CPU e 24 GB de RAM, configurando o app.yml com os seguintes valores:
Com essa configuração, alguns usuários relatam que o site carrega lentamente para eles e, às vezes, ao enviar um post, a tela fica em branco (o cabeçalho continua visível). Além disso, durante os horários de pico, o desempenho do site às vezes diminui.
Por favor, explique se fizemos uma configuração incorreta ou se precisamos de mais recursos.
Muito obrigado
10 mil postagens por dia é bastante alto, em relação à quantidade de visualizações de página. Posso imaginar que você esteja atingindo alguns limites de recursos aqui, dada sua configuração, e suspeito que o problema seja o banco de dados. Você pode tentar migrar para uma configuração com múltiplos containers, efetivamente descarregando os workers do Unicorn do servidor principal.
De acordo com sua resposta, aumentar os recursos nesta configuração não ajuda a resolver nosso problema? Por exemplo, 24 núcleos de CPU com 32 GB de RAM.
Pode muito bem ser, mas eu primeiro tentaria escalar horizontalmente tudo o que puder ser escalado dessa forma. Isso também lhe dará uma ideia muito melhor de onde está o seu gargalo.
A maioria dos problemas de desempenho pode ser resolvida simplesmente jogando mais recursos contra o problema. A parte difícil é fazer isso de forma inteligente para que você possa economizar alguns dólares (ou potencialmente muito dinheiro).
Obrigado pela sua expertise e conselhos amigáveis. Com certeza, vou ler sobre como implementar isso. Outra dúvida que tenho é quais configurações devem ser aplicadas no aplicativo para as especificações que mencionei acima (24 núcleos de CPU com 32 GB de RAM).
As configurações atuais são adequadas ou é melhor aumentar os valores?
Difícil dizer sem inspecionar o sistema e ver o que está acontecendo.
Como você mencionou que a maioria dos problemas ocorre ao enviar uma postagem, o problema provavelmente está relacionado às escritas no banco de dados, e não acho que aumentar ainda mais o shared buffers seja de grande ajuda, mas você pode tentar. Já vi ele configurado para mais de 50% da memória (contra todos os conselhos), então você pode tentar aumentá-lo gradualmente até 12 GB.
Se você não estiver vendo erros 502, não há utilidade em aumentar o UNICORN_WORKERS também.
Você não menciona o uso disso, por isso acho que a primeira coisa que eu faria seria adicionar um CDN. Isso reduziria muito a carga no VPS, pois as requisições maiores não chegariam ao servidor.
Além do CDN, eu também optaria por um armazenamento do tipo S3, o que permitiria dimensionar de forma independente o armazenamento e os recursos do VPS (se sua comunidade tiver muitas uploads).
Essas recomendações ajudam muito a reduzir a carga, e o aumento de preço é bem menor do que contratar um VPS maior.
Obrigado @marianord. Infelizmente, não utilizamos CDN. A taxa de upload em nosso fórum não é muito alta. Na maioria das vezes, os usuários discutem vários assuntos. Por exemplo, no último ano, tivemos cerca de 2,8 milhões de posts e 2,7 milhões de curtidas, mas apenas 25 GB de arquivos foram enviados.
Você acha que, com base nas informações que forneci, o uso de uma CDN como a S3 reduziria a carga do nosso servidor?
Não concordo com @marianord. Não acho que uma CDN faria uma diferença perceptível em relação à carga no seu servidor.
São apenas arquivos estáticos e não são pesados para serem servidos.
O S3 transfere os arquivos e backups para outro servidor gerenciado por um provedor de nuvem (resumo de alto nível)
O CDN armazena em cache os arquivos estáticos do seu servidor (imagens, JS, CSS) para servir a partir de vários servidores (PoP) ao redor do mundo, acelerando o carregamento desses ativos.
Pelo menos, essa é a minha experiência: você reduz a quantidade de requisições que chegam ao seu servidor, diminuindo assim a carga. É muito mais fácil atender apenas 10 requisições JSON por usuário do que 100 requisições por usuário.
Talvez isso não resolva todos os problemas que @nildarar está enfrentando, mas reduzirá a carga mais pesada no servidor, removendo todas as requisições estáticas (as armazenadas em cache) do servidor Discourse.
Uma requisição para um arquivo estático não tem grande impacto na carga geral do servidor. As requisições para conteúdo dinâmico são as mais pesadas.
Em geral, uma requisição json não é um ativo estático que será armazenado em cache por uma CDN. É conteúdo dinâmico gerado sob demanda. Por que você está falando sobre arquivos JSON no contexto de uma CDN?
requisições estáticas != carga mais pesada.
Peço desculpas, mas esse é realmente um conselho ruim.
Este é um exemplo de uma máquina com 6 CPUs (então a CPU soma até 600%) rodando o Discourse sem CDN ou S3.
Verdade, mas o Discourse tem algumas exceções, como folhas de estilo que são servidas pelo Ruby, então ter um CDN de cache significa que essas requisições não consomem os processos do Unicorn.
Quanto ao problema do OP, a primeira coisa necessária é que alguém com conhecimento realize uma análise de desempenho durante os horários de pico e identifique qual é o gargalo atual.
Obrigado pela sua orientação. Até alguns meses atrás, usávamos o serviço CDN da Cloudflare e fizemos boas melhorias no conteúdo estático por meio das regras de página. Depois disso, li em algum lugar que o uso de proxies como a Cloudflare reduz drasticamente o desempenho do Discourse, então o desativamos.
Ontem, aumentamos os núcleos de CPU de 16 para 24 e fizemos as seguintes alterações no app.yml:
Com essas alterações, nosso problema foi resolvido temporariamente, mas acredito que devemos fazer uma mudança fundamental nos próximos meses.
Portanto, de acordo com suas recomendações, o uso de CDN para servir conteúdos estáticos e a divisão do Discourse em dois contêineres separados têm maior prioridade em termos de melhorias de desempenho.
Isso pode ser uma informação mais antiga, mas lembro de ter lido que o Discourse prefere um número menor de CPUs mais potentes em vez de um número maior de CPUs menos potentes… mesmo que você atualize o número de trabalhadores unicorn.
@codinghorror, você pode confirmar se essa informação ainda está correta?
Nossa projeção é que, no próximo ano, o número de nossos usuários triplique, então, a partir de hoje, devemos fornecer os recursos necessários para essa escala.
Usar algo como Prometheus + Grafana pode ajudar você apenas a obter o histórico dos dados, em vez de vê-los em tempo real e, em seguida, fazer uma análise mais profunda do que está acontecendo.
Olá novamente
Seguindo suas dicas, instalamos o Prometheus e monitoramos o desempenho da comunidade por um tempo. Veja os relatórios abaixo e compare com os valores que você vê em diferentes instalações.
