Je viens d'installer Discourse, mais les pages se chargent très lentement à cause d'une base de données externe lente

Installation
1

La page d’accueil prend 2 à 4 secondes pour répondre

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)

Mon serveur a 2 cœurs CPU et 8 Go de RAM.

Le log montre que layouts/application.html.erb a rendu très lentement.

J’ai supprimé une partie du contenu de layouts/application.html.erb et cela prend 300 à 500 ms pour répondre.

<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>

Chaque requête utilisateur consomme une grande quantité de CPU.
Aidez-moi s’il vous plaît.

3

Avez-vous effectué une installation standard ?

2 « J'aime »
4

Oui, je l’ai fait.

Et j’ai trouvé un problème hier.

J’ai utilisé une base de données distante. Le composant de mise en page de Discourse récupère plus de 60 requêtes SQL, chaque requête SQL nécessite environ 30 ms pour le transfert, donc le premier rendu prend 2 à 4 secondes.

Le problème disparaît lorsque je suis passé à une base de données locale.

1 « J'aime »
6

Oui, c’est le cas :

7

J’ai un problème similaire.
Je pense que Docker effectue une sorte d’indexation magique sur des bases de données internes uniquement, ce qui n’est pas idéal car cela limite considérablement notre capacité à évoluer.

8

Hmm… cela ne me semble pas correct. Les mêmes migrations devraient être appliquées, quelle que soit la localisation de la base de données… et cela inclut l’ajout d’index.

Il serait bon de démontrer la différence si vous pouvez obtenir un plan de requête sur les deux instances pour la même requête qui prend beaucoup plus de temps sur l’instance externe.

(j’apprécie que cela puisse être une corvée pour vous de rassembler)

Si le plan de requête est identique, alors il doit certainement s’agir de la latence ou des performances de la base de données externe qui sont en faute ?

9

J’ai ce plan que j’ai fait il y a quelque temps pour une requête de longue durée :

Ce plan ÉTAIT sur une base de données hébergée localement, les E/S disque étaient le problème, c’est pourquoi je suis passé à une base de données externe.

J’essaie de reconstruire avec une base de données interne.

1 « J'aime »
10

C’est une quantité de temps énorme en comparaison. Il y a quelque chose de très problématique dans votre configuration SQL.

Quelle est la distance de la base de données ?

Le 99e centile du temps SQL total pour les requêtes connectées sur meta (hébergé sur AWS) est d’environ 54 ms et sur notre hébergement dédié pour un site similaire, il est d’environ 25 ms.

Pour les utilisateurs anonymes, c’est environ 40 ms et 10 ms.

Cela ressemble à une exécution en mode développement, pas à une installation standard.

1 « J'aime »