I just installed Discourse, but the pages load very slowly due to slow external database

Installation
1

Homepage take up 2-4 sec to respond

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)

My server has 2 CPU cores and 8GB of RAM.

The log shows layouts/application.html.erb rendered so slow.

I removed some content in layouts/application.html.erb and it take up to 300-500ms to respond.

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

Each user request consumes a large amount of CPU.
Please help me.

3

Did you do a standard install?

2 Likes
4

Yes, i did.

And i found issue yesterday.

I used a remote database, The layout component of discourse fetch 60+sqls, every sql need ±30ms to transfer，so the first render cause 2-4 sec.

The issue go away when I changed to local database.

1 Like
6

Yes, it does:

7

I’m having a similar problem.
I think the docker might be doing some kind of magic indexing on internal databases only, which isn’t great as that severely limits how we can scale.

8

Hmmm … that doesn’t sound right to me. The same migrations should be being applied regardless of where the database is … and that includes the addition of indexes.

It would be good to demonstrate the difference if you can get a query plan on both instances for the same query that is taking much longer on the external instance.

(appreciate that might be a pain for you to gather)

If the query plan is identical, then it surely must be latency or performance of the external database that is at fault?

9

I have this plan I did a while ago for a long running query:

This plan WAS a database that was locally hosted, disk IO was the issue there, which is why I moved to external database.

I’m attempting a rebuild with an internal database.

1 Like
10

This is comparatively a huge amount of time. There’s something very wrong with your SQL setup.

How remote is the database?

99th percentile of total SQL time for logged-in requests on meta (hosted in AWS) is ~54ms and on our metal hosting for a similar site it’s ~25ms.

Anon is around 40ms and 10ms.

This looks like you’re running in development mode, not a standard install.

1 Like