Tengo una instalación nueva de Ubuntu 20, Docker y Discourse. No he añadido ningún plugin y solo tengo dos usuarios en mi base de datos, ¡pero las compilaciones tardan más de 40 minutos en completarse! No hay ninguna parte específica del proceso de compilación que sea lenta, todo el proceso tarda una eternidad en completarse. Es un servidor con buenas especificaciones y tengo otro que sirve felizmente 20 sitios web de mis clientes, así que no es un problema de rendimiento.
Se cuelga aquí durante al menos 4 minutos:
warning Resolution field "lodash@4.17.21" is incompatible with requested version "lodash@4.17.15"
Se cuelga de nuevo aquí inmediatamente después durante otros 4-5 minutos:
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".
He intentado compilar con --skip-prereqs sin éxito, todavía tarda más de 40 minutos en cada reconstrucción.
¿Hay algo en particular que creas que pueda estar causando el problema?
Tenemos una regresión en los tiempos de compilación causada por la nueva capacidad de ejecutar pruebas de temas a través de la interfaz de usuario. Esto es algo que estamos siguiendo de cerca y tratando de solucionar.
Gracias por confirmar @Falco, 1 GB de RAM aquí (justo pero nunca necesité más para un sitio ligero). Está tardando más de 30 minutos en compilar (normalmente son unos 10).
Rafael, ¿esta regresión es en la beta 2.9.0 o en la estable 2.8.0?
Volviendo a la primera publicación, ¿alguien sabe de dónde viene esa advertencia?
No sé si es algo realmente a considerar, pero personalmente, en muchas cosas he notado que el rendimiento cae al usar Ubuntu 20.04 (Discourse, WebServers, Game Servers) incluso intentando diferentes formas de optimizar
Por el momento estoy ejecutando Discourse en un Droplet para pruebas con las mismas características, tarda entre 8 y 12 minutos en reconstruirse (Ubuntu 18)
No creo que la compilación se esté “colgando” en esas advertencias. Simplemente se está compilando silenciosamente y las advertencias se emiten como parte del proceso.
Es decir, las advertencias o su problema subyacente no contribuyen al largo tiempo de compilación.
Este es un cambio gigantesco en el que hemos estado trabajando durante años y que está llegando a sus etapas finales. Durante este tiempo, tenemos un período en el que “las cosas empeorarán antes de mejorar”, y este es uno de los efectos secundarios “peores” del mismo.
También existe la posibilidad de permitir que las personas con CPU lentas opten por no usar mapas de origen y otras características “agradables” para acelerar sus reconstrucciones.
Aprecio la actualización @Falco En una CPU quad con 8 GB de RAM en Linode y normalmente esta es una configuración fantástica, pero ahora es una pesadilla. Tenemos una serie de cambios que planeábamos hacer, pero tendremos que esperar hasta que el despliegue vuelva a velocidades normales o casi normales.
@Falco También estoy notando que en los últimos lanzamientos el rendimiento del servidor se está degradando, tarda más en cargar los sitios y consume más memoria. No ha habido cambios en mi configuración en los últimos 2 años (plugins, hardware, etc.) y el número de usuarios activos en el sitio también es el mismo. ¿Hay alguna forma de monitorear objetivamente el rendimiento del sitio dentro de Discourse que podamos informar aquí? En este momento, la única forma que conozco es cuando abro el sitio, tarda más de 8 segundos en cargarse la primera vez (con versiones anteriores siempre tardaba menos de 2-3 segundos).
¿Qué tipo de tiempos de reconstrucción están viendo? Solo necesitaba reconstruir debido a un cambio de SMTP, y tardó poco menos de 12 minutos para un sitio PEQUEÑO (30 usuarios, 400 publicaciones).
Este tema trata sobre los “tiempos de compilación”, no sobre los tiempos de carga de página. Si está hablando de la degradación de los tiempos de respuesta de la página, abra un nuevo tema al respecto con algunos datos.
Creo que descubrí por qué tarda tanto en cargar las páginas. El tamaño de la base de datos compartida en app.yml se estableció igual a la memoria total del sistema. Restablecerlo al valor predeterminado (25%), reconstruir y ahora tarda menos de un segundo.
Gracias por la actualización 
En una CPU quad con 8 GB de RAM en Linode y normalmente esta es una configuración fantástica, pero ahora es una pesadilla. Tenemos una serie de cambios que planeábamos hacer, pero tendremos que esperar hasta que el despliegue vuelva a velocidades normales o casi normales.