Introduccin

Las pruebas de rendimiento realizados sobre computadoras, redes, soft

ware u otros dispositivos, son utilizados para determinar la velocidad y

eficiencia de los mismos. Este procedimiento puede involucrar tanto tests cu
antitativos, por ejemplo, medir tiempos de respuesta o cantidad en millones de ln
eas de cdigo, como tests cualitativos, en los cuales se evala fiabilidad,
escalabilidad e interoperabilidad. Estas pruebas de rendimiento pueden ser realiza
das a travs de herramientas que proveen pruebas de estrs, que permiten deter
minar la estabilidad del sistema.
12

Las limitaciones en los tiempos de respuesta de un sitio web y una aplicacin de e
scritorio son similares, y no han cambiado en el transcurso de los aos. Cabe aclar
ar que en la caso de los sitios web el tiempo est muy relacionado a la velocidad d
el enlace donde se est navegando. Segn el autor Jakob Nielsen, en el libro Us
ability Engineering
3
existen tres lmites importantes en el tiempo de respuesta:
45

0,1 segundo: es el lmite en el cual el usuario siente que esta manipulando
los objetos desde la interfaz de usuario.
1 segundo: es el lmite en el cual el usuario siente que est navegando libr
emente sin esperar demasiado una respuesta del servidor.
10 segundos: es el lmite en el cual se pierde la atencin del usuario, si la r
espuesta tarda ms de 10 segundos se deber indicar algn mecan
ismo por el cual el usuario pueda interrumpir la operacin.

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 prue
bas.
Velocidad de conexin del servidor.
Velocidad de conexin del cliente.
Tiempo en el cual el navegador web tarda para dibujar la pgina (tiempo mu
y pequeo).
Rendimiento de la red en el momento de la prueba.

1
http://en.wikipedia.org/wiki/Performance_testing
2
http://en.wikipedia.org/wiki/Stress_testing_%28software%29
3
Usability Engineering autor: Jakob Nielsen, publicado por: Morgan Kaufmann, San
Francisco, 1994.ISBN 0-12-518406-9
4
http://www.useit.com/alertbox/9703a.html
5
http://www.useit.com/papers/responsetime.html
Caractersticas de la Prueba
En esta seccin se describir tanto la herramienta utilizada como las pruebas reali
zadas.
La herramienta
Para analizar el tiempo de respuesta del servidor se utiliz la herramienta Jmeter
6
.
La versin utilizada de Jmeter durante este trabajo es la 2.11
Jmeter es una herramienta open source muy completa, implementada en Java que
permite realizar test de comportamiento funcional y medir el rendimiento. Tambin
se puede utilizar para realizar pruebas de estrs, por ejemplo, en un servidor, y po
ner a prueba su rendimiento
7
.
Para estas pruebas con el fin
de poder evaluar los resultados se utilizaron 3 (tres) componentes provi
stos por la herramienta
89
.
Summary Report: Permite visualizar los resultados del test realizado, en una ta
bla. 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 mnimo que demora un thread en acceder a una pgina.
o Max: tiempo mximo que demora un thread en acceder a una pgina
o Rendimiento: rendimiento medido en los requerimiento por segundo / minu
to / hora.
o Kb/sec: rendimiento medido en Kbytes por segundo.
o Media en bytes: tamao medio de respuesta del servidor (en bytes).
Agreggate Graph: Esta componente es similar a la anterior, pero permite obte
ner resultados ms precisos. Utiliza ms memoria, ya que calcula la mediana y la l
nea al 90%, la cual requieren que todos los datos estn 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.

6
http://jakarta.apache.org/jmeter/
7
http://www.osmosislatina.com/jmeter/basico.htm
8
http://jakarta.apache.org/jmeter/usermanual/component_reference.html
9
Testes de Desempenho com o Tidia-Ae e o Sakai Utilizando o Benchmark Jmeter. Tiago
Caminha Gaspar; Sandro Lopes Bianchini; Flvia Linhalis; Csar Augusto Camillo Teixeira; Maria
da Graa Campos Pimentel.http://lince.dc.ufscar.br/home/projetos/tidia-ae%20II%20-
%20Lince/relatorios/relatorio.pdf
o Lnea de 90%: mximo tiempo utilizado por el 90% de la muestra, al resto d
e la misma le llevo ms tiempo.
o Min: tiempo mnimo de la muestra de una determinada URL.
o Max: tiempo mximo de la muestra de una determinada URL.
o %Error: porcentaje de requerimientos con errores.
o Rendimiento: rendimiento medido en los requerimiento por segundo / minu
to / hora.
o KB/sec: rendimiento medido en Kbytes por segundo.

Grafico de Resultados: Esta componente permite visualizar grficame
nte los siguientes datos: media, mediana, dispersin y el rendimiento (representa
do como el nmero 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 a la pgina principal de la
revista vnculos respectivamente y luego se simula un inicio de sesin.
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 interpretacin.
El servidor contiene las siguientes caractersticas


El anlisis
Se analizaron los resultados a travs de un intervalo de confianza con un nivel de
confianza al 95%.
Para un primer anlisis, se supone que la poblacin tiene una distribucin Normal.
Para un segundo anlisis, dado que la muestra es grande, no se requiere hacer la
suposicin de que la muestra tiene una distribucin Normal ya que por el Teorema
Central del Lmite (TCL), para n grande implica que X tiene una distribucin ap
roximadamente Normal sin importar la naturaleza de la distribucin poblacional
10
.

Resultados Detallados

Prueba Nro. 1 =50 usuarios

La primera prueba fue realizada el da 03/03/2014 a las 10:33 am, Se configuraron
50 threads, cada 1 seg.

10
Probabilidades y Estadsticas para Ingeniera y Ciencias 6ta edicin Jay L. Devore
Los valores totales obtenidos por la componente Aggregate Graph se muestran e
n la Tabla 1.


Como puede verse, el tiempo promedio para acceder a una pgina es 0,1
53 segundos, realizndose un total de 7833 requerimientos al servidor a su vez el
tiempo promedio de logueo aumenta a 0.336 segundos.
El tiempo total utilizado para los 50 threads se puede calcular con la siguiente frm
ula:
Total Inicio = #Muestras * Media = 3937 * 0.130 = 511.81 milisegundos
Total Login = #Muestras * Media = 3926 * 0.312 = 1224,912 milisegundos

El tiempo promedio total requerido por cada thread, se puede calcular de
la siguiente manera:
Para Pagina Inicial
(Tiempo Total /1000)/cant Thread = (511.81 /1000)/50=0,0102362 seg.
Para Login
(Tiempo Total /1000)/cant de Thread = (1224.912 /1000)/50=0, 02449824 seg.

Summary Report



Grfico de Resultados



Prueba Nro. 2 =25 usuarios




El tiempo total utilizado para los 25 threads se puede calcular con la siguiente frm
ula:
Total Inicio = #Muestras * Media = 3961 * 0.051 = 202,011 milisegundos
Total Login = #Muestras * Media = 3955 * 0.123 = 486,465 milisegundos

El tiempo promedio total requerido por cada thread, se puede calcular de
la siguiente manera:
Para Pagina Inicial
(Tiempo Total /1000)/cant Thread = (202.011 /1000)/25= 0,0080844 seg.

Para Login
(Tiempo Total /1000)/cant de Thread = (486,465 /1000)/25=0, 0,0194586seg.


Summary Report

Grfico De resultados


Prueba Nro. 3 =100 usuarios




El tiempo total utilizado para los 25 threads se puede calcular con la siguiente frm
ula:
Total Inicio = #Muestras * Media = 4225 * 0.280 = 1183 milisegundos
Total Login = #Muestras * Media = 4197 * 0.577 = 2421,669milisegundos

El tiempo promedio total requerido por cada thread, se puede calcular de
la siguiente manera:
Para Pagina Inicial
(Tiempo Total /1000)/cant Thread = (1183 /1000)/100= 0,01183 seg.

Para Login
(Tiempo Total /1000)/cant de Thread = (2421,669/1000)/100= 0,02421669seg.

Summary Report



Grfico De resultados


Conclusiones
Los resultados de las pruebas nos demuestran casi un rendimiento ideal en las primeras
3000 peticiones, luego de estas peticiones los sockets en el servidor se reiniciaban lo que
iniciaba un porcentaje mnimo de error.
En vista que las pruebas se realizaron dentro de la misma red local , no se pueden
considerar como datos reales de rendimiento pero si como una referencia que indica que
el servidor se comporta de una manera normal con grandes cantidades de peticiones