Diferencias entre Herramientas de Test de Performance

Introducción
Básicamente hay dos maneras de obtener indicadores de performance:

  • Fijar los usuarios concurrentes y medir los tiempos de respuesta de uno o más pasos por llamada/s (la experiencia del usuario, la cantidad de usuarios que supuestamente soporto concurrentes en línea)
  • Fijar la tasa de requests que se quiere obtener y medir los tiempos de respuesta (la experiencia del server con los usuarios arriba intentando ver mi contenido)

Hay dos herramientas Open Source que se utilizan habitualmente para fijar la cantidad de usuarios (o threads concurrentes) y medir tiempo de respuesta:

ab (Apache Benchmarking)
Línea de comandos, normalmente instalado por default cuando se instala Apache.

JMeter (Apache JMeter)
Mucho más sofisticada. Interfaz gráfica, Java, permite hacer varios pasos por llamada y varias llamadas, parseo de regular expressions, graduar cantidad de threads concurrentes, etc.

Diferencias entre AB y JMeter
En caso de querer comparar los resultados de un test de stress entre estas diferentes herramientas con el objetivo de que los resultados sean similares se sugiere leer esta breve descripción:

1) El testing con JMeter se lo debe ejecutar teniendo destildado en la pantalla HTTP Request http Client el checkbox: Recuperar todos los recursos empotrados en el archivo HTML (retrieve all embedded resources from html files) dado que AB sólo hace la llamada al HTML y no a lo que el mismo tiene embebido.

2) En JMeter el tester coloca Número de Hilos (threads) que es la Concurrencia y cantidad de pedidos (requests) que repite un usuario; la multiplicación de ambas nos da la muestra total de la prueba. Ej: 10 hilos x 10 req/hilo = 100 req totales de las 10 concurrencias (total de la muestra).

Por otro lado Apache Benchmarking, en cambio se colocan los siguientes valores:
ab –n(valor) –c(valor) http://hostname:port/path

Donde a diferencia de JMeter –n no es la cantidad de request por usuario sino la cantidad total de request de toda la concurrencia, es decir lo que para JMeter es la muestra total, mientras que –c es la Concurrencia (o Grupo de Hilos para JMeter).

De esta manera, para que las pruebas en las diferentes herramientas, se ejecuten con el mismo nivel de carga con el objetivo de validar los resultados entre ambas se muestra el siguiente ejemplo:
En JMeter                                                        En AB
Prueba 1: 30 hilos x 1 req/hilo = 30               ab -n 30 -c 30 http://hostname:port/path
Prueba 2: 30 hilos x 10 req/hilo = 300         ab -n300 -c30 http://hostname:port/path
Prueba 3: 30 hilos x 100 req/hilo = 3000      ab -n3000 -c30 http://hostname:port/path

Usando una u otra herramienta, siempre se sugiere tener un panorama bien amplio y probar:

  • URL de Home
  • URL de Nota / Aviso / Post
  • URL inexistente (Error 404) como una forma de medir cuanto le cuesta al webserver resolverlo

En la otra vertiente de fijar requests/segundo se encuentra otra herramienta Open Source:

httperf
Línea de comandos, la estamos usando en combinación con autobench (un script para automatizar ejecuciones sucesivas de httperf.
Desde el punto de la estabilidad, el uso de httperf permite encontrar más rápidamente los puntos de saturación que con las otras herramientas suele disimularse. Fundamentalmente porque la carga es un producto de la cantidad de usuarios concurrentes por los requests que realiza cada uno. Así que fijar una carga de esta manera implica cantidad de usuarios pero también un comportamiento esperado. En cambio, la tasa de requests por segundo bruta es un indicador más directo del umbral que soporta el server y de los efectos bola de nieve que se producen cuando se encuentra la saturación. Permitiendo encontrar además otros indicadores paralelos en CPU y memoria, pudiéndose validar la cercanía a un punto de quiebre/saturación directamente en un access.log.

Claro que existen también herramientas pagas -algunas incluso muy costosas- pero entendemos que, a menos que necesitemos alguna funcionalidad específica que estas herramientas puedan proveer, para las pruebas básicas de Performance que podemos hacer desde Testing, las mencionadas arriba son más que suficientes.

Las principales ventajas:

  • Son gratuitas
  • No requieren de demasiado tiempo ni esfuerzo para dominar sus funcionalidades básicas
  • Ofrecen flexibilidad para obtener reportes e información de performance con diferentes indicadores

En próximos posts iremos profundizando sobre algunas de las pruebas de performance típicas, como planificarlas, ejecutarlas, reportar y los aspectos a tener en cuenta en cada una.

 

 

Anuncios