20120216

JMeter : peticiones HTTP basadas en consultas a Base de Datos

Esta tarde he estado realizando unas pequeñas pruebas de integración, para comprobar el funcionamiento de un pequeño proyecto en el trabajo. Ha sido a última hora, por lo que no he tenido tiempo de investigar a fondo, así que he decidido mirarlo en casa, sin que sirva de precedente, pero sin por ello dejar de aprender ; )

La prueba consiste en acceder al sistema mediante un token. Este token está almacenado en base de datos, y tenemos una consulta para saber qué tokens son válidos. Este token se pasa por la URL de forma que se valida y luego se puede acceder a la aplicación. No se requiere mayor seguridad, es algo simple.

Así que he montado un entorno similar en mi equipo en casa.

Descripción

Vamos a realizar una prueba en la que se haga una petición HTTP con un parámetro obtenido de la base de datos.

Qué necesitamos
  • JMeter. En mi caso he descargado la última versión de aquí
  • Base de datos : en mi caso MySQL
  • Driver de la BD : hay que tener el driver jdbc en el directorio \lib de la instalación de JMeter para que éste sea capaz de conectarse.

Preparativos previos
He accedido a MySQL, he creado un usuario y un esquema para las pruebas.
He insertado varios valores de prueba en una tabla simple.
Tenemos una tabla jmeter_test1 con varios valores:




Proyecto JMeter

Debemos configurar la conexión a la base de datos.
Para ello, incluimos un elemento "Configuración de la conexión JDBC":



Es importante el nombre de la variable, en este caso jmeter_test1_jdbc_connection, ya que se usará más adelante.

Una vez configurado, debemos obtener los datos de la tabla de ejemplo. Para ello, incluimos un elemento "Petición JDBC":



En este elemento indicamos la variable definida en la configuración de la conexión.
La variable resultado jdbc_result contiene los datos que se obtengan en la consulta, que como vemos es muy simple.

Los resultados obtenidos son:
jmeter_value1
value11
value21
value31
value41

Es importante ver que la primera columna de los datos obtenidos es el nombre de la columna.Teniendo esto en cuenta, debemos definir el extractor de los datos mediante expresion regular, para obtener el primer VALOR de la consulta:





Ver tutorial sobre ER
Simulador para probar tus ER

Como vemos, obtendremos el primer elemento del listado.
El valor en "Nombre de Referencia" indica el nombre que le damos a la variable que contiene el valor obtenido.
La expresión (.+) nos obtiene cada una de las lineas del texto resultado obtenido por el elemento de petición JDBC.
Indicamos la plantilla como $1$
La coincidencia es 2, ya que la primera coincidencia es el nombre de la columna (la primera linea obtenida)
El valor por defecto "FAIL" es indicativo para las pruebas y nos indicará que ha fallado la extracción del valor buscado.


Para ver el uso, lo vamos a utilizar para hacer una petición HTTP a localhost.
Incluimos un elemento "Peticion HTTP":



Una vez lanzamos la ejecución de la prueba JMeter, obtendremos los resultados de cada petición.
Para verlos, añadimos un receptor, por ejemplo "Ver Árbol de Resultados". Al ejecutar, tendremos los resultados ahí guardados.



Vemos en la obtención de los datos usando JDBC que se obtiene la lista de valores.



Vemos en la petición HTTP que se ha usado como parámetro el primer valor obtenido. No es importante que haya fallado, sino ver la url con el parámetro q=value11, que es el que hemos obtenido de la consulta a BD.




20120205

El primer día en bici

Hoy ha hecho un día frío en Málaga, uno de esos días que te recuerdan el invierno, que también existe, y del que nos solemos librar.

Pero eso no ha impedido estrenar las bicis hoy, y salir a dar un paseo. He decidido crear la ruta que he hecho, no será una costumbre, pero así dejo constancia del primer paseo por Málaga con nuestras nuevas bicicletas :).


Ver Primer paseo en bici por Málaga en un mapa más grande

20111111

Bonita fecha

Un día curioso, en notación típica de informático (logs, ficheros fáciles de ordenar por fecha...):


20111111_1111

20110925

Matar proceso que usa un puerto

Ahora mismo estoy trabajando en el PFC, y arrancando y parando el Tomcat integrado en Eclipse hasta la saciedad (debería usar JRebel ahora que hay una versión libre?)

Lo que me ha ocurrido es algo que pasa "a veces" sin saber porqué : al arrancar Tomcat, me dice que alguno de los puertos que necesita está ocupado. Me voy a la vista de Debug para ver si hay algo en ejecución, y la vista de Servers para ver si está levantado, y ... nada, no veo nada desde ahí.

En el monitor del sistema si veo varios procesos java, pero claro, cual matar? No quiero que se me cierre el Eclipse o cualquier otra cosa que tenga levantada en ese momento.

Googleando un poco me encuentro esto.

Básicamente, ejecutando el comando:

netstat -anp|grep :

vas a poder ver qué proceso está usando qué puerto, para lo que necesites (en mi caso, matar el proceso que se ha quedado "suelto")

A veces pasan estas cosas y no sabes porqué, pero mejor tener a mano la forma de solucionarlas sin más y poder seguir trabajando.

20110525

Susto con 'mv *' en linux

Hoy he tenido un pequeño susto en mi equipo de casa, al intentar mover unos ficheros
Quería mover todos los logs a un directorio para mantener históricos, logs de mi aplicación, y he ido a teclear:

mv *.log ../_rutahistoricos_

en ese momento se me ha ido la mano y he tecleado:

mv *

y al pulsar enter... han desaparecido todos los .log y todo lo que había en ese directorio!

La mala suerte hace que, mi configuración, haga que deje las trazas en el HOME de mi usuario, con lo que se había perdido TODO mi contenido.

Perdido? No! Aquí hay un alma caritativa que dice básicamente que:

"si ejecutas 'mv *' se moveran todos los ficheros al último elemento, en caso de ser un subdirectorio, en otro caso se produce un error"

Efectivamente, en mi caso hay un directorio "workspace" (eclipse ;) ) donde estaba TODO mi home.
Curiosamente no se habían movido los directorios/ficheros ocultos.

Así que he podido recuperar todo lo que tenía, simplemente ejecutando de nuevo un mv, esta vez, con mucho cuidado!

He comprobado, además, que ejecutando mv * en un directorio cuyo último elemento no es otro directorio, se da el siguiente error:

mv: el destino, «applogxxxxxx.log», no es un directorio

20110507

SpringSecurity y Sitemesh : filters

A la hora de integrar SpringSecurity con Sitemesh, se me planteó un problema : al usar las tags de springsecurity, en los decoradores de sitemesh, no funcionaban.
La solución estaba a unos cuantos enlaces de Google:
aquí


La idea:
Al cambiar el orden de los filtros en el web.xml de la aplicación web, de forma que el filter de SpringSecurity actue antes que el de Sitemesh, todo funciona. Tiene sentido, ya que antes de que pueda usarse la información de SpringSecurity, debe haberse pasado por su filtro.

20110225

Autocompletado en las JSP de Eclipse

Estoy trabajando en mi proyecto fin de carrera, y una parte del mismo es una aplicación web (como no!)

En esta parte estoy usando Spring MVC, y en la vista estoy usando JSPs ayudándome de los grandes aliados : los tags.

Para que esta ayuda sea cómoda, lo mejor es que el autocompleado (ese mágico Ctrl+Espacio) funcione correctamente. Para ello, la solución ha sido declarar en la jsp los tags a usar de la siguiente forma:

<jsp:root version="1.2"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:jsp="http://java.sun.com/JSP/Page">

... código de la JSP aquí ...

</jsp:root>

De esta manera, el editor de JSP de eclipse "se da cuenta" de los TLD de definición de estos tags, que de otra forma no lo hacía. Voilà!

En mi caso, el proyecto está usando Maven para gestión de las dependencias, por lo que los JAR necesarios no están físicamente en el lib del proyecto, sino que están en el repositorio local maven y se despliegan en el servidor de aplicaciones al publicar la aplicación web.