Ejercicios de rendimiento y alta disponibilidad

1. Tenéis que crear un nuevo dominio, denominado tuning, compuesto únicamente por el AdminServer. Creadlo en la carpeta home/especialista y aseguraos de que se cree en modo producción y que utilice la JVM Hot Spot de Sun (Por defecto se os activará JRockit). El usuario administrador será system/especialista11 como en anteriores ejercicios.

   

2. Comprobad que esté instalada la aplicación JMeter en la máquina virtual (ejecutad jmeter). Si no lo está, se puede instalar con los comandos:

   sudo apt-get install jmeter
   

   

3. Combrobad que esté instalada la aplicación Java VisualVM. Para ello acceded a /opt/jdk1.6.0_30/bin y ejecutad jvisualvm:

   

JMeter es una potente herramienta de pruebas, se basa en crear flujos de navegación y ejecutarlo desde múltiples hilos de ejecución. Como generar cargas de prueba puede llegar a consumir muchos recursos del cliente, es posible coordinar varias máquinas para que entre todas generen el volumen desado de peticiones.

Vamos a trabajar uno de los casos más sencillos: vamos a simular múltples llamadas a un servlet de una aplicación Web. Para ello hay que crear en JMeter:

• Un grupo de hilos, cada hilo simulará un usuario concurrente
• Un muestreador , que será el tipo de operación a ejecutar por cada muestra. En nuestro caso será una petición HTTP.
• Un temporizador, que fije el número de peticiones que vamos a procesar por minuto.
• Una aserción, que es un elemento que permite validar si la respuesta de la petición ha sido correcta o no.
• Un Listener, que será un objeto que recopile los resultados de la prueba. Utilizaremos normalmente el informe Agregado que nos dará resultados totalizados por muestreador (número de muestras, tiempo de ejecución medio, % de error, etc). En el caso de querer analizar individualmente la ejecución de cada petición, podemos utilizar el denominado "Arbol de resultados".

Por ejemplo, para simular 100 usuarios llamando a una página 1 vez por segundo haremos lo siguiente:

1. Crear un grupo de hilos:

   

   Como parámetros importantes, debemos asignar el número de hilos (equivalente al número de usuarios), marcar el número de segundos que se tardará en arrancar los hilos especificados, y marcad la casilla de sin fin para que la batería de pruebas sólo termine cuando nosotros lo indiquemos:

   

2. Crear el muestreador (botón derecho sobre el grupo de hilos->Añadir->Muestreador->Petición HTTP. Debemos configurar como mínimo: servidor, puerto, protocolo (HTTP) método (GET/POST) y ruta de la página a la que queremos acceder.

   

3. Crear el temporizador (botón derecho sobre el grupo de hilos->Añadir->Temporizador->Temporizador de rendimiento constante) Este tipo de temporizador permite modelar una tasa de peticiones por minuto constantes para el conjunto de hilos, no necesariamente ejecutadas con el mismo intervalo de tiempo entre cada petición. Si tenemos 100 usuarios y queremos una petición por segundo debemos configurar 100*60 peticiones por minuto y definir que el temporizador afecte sólo al conjunto de hilos al cual pertenece:

   

4. Añadir la aserción (botón derecho sobre el grupo de hilos-> Añadir->Aserción->Aserción de respuesta. Podemos configurar la aserción en base a un código de respuesta (200, OK) o a la salida que devuelva la página:

   

5. Añadir un Listener (botón derecho sobre el grupo de hilos->Añadir->Listener->Informe Agregado. Este elemento no tiene configuración, pero permite especificar un fichero de salida para volcar el resultado de la prueba.

   

Recordad que debéis grabar el plan de pruebas una vez configurado para recuperarlo cuando sea necesario. La forma habitual de utilizar la herramienta es la siguiente:

• Inicializar contadores: Lanzar->Limpiar todo
• Iniciar las pruebas: Menu Lanzar->Arrancar.
• Parar las pruebas: Menu Lanzar->Parar (si la aplicación está en castellano, saldrá dos veces, la "buena" es la primera).

Si iniciamos la batería de pruebas, podemos acceder al Informe agregado y ver en tiempo de ejecución cómo está funcionando nuestra prueba:

Se trata de una herramienta que viene de serie con el JDK y resulta muy útil para monitorizar la ejecución de las aplicaciones Java. Es ampliable mediante plugins y resulta muy sencilla de utilizar.

Podemos monitorizar tanto procesos locales como remotos, pero estos últimos exigen configuración adicional a nivel de máquina o proceso remoto.

Aquí veremos el caso sencillo, monitorizar una instancia de WebLogic Local. Para ello:

1. Iniciaremos la aplicación, desde la carpeta bin del JDK (ejecutaremos jvisualvm)

   

2. En la parte izquierda de la ventana podemos ver los procesos Java que se están ejecutando en nuestra máquina. Pinchamos sobre WebLogic con el botón derecho y elegimos la opción de "Open".

3. A continuación VisualVM se conectará al proceso y nos mostrará información agrupada por pestañas. La primera que veremos es la configuración de la JVM del proceso :

   

   En la pestaña Monitor podremos observar uso del Heap y la CPU por parte de la JVM:

   

En este ejercicio vamos a intentar ajustar la configuración de la JVM de un servidor WebLogic a la carga de trabajo que va a soportar. El objetivo es que comprobéis que los valores por defecto no siempre son los más adecuados para un sistema en producción.

Vamos a desplegar en nuestro dominio, una aplicación Web que realiza cálculos "pesados", concretamente calcula el número PI con unos 500 decimales de precisión.

Se trata de una aplicación muy sencilla, compuesta por un EJB y un servlet. El servlet es invocado por el usuario y éste llama a un EJB sin estado que será quien haga el cálculo.

La cuestión es que no vamos a limitarnos a lanzar una prueba desde un navegador, vamos a simular que múltiples usuarios están trabajando concurrentemente con la misma. Para ello generaremos una batería de pruebas con JMeter y monitorizaremos el rendimiento del servidor con Visual VM.

Para ello tenéis que:

1. Compilar la aplicación de pruebas Stress suministrada como plantilla. Podéis hacerlo directamente desde la línea de comandos con Maven.
2. Iniciar el dominio tuning, desplegad la aplicación en el servidor admin y reiniciar el dominio. En el arranque debéis observar el log y anotar la configuración de memoria que utiliza WebLogic por defecto, sobre esa configuración trabajaremos más adelante.
3. Crear una batería de pruebas de JMeter que simule la actividad de unos 40 usuarios ejecutando una consulta por segundo. Como cada ordenador es un mundo, debéis lanzar la prueba y comprobar que el consumo de CPU de la máquina (medido con el gnome-system-monitor o con el comando top de la consola) se mantiene por encima del 80% pero sin llegar al 100%. Debéis ajustar el número de usuarios simulados para que el consumo permanezca en la franja delimitada.
4. Iniciar Visual VM y conectaros al proceso de WebLogic.
5. Lanzar la batería de pruebas y observar el comportamiento del Heap y el uso de CPU.
6. Estimar que cambios se deberían hacer sobre la configuración de la JVM, aplicadlos y volver a probar.

Los entregables del ejercicio serán la batería de pruebas y un fichero TXT con la configuración de memoria escogida y una breve argumentación de la misma. Una vez finalizado el ejercicio, es recomendable entrar en la carpeta logs del servidor Admin y borrar los ficheros access.log* que se hayan generado.

Vamos a definir un clúster en nuestro dominio tuning compuesto por dos servidores, nodo1 (puerto 7002) y nodo2 (puerto 7003). Debéis seguir los pasos vistos en teoría con la precaución adicional de modificar la configuración de memoria por defecto para todos los servidores, de modo que consuma un máximo de 256 Mb por servidor (de otro modo sería "problemático" arrancar tres servidores de WebLogic).

Como aplicación de pruebas trabajaréis con PruebaCluster, incluida en las plantillas.

Esta aplicación es un WAR que contiene un par de servlets: el primero de ellos es el denominado Consulta , el cual solicita un nombre de usuario mediante un sencillo formulario, y lo almacena en la sesión. A continuación se conecta a una base de datos y visualiza el resultado de una consulta. El dato del usuario queda almacenado en la sesión y para sucesivas llamadas que podamos realizar se utilizará este dato, sin necesidad de volver a pedirlo.

Para que todo funcione correctamente tenéis que:

1. Crear un origen de datos denominado jdbc/cluster que apunte a la BD de mysql "cluster" y utilice el usuario root/especialista. Tenéis en la plantilla el script necesario para crear la base de datos.
2. Compilar la aplicación y desplegarla en el clúster.
3. Probad la aplicación en cada nodo y ver qué diferencias hay en la respuesta del servlet.

4. Configurar el balanceador HTTPClusterServlet para que reparta la carga de los dos servidores. Cread un proyecto denominado apli-Balanceador, y desplegadlo en el servidor admin.

   Como vamos desplegar el balanceador sobre el servidor admin, éste sólo debe tratar peticiones con el patrón /cluster que se corresponde con el contexto raíz de la aplicación PruebaCluster. Para ello especificar como contexto raíz, /cluster.

5. Probad a acceder a la aplicación a través del admin, con la URL http://localhost:7001/cluster/Consulta Veréis que se muestra el formulario de login. Introducid un usuario y verificad que se muestra una lista de resultados por pantalla, y en dicha lista se indica a qué servidor os habéis conectado realmente.
6. Parad el nodo contra el cual estáis trabajando y lanzar de nuevo la consulta a través del servidor admin. Comprobad todas las consultas van dirigidas al otro nodo. Iniciad de nuevo el nodo apagado y repetid el proceso con el otro nodo.

7. Contestad brevemente en un archivo de texto "cluster.txt" las siguientes preguntas:

   1. Si repetimos el punto 6, pero en lugar de "parar", "suspendemos" un servidor ¿Qué ocurre y por qué?
   2. La aplicación web tiene un segundo servlet, que podéis consultar mediante la llamada: http://localhost:7001/cluster/Hello. Este servlet únicamente nos dice qué nodo está atendiendo la petición. Desde Firefox lanzad varias llamadas al servlet. A continuación activad el modo navegación privada y volved a llamar al servlet varias veces. ¿Qué diferencias observáis y por qué creéis que se producen?
8. Opcionalmente podéis modificar el plan de pruebas de JMeter para que ataque al servlet Hello, a través del balanceador y repetir las pruebas del punto 6. Comprobad si se produce algún error al parar/arrancar algún servidor con una carga de trabajo significativa. Podéis utilizar el Listener de "Árbol de resultados" para examinar las posibles peticiones que fallen.

Los entregables del proyecto serán el proyecto Web que contenga al balanceador, el archivo clúster.txt y la exportación del dominio tuning. Si hacéis el punto 8, entregad también el nuevo plan de pruebas.