Acabamos de experimentar un pico de tráfico de aproximadamente 1.500 usuarios concurrentes (en su mayoría anónimos) visitando una sola página.
El foro entró en un modo en el que se muestra una advertencia a todos los miembros sobre la alta carga.
Droplet de Digital Ocean optimizado para CPU
CPU dedicada: 4 vCPUs
RAM: 8 GB
Workers de Unicorn: 10
Dado que solo se utiliza aproximadamente el 50% de la RAM y la CPU, ¿sería útil aumentar los workers de Unicorn para casos de tráfico pico como este provenientes de visitantes anónimos o no?
He aumentado los workers a 24. No hay diferencia (sigue mostrando: “Debido a una carga extrema, esto se muestra temporalmente a todos como lo vería un usuario sin iniciar sesión”), con un pico de visitantes concurrentes similar (99% anónimos) justo ahora:
@sam ¿Tienes alguna idea sobre cómo optimizar aún más para el tráfico máximo de usuarios anónimos (por ejemplo, si un tema se vuelve viral en redes sociales)? En ambos casos descritos anteriormente, la memoria y la CPU todavía tienen mucho margen (según Digital Ocean), y ni siquiera hemos alcanzado una carga de 4. Aun así, el foro entra en modo “carga extrema”, a pesar de haber triplicado el número de workers.
Creo que el monitor de datos de DO no es lo suficientemente sensible y resulta algo engañoso. Experimenté con cargas extremas en Hetzner y Digital Ocean. Con Hetzner, cuando apareció el mensaje de carga extrema, hubo un pico breve y agudo que llegó al 120%.
Duró quizás un segundo antes de bajar al rango del 40-50%.
Repetí lo mismo con Digital Ocean y, según recuerdo, el uso de CPU nunca superó el 50% (aunque no se podía ajustar el eje X al nivel de segundos).
Mi hipótesis es que el nivel de CPU de DO podría ser un promedio de 5 o 15 segundos. Por eso no se aprecian esos picos breves y agudos.
Necesitaremos informes del exportador de Prometheus para profundizar más.
Si tienes suficiente RAM y CPU, siempre puedes agregar más trabajadores de Unicorn; esto te permitirá escalar durante esos picos. Solo debes evitar el intercambio de memoria, ya que el rendimiento caerá drásticamente.
Parece que, en tal caso, esa página de tema individual debería poder almacenarse en caché y servirse de forma estática durante un corto período sin tener que acceder al backend en absoluto. No tengo idea de si Discourse puede hacer eso (es decir, establecer encabezados de control de caché cuando está bajo carga y sirve contenido a usuarios anónimos) ni si la configuración de DO tiene un proxy de caché capaz en la cadena, pero es una idea de desarrollo que podría valer la pena considerar si no estoy totalmente equivocado y si aún no se ha hecho.
Quizás @sam ya lo haya pensado o hecho, o sepa por qué es una mala idea.
Sí, pero mi sugerencia es redirigir solo a los usuarios anónimos a una página en caché con un tiempo de espera breve (¿60 s?) para aliviar la carga, con la esperanza de que el resto del sitio pueda seguir funcionando en modo de lectura y escritura.
Eso sería genial. Actualmente, si destacamos un tema en nuestro canal de Telegram de más de 200.000 suscriptores, todo el sitio Discourse entra en modo «solo lectura» durante casi una hora. Aunque los usuarios conectados son solo alrededor de 50 (el 99 % es tráfico anónimo).
Esto ya ocurre; tenemos una caché bastante agresiva directamente en Redis para usuarios anónimos en las páginas de listas de temas y en las páginas de temas. Tiempo de espera de 60 s.
Intentaré ejecutar Prometheus para identificar el cuello de botella, pero probablemente se trate de la monitorización de DigitalOcean, que está con retraso, como mencionó @Alec. Si ese es el caso, supongo que la solución será usar una máquina más grande.
