Gracias. Es muy probable que me hayas ahorrado muchas horas de depuración y ensayo y error.
Esta diferencia de comportamiento me ha llevado a concluir que se trata de alguna correlación a nivel de aplicación que deriva de un problema en el FrontEnd que “hace colapsar” la aplicación (siendo que el FrontEnd no es mi área de especialización, a diferencia del BackEnd) y las operaciones en curso al publicar y que la gente permanezca en un tema esperando que se “actualice automáticamente” con decenas de mensajes en un solo minuto.
Para resumir esta mega-oración: ¿Tu conclusión es que el “ahogo” de la discusión en tiempo real rápida es un problema del front-end?
No avancé mucho en nuestro análisis, pero sí observé que la carga de la CPU estaba muy lejos de su máximo, solo alrededor del 25% más o menos. A lo largo de los años hemos alcanzado el 100% de la CPU muchas veces antes, pero este no fue el caso en el último incidente del sábado pasado. Solo tuvimos alrededor de 150 usuarios concurrentes.
Lo que me llevó a sospechar del back-end es el hecho de que hemos estado ejecutando estos chats de juegos durante años y no había visto este “ahogo” antes. Con el paso de los años, la base de datos ha crecido y ahora tenemos más de 800.000 publicaciones.
¿Cuándo fue la primera vez que observaste esto? ¿Podría tratarse de una regresión con la última actualización importante? Nuestro sitio y su rendimiento estaban bien en primavera y no hemos crecido tanto durante el verano.
Babel es un plugin espectacularmente ineficiente, por lo que si lo estás utilizando, vas a tener un mal momento… especialmente bajo una gran carga de usuarios activos simultáneamente.
Tenemos una tarea pendiente en nuestra lista de espera para mejorar el rendimiento en los casos en los que 1000 personas están viendo el mismo tema y una persona publica.
Tal como está diseñado hoy, publicamos a las 1000 personas: “Hola, hay una nueva publicación para este tema”, y luego las 1000 personas van al servidor (principalmente al mismo tiempo) preguntando… “oye, ¿qué es este nuevo tema del que estás hablando”.
Vamos a revisar cómo limitar mínimamente esto de una manera más limpia para que los clientes no saturen el servidor, pero hay una serie de optimizaciones que podemos hacer para este caso atípico.
¡Excelente noticia que esto esté en tu radar. ¿Puedes confirmar si ha habido una regresión desde la primavera pasada?
Nuestra liga local de hockey intenta comenzar los partidos el 1 de octubre. Esto significa que nuestro sitio puede generar picos de tráfico en vivo semanalmente, por si necesitas o quieres estudiar el comportamiento tal como ocurre en un entorno real (no simulado).
Envía un mensaje directo si estás interesado. Estamos encantados de apoyar.
Desde el punto de vista de UX, el usuario final debería saber de alguna manera que la discusión está activa, incluso cuando el sistema empieza a fallar. Esto podría evitar actualizaciones innecesarias del navegador.
El primer partido acaba de terminar y definitivamente tenemos un problema que no teníamos en marzo. La razón aún es desconocida.
El chat del juego se satura en el frontend, aunque la carga del servidor debería estar muy por debajo del 100%.
Uno de nuestros usuarios detectó varias respuestas de servidor 429 durante los atascos, pero no puedo decir si esto es “normal”, ya que no hemos realizado este tipo de inspección antes, durante los partidos.
He visto uno de esos mientras investigaba un error ‘500’ totalmente irrelevante
El servidor no estaba ocupado en absoluto, pero estaba manipulando una configuración frontal de nginx (http2).
Efectivamente. Hubo alrededor de 900 respuestas reaccionarias en un lapso de unas pocas horas. @ljpp tiene números más exactos de usuarios, pero estamos hablando de cientos de usuarios navegando por el tema en cualquier momento durante el partido.
Curiosamente, esto no afecta a todos los usuarios. Yo, por ejemplo, no he encontrado ningún problema en ningún dispositivo. Pero, según los informes, es lo suficientemente generalizado.
No es tan obvio detectarlo, especialmente si no estás prestando mucha atención.
Primero hay una pausa de 30 a 60 segundos sin respuestas. Nada parece “mal”, simplemente está en silencio. Incluso puedes escribir tu propia publicación. De repente, recibes docenas de mensajes en un instante y te das cuenta de que te has quedado atrás. He visto esto en iOS Safari y en Chrome para Android.
Nuestros chats de juegos en tiempo real están activos, pero no son casos extremos. Ayer tuvimos 972 mensajes en aproximadamente 3 horas.
El próximo chat del partido tendrá lugar hoy a las 14:00 UTC. Debido a la pandemia, espero cifras similares, aunque sea un partido en casa.
Estoy de acuerdo con la publicación de @pfaffman sobre esto.
¿No estás intentando imponer un caso de uso de chat en una plataforma de foro?
¿Por qué no integras en su lugar un servicio de chat como Mattermost o Discord en la interfaz de tu sitio Discourse y utilizas este medio para cubrir la discusión dentro del juego?
Podrías encontrar otra forma de cubrir el juego en un tema del foro, como discusiones previas o posteriores al juego, donde la carga de uso podría ser menos exigente, pero que quizás contenga información útil de resumen que muchos usuarios podrían querer consultar en una fecha posterior.
Tampoco veo el beneficio de almacenar un gran volumen de chat improvisado en un foro. ¿Alguien va a volver a leer eso? ¿Es útil?
Bueno, él usa la palabra «chat» para esto, pero según el usuario, su configuración de Discourse no puede manejar «972 publicaciones en aproximadamente 3 horas» en un tema. En mi opinión, debería poder hacerlo; incluso un simple phpBB puede manejar varias veces más publicaciones en 3 horas que esto.
¿Así que 1 publicación cada 10 segundos? Por sí solo, eso no suena poco razonable. Pero luego haces que el tema tenga 1000 publicaciones y participan varios cientos de usuarios, además de que hay picos de publicaciones. ¡Puedo ver el desafío!
Pero, ¿cuál es el verdadero culpable o cuello de botella aquí? ¿El número de usuarios que participan, el límite de 1 publicación cada 10 segundos, la renderización del contenido modificado para (demasiados) usuarios anónimos o no anónimos, o el número de conexiones necesarias para atender a muchos usuarios con sesión iniciada?
¿Tendría el mismo problema si solo 2 usuarios generaran la misma cantidad de publicaciones en un tema dentro del mismo período de tiempo?
Incluso con solo 972 usuarios con sesión iniciada haciendo una sola publicación en ese tema, ¿no debería Discourse ser capaz de manejar esto? Y si no es así, ¿por qué? ¿Es Discourse simplemente la opción adecuada para comunidades muy pequeñas con un bajo número de usuarios con sesión iniciada simultáneos?
Solo me pregunto, ya que en ocasiones hemos llegado a tener hasta 400 usuarios con sesión iniciada simultáneamente, generando hasta 3000 publicaciones al día… hasta ahora, sin problemas.
Claramente debes tener en cuenta las especificaciones del servidor y la cantidad de unicornios en ejecución; de lo contrario, los resultados de estos escenarios de estrés tendrán menos sentido.
Blenderartists (@bartv), creo que tienen un servidor de 64 GB y alrededor de una docena de unicornios en ejecución. ¡Qué bestia!
Absolutamente, actualmente estamos usando 8 GB de RAM y 4 vCPUs en DigitalOcean y no tenemos ningún problema por el momento. Así que, si la solución a esto es simplemente añadir más recursos (RAM y CPU), estoy de acuerdo. En el pico más alto desde el relanzamiento con Discourse, tuvimos unos 2000 visitantes simultáneos en un solo post que se volvió viral; la carga del sistema fue ligeramente superior a 1 y el uso de CPU estuvo entre 60% y 70%. En promedio, con aproximadamente 200-250 usuarios conectados simultáneamente, el uso de CPU se mantiene alrededor del 15%-20% actualmente.
Podrías argumentar eso, pero realmente no me gusta la idea de fragmentar las conversaciones entre dos plataformas. La inmediatez es, de hecho, una de las características estrella de Discourse que los usuarios finales valoran. Nuestras conversaciones durante las partidas son un gran éxito y una parte importante de la cultura de nuestra comunidad.
Ten en cuenta que hemos estado organizando esto durante cuatro años y este es un problema nuevo que estamos enfrentando. Así que cientos de partidas se han desarrollado sin problemas, sin “imponer” nada.
Uno de nuestros miembros más experimentados tenía una teoría: ¿podría ser que estemos alcanzando los límites globales de Discourse y que CloudFlare tenga algún impacto?
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: número de solicitudes por IP por minuto (el valor predeterminado es 200)
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: número de solicitudes por IP por 10 segundos (el valor predeterminado es 50)
La próxima partida es en una hora y lo probaremos con la caché de CF desactivada.
Ten en cuenta que también hemos estado usando CloudFlare durante 4 años, aunque generalmente no se recomienda aquí. Solo hemos tenido uno o dos problemas en el camino; uno fue Brotli y otro la plantilla desactualizada.
