Pruebas de carga y stress

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:

image

image

Dependiendo del tipo de pruebas que querramos hacer, necesitaremos una máquina poderosa. Yo elijo un A4 ya que pienso correr pruebas fuertes.

image

Con estas credenciales nos vamos a conectar vía Remote Desktop.

image

image

image

Una vez creada, tendremos un servicio como el siguiente, al cual nos conectamos de forma remota:

image

image

image

image

image

De ahora en adelante, trabajamos en la máquina en Azure

image

image

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.

image

Empecemos por crear un Web Performance Test común y silvestre

image

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:

image

image

Muestro el ejemplo más sencillo: sólo un request.

image

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:

image

image

image

image

Agregamos el WebTest que creamos anteriormente:

image

image

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á:http://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:

image

image

Super inspirado, eh? Lo único que hace este programa es consumir ciclos. Lo voy a subir a Azure a un web role:

image

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: http://msdn.microsoft.com/en-us/library/vstudio/ee923686(v=vs.110).aspx.

image

image

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%.

image

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.

image

Como podemos ver, el response time se vió durísimamente afectado. No bueno.

Una vez terminada la ráfaga, volvió a la normalidad:

image

Acá podemos ver la saturación del procesador

image

Y los resultados del test:

image

image

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:

image

image

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:

image

Durante el test:

image

Nuevamente, la performance parece verse afectada. No obstante, el tiempo de respuesta se redujo en un 50% al duplicar la cantidad de instancias (casualidad?).

image

Así se ve desde Azure:

image

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.