방금 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)

서버는 CPU 2코어와 RAM 8GB를 갖추고 있습니다.

로그에 layouts/application.html.erb 렌더링이 매우 느리다고 나와 있습니다.

layouts/application.html.erb에서 일부 콘텐츠를 제거하니 응답 시간이 300~500ms로 줄었습니다.

<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

표준 설치를 했나요?

4

네, 그렇게 했습니다.

그리고 어제 문제를 발견했습니다.

저는 원격 데이터베이스를 사용했는데, Discourse의 레이아웃 컴포넌트가 60개 이상의 SQL 쿼리를 가져옵니다. 각 SQL 쿼리는 전송에 약 30ms가 소요되므로, 첫 번째 렌더링에 2~4초가 걸렸습니다.

데이터베이스를 로컬로 변경했을 때 문제가 사라졌습니다.

6

네, 충족합니다:

7

저도 비슷한 문제를 겪고 있습니다.
Docker가 내부 데이터베이스에 대해 어떤 종류의 마법 같은 인덱싱을 수행하고 있는 것 같습니다. 이는 확장성을 심각하게 제한하므로 좋은 방법이 아닙니다.

8

음… 제 생각에는 그 말이 맞지 않는 것 같습니다. 데이터베이스가 어디에 위치하든 동일한 마이그레이션이 적용되어야 하며, 이는 인덱스 추가를 포함합니다.

외부 인스턴스에서 훨씬 더 오래 걸리는 동일한 쿼리에 대해 두 인스턴스 모두에서 쿼리 플랜을 가져올 수 있다면, 그 차이를 시연해 보시는 것이 좋을 것입니다.

(이를 수집하는 것이 귀찮을 수 있다는 점은 이해합니다.)

만약 쿼리 플랜이 동일하다면, 문제의 원인은 분명 외부 데이터베이스의 지연 시간이나 성능일 것입니다.

9

며칠 전에 긴 실행 시간의 쿼리를 위해 작성한 실행 계획이 있습니다:

이 계획은 로컬 호스팅된 데이터베이스에 대한 것이었으며, 당시 문제는 디스크 I/O였습니다. 그래서 외부 데이터베이스로 이전했습니다.

현재는 내부 데이터베이스를 사용하여 재구성을 시도하고 있습니다.

10

이는 상대적으로 매우 긴 시간입니다. SQL 설정에 심각한 문제가 있는 것으로 보입니다.

데이터베이스가 얼마나 멀리 위치해 있나요?

메타(meta) 사이트(AWS 호스팅)의 로그인된 요청에 대해 총 SQL 시간의 99퍼센타일은 약 54ms이고, 유사한 사이트의 메탈 호스팅에서는 약 25ms입니다.

비로그인(Anon) 사용자의 경우 각각 약 40ms와 10ms입니다.

이것은 표준 설치 환경이 아니라 개발 모드에서 실행되고 있는 것으로 보입니다.