Pruebas de stress con JMeter
Hace un tiempo escribí un post sobre como hacer pruebas de stress con JMeter, pero hace no mucho, lanzaron una actualización y ahora hay cosas que funcionan un poco diferentes.
Para comenzar, debemos descargar JMeter de su web oficial
Debemos descargar la versión ZIP o TGZ del la sección de Binarios. Y tal como dice el requerimiento, debemos tener instalado Java 8 o superior.
Una vez descargado, debemos descomprimirlo. Para ejecutarlo, debemos entrar a la carpeta BIN y ejecutar el archivo llamado «jmeter.bat»
El motivo por el cual ejecuto el .bat y no el .jar, es porque el .bat abre una consola y esta abre el .jar. La consola sirve para que muestre el log de errores en caso de que algo falle en JMeter.
Agregaremos un nuevo grupo de hilos, para ello damos click derecho en nuestro test plan y luego vamos a ADD >> THREADS (USERS) >> THREAD GROUP
Este grupo de hilos contiene la información de cuantas veces vamos a querer que se ejecute una acción X. Es decir, indica cuantos usuarios vamos a simular que entran a una aplicación y cada cuanto tiempo.
En este ejemplo, vamos a ejecutar este hilo 100 veces (Number of Threads) al mismo tiempo (Ramp-up period) y esta repetición solo se va a efectura una sola vez (Loop Count)
Ahora vamos a agregar un HTTP Request, para indicarle a que URL debe hacerle esa cantidad de peticiones. Para ello damos click derecho en nuestro grupo de Hilos y vamos a: ADD >> SAMPLER >> HTTP REQUEST
Acá debemos prestar atención si es una petición de tipo GET o POST. En este caso haremos un GET al foro de Underc0de, por lo tanto completamos los siguientes campos: Protocol, Server Name, HTTP Request y Path.
En caso de ser un POST, deberíamos completar el body data con el JSON de la petición y las cabeceras con alguna Cookie, Token o lo que sea necesario para enviar dicho POST.
Por último, debemos agregar un Listener, que será el encargado de mostrarnos los resultados de la ejecución. Cabe aclarar que hay varios, cada uno para cosas distintas. Para este ejemplo voy a usar el más simple a modo de muestra. Para ello damos click derecho en el grupo de hilos y vamos a: ADD >> LISTENER >> VIEW RESULTS TREE
Lo único que resta, es clickear el ícono del PLAY de color verde y aguardar los resultados
Al finalizar la ejecución, podremos ver los resultados
Otro reporte muy útil y el cual recomiento agregar siempre, es el de «Sumary Report». Este reporte muestra de forma ordenada un poco más de información acerca de la ejecución y también cual es el porcentaje de error que arroja dicha prueba
Ahora que ya sabemos usar JMeter y ver los resultados de la ejecución, vamos a proceder a testear stress. Para esto, debemos ver cuantos usuarios soporta el foro al mismo tiempo. Esto se configura en nuestro Thread Group, incrementando el numero de usuario que entrarían al mismo tiempo hasta que comience a fallar.
En este caso, lo que hice fue aumentarlo de 100 a 200 y seguía funcionando bien, luego de 200 a 300 y falló, y lo bajé a 275 y tiró un 2.55% de error. Por lo que se puede concluir de que el foro de Underc0de soporta 270 usuarios entrando al mismo tiempo.
Al revisar el View Results Tree y analizar alguna petición fallida, pude ver de que los errores que arrojó, vienen de CloudFlare
Cloudflare es una especie de protección entre el usuario que intenta ingresar y el servidor. Al detectar que yo estoy enviando muchas peticiones al mismo tiempo, este me bannea. Es por ello que puede que este tirando error al pasar las 270 peticiones.
Lo más probable es que el servidor de Underc0de soporte más, pero Cloudflare lo frena. Para poder hacer más real la prueba, habría que desactivarlo mientras se prueba el stress en este sitio para determinar cuanta es la cantidad de usuarios real que soporta.
Algunas cosas a tener en cuenta al momento de probar stress
– Estas pruebas NO deben realizarse en producción
– Se debe ejecutar esta prueba en el flujo más pesado de la aplicación. En este caso apunté al inicio del foro, pero quizas lo correcto hubiese sido apuntar a una petición POST a la hora de crear un post, ya que debe ir y almacenar las cosas en la base de datos.
– Estas pruebas se realizan en un ambiente espejo a producción. Es decir, No se deben hacer ni en producción, ni en un servidor de QA o Desarrollo. Debe ser otro ambiente que tenga las mismas características que producción. De lo contrario, los datos que obtendremos no serán datos que escenarios que pasarán en producción.
