PDF de programación - Usando Jmeter para pruebas de rendimiento

Usando Jmeter para pruebas de rendimiento

F. Javier Diaz

Claudia M. Tzancoff Banchoff

Anahí S. Rodríguez

Valeria Soria

{jdiaz, cbanchoff, anahi, valeria}@linti.unlp.edu.ar

LINTI. Fac. de Informática, Universidad Nacional de La Plata.

La Plata, 1900, ARGENTINA

Abstract

Producing   high   quality   software   [1]   implies   developing   systems   which   fulfill   all   the 

specified or implicit needs established by the user.

The software process is conformed by seven stages: Requirements analysis – Specification – 

Design and architecture – Programming – Testing – Documentation – Maintenance. 

Software testing can be made in different stages of this process. It is important to emphasize 

on it being performed in early stages, so as to condition the posterior development.

When dealing with a web application, there are many aspects to analyze. Apart from the 
functional ones. Many are related to the specification and functional customization of the system, 
but there are other aspects related to the performance of the server, ease of navigation, security 
aspects, etc.

The goal of this article is to emphasize on the testing process of the use of a tool [2] which 
simplifies the analysis. We took as pilot case the analysis of the performance of a content manager 
implemented by the UNLP.

Key words: Quality, Testing, Performance Tests, Web applications.

Resumen

Producir software de alta calidad [1] implica desarrollar   sistemas que   cumplan con la 

totalidad de las necesidades especificadas o implícitas  establecidas por el usuario.

El proceso de software consta de siete etapas: Análisis de requisitos ­ Especificación ­ 

Diseño y Arquitectura ­ Programación ­ Prueba ­ Documentación ­ Mantenimiento.

Las pruebas del software pueden realizarse en distintas etapas de este proceso. Se destaca la 
importancia   de   que   las   mismas   se   realicen   en   etapas   tempranas,   pudiendo   esto,   obviamente, 
condicionar  el posterior desarrollo.

Cuando   se trata de   una aplicación web, existen varios aspectos adicionales a analizar, 
además de los funcionales. Muchos tienen que ver con la especificación y adecuación funcional del 
sistema, pero hay otros aspectos que tienen que ver con la perfomance del servidor, la facilidad de 
navegación, aspectos de seguridad, etc.

El objetivo de este artículo es destacar en el proceso de testing el uso de una herramienta [2] 
que simplifique el análisis. Se tomó como caso piloto, el análisis de rendimiento de un manejador 
de contenidos implementado por la UNLP.
Palabras Claves: Calidad, Testing, Pruebas de Rendimiento, Aplicaciones web. 

Introducción

Las   pruebas   de   rendimiento   realizados   sobre   computadoras,   redes,   software   u   otros 
dispositivos,   son   utilizados   para   determinar   la   velocidad   y   eficiencia   de   los   mismos.   Este 
procedimiento puede involucrar tanto tests cuantitativos, por ejemplo, medir tiempos de respuesta o 
cantidad en millones de líneas de código, como tests cualitativos, en los cuales se evalúa fiabilidad, 
escalabilidad e interoperabilidad. Estas pruebas de rendimiento pueden ser realizadas a través de 
herramientas que proveen pruebas de estrés, que permiten determinar la estabilidad del sistema. [3] 
[4]

Las limitaciones en los tiempos de respuesta de un sitio web y una aplicación de escritorio 
son similares, y no han cambiado en el transcurso de los años. Cabe aclarar que en la caso de los 
sitios web el tiempo está muy relacionado a la velocidad del enlace donde se esté “navegando”. 

Según el autor Jakob Nielsen, en el libro “Usability Engineering”[5] existen tres límites importantes 
en el tiempo de respuesta: [6] [7]

•

•

•

0,1 segundo: es el límite en el cual el usuario siente que esta “manipulando” los objetos 
desde la interfaz de usuario.
1 segundo: es el límite en el cual el usuario siente que está navegando libremente sin esperar 
demasiado una respuesta del servidor.
10 segundos: es el límite en el cual se pierde la atención del usuario, si la respuesta tarda 
más de 10 segundos se deberá indicar algún mecanismo por el cual el usuario pueda 
interrumpir la operación.
En nuestro caso particular, este tiempo está condicionado a los siguientes puntos:

• El servidor testeado se encuentra en la misma red en la cual se realizaron las pruebas.
• Velocidad de conexión del servidor.
• Velocidad de conexión del cliente.
• Tiempo en el cual el navegador web tarda para dibujar la página (tiempo muy pequeño).
• Rendimiento de la red en el momento de la prueba.

Características de la Prueba

En esta sección se describirá tanto la herramienta utilizada como las pruebas realizadas.

La herramienta

Para analizar el tiempo de respuesta del servidor se utilizó la herramienta Jmeter [8]. La 

versión utilizada de Jmeter durante este trabajo es la 2.3.1.

Jmeter es una herramienta open source muy completa, implementada en Java que permite 
realizar test de comportamiento funcional y medir el rendimiento. También se puede utilizar para 
realizar pruebas de estrés, por ejemplo, en un servidor, y poner a prueba su rendimiento [9].

Para estas pruebas, se configuró un servidor Proxy que provee Jmeter, para poder construir 

un camino de navegación aleatorio, y así simular la visita de un usuario.

Para   poder   evaluar   los   resultados   se   utilizaron   3   (tres)   componentes   provistos   por   la 

herramienta[10] [11].

•

Summary Report:
 

  Permite visualizar los resultados del test realizado, en una tabla. Los datos 

que presenta son:

o Label: etiqueta de la muestra

o #Muestras: cantidad de thread utilizados para la URL.
o Media: tiempo promedio en milisegundos para un conjunto de resultados.

o Min: tiempo mínimo que demora un thread en acceder a una página.
o Max: tiempo máximo que demora un thread en acceder a una página

o Rendimiento: rendimiento medido en los requerimiento por segundo / minuto / hora. 
o Kb/sec: rendimiento medido en Kbytes por segundo.

o Media en bytes: tamaño medio de respuesta del servidor (en bytes).

• Agreggate Graph:

 

  Esta componente es similar a la anterior, pero permite obtener resultados 
más precisos. Utiliza más memoria, ya que calcula la mediana y la línea al 90%, la cual 
requieren que todos los datos estén almacenados. Los  datos que se presentan son:

o URL : etiqueta de la muestra

o #Muestras: cantidad de Thread utilizados para la URL.
o Media: tiempo promedio en milisegundos para un conjunto de resultados.

o Mediana: valor en tiempo del percentil 50.
o Línea de 90%: máximo tiempo utilizado por el 90% de la muestra, al resto de la 

misma le llevo más tiempo.

o Min: tiempo mínimo de la muestra de una determinada URL.
o Max: tiempo máximo de la muestra de una determinada URL.

o %Error: porcentaje de requerimientos con errores.
o Rendimiento: rendimiento medido en los requerimiento por segundo / minuto / hora. 

o KB/sec: rendimiento medido en Kbytes por segundo.

 

• Grafico de Resultados

 : Esta componente  permite visualizar  gráficamente  los siguientes 
datos: media, mediana, dispersión y el rendimiento (representado como el número actual de 
requerimientos/minutos que el servidor maneja).

La Prueba

La prueba realizada consistió en definir 3 tests de  100, 50 y 25 threads cada uno, los cuales 

simulan 100, 50 y 25 accesos de usuarios respectivamente.

Se definieron una lista de enlaces a los que se simuló el acceso aleatorio y a partir de ahí, se 

recolectaron los datos necesarios para su interpretación.

El análisis

Se analizaron los resultados a través de un intervalo de confianza1 con un nivel de confianza 

al 95%.

Para un primer análisis, se supone que la población tiene una distribución Normal. 
Para un segundo análisis, dado que la muestra es grande, no se requiere hacer la suposición 
de que la muestra tiene una distribución Normal ya que por el Teorema Central del Límite (TCL), 
para  n  grande implica que X   tiene una distribución aproximadamente Normal sin importar la 
naturaleza de la distribución poblacional [12].

1 Se llama intervalo de confianza a un intervalo de valores alrededor de un parámetro muestral en los que, con una probabilidad o 
nivel de confianza determinado, se situará el parámetro poblacional a estimar. [13]. 

Resultados Detallados

Prueba Nro. 1

La primera prueba fue realizada el día 10/06/08 a las 16:07 hs, Se configuraron 50 threads, 

cada “1 seg”. Los valores totales obtenidos por la componente “Aggregate Graph” se muestran en 
la Tabla 1. 

TOTAL

# Muestras

3850

Media
5405

Línea de 90%

Mediana
1078
Tabla 1: Valores correspondientes a la Prueba 1.

Min
0

15000

Máx

125360

% Error
1.3%

Rendimiento

8,3/sec

Kb/sec
79

Como puede verse, el tiempo promedio para acceder a una página es 5,405 segundos, 

realizándose un total de 3850 requerimientos al servidor.

El tiempo total utilizado para los 50 threads se puede calcular con la siguiente fórmula:

Tiempo Total = #Muestras * Media = 3850 * 5405 = 20809250 milisegundos

El tiempo  promedio total requerido por cada thread, se puede calcular de la siguiente 

manera:

((Tiempo Total /1000)/60)/cantidad de Thread = ((25535400/1000)/60)/50=6,936416 minutos

Análisis realizado

En primer lugar se evaluaron los resultados obtenidos a través de un intervalo de confianza 

para una distribución Normal al 95%. La fórmula del mismo es la siguiente:
[ TP  – Z 0.95 * D/√n, TP + Z0.95 * D/√n ]

Donde:

• Tiempo promedio (TP) de respuesta es: 5405

• Desviación (D) es: 11443.
• Tamaño de la muestra (n) es de: 3850
• Z0.95 : 1,96

El intervalo resultante es el siguiente:

 [ 5405 – 1,96 * 11443/√3850, 5405 + 1,96 * 11443/√3850 ] 
= [5043,535539 ; 5766,464461 ] en milisegundos. 
= [5,043535539 ; 5,766464461 ] en segundos. 

Por lo tanto, se puede   esperar que el tiempo de respuesta promedio esté entre 5 y 5,7 

segundos para una cantidad de 50 usuarios simultáneos realizando 3850 solicitudes. 

En   segundo   lugar,   se   evalu