You are on page 1of 34

MANUAL APACHE JMETER

Hola compañeros en el día de hoy vamos a trabajar con la aplicación JMETER. Antes de
empezar una introducción y la interpretación de lo que significa para nosotros.

INTRODUCCIÓN

El Apache JMeter es un software de código abierto, una aplicación diseñada


totalmente en JAVA para medir el rendimiento y comportamiento de servidores
mediante pruebas. Originalmente se diseñó para probar aplicaciones Web, pero se ha
ampliado desde entonces a otras funciones. Se utilizar para probar el rendimiento
tanto de los recursos estáticos y dinámicos (archivos, Servlets, scripts de Perl, objetos
Java, bases de datos - consultas, servidores FTP y mucho más). Se puede utilizar para
simular una carga pesada en un servidor, la red o un objeto para poner a prueba su
resistencia o para analizar el rendimiento global en diferentes tipos de carga. Puede
usarlo para hacer un análisis gráfico de rendimiento o para probar el comportamiento
de diferentes elementos con un gran volumen de carga y concurrencia.

Algunos de los tipos de Servidor que se pueden probar son:

 Web HTTP y HTTPS.


 SOAP.
 Base de datos a través de JDBC.
 LDAP.
CONCEPTO

JMETER permitirá controlar y manejar las concurrencias de la base de datos, esto hará
más eficiente el control y la administración de las instancias. Y permitirá resolver
problemas como los cuellos de botellas, datos erróneos o inclusive bloqueos errados.

El concepto para el laboratorio es ese, sin embargo cabe aclarar que sirve para mucho
más. Pero bueno eso lo veremos más adelante.

ANTES QUE ES JDBC

Para que la herramienta JMETER funcione correctamente necesitamos entender que


es el JDBC y como instalarlo o si en el momento de instalar JAVA ya viene con él.

Java Database Connectivity, más conocida por sus siglas JDBC, es una API que permite
la ejecución de operaciones sobre bases de datos desde el lenguaje de programación
Java, independientemente del sistema operativo donde se ejecute o de la base de
datos a la cual se accede, utilizando el dialecto SQL del modelo de base de datos que
se utilice.
El API JDBC se presenta como una colección de interfaces Java y métodos de gestión
de manejadores de conexión hacia cada modelo específico de base de datos. Un
manejador de conexiones hacia un modelo de base de datos en particular es un
conjunto de clases que implementan las interfaces Java y que utilizan los métodos de
registro para declarar los tipos de localizadores a base de datos (URL) que pueden
manejar. Para utilizar una base de datos particular, el usuario ejecuta su programa
junto con la biblioteca de conexión apropiada al modelo de su base de datos, y accede
a ella estableciendo una conexión; para ello provee el localizador a la base de datos y
los parámetros de conexión específicos. A partir de allí puede realizar cualquier tipo de
tarea con la base de datos a la que tenga permiso: consulta, actualización, creación,
modificación y borrado de tablas, ejecución de procedimientos almacenados en la base
de datos, etc.
CONCEPTO
Como se mencionó el JDBC es una API que permitirá la ejecución de operaciones sobre
base de datos utilizando el lenguaje JAVA. Significa lo siguiente, como ustedes sabrán
el lenguaje de programación JAVA y la base de datos ORACLE son del mismo
proveedor. Pero más allá de ese hecho la base de datos ORACLE en el trasfondo utiliza
sentencias SQL y está basada en ese lenguaje la mayoría de operaciones. La ventaja de
utilizar esta aplicación es que no solo funciona con ORACLE si no que se puede
emplear cualquier base de datos que utilice sentencias SQL. Por eso es que la
herramienta está diseñada para ser utilizada en aplicaciones WEB principalmente, la
prueba básicamente consiste en simular conexiones y ver cómo se comporta la
aplicación.

INSTALACIÓN DE JMETER

http://jmeter.apache.org/usermanual/build-db-test-plan.html

Le damos en descargar y lo llevamos a la máquina virtual donde este nuestra base de


datos. Por ahora no se preocupen por el JDBC, enfoquémonos que esto salga bien.

Ahora descomprimimos esos archivos. Les dejo el Link de la página oficial de JMETER
de por cierto es muy buena.

http://jmeter.apache.org/download_jmeter.cgi

Una vez descomprimido ya podemos abrirlo, sin embargo hay que tener en cuenta que
en el caso de nosotros ya teníamos instalado el JDBC con el SQLDEVELOPER, por lo
que no es necesario instalar esa excepción.

Otra aspecto a tener en cuenta son las variables de entorno, simplemente es irnos a
propiedades del sistema y CONFIGURAR el JAVA_HOME.

Eso ya lo habíamos realizado pero igual les dejo las imágenes para que vayan de la
mano con el curso. No les voy a mentir se ha avanzado bastante y podemos llegar a
perdernos por momentos. Por eso siempre les recalco los CONCEPTOS para que
puedan desarrollar todas las actividades.

Recordemos rápidamente el JAVA_HOME hay que configurarlo tanto para el


Administrador como para el usuario.

Para abrir el JMETER es muy sencillo, vamos a los archivos descomprimidos.

La carpeta que contiene el ejecutable es BIN.BAT damos clic.


y por último en el archivo ejecutar por lotes con el nombre JMETER, si todo sale bien
abrirá el programa y vamos a estar felices porque hemos avanzado sino no pasa nada
tomarlo con calma y ver qué es lo que está sucediendo.

En mi caso la aplicación abrió, pero vamos a ver si todo marcha sobre ruedas durante
la marcha.
Antes de continuar algo interesante, la versión más reciente de JMETER contiene el
JDBC, por lo que solamente tenemos que preocuparnos por la instalación del JAVA y la
configuración de las variables de entorno.

De hecho en la imagen de arriba podemos ver todos los servicios que soporta el
Jmeter.

PLAN DE PRUEBAS

Un Plan de Prueba o Test Plan, es el eje de ejecución de Jmetter, en él se determinan


los aspectos relacionados con una prueba de carga, como pueden ser los parámetros
empleados por requisición, el tipo de reportes a generarse, la posible reutilización de
requisiciones compuestas por usuarios, entre otros aspectos. Un plan de pruebas
completo trabaja en forma de árbol y consta de los siguientes ítems:

 Threads(users) (Hilos(Usuarios))–> Thread Groups (Grupo de Hilos)


 Logic controllers (Controladores lógicos)
 Listeners (Receptores)
 Timers (Temporizadores)
 Assertions (Afirmaciones - Aserciones)
 Configuration elements (Elementos de configuración)

El laboratorio consistirá en crear un plan de prueba de la base de datos más


específicamente de la secretaria de SALUD.
EJERCICIO CON JMETER

En esta sección aprenderemos a crear un plan de prueba para un servidor de base de


datos. Se crearan 50 usuarios que enviaran 2 SQL requests o peticiones al servidor de
base de datos. También le pediremos a los usuarios que corran las pruebas 100 veces.
Entonces el total de número de peticiones es 50 usuarios X 2 peticiones X 100
repeticiones de la prueba = 10’000 JDBC request. Para construir el plan de prueba,
utilizaremos los siguientes elementos: grupos de hilos, JDBC request, reporte del
resumen en general.

La imagen de arriba nos muestra el entorno grafico de la herramienta JMETER. Lo


primero que se hace es la creación del grupo de hilos. Porque con ello se dará solución
a los problemas.
El siguiente paso es guardar el plan de pruebas antes de ejecutarlo, esto solo se hace
cuando estemos seguros de que hemos terminado la tarea y podemos correr el
SCRIPT. Sin embargo les voy a mostrar la imagen y como se realiza.

Sucesos a tener en cuenta, durante el proceso se necesitara validar la base de datos y


la tabla en la que se vaya a generar el entorno de prueba. Se necesita entonces un
acceso de nivel de usuario para el objeto y la contraseña.

Acabo de realizar varias modificaciones, voy a explicarlas para continuar.

Lo primero es colocarle un nombre al grupo de hilos y un comentario. En este caso el


comentario puede dar una idea generalizada de lo que se va a realizar. Después
coloque el número de hilos en este caso 50 en este caso se simula una operación con
50 usuarios y el periodo de subida o peticiones será de 10 segundos, por último se
coloca el bucle que realizara el proceso 100 veces para cada usuario.
EL SIGUIENTE PASO ES AGREGAR EL JDBC REQUEST

Ahora tenemos que definir nuestro usuario y excepciones que se nombró


anteriormente, como el nombre de la base de datos y el objeto a utilizar. Para agregar
el JDBC Request es muy sencillo damos clic derecho, seleccionamos la pestaña
elementos de configuración y por último la pestaña conexión JDBC.

Una vez hecho todo lo anterior aparecerá una nueva venta en nuestro árbol y es la de
la configuración JDBC. Pero para esta configuración en particular necesitamos unos
conceptos previos para que lograr configurar con éxito la conexión JDBC. Entonces la
idea de hoy es lograr entender y terminar todo el laboratorio.

Conceptos que se aprenderán hoy, hoy vamos a saber la importancia del JDK, donde se
encuentra el JDBC y otros conceptos que más adelante iremos adelantando.
QUE ES JDK, JRE Y JVM

A lo largo de nuestra carrera como desarrolladores encontraremos estos significados


con mucha frecuencia. La idea principal es entenderlos desde una perspectiva fácil y
rápida.

JAVA VIRTUAL MACHINE

JVM es la aplicación donde corren los programas hechos en JAVA, es nativa del sistema
operativo lo que significa que cada SO tiene su JVM independiente con características
obviamente diferentes. Cabe aclarar que con esta herramienta no es posible
desarrollar, solo puede desplegarse aplicaciones.

Para entenderse mejor el concepto el JVM permite traducir o interpretar el código de


las aplicaciones hechas en JAVA.

JAVA RUNTIME ENVIRONMENT

JRE es el complemento del JVM se puede decir que son las herramientas o el material
necesario para instalar el JVM y es el proceso del sistema operativo que permite correr
las aplicaciones.

Entonces el JRE es el software en sí que permite crear los registros y las llaves para que
la máquina virtual se mantenga en ejecución.
JAVA DEVELOPMENT KID

El JDK comprende todo lo anteriormente dicho y mucho más, es conocido como KID
para desarrolladores y en el podemos generar códigos y crear programas siempre y
cuando tengamos nociones del lenguaje de programación JAVA. En otras palabras
permite generar casi cualquier aplicación y lo más importante establecer los
parámetros para que otras computadores visualicen el proyecto, y entre esos
requisitos puede estar el tener instalado JAVA 7 o más reciente con sus complementos
por default como los JVM y JRE.

PERO PORQUE TODOS ESTOS CONCEPTOS

Todos los conceptos son muy importantes debido a que la aplicación JMETER utiliza
sentencias SQL combinadas con comandos JAVA para crear las pruebas de
concurrencias y si no tenemos claridad con respecto a ello, se puede convertir en un
dolor de cabeza. Cuando instalamos el SQLDEVELOPER instalamos gran parte de todo
lo mencionado anteriormente, entonces esto facilitara el proceso pero si no es el caso
tenemos que buscar esos paquetes e instalarlos, si quieren ahorrar tiempo con tan
solo que instalen el JDK es suficiente.

CONEXIÓN JDBC Y JMETER

La configuración que vamos a ver a continuación varia respecto al SGDB que estemos
utilizando, pero prácticamente todos cumplen la misma lógica. En el caso de nosotros
el enfoque principal será en ORACLE.
Toda la configuración importante se reduce a la imagen anterior, el URL de la base de
datos es la conexión JDBC-ORACLE y algo importante la conexión puede ser remota,
siempre se utiliza el puerto 1521 y el nombre de la base de datos. Hasta el momento
no parece nada extraño, pero antes de todo esto tenemos que cargar el DRIVER y aquí
es cuando se complica la situación. Donde encontramos ese DRIVER.

En todos los motores de bases de datos encontraremos esos drivers, pero hay que
buscarlos. Les voy a enseñar la ruta en el caso de ORACLE.

Entonces en la carpeta donde está instalado el ORACLE se encuentra el JDBC.

Hay que tener muy en cuenta esa carpeta JDBC, porque en teoría ese el DRIVER para
crear la conexión entre el JMETER y la base de datos.
Como pueden ver en la imagen de arriba, están todos los DRIVERS. Listo pero ahora
como se configura eso. Sencillo nos dirigimos al JMETER.

Lo primero es dirigirnos al campo de dice PLAN DE PRUEBAS, y damos clic en la


pestaña Navegar y seleccionamos la ruta donde se encuentran los DRIVERS. Eso es
todo, básicamente lo demás corre por nuestra cuenta y ya cada uno podrá realizar
las pruebas que desee. En el caso de nosotros vamos a realizar varias experimentos
la idea es profundizar bastante en la herramienta.

RETOMANDO EL EJERCICIO ANTERIORMENTE PLANTEADO


REALIZACIÓN DE LA PRIMERA PRUEBA

Quedamos en la configuración de grupos de hilos, ya se habían especificado las reglas.


Sin embargo colocare el pantallazo de como de cómo está compuesta para este caso la
configuración.
Entonces les vuelvo a decir el orden de cómo se crea una prueba como esta, primero
creamos el grupo de hilos con sus respectivas especificaciones, segundo configuramos
la conexión JDBC y después las sentencias SQL, por último los informes o graficas que
muestre el comportamiento de la base de datos.

PETICIÓN JDBC

Para crear una petición JDBC, nos dirigimos al grupo de hilos y seleccionamos la
pestaña muestre ador y por ultimo seleccionamos la pestaña petición JDBC.

Si todo sale bien, se desprenderá otra ventana con una nueva petición JDBC. Para esta
prueba necesitaremos dos peticiones que simularan consultas de dos usuarios a las
tablas EPS y PERSONA. Entonces vamos bien y haber que sucede!!!!
Antes de continuar las imágenes de las dos tablas con las que desarrollaremos el
ejercicio.

COMO CONFIGURAR UNA PETICIÓN JDBC

Lo primero es colocar el nombre con el que queremos identificar esa petición, después
el nombre de la variable es mismo nombre que colocamos en la conexión JDBC. y por
último, pero lo más importante es la sentencia SQL.

Por ultimo coloco los argumentos, pero realmente no tengo mucha claridad con
respecto a ese tema.
POR ÚLTIMO LOS INFORMES
ESTO ES SUMAMENTE IMPORTANTE

Los receptores principales desde mi punto de vista son los que se ven en la imagen
anterior. A los receptores no hay que configurarles nada.

VER ÁRBOL DE RESULTADO


GRÁFICO DE RESULTADOS

REPORTE RESUMEN

Entonces para correr la prueba guardamos primero, por último damos clic en el icono
ver Play/Ejecutar.

ANALISIS DE LOS RESULTADOS

Entonces sea culminado la prueba, se hicieron algunas modificaciones porque la base


de datos que tengo en estos momentos activada no es capaz de soportar tanta
concurrencia.

Pero les quería comentar como funciona y todo el proceso en general.

Realmente hice muchas modificaciones, la idea es que entendamos el proceso. Cuando


nos dicen el número de hilos, hace referencia al número de conexiones que van a
interactuar con el objeto que se a manipular, mediante la sentencia SQL. Este
concepto es fundamental. Porque en la vida real necesitaremos calcular el número de
conexiones promedio que tendrá la instancia.

Una vez entendemos el concepto de hilos podemos establecer periodos de tiempo.


Ejemplo en la imagen de arriba aparece 10 segundos ese tiempo es el periodo
establecido en el cual todas las 20 conexiones tienen que generarse. En otras palabras
es dividir 20/10 = 2 conexiones cada segundo. Entonces cada 2 segundos se genera
una conexión. Eso es fundamental saberlo, no es complejo y ayudara bastante a
administrar la base de datos.

Por último el contador de bucle que significa, buen aquí si entra un poco la lógica,
supongamos que el bucle va a ser 15. Eso significa que cada usuarios va a tener que
realizar el proceso 15 veces. Me explico en este caso solo se maneja un usuario que
tiene 20 hilos pero como el proceso se repite 15 veces entonces se multiplica
20*15=300 conexiones durante un periodo de 10 segundos. Para ello lo que hacemos
es 300/10=30 conexiones promedio durante cada segundo.

Vamos a realizar la prueba, para que logren entender el proceso. Recuerden al final es
importante captar el JMETER desde su plenitud.

En este caso hay dos usuarios o dos consultas simultáneas. Entonces segundo eso
datos el número total de conexiones es 300*2=600 total de conexiones. Para saber el
promedio de las conexiones por segundo es simplemente dividir 600/10 = 60
conexiones cada segundo. Y este análisis lo podemos observar en el reporte resumen.
Como pueden observar en la imagen de arriba todo concuerda. Eso significa que
efectivamente si estamos haciendo las cosas bien. Este tema es bastante profundo y es
de continuo estudio pero en general lo hemos hecho sobresaliente.

La grafica de resultados es muy importante conocerla e interpretarla. En ella podemos


observar el número de muestras, el rendimiento que tienen, la media, mediana y la
desviación estándar.
ÚLTIMO EJERCICIO JMETER DE ESTA PRÁCTICA DE LABORATORIO

Vamos a crear el plan de pruebas y en general todo el ejercicio, manos a la obra con la
aplicación JMETER.

Para este ejercicio el nombre de prueba se va a llamar RUBEN ANGULO y en los


comentarios SECRETARIA DE SALUD.

Posteriormente crearemos un grupo de hilos con una conexión a la base de datos


“SECSALUD” y tres peticiones JDBC.

ULTIMO DÍA DEL LABORATORIO

Las tres consultas o peticiones que colocaremos son las siguientes.

CONSULTA 1:

Listado con el número de identificación, nombre y apellido de las personas, además del
nombre de la EPS y la fecha de ingreso y salida.

SELECT p.idpersona, p.nombre, p.apellido, e.Nombre, h.fechaingreso, h.fecharetiro


FROM persona p INNER JOIN historialpersona h on p.idpersona=h.idpersona INNER
JOIN eps e on e.ideps=h.ideps ORDER BY p.apellido

CONSULTA 2:

Listado en que se visualiza las EPS con el nombre de los servicios que presta y el costo
de cada uno ellos.

BEGIN; SELECT e.nombre, t.descripcion, s.detalle, s.valor FROM eps e INNER JOIN
servicioeps s on e.ideps=s.ideps INNER JOIN tipoServicio t on
s.idtiposervicio=t.idtiposervicio ORDER BY e.nombre COMMIT;
CONSULTA 3:

Listado con el número de identificación, nombre y apellido de las personas, además del
tipo de afiliación que tiene.

BEGIN; SELECT p.idpersona, p.nombre, p.apellido, t.descripcion FROM persona p


INNER JOIN historialpersona h ON p.idpersona=h.idpersona INNER JOIN tipoafiliado t
ON h.tipoafiliado=t.idtipoafiliado ORDER BY t.descripcion; COMMIT;

-------------------------------------------------------------------------------------------------------------------

Ante empezar con JMETER es necesario asegurarnos que esas consultas realmente se
pueden realizar, porque de lo contrario estaríamos perdiendo nuestro tiempo.

CONSULTA 1

Tabla EPS

Tabla PERSONA
Tabla HISTORIALPERSONAL

Entonces, como lo mencione anteriormente antes de colocar las tres peticiones en


JMETER es necesario verificar cada una como consultas de la base de datos.

CONSULTA 1

En la consulta 1, tuve que modificar varias cosas. La primera de ella es la sintaxis en


general es importante una vez se tienen los conceptos claros practicar bastante para
crear sentencias correctas como en este caso, tuve que durar más de 30 minutos
intentando que corriera la sentencia y en la mayoría de casos es por errores muy
sencillos. Lo segundo es entender cómo funciona el INNER JOIN esto entraría más en la
parte de conceptos teóricos.
LA CONSULTA 1 CON LOS DOS INNER JOIN QUEDO DE LA SIGUIENTE MANERA

CONSULTA 2

Tabla EPS

Tabla SERVICIOEPS
Tabla TIPOSERVICIO

LA CONSULTA 2 CON LOS DOS INNER JOIN QUEDO DE LA SIGUIENTE MANERA

CONSULTA 3

Tabla PERSONA
Tabla HISTORIALPERSONAL

Tabla TIPOAFILIADO

LA CONSULTA 3 CON LOS DOS INNER JOIN QUEDO DE LA SIGUIENTE MANERA

Una vez sea corroborada las consultas se pasa al JMETER para iniciar con la última fase
del laboratorio.
JMETER EJERCICIO FINAL
Por último se realizaran varias pruebas con el fin de analizar el comportamiento de la
base de datos, pero más específicamente la instancia de la secretaria de SALUD.

PLAN DE PRUEBA No de hilos Periodo de subida en (s) No de peticiones


1. 10 10 3
2. 25 10 3
3. 50 10 3
4. 100 10 3
5. 250 10 3
6. 500 10 3
7. 1000 10 3
8. 1500 10 3
9. 2000 10 3
10. 3000 10 3
11. 4000 10 3

PLAN DE No de Rendimiento
Desviación Media mediana
PRUEBA muestras / minuto
1. 30 10 197,239 17 12
2. 75 10 463,154 15 10
3. 150 9 908,907 15 10
4. 300 5 1795,332 12 9
5. 750 162 2859,867 67 13
6. 1500 524 3469,278 266 15
7. 3000 4367 3503,65 5493 6834
8. 4500 3905 3601,537 8402 9113
9. 6000 6158 3041,774 7462 9906
10. 9000 El servidor detuvo, se paralizo la operación debido a la
11. 12000 sobrecarga de peticiones.
Para controlar ese problema existen muchos mecanismos, entre ellos esta:

- Implementar un buen FIREWALL que permita restringir las conexiones o


concurrencias, creando filtros de seguridad muy similar a lo que
encontraríamos con por ejemplo en las listas de acceso.

- Lo siguiente sería crear bloqueos de tablas que den un orden a la problemática.

- Otra de las soluciones es limitar la cantidad de usuarios que pueden ingresar a


la instancia a la misma vez. Para que al final no se sobresature el servidor con
concurrencias muchas veces sin sentido.

- Por último mejorar el HARDWARE del servidor, que en ocasiones no calculamos


realmente el impacto que ocurrirá dentro de la operación.