Feda /dev/ - No Javascript allowed

#59460 ¿Cuando dice "tournament update requests" se refiere a que se updatea el leaderboard o que los clientes piden actualizaciones?

Sea como sea, si lila es el cuello de botella, una solución sería replicar los datos cacheados. Tienes una fuente de la verdad que se va actualizando con datos del torneo y cada acualización updatea las cachés. Cuando un cliente pide los datos del torneo un load balancer los distribuye entre las réplicas.

#59461 #59463 es como funciona un servicio de lichess, para jugar torneos https://github.com/lichess-org/lila-http/blob/master/README.md

la arquitectura cada caja con un nombre es un servidor

asi que si, podria decirse que es un "single instance" mal provisionado xq es un monolito y no se puede escalar muy bien. aun asi, yo creo que se soluciona:

• haciendo push de eventos, si es un torneo no necesitas hacer polling, cuando la partida termina haces push
• teniendo una cache dedicada para los torneos mas grandes, fijaros en el diagrama como de lila-http va a una redis y de la redis a lila (que es el backend) y de ahi a db.

a mi esta solución me parece horrible, xq bien si desacoplas las peticiones HTTP de lila, el backend, pero estas golpeando la misma redis... y haciendo push en lugar de poll lo solucionas todo. si estas jugando un torneo te interesa saber los resultados de otras partidas, y entiendo que cada 4 segundos es para poder subscribirte a otras partidas y mirar como van, yo creo que esto es otro caso de uso.

#59466 no hace falta tanto, con hacer un push a una cache de los resultados/partidas del torneo es suficiente y luego habria que ver que otros cuellos de botella hay. como lo que comento de querer seguir las partidas de tu torneo... pero eso ya es otro caso de uso, el de espectador.

lo comparto porque liches lo lleva un tio y esta todo en Scala, y ahora también rust:

y me he mirado un poco las cosas y tampoco es que esten muy alla... esto mismo esta mal diseñado, de que te sirve meter rust??? si vas a hacer polling igual

#59462 si es tan fácil como tener una cache para los torneos en curso que se vaya limpiandono haciendo push desde el server... si total, todos los movimientos y partidas pasan por el server principal, no hace falta ni crear eventos, push directo a la cache del torneo y de ahi se lee.

#59468 lo que dices no tiene sentido, q quieres decir "tener 5k conexiones abiertas y hacer push"? las conexiones tcp se re-utilizan y en este caso estarías pusheando a tu propia redis... escalas la redis o la cache que quieras poner y punto.

y para resolver los get al backend/db cambia el polling por un push, asi solo haces polling de la redis.

antes:

client => redis cache miss => lila => db (cada 4s)
client => redis cache hit

ahora:

client => redis <= lila push (cada 4s o cada evento importante como fin de una partida)

y es imposible que haya un miss si inicializas los torneos desde lila, no habra un torneo que no exista en la cache de torneos.

el problema es que el refresco de 4s no lo soporta su lila/db y ademas, intuyo que la redis se les queda pequeña y necesitaran escalar horizontal.

#59469 Pensé que hablabas de hacer push del servidor al navegador, con WebSockets.

Edit: Pero vamos, que tienes el mismo problema. Alguien tiene que leer de ese Redis, cuando el JSON de respuesta es lo que podría estar cacheado y lo podría servir Varnish mucho más rápido.

Con Varnish puedes invalidar la caché y seguir sirviéndola mientras se regenera, generando una única petición al servidor de aplicación.

Si los 17K están pidiendo lo mismo cada 4s, varnish les vale, pero es que hasta un cloudfront les valdría si no quieren gestionar nada.

#59482 Que pesado eres compañero con Varnish, que la solución primero es cambiar el push por polling en el backend. Da igual si usas Varnish o no si todo son cache misses.

#59484 Que las partidas son en tiempo real, en 4s si tienes cientos de partidas todo sera miss... no has jugado a blitz en tu vida no? una partida son 3 minutos, con incremento de +2 segundos por movimiento, pon que una partida te dura unos 5 minutos de media... con 4s ya es un buen average de tiempo por jugada, pero en los momentos finales de la partida que vas volando las partidas no puedes hacer nada.

Tanto al principio como al final de la partida donde tendrás varios movimientos por segundo si alguien esta en espectador se le congelara. Por eso comente que el problema de spectator es mejor tratarlo de otra manera y lo mejor es tener push del server a la cache del estado de las partidas.

Y en los momentos intermedios de la partida en medio juego donde mas vas a pensar, pon 10-20segundos incluso, entonces vas a hacer 4 polls que no valen nada que van a dar en la cache...

El problema a resolver es tener una cache para partidas en tiempo real eficiente y maximizar la UX. Ubicate fpero.

Os recuerdo que no por escribir "tochos" vais a llevar la razón. Un saludo y buen viernes.

#59488 Yo que tú me leería el problema de nuevo. Es lo típico de juniors, les piden algo concreto y se ponen a soltar chorraditas genéricas del estilo “para mí Redis y Varnish es lo mismo”, “caché abstracta”.

Soluciones concretas a problemas reales.