Usando Jmeter para pruebas de rendimiento

Transcripción

1 Usand Jmeter para pruebas de rendimient F. Javier Diaz Claudia M. Tzancff Banchff Anahí S. Rdríguez Valeria Sria {jdiaz, cbanchff, anahi, LINTI. Fac. de Infrmática, Universidad Nacinal de La Plata. La Plata, 1900, ARGENTINA Abstract Prducing high quality sftware [1] implies develping systems which fulfill all the specified r implicit needs established by the user. The sftware prcess is cnfrmed by seven stages: Requirements analysis Specificatin Design and architecture Prgramming Testing Dcumentatin Maintenance. Sftware testing can be made in different stages f this prcess. It is imprtant t emphasize n it being perfrmed in early stages, s as t cnditin the psterir develpment. When dealing with a web applicatin, there are many aspects t analyze. Apart frm the functinal nes. Many are related t the specificatin and functinal custmizatin f the system, but there are ther aspects related t the perfrmance f the server, ease f navigatin, security aspects, etc. The gal f this article is t emphasize n the testing prcess f the use f a tl [2] which simplifies the analysis. We tk as pilt case the analysis f the perfrmance f a cntent manager implemented by the UNLP. Key wrds: Quality, Testing, Perfrmance Tests, Web applicatins.

2 Resumen Prducir sftware de alta calidad [1] implica desarrllar sistemas que cumplan cn la ttalidad de las necesidades especificadas implícitas establecidas pr el usuari. El prces de sftware cnsta de siete etapas: Análisis de requisits Especificación Diseñ y Arquitectura Prgramación Prueba Dcumentación Mantenimient. Las pruebas del sftware pueden realizarse en distintas etapas de este prces. Se destaca la imprtancia de que las mismas se realicen en etapas tempranas, pudiend est, bviamente, cndicinar el psterir desarrll. Cuand se trata de una aplicación web, existen varis aspects adicinales a analizar, además de ls funcinales. Muchs tienen que ver cn la especificación y adecuación funcinal del sistema, per hay trs aspects que tienen que ver cn la perfmance del servidr, la facilidad de navegación, aspects de seguridad, etc. El bjetiv de este artícul es destacar en el prces de testing el us de una herramienta [2] que simplifique el análisis. Se tmó cm cas pilt, el análisis de rendimient de un manejadr de cntenids implementad pr la UNLP. Palabras Claves: Calidad, Testing, Pruebas de Rendimient, Aplicacines web. Intrducción Las pruebas de rendimient realizads sbre cmputadras, redes, sftware u trs dispsitivs, sn utilizads para determinar la velcidad y eficiencia de ls misms. Este prcedimient puede invlucrar tant tests cuantitativs, pr ejempl, medir tiemps de respuesta cantidad en millnes de líneas de códig, cm tests cualitativs, en ls cuales se evalúa fiabilidad, escalabilidad e interperabilidad. Estas pruebas de rendimient pueden ser realizadas a través de herramientas que prveen pruebas de estrés, que permiten determinar la estabilidad del sistema. [3] [4] Las limitacines en ls tiemps de respuesta de un siti web y una aplicación de escritri sn similares, y n han cambiad en el transcurs de ls añs. Cabe aclarar que en la cas de ls sitis web el tiemp está muy relacinad a la velcidad del enlace dnde se esté navegand.

3 Según el autr Jakb Nielsen, en el libr Usability Engineering [5] existen tres límites imprtantes en el tiemp de respuesta: [6] [7] 0,1 segund: es el límite en el cual el usuari siente que esta manipuland ls bjets desde la interfaz de usuari. 1 segund: es el límite en el cual el usuari siente que está navegand libremente sin esperar demasiad una respuesta del servidr. 10 segunds: es el límite en el cual se pierde la atención del usuari, si la respuesta tarda más de 10 segunds se deberá indicar algún mecanism pr el cual el usuari pueda interrumpir la peración. En nuestr cas particular, este tiemp está cndicinad a ls siguientes punts: El servidr testead se encuentra en la misma red en la cual se realizarn las pruebas. Velcidad de cnexión del servidr. Velcidad de cnexión del cliente. Tiemp en el cual el navegadr web tarda para dibujar la página (tiemp muy pequeñ). Rendimient de la red en el mment de la prueba. Características de la Prueba En esta sección se describirá tant la herramienta utilizada cm las pruebas realizadas. La herramienta Para analizar el tiemp de respuesta del servidr se utilizó la herramienta Jmeter [8]. La versión utilizada de Jmeter durante este trabaj es la Jmeter es una herramienta pen surce muy cmpleta, implementada en Java que permite realizar test de cmprtamient funcinal y medir el rendimient. También se puede utilizar para realizar pruebas de estrés, pr ejempl, en un servidr, y pner a prueba su rendimient [9]. Para estas pruebas, se cnfiguró un servidr Prxy que prvee Jmeter, para pder cnstruir un camin de navegación aleatri, y así simular la visita de un usuari.

4 Para pder evaluar ls resultads se utilizarn 3 (tres) cmpnentes prvists pr la herramienta[10] [11]. Summary Reprt: Permite visualizar ls resultads del test realizad, en una tabla. Ls dats que presenta sn: Label: etiqueta de la muestra #Muestras: cantidad de thread utilizads para la URL. Media: tiemp prmedi en milisegunds para un cnjunt de resultads. Min: tiemp mínim que demra un thread en acceder a una página. Max: tiemp máxim que demra un thread en acceder a una página Rendimient: rendimient medid en ls requerimient pr segund / minut / hra. Kb/sec: rendimient medid en Kbytes pr segund. Media en bytes: tamañ medi de respuesta del servidr (en bytes). Agreggate Graph: Esta cmpnente es similar a la anterir, per permite btener resultads más preciss. Utiliza más memria, ya que calcula la mediana y la línea al 90%, la cual requieren que tds ls dats estén almacenads. Ls dats que se presentan sn: URL : etiqueta de la muestra #Muestras: cantidad de Thread utilizads para la URL. Media: tiemp prmedi en milisegunds para un cnjunt de resultads. Mediana: valr en tiemp del percentil 50. Línea de 90%: máxim tiemp utilizad pr el 90% de la muestra, al rest de la misma le llev más tiemp. Min: tiemp mínim de la muestra de una determinada URL. Max: tiemp máxim de la muestra de una determinada URL. %Errr: prcentaje de requerimients cn errres. Rendimient: rendimient medid en ls requerimient pr segund / minut / hra. KB/sec: rendimient medid en Kbytes pr segund.

5 Grafic de Resultads: Esta cmpnente permite visualizar gráficamente ls siguientes dats: media, mediana, dispersión y el rendimient (representad cm el númer actual de requerimients/minuts que el servidr maneja). La Prueba La prueba realizada cnsistió en definir 3 tests de 100, 50 y 25 threads cada un, ls cuales simulan 100, 50 y 25 access de usuaris respectivamente. Se definiern una lista de enlaces a ls que se simuló el acces aleatri y a partir de ahí, se reclectarn ls dats necesaris para su interpretación. El análisis Se analizarn ls resultads a través de un interval de cnfianza 1 cn un nivel de cnfianza al 95%. Para un primer análisis, se supne que la pblación tiene una distribución Nrmal. Para un segund análisis, dad que la muestra es grande, n se requiere hacer la supsición de que la muestra tiene una distribución Nrmal ya que pr el Terema Central del Límite (TCL), para n grande implica que X tiene una distribución aprximadamente Nrmal sin imprtar la naturaleza de la distribución pblacinal [12]. 1 Se llama interval de cnfianza a un interval de valres alrededr de un parámetr muestral en ls que, cn una prbabilidad nivel de cnfianza determinad, se situará el parámetr pblacinal a estimar. [13].

6 Resultads Detallads Prueba Nr. 1 La primera prueba fue realizada el día 10/06/08 a las 16:07 hs, Se cnfigurarn 50 threads, cada 1 seg. Ls valres ttales btenids pr la cmpnente Aggregate Graph se muestran en la Tabla 1. # Muestras Media Mediana Línea de 90% Min Máx % Errr Rendimient Kb/sec TOTAL % 8,3/sec 79 Tabla 1: Valres crrespndientes a la Prueba 1. Cm puede verse, el tiemp prmedi para acceder a una página es 5,405 segunds, realizándse un ttal de 3850 requerimients al servidr. El tiemp ttal utilizad para ls 50 threads se puede calcular cn la siguiente fórmula: Tiemp Ttal = #Muestras * Media = 3850 * 5405 = milisegunds manera: El tiemp prmedi ttal requerid pr cada thread, se puede calcular de la siguiente ((Tiemp Ttal /1000)/60)/cantidad de Thread = (( /1000)/60)/50=6, minuts Análisis realizad En primer lugar se evaluarn ls resultads btenids a través de un interval de cnfianza para una distribución Nrmal al 95%. La fórmula del mism es la siguiente: [ TP Z 0.95 * D/ n, TP + Z 0.95 * D/ n ] Dnde: Tiemp prmedi (TP) de respuesta es: 5405

7 Desviación (D) es: Tamañ de la muestra (n) es de: 3850 Z 0.95 : 1,96 El interval resultante es el siguiente: [ ,96 * 11443/ 3850, ,96 * 11443/ 3850 ] = [5043, ; 5766, ] en milisegunds. = [5, ; 5, ] en segunds. Pr l tant, se puede esperar que el tiemp de respuesta prmedi esté entre 5 y 5,7 segunds para una cantidad de 50 usuaris simultánes realizand 3850 slicitudes. En segund lugar, se evaluarn ls resultads btenids a través de un interval de cnfianza al 95% para muestras grandes. La fórmula del mism es la siguiente: Dnde: [ TP Z 0.95 * S/ n, TP + Z 0.95 * S/ n ] Tiemp prmedi (TP) de respuesta es: 5405 Estimadr del Desví (S) es: ( Σx 2 ( Σx) 2 /n)/n 1) = 85971,17312 Tamañ de la muestra (n) es de: 3850 Z 0.95 : 1,96 El interval resultante es el siguiente: [ ,96 * 85971,17312/ 3850, ,96 * 85971,17312/ 3850 ] = [ 2689, ; 8120, ] en milisegunds. = [ 2, ; 8, ] en segunds. En este cas, se puede esperar que el tiemp de respuesta prmedi esté entre 2 y 8 segunds para una cantidad de 50 usuaris simultánes realizand 3850 slicitudes.

8 Prueba Nr. 2 La segunda prueba fue realizada el día 11/06/08 a las 11:12 hs, se cnfigurarn 25 threads, cada 1 seg. Se utilizó la misma lista de enlaces utilizada en la Prueba Nr. 1. Ls valres ttales btenids pr la cmpnente Aggregate Graph se muestran en la Tabla 2. #Muestras Media Mediana Línea de 90% Min Máx % Errr Rendimient Kb/sec TOTAL % 11,7/sec 111,8 Tabla 2: Valres crrespndientes a la Prueba 2. Cm puede verse en la tabla anterir, el tiemp prmedi para acceder a una página es 1,294 segunds, realizándse un ttal de 1925 requerimients al servidr. El tiemp ttal utilizad para ls 25 threads y el requerid para cada thread se calcularn de la misma manera que en la Prueba 1: Tiemp Ttal = #Muestras * Media = 1925 * 1294 = milisegunds ((Tiemp Ttal /1000)/60)/cantidad de Thread = (( /1000)/60)/50=1,66063 en minuts Análisis realizad El análisis para la segunda prueba, fue realizad de manera similar que en la primera, usand las mismas fórmulas. El interval resultante, utilizand un interval de cnfianza para una distribución Nrmal al 95%, es: [ ,96 * 8783/ 1925, ,96 * 8783/ 1925 ] = [ 902, ; 1687, ] en milisegunds = [ 0, ; 1, ] en segunds

9 Est significa que, puede esperarse un tiemp de respuesta prmedi entre 0,9 y 1,7 segunds para una cantidad de 25 usuaris simultánes realizand 1925 slicitudes. Cn un interval de cnfianza al 95% para muestras grandes, el interval resultante es el siguiente: [ ,96 * 56413,6792/ 1924, ,96 * 56413,6792/ 1924] = [ 1225, ; 3815, ] en milisegunds. = [ 1, ; 3, ] en segunds. Cm el límite inferir es negativ, y la medida del tiemp nunca puede ser negativa, se puede esperar que el tiemp de respuesta prmedi esté entre 0 y 3,8 segunds para una cantidad de 25 usuaris simultánes realizand 1295 slicitudes. Prueba Nr. 3 La tercera prueba fue realizada el día 11/06/08 a las 12:08 hs, se cnfigurarn 100 threads, cada 1 seg. Se utilizó la misma lista de enlaces utilizada en la Prueba Nr. 1. La Tabla 3 muestra ls valres btenids de la cmpnente Aggregate Graph. #Muestras Media Mediana Línea de 90% Min Máx % Errr Rendimient Kb/sec TOTAL ,42 % 5,7/sec 102,5 Tabla 3: Valres crrespndientes a la Prueba 3. Cm puede verse en la tabla anterir, el tiemp prmedi para acceder a una página es 12,526 segunds, realizándse un ttal de 7300 requerimients al servidr. El tiemp ttal utilizad para ls 100 threads es de milisegunds y el tiemp prmedi ttal requerid pr cada thread es de 15,23996 en minuts.

10 Análisis realizad Cm en las pruebas anterires, se calcularn ls intervals en base a un interval de cnfianza para una distribución Nrmal al 95% y en base a un interval de cnfianza al 95% para muestras grandes. Ls dats btenids sn: [ 11, ; 13, ] en segunds para el primer cas y, [ 7, ; 17, ] en segunds para el segund. Pr l tant, se puede esperar que el tiemp de respuesta prmedi esté entre 11 y 13 segunds para una cantidad de 100 usuaris simultánes realizand 7300 slicitudes y que el tiemp de respuesta prmedi esté entre 7,8 y 17,2 segunds para la misma cantidad de muestras. Resultads Generales Cm se mencinó al cmienz de este artícul, Jmeter prvee una cmpnente que permite visualizar ls dats btenids en frma gráfica. Gráfics Obtenids Las Figuras 1, 2 y 3 muestran ls dats btenids para la prueba 1, 2 y 3 respectivamente.

11 Figura 1: Valres crrespndientes a la Prueba 1. Figura 2: Valres crrespndientes a la Prueba 2.

12 Figura 3: Valres crrespndientes a la Prueba 3. Tabla Cmparativa La Tabla 4 permite bservar un resumen de ls dats infrmads pr las pruebas anterires: # Thread # muestras Rendimient Tiemp medi de Respuesta Dispersión % Errr ,262/min ,30% ,825/min ,30% ,69/min ,42% Tabla 4: Dats btenids en las tres pruebas Un resumen de ls dats estadístics analizads pueden verse en la Tabla 5. #Thread IC Distribución Nrmal al 95% IC al 95% usand TCL 25 [0, ; 1, ] en seg [ 1, ; 3, ] en seg 50 [5, ; 5, ] en seg [2, ; 8, ] en seg 100 [11, ; 13, ] en seg [7, ; 17, ] en seg Tabla 5: Dats estadístics en las tres pruebas

13 Cnclusión Si bien la etapa de pruebas funcinales de una aplicación sn sumamente imprtantes, ya que a partir de las mismas se pdrá cntar cn la aprbación del usuari final, el tip de pruebas mencinadas en el presente artícul sn también críticas. Una mala cnfiguración del servidr web, de la red dnde crrerá el mism (cn la aplicación residente en él) puede influenciar negativamente el us de la misma. En este trabaj se evaluó la utilización de la herramienta Jmeter, para la etapa de teste de rendimient del servidr web del siti de la Universidad Nacinal de La Plata. Al tratarse de un prtal al cual acceden muchs usuaris en frma simultánea, es indispensable estar segurs de una buena cnfiguración del servidr dnde crrerá. Las primeras pruebas realizadas diern tiemps de respuestas pc aceptables para una cierta cantidad de usuaris cncurrentes. El us de la herramienta JMeter fue de gran ayuda para realizar estas pruebas, gracias a su flexibilidad de cnfiguración y claridad de visualización de ls resultads de las pruebas, l que ayuda a su interpretación. A partir del análisis de ests dats y, teniend en cuenta ls parámetrs sugerids desde el área HCI [5] se sugirió al grup de desarrll una recnfiguración del servidr web hasta alcanzar ls valres óptims de tiemp de respuesta. Referencias [1] ISO [2] [3] [4] [5] Usability Engineering autr: Jakb Nielsen, publicad pr: Mrgan Kaufmann, San Francisc, 1994.ISBN [6] [7]

14 [8] [9] [10] [11] Testes de Desempenh cm Tidia Ae e Sakai Utilizand Benchmark Jmeter. Tiag Caminha Gaspar; Sandr Lpes Bianchini; Flávia Linhalis; César August Camill Teixeira; Maria da Graça Camps Pimentel. ae%20ii%20 %20Lince/relatris/relatri.pdf [12] Prbabilidades y Estadísticas para Ingeniería y Ciencias 6ta edición Jay L. Devre [13]