Cómo ejecutar Stress/Load Tests desde la nube
Hoy vamos a ver como en algunos simples pasos podemos testear nuestra aplicación web, no importa su tecnología o donde esté alojada, usando todo el poder de la nube y de Visual Studio. Además, no vamos a necesitar instalar ningún tipo de software ya que lo haremos desde máquinas virtuales en Azure.
Si aún no tenés cuenta, te dejo algunas opciones para que empieces gratis:
Bien. Si tu cuenta ya está activa, entremos al portal de Azure en esta dirección: https://manage.windowsazure.com/.
Levantando el ambiente
Lo que vamos a hacer esencialmente es levantar una máquina de desarrollo en Azure, desde donde se ejecutarán las pruebas. Para ello, seguimos los siguientes pasos:
Dependiendo del tipo de pruebas que querramos hacer, necesitaremos una máquina poderosa. Yo elijo un A4 ya que pienso correr pruebas fuertes.
Con estas credenciales nos vamos a conectar vía Remote Desktop.
Una vez creada, tendremos un servicio como el siguiente, al cual nos conectamos de forma remota:
De ahora en adelante, trabajamos en la máquina en Azure
Subscriptores MSDN: directamente pueden hacer Sign in con su cuenta Microsoft. Para todo el resto, deben usar su cuenta de Visual Studio.
Ahora vamos a File > New > Project y elegimos Web Performance and Load Test Project.
Empecemos por crear un Web Performance Test común y silvestre
Aquí es donde empezamos a grabar nuestros escenarios. Básicamente, lo que hacemos es grabar un recorrido del sitio web para que luego Visual Studio lo repita decenas o hasta miles de veces en simultáneo. Las acciones pueden ser cualquiera: nos autenticamos, generamos requests, transacciones etc. Yo en particular únicamente tengo un sitio web que genera ciclos de procesamiento cuando me conecto, pero las variantes son infinitas y depende de tu negocio.
Grabemos la sesión:
Muestro el ejemplo más sencillo: sólo un request.
Perfecto. Ya creamos un caso automatizado de un usuario visitando un sitio, ahora lo que podemos hacer, es simular que cientos de ellos accedan en simultáneo a mi sitio:
Agregamos el WebTest que creamos anteriormente:
Como podes ver, este wizard te permite muchas alternativas. Generar olas, generar tráfico constante, configurar la duración, warm up y muchas otras cosas más. Todo esto, está mejor explicado acá: https://msdn.microsoft.com/en-us/library/vstudio/dd293540(v=vs.110).aspx.
Ya está creado, una vez que le demos Run, empezará a ejecutar. Mientras tanto, te cuento qué usé yo para testear:
Super inspirado, eh? Lo único que hace este programa es consumir ciclos. Lo voy a subir a Azure a un web role:
Ahora sí, lo corremos.
Resultados
Primero observemos el panel desde el lado de Visual Studio. Podrás ver valores como Key Indicators, Page Response Time, y muchos otros valores que son útiles para entender como se comportó la aplicación. Te recomiendo que lo pruebes por vos mismo y si tenés dudas leé esto: https://msdn.microsoft.com/en-us/library/vstudio/ee923686(v=vs.110).aspx.
Ahora, veamos la parte más interesante, los resultados a cara del “usuario final”.
Como podés ver más abajo, mi aplicación empezó a recibir una carga muy fuerte de usuarios alrededor de las 12:45. Mi ráfaga de 100 usuarios generando requests cada 1 segundo (cada uno) generó que se levante el CPU hasta el 63,58%.
No obstante, mi aplicación seguía responsiva y por los valores obtenidos en los Page Response Time determiné que este es un resultado aceptable. Notemos también los aspectos de capacity planning asociados con estos escenarios: simulo usuarios, calculo cantidad de instancias, proyecto en el largo plazo.
Avancemos con un caso menos feliz, ejecuto la misma prueba pero saturo al procesador. Inicio la prueba con 5000 usuarios (!) concurrentes haciendo requests cada 1 segundo.
Como podemos ver, el response time se vió durísimamente afectado. No bueno.
Una vez terminada la ráfaga, volvió a la normalidad:
Acá podemos ver la saturación del procesador
Y los resultados del test:
Escalemos
Intencionalmente, desactive el escalado de mis instancias de forma de tal de conocer la máxima capacidad de cada una. Ahora, lo que podemos hacer simplemente es escalar la cantidad de las mismas y averiguar cómo responde el mismo test. Para ello, lo que hago es simplmenente incrementar la cantidad de instancias a 2:
Ahora con 2 instancias, procedo a correr el mismo test exhaustivo. Además, configuré el balanceador de cargas para que use un algoritmo Round Robin (es decir, envíe un request alternando entre cada instancia).
Antes del test:
Durante el test:
Nuevamente, la performance parece verse afectada. No obstante, el tiempo de respuesta se redujo en un 50% al duplicar la cantidad de instancias (casualidad?).
Así se ve desde Azure:
Conclusiones
Con estos métodos podemos conocer hasta qué niveles nuestra aplicación soporta cargas exhaustivas externas. Con este conocimiento, podemos hacer una estimación mucho más precisa (y basada en hechos) de cuántas instancias necesitaremos asignar a nuestra aplicación para soportar un determinado nivel de servicio. Esto es crucial para aplicaciones que requiere alta disponibilidad. La mejor parte: podemos tener todo configurado en menos de media hora y evitamos instalar o comprar ningún tipo de software gracias al poder de Azure.