Acabei de instalar o Discourse, mas as páginas carregam muito lentamente devido ao banco de dados externo lento

Instalação
1

Página inicial leva de 2 a 4 segundos para responder

Started GET "/" for 219.144.218.209 at 2025-03-17 18:22:55 +0000

Processing by ListController#latest as HTML

Rendered layout layouts/application.html.erb (Duration: 1932.6ms | GC: 10.6ms)

Completed 200 OK in 2521ms (Views: 1933.4ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 14.9ms)

Meu servidor tem 2 núcleos de CPU e 8 GB de RAM.

O log mostra que layouts/application.html.erb renderizou lentamente.

Removi algum conteúdo em layouts/application.html.erb e ele leva de 300 a 500 ms para responder.


<discourse-assets>
    <discourse-assets-stylesheets>
      <%= render partial: "common/discourse_stylesheet" %>
    </discourse-assets-stylesheets>
    <discourse-assets-json>
      <div class="hidden" id="data-preloaded" data-preloaded="<%= preloaded_json %>"></div>
    </discourse-assets-json>
    <discourse-assets-icons></discourse-assets-icons>
  </discourse-assets>

Cada solicitação do usuário consome uma grande quantidade de CPU.
Por favor, me ajude.

3

Você fez uma instalação padrão?

2 curtidas
4

Sim, eu fiz.

E encontrei um problema ontem.

Eu usei um banco de dados remoto, o componente de layout do Discourse busca mais de 60 SQLs, cada SQL precisa de ±30ms para transferir, então a primeira renderização causa de 2 a 4 segundos.

O problema desaparece quando mudei para um banco de dados local.

1 curtida
6

Sim, atende:

7

Estou tendo um problema semelhante.
Acho que o docker pode estar fazendo algum tipo de indexação mágica apenas em bancos de dados internos, o que não é bom, pois limita severamente como podemos escalar.

8

Hmmm… isso não me parece certo. As mesmas migrações devem ser aplicadas independentemente de onde o banco de dados esteja… e isso inclui a adição de índices.

Seria bom demonstrar a diferença se você puder obter um plano de consulta em ambas as instâncias para a mesma consulta que está demorando muito mais na instância externa.

(aprecio que isso possa ser um incômodo para você coletar)

Se o plano de consulta for idêntico, então certamente deve ser a latência ou o desempenho do banco de dados externo que está em falta?

9

Tenho este plano que fiz há algum tempo para uma consulta de longa duração:

Este plano ERA um banco de dados hospedado localmente, o IO de disco era o problema lá, é por isso que mudei para um banco de dados externo.

Estou tentando uma reconstrução com um banco de dados interno.

1 curtida
10

Isso é comparativamente uma quantidade enorme de tempo. Há algo muito errado com sua configuração de SQL.

Quão remota é o banco de dados?

O percentil 99 do tempo total de SQL para requisições logadas no meta (hospedado na AWS) é de ~54ms e em nosso servidor dedicado para um site similar é de ~25ms.

Anon está em torno de 40ms e 10ms.

Isso parece que você está rodando em modo de desenvolvimento, não uma instalação padrão.

1 curtida