in ,

De qué ha servido la prueba de estrés de AQ

De qué ha servido la prueba de estrés de AQ
 

Blizzard ha publicado un post en el que nos cuentan de qué les ha servido la prueba de estrés de AQ y nos agradecen las pruebas porque han sido un éxito. Además, también celebrarán otra el día 25 a la misma hora (00:00 CEST).

 

De qué ha servido la prueba de estrés de AQ

Fuente traducida

¡Hola a todos!

Quiero agradecer personalmente a todos los que vinisteis a ayudar con las pruebas de estrés el otro día. Todo el equipo de WoW Classic estaba dentro, y de verdad que disfrutamos nuestras interacciones con vosotros.

Estos son uno detalles más sobre las pruebas.

Lo que vimos

Mucha gente preguntaba durante las pruebas que el rendimiento iba a ser malo en la versión en vivo, mientras que algunos bromeaban de que ya estaba listo y que lo lanzáramos ya. ¿O no era broma? Después de todo, la experiencia de nuestra prueba de estrés no era muy diferente a la apertura de las puertas de AQ original de 2006. Hubo mucho lag, crasheos de servidores y cuando los jugadores se dieron por vencidos la población disminuyó, y el evento se completó. Estamos planeando mejorar esto, pero no seremos capaces de eliminar el lag por completo.

Quiero agradecer especialmente a todos los jugadores que estaban atascados en las rutas de vuelo, porque descubrimos y arreglamos ese problema. Al igual con otros muchos problemas, una vez descubrimos la raíz del mismo, no era muy complicado arreglarlo y encima parecía contribuir a otros problemas. Así que a todos los que visteis un popurri de geometría al final de la ruta de vuelo: gracias; has hecho que la experiencia general sea mucho mejor.

Si aguantaste hasta las 2:00 CEST, nuestras condiciones de las pruebas cambiaron a un punto en el que el lag estaba siendo parecido al que verías en la versión en vivo. No nos queda otra que dar un poco de lag de servidor por la densidad de población. Cuando más gente, más lag, y en algún momento, con tantos jugados en el mismo área, el lag lleva a ser tan malo que el servidor cree que está muerto (la forma bonita de decir que está «atascado y sin pode recuperarse») y se reinicia.

Un reinicio porque el servidor se piensa que está muerto es un crasheo, pero presenta un reto especial. Otro tipo de crasheos pasan cuando un programa intenta hacer algo muy malo, así que descubrimos esa cosa muy mala, y la arreglamos y ya. Las muertes de servidor son un reto peor porque no es un solo problema, son un montón de trabajos yendo a más y más. Todavía quedan mejoras que podemos hacer para solucionarlo.

Densidad de población

Nuestro primer problema es uno de escalada exponencial. Imagina una ventisca que golpea a 10 jugadores, que les aplica un aura a cada uno, reduciendo su movimiento (porque tienes puesto el talento para la ralentización, ¿no?). Por cada jugador que recibe el aura de ralentización, también tenemos que mandar un mensaje a los jugadores cercanos para avisarles de que se ha aplicado el aura. Lo que acaba siendo un total de 100 mensajes. 10 jugadores afectados enviando 10 mensajes cada uno (uno a la persona que lanza ventisca, y otros nueve a los otros jugadores afectados por la ventisca).

Si hay 20 jugadores presentes para que les golpee la ventisca, son cuatro veces más mensajes. Si golpea a cuarenta, pues son mil seiscientos mensajes. Duplicar la cantidad de jugadores multiplica la carga de trabajo por cuatro. Ir de diez jugadores en un área a mil hace que pasemos de enviar cien mensajes a diez mil por un único hechizo. Ya tenemos un hardware muy potente, así que es cuestión de entender cuántos jugadores podemos aguantar sin que muera el servidor, que era el objetivo de la prueba de estrés, y hemos obtenido datos bastante buenos gracias a todos los que entrastéis.

Optimizando el código

Esto lleva en marcha desde el 2004, y estos últimos meses hemos estado optimizando código con este evento en mente. Aquí tenéis algunos ejemplos.

Primero, vamos a considerar el aura de ralentización. ¿Y si no enviamos todos los mensajes de actualización del aura de inmediato? Si golpeas a cien personas con ventisca, ¿de verdad necesitas saber el segundo exacto en el que cada uno de ellos tienen el aura de ralentización aplicada? El servidor lo sabrá de inmediato, claro, así que aura hará efecto y les ralentizará, pero si tu no ves el aura en uno o dos segundos, ¿pasa algo? Si eso significa que el servidor no crashea nuestra respuesta es que sí, así que hemos permitido que se retrasen los mensajes de las auras. Y esto también tiene otro beneficio adicional, porque si otra actualización de aura ocurre mientras la primera está esperando para enviarse, podemos combinar esos mensajes y enviar menos en total. El resultado es que hay menos paquetes circulando por la red, y menos trabajo en el servidor.

Otra optimización de código que probamos el otro día tenía que ver con el verse. La pieza de información que indica hacia dónde está mirando un jugador. ¿Qué pasa si ralentizamos o dejamos de actualizador los mensajes de dirección cuando la población llega a un punto determinado? El coste es pequeño: los jugadores van transportándose un poco cuando se mueven. Cuando una zona está sobrepoblada, los jugadores ya petardean mientras se mueven, así que esto puede ser un aumento general del rendimiento sin ningún efecto visible. De hecho, creo que vi que los jugadores petardeaban menos con esta optimización de lo que lo habrían hecho si no estuviera.

También hemos mejorado el rendimiento de decidir a quién mandar los mensajes. Cuando hay miles de jugadores reunidos en un área, ya solo decidir quién necesita saber sobre tus actualizaciones de aura y la dirección a la que te mueves es mucho trabajo, así que lo hemos mejorado también.

Mover a jugadores

Cuando arreglamos los problemas anteriores, teníamos que considerar esto. Cuando se abrió por primera vez en 2006 el evento de AQ, teníamos MJ transportando manualmente fuera de la zona para que el evento progresara. Más tarde, los diseñadores hicieron un sistema automático que transportaba al jugador fuera. Hoy tenemos transportes automáticos que funcionan bastante bien, y los utilizaremos para controlar la zona para que si lleva a su límite no lo traspase. Silithus va a estar lagueada, pero preferimos transportar jugadores a que crashee el servidor.

Este evento abarca mucha parte del sur de Kalimdor, así que no tener acceso a Silithus no significa que te pierdas el evento. Hay Anubisath y Silítidos para matar en Tanaris, las Mil agujas, Feralas y los Baldíos durante las 10 horas siguientes a golpear el gong.

De nuevo

Las pruebas de ayer nos distéis una muy buena idea de cuáles deberían ser esos límites, y cómo recuperarnos de un crash, pero nos gustaría saber más, por eso vamos a hacer otra prueba el jueves 25 de junio a la misma hora (00:00 CEST). Intentaremos completarlo más rápido esta vez, ya que esta vez debería haber menos investigación y menos interrupciones.

Esperamos veros a todos.

 
 

Written by Keph

Deja una respuesta

Vendedor de Corruptos

Vendedor de Corruptos hasta el 23/24 de Junio

Destripes de la Alianza durante el Parche Pre-expansión

Destripes de la Alianza durante el Parche Pre-expansión