Con esta configuración, la experiencia de usuario fue mejor. Sí, hubo varios “cuellos de botella” y se registraron muchos errores 429 en la consola de desarrollo de Chrome. La carga de la CPU fue baja. Pero, por otro lado, fue un juego en casa bastante tranquilo (muchos miembros activos estaban presentes, pero no chateando).
No puedo indicar qué ajustes concretos modificar, pero, desde mi experiencia bastante subjetiva:
La función de código sigue siendo demasiado protectora con respecto a la carga del servidor. Quizás se podría permitir un nivel de estrés del servidor ligeramente mayor.
Cuando el cliente reduce la frecuencia de las solicitudes, el retraso es demasiado largo desde la perspectiva de la experiencia de usuario. El juego continúa y puede ocurrir mucho en un minuto. El chat se desincroniza, con personas haciendo referencia a diferentes eventos del juego. (Esto agrava el problema de los diferentes retrasos entre el tiempo real, la televisión por cable, la IPTV y el búfer de 20 segundos de Chromecast, etc.).
Los usuarios solo ven que el chat se ha detenido, pero no reciben ninguna indicación de que el sitio sigue en línea y activo. Es más probable que refresquen la página o realicen otras acciones que aumentan la carga.
Solo para descartar posibilidades, actualicé el servidor a 8 vCores y 32 GB de RAM. Configuré los búferes de la base de datos a 16 GB y los procesos Unicorn a 16. Dejé las demás optimizaciones en sus valores predeterminados.
Desafortunadamente, la actualización no sirvió de mucho. Las discusiones rápidas se congelan constantemente, incluso con una actividad mediocre.
El rendimiento es miserable en estos días. Supongo que tendré que empezar a revisar herramientas como Prometheus, etc. Estoy casi seguro de que el rendimiento del software ha retrocedido gravemente desde la versión 2.3.
El comentario del hermano @Iceman fue mayormente ignorado en septiembre. Él reporta que los bloqueos ocurren sin importar qué hardware esté utilizando.
Sospecho que podrías estar encontrando un cuello de botella en Redis, pero como he dicho muchas veces, solo podemos estar seguros si recopilas esas estadísticas. Sin ellas, podríamos tan bien usar astrología.
Si mi sospecha es correcta, también explicará por qué añadir más núcleos lentos y RAM al problema no hace ninguna diferencia, ya que Redis es de un solo hilo; solo podrías escalar obteniendo núcleos de alto rendimiento.
Lanzaremos una nueva imagen con la versión final de 2.6 antes de fin de mes, que incluirá Redis 6 y nuevas variables en app.yml para aprovecharlas al máximo. Avísame si quieres probarlo antes; puedo darte las instrucciones para hacerlo.
Acabo de notar esto en un tema cerrado. @codinghorror - eso es incorrecto. Lo que realmente obtiene el usuario final en una situación de alta carga es:
Una notificación de que ha sido desconectado
Es llevado a la página de índice del sitio
La página de índice muestra la notificación de carga alta en el banner
Sin embargo, el usuario en realidad no ha sido desconectado. Por lo general, cuando vuelve a entrar al tema activo, el sitio funciona con normalidad.
Una vez más, no tenemos ningún cliente que informe este comportamiento (de entre miles, muchos mucho más activos que su sitio), por lo que cualquier discusión adicional en este punto es básicamente inútil: no tenemos visibilidad de la extraña situación de configuración o de las anomalías en el rendimiento del hardware que pueda tener usted por ahí.
En el futuro, esperamos que esto cambie y que tengamos una mejor visibilidad del problema real.
El comportamiento debe ser que se mantengan en la página del tema y se les muestre una vista de sesión cerrada, no que sean llevados a la página de inicio.
Entonces, si Redis es el cuello de botella, ¿cómo lo escalarías horizontalmente?
Todavía me desconcierta lo que ha cambiado desde la última temporada. No veo mucho crecimiento orgánico ni un aumento en la popularidad del chat del juego. Sin embargo, nuestra capacidad de servicio se ha reducido drásticamente y hasta los juegos más tranquilos están sufriendo estrangulamientos.
Hasta que no puedas recopilar métricas de tu instancia histórica de Discourse y luego compararlas con las métricas que recopiles en tu instalación actual, manteniendo exactamente el mismo hardware, esto seguirá siendo un misterio.
La diferencia podría deberse a que tu proveedor de VPS te haya trasladado de una máquina física a otra, o que hayas adquirido un “vecino ruidoso”, o que tu VPS ahora esté ejecutando 17 en lugar de 13 servicios alojados conjuntamente por máquina de media.
Por favor, no especules sobre escalar el problema al proveedor de VPS. UpCloud es uno de los mejores del mercado y ya han verificado su parte para descartar cualquier anomalía. Publicitan en nuestro sitio y no sería una buena imagen que el sitio tuviera interrupciones
Pero no hay datos históricos y, para ser honesto, no prestaba tanto atención porque todo funcionaba bien hasta que se celebraron los primeros partidos de exhibición en agosto. Por supuesto, los patrones de comportamiento de las personas han cambiado gracias a la COVID y quién sabe qué más. Sin embargo, no lo veo reflejado en las métricas de nuestro sitio o servidor.
Pero esto es material de prueba excelente. Acabo de proporcionar a @riking algunas capturas de pantalla de lo que ocurre cuando se activa la sobrecarga del servidor. Supongo que ustedes no lo ven tan a menudo.
Ten en cuenta que nadie está en desacuerdo contigo; solo estamos señalando que un médico solo puede hacer tanto para diagnosticar a un paciente cuando está limitado a verlo a través de una cámara de video en internet.
Solo quería decir que esto fue exactamente lo que experimenté cuando configuré mi sitio por primera vez (así que no es algo exclusivo de tu sitio).
Aquí hay un hilo que publiqué sobre el tema en ese momento:
Esto fue lo que me llevó a cambiar a diferentes opciones de CPU/memoria descritas aquí:
Desafortunadamente, no he tenido la oportunidad de migrar correctamente a Hetzner desde Digital Ocean como había planeado (empecé un nuevo trabajo). Pero lo haré tan pronto como pueda este mes.
La experiencia del usuario final al ser expulsado del hilo, o permanecer en él (con el mensaje de que ha cerrado sesión), parecía depender de la carga. (más usuarios fueron enviados a la página de índice del sitio después de un gol).
No tengo suficiente conocimiento técnico para ser de gran ayuda, pero pensé que podría ser útil saber que un sitio deportivo con picos similares de comportamiento de chat también experimenta problemas parecidos. El mío (un sitio más pequeño y reciente) se resolvió al mejorar aún más el servidor.
Instalé un nuevo entorno de 2 contenedores en 2 servidores VPS (web_only, data).
Sorprendentemente (para mí), el servidor web_only se está agotando, mientras que el de datos está relativamente poco cargado. Ambos ejecutan un plan de UpCloud.com de 4x vCore y 8 GB de RAM.
Actualicé el servidor web_only a un plan de UpCloud.com de 6x vCore y 16 GB de RAM. Aumenté los Unicornios a 18.
Aún así, estamos alcanzando varios limitadores 429. Sin embargo, el modo sistema bajo alta carga no se activó.
La temporada de hockey se ha visto arruinada por la COVID, y ahora están jugando algunos partidos al azar sin público. Dado que contamos con créditos de alojamiento en UpCloud.com, nos estamos esforzando por mejorar la experiencia con los recursos que tenemos. Actualmente ejecutamos 6x vCore 16 GB para web_only y 4x vCore 8 GB para data, con unicornios en 18.
Hemos vuelto a desactivar el limitador de tasa…
DISCOURSE_MAX_REQS_PER_IP_MODE : none
…lo cual ayuda, pero aún recibimos errores 429 desde POLLs, que provocan largos retrasos o congelamientos para el usuario final. Continuaremos ajustando aumentando el valor de DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS.
Pero antes de hacerlo, una pregunta para @sam / el equipo:
¿Existe una variable de entorno para aumentar el umbral del limitador de carga extrema - modo solo lectura, o puede desactivarse por completo?
Quizás sea así, pero nos gustaría ser un poco menos protectores con el servidor, ya que los picos de actividad naturales son muy breves y generalmente se estabilizan en un minuto más o menos. Por lo tanto, ajustar los umbrales un poco más alto podría mejorar la experiencia de usuario, mientras esperamos la migración.
Los partidos han sido escasos (gracias a la COVID), por lo que hemos tenido muy pocas oportunidades para medir y experimentar con esto.
Lo que descubrimos es que, incluso con nuestros recursos de hardware mejorados (6+4 vCores y 16+8 GB de RAM), una audiencia moderadamente activa puede generar 429 errores de congelación en el cliente. Vimos esto en los partidos de la U20 WC, que atrajeron aproximadamente el 50 % de nuestra audiencia habitual de juegos para los chats.
Tras medir, probar y cometer errores, hemos optado por los siguientes ajustes:
Esto parece eliminar el 80 % de los errores 429, lo que permite una experiencia relativamente fluida para la mayoría de los usuarios.
El siguiente paso habría sido adquirir otro tipo de recursos de hardware, ya sea utilizando servidores dedicados para velocidad de un solo hilo o cambiando a un proveedor de VPS que ofrezca planes con una cantidad enorme de vCores. Sin embargo, para nosotros, el siguiente paso es trabajar con el equipo de alojamiento de Discourse, como sugirió @sam antes.
Esperamos que estos ajustes sean útiles para @iceman, @alec o cualquier otra persona. Asegúrate de vigilar el uso de la CPU y la cola de procesamiento. Además, lo que aprendí de esta experiencia es que dos contenedores son mucho mejores que uno: los ajustes se pueden aplicar con un tiempo de inactividad casi nulo y los recursos de hardware se aprovechan de manera más granular.
Sigo interesado en cualquier nuevo ajuste o hallazgo que pueda ayudar a mejorar el rendimiento y la experiencia de usuario en discusiones rápidas impulsadas por eventos del mundo real.
