Acabo de instalar Discourse, pero las páginas cargan muy lentamente debido a una base de datos externa lenta

Instalación
1

La página de inicio tarda entre 2 y 4 segundos en 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)

Mi servidor tiene 2 núcleos de CPU y 8 GB de RAM.

El registro muestra que layouts/application.html.erb se renderizó muy lentamente.

Eliminé parte del contenido de layouts/application.html.erb y tarda entre 300 y 500 ms en 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 solicitud de usuario consume una gran cantidad de CPU.
Por favor, ayúdame.

3

¿Hiciste una instalación estándar?

2 Me gusta
4

Sí, lo hice.

Y encontré un problema ayer.

Usé una base de datos remota, el componente de diseño de Discourse recupera más de 60 SQL, cada SQL necesita ±30 ms para transferirse, por lo que la primera renderización causa 2-4 segundos.

El problema desaparece cuando cambié a una base de datos local.

1 me gusta
6

Sí, lo hace:

7

Tengo un problema similar.
Creo que Docker podría estar haciendo algún tipo de indexación mágica solo en bases de datos internas, lo cual no es bueno, ya que limita severamente cómo podemos escalar.

8

Hmmm… eso no me suena bien. Las mismas migraciones deberían aplicarse independientemente de dónde esté la base de datos… y eso incluye la adición de índices.

Sería bueno demostrar la diferencia si puedes obtener un plan de consulta en ambas instancias para la misma consulta que tarda mucho más en la instancia externa.

(Aprecio que esto pueda ser una molestia para ti recopilarlo)

Si el plan de consulta es idéntico, entonces seguramente debe ser la latencia o el rendimiento de la base de datos externa lo que está en falta.

9

Tengo este plan que hice hace un tiempo para una consulta de larga duración:

Este plan ERA una base de datos alojada localmente, el problema allí era la E/S de disco, por eso me mudé a una base de datos externa.

Estoy intentando reconstruir con una base de datos interna.

1 me gusta
10

Esta es, comparativamente, una enorme cantidad de tiempo. Hay algo muy mal con tu configuración de SQL.

¿Qué tan remota es la base de datos?

El percentil 99 del tiempo total de SQL para las solicitudes de usuarios conectados en meta (alojado en AWS) es de ~54ms y en nuestro alojamiento en metal para un sitio similar es de ~25ms.

Los usuarios anónimos rondan los 40ms y 10ms.

Esto parece que estás ejecutando en modo de desarrollo, no en una instalación estándar.

1 me gusta