Nuestro sitio Discourse tiene más de 10 mil usuarios y aproximadamente 700 usuarios activos diarios. Los usuarios envían un promedio de 10 mil publicaciones por día. Nuestra comunidad tiene más de 160 mil vistas de página/día, incluidos rastreadores y usuarios anónimos. Casi todos nuestros usuarios se conectan a través de dispositivos móviles.
Ejecutamos la comunidad en modo de configuración independiente en un único VPS con 16 núcleos de CPU y 24 GB de RAM, configurando app.yml con estos valores:
Con la configuración anterior, algunos usuarios indican que el sitio carga lentamente para ellos, y a veces, al enviar una publicación, la pantalla se queda en blanco (aunque el encabezado sigue visible). Además, en ocasiones, durante las horas pico, el rendimiento del sitio disminuye.
Por favor, explique si configuramos algo incorrectamente o si necesitamos más recursos.
10.000 publicaciones por día es bastante alto en relación con la cantidad de visitas a la página. Puedo imaginar que estarías alcanzando algunos límites de recursos con tu configuración actual, y sospecho que el problema será la base de datos. Podrías intentar pasar a una configuración de múltiples contenedores, descargando efectivamente los workers de Unicorn del servidor principal.
Según tu respuesta, ¿aumentar los recursos en esta configuración no ayuda a resolver nuestro problema? Por ejemplo, 24 núcleos de CPU con 32 GB de RAM.
Podría ser muy bien, pero primero intentaría escalar horizontalmente todo lo que pueda escalar de esa manera. Esto también te dará una idea mucho más clara de dónde está tu cuello de botella.
La mayoría de los problemas de rendimiento se pueden resolver simplemente asignando más recursos al problema. La parte difícil es hacerlo de manera inteligente para ahorrar dinero (o potencialmente una gran cantidad de dinero).
Gracias por tu experiencia y tus amables consejos; definitivamente leeré sobre cómo implementar esto. Otra pregunta que tengo es qué configuraciones se deben aplicar en la aplicación para las especificaciones que mencioné anteriormente (24 núcleos de CPU con 32 GB de RAM).
¿Son adecuadas las configuraciones actuales o es mejor aumentar los valores?
Es difícil decirlo sin inspeccionar el sistema y ver qué está ocurriendo.
Dado que mencionaste que la mayoría de los problemas ocurren al enviar una publicación, el problema probablemente esté relacionado con las escrituras en la base de datos. No creo que aumentar aún más shared buffers sea de gran ayuda, pero puedes intentarlo. He visto que se ha subido a más del 50% de la memoria (contra todo consejo), así que podrías probar a aumentarlo gradualmente hasta 12 GB.
Si no estás viendo errores 502, tampoco tiene sentido aumentar UNICORN_WORKERS.
No mencionas usarlo, por eso creo que lo primero que haría sería agregar un CDN; esto reduciría mucho la carga del VPS, ya que las solicitudes más grandes no tocarían el servidor.
Además del CDN, también optaría por un almacenamiento similar a S3 que te permita escalar por separado el almacenamiento y los recursos del VPS (si tu comunidad depende mucho de las subidas).
Estas recomendaciones ayudan mucho a reducir la carga y el aumento de precio es mucho menor que el de un VPS más grande.
Gracias, @marianord. Desafortunadamente, no utilizamos CDN. La tasa de subida en nuestro foro no es muy alta. La mayoría de las veces, los usuarios hablan sobre diversos temas. Por ejemplo, en el último año, tuvimos aproximadamente 2,8 millones de publicaciones y 2,7 millones de «me gusta», pero solo se subieron 25 GB de archivos.
¿Crees que, según la información que he proporcionado, el uso de una CDN como S3 reduciría la carga de nuestro servidor?
No estoy de acuerdo con @marianord. No creo que una CDN marque una diferencia notable en cuanto a la carga en tu servidor. Son solo archivos estáticos y no son pesados de servir en absoluto.
S3 descarga los archivos y copias de seguridad a otro servidor gestionado por un proveedor de servicios en la nube (resumen muy general).
CDN almacena en caché los archivos estáticos de tu servidor (imágenes, JS, CSS) para servirlos desde múltiples servidores (PoP) alrededor del mundo, acelerando la carga de estos recursos.
Al menos, esa es mi experiencia: reduces la cantidad de solicitudes que llegan a tu servidor, disminuyendo así la carga. Es mucho más fácil atender solo 10 solicitudes JSON por usuario que 100 solicitudes por usuario.
Quizás esto no resolverá todos los problemas que enfrenta @nildarar, pero reducirá la carga pesada del servidor al eliminar todas las solicitudes estáticas (las almacenadas en caché) del servidor de Discourse.
Una solicitud para un archivo estático no tiene un gran impacto en la carga general del servidor. Las solicitudes de contenido dinámico son las que más consumen.
En general, una solicitud json no es un recurso estático que pueda ser almacenado en caché por una CDN. Es contenido dinámico que se genera al momento. ¿Por qué estás hablando de archivos JSON en el contexto de una CDN?
Las solicitudes estáticas no equivalen a una carga más pesada.
Lo siento, pero este es realmente un mal consejo.
Este es un ejemplo de una máquina con 6 CPUs (por lo que la CPU suma hasta un 600%) ejecutando Discourse sin una CDN ni S3.
Es cierto, pero Discourse tiene algunas excepciones, como las hojas de estilo que se sirven mediante Ruby, por lo que tener una CDN de caché significa que esas solicitudes no consumen los procesos de Unicorn.
En cuanto al problema del autor del tema, lo primero necesario es que alguien con conocimientos realice un análisis de rendimiento durante las horas pico e identifique cuál es el cuello de botella actual.
Gracias por tu orientación. Hace unos meses utilizábamos el servicio CDN de Cloudflare y realizábamos ajustes en el contenido estático a través de las reglas de página. Posteriormente, leí en algún lugar que el uso de proxies como Cloudflare reduce drásticamente el rendimiento de Discourse, por lo que lo desactivamos.
Ayer aumentamos los núcleos de CPU de 16 a 24 y realizamos los siguientes cambios en app.yml:
Con estos cambios, nuestro problema se resolvió temporalmente, pero creo que deberíamos realizar un cambio fundamental en los próximos meses.
Por lo tanto, según tus recomendaciones, el uso de una CDN para servir contenido estático y dividir Discourse en dos contenedores separados tiene mayor prioridad en las mejoras de rendimiento.
Esto podría ser información antigua, pero recuerdo haber leído que Discourse prefiere un menor número de CPUs más potentes en lugar de un mayor número de CPUs menos potentes… incluso si actualizas la cantidad de workers de unicornio.
@codinghorror, ¿puedes confirmar si esta información sigue siendo precisa?
Nuestra previsión es que el próximo año el número de nuestros usuarios se triplicará, por lo que, a partir de hoy, debemos proporcionar los recursos necesarios para esta escala.
Usar algo como Prometheus + Grafana puede ayudarte a obtener el historial de los datos, en lugar de verlos en tiempo real y luego realizar un análisis más profundo de lo que está sucediendo.
¡Hola de nuevo!
Siguiendo sus consejos, instalamos Prometheus y monitoreamos el rendimiento de la comunidad durante un tiempo. Consulte los informes a continuación y compare los valores con los que observa en diferentes instalaciones.
