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 PRUEBA

No de muestras

Desviación Rendimiento

/ minuto Media mediana

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 sobrecarga de peticiones. 11. 12000

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.