私はDiscourseをインストールしたばかりですが、外部データベースが遅いためページの読み込みが非常に遅いです

インストール
1

ホームページの応答に2〜4秒かかります

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)

私のサーバーは2つのCPUコアと8GBのRAMを搭載しています。

ログによると、layouts/application.html.erbのレンダリングが非常に遅いようです。

layouts/application.html.erbの一部のコンテンツを削除したところ、応答時間は300〜500ミリ秒になりました。


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

各ユーザーリクエストは大量のCPUを消費します。
助けてください。

3

標準のインストールを行いましたか？

「いいね！」 2
4

はい、そうしました。

そして昨日、問題を見つけました。

リモートデータベースを使用しました。Discourseのレイアウトコンポーネントは60以上のSQLを取得し、各SQLの転送に±30ミリ秒かかります。そのため、最初のレンダリングに2〜4秒かかります。

ローカルデータベースに変更すると、問題は解消されました。

「いいね！」 1
6

はい、満たしています。

7

同様の問題が発生しています。
Dockerが内部データベースのみで何らかのインデックス作成を行っている可能性があり、これはスケーリング方法を大幅に制限するため、あまり良くありません。

8

うーん…それは私には正しく聞こえません。データベースがどこにあっても、同じマイグレーションが適用されるはずです…それにはインデックスの追加も含まれます。

もし可能であれば、外部インスタンスでより長くかかっている同じクエリについて、両方のインスタンスでクエリプランを取得して違いを実証できれば良いのですが。

（それを収集するのは大変なことだと理解しています）

クエリプランが同一であれば、それは外部データベースのレイテンシまたはパフォーマンスに問題があるに違いありませんか？

9

以前作成した長時間実行クエリの実行計画はこちらです。

この実行計画はローカルホストのデータベースのもので、ディスクI/Oが問題だったため、外部データベースに移行しました。

現在、内部データベースで再構築を試みています。

「いいね！」 1
10

これは比較すると膨大な時間です。SQLの設定に何か非常に問題があるはずです。

データベースはどのくらい離れていますか？

メタ（AWSでホスト）でのログイン済みリクエストのSQL全体の99パーセンタイル時間は約54msで、同様のサイトのメタルホスティングでは約25msです。

匿名ユーザーの場合は約40msと10msです。

これは、標準的なインストールではなく、開発モードで実行しているように見えます。

「いいね！」 1