Entradas etiquetadas con configuracion

Tunning de aplicaciones en WildFly

JBUG: London

JBUG: London

El grupo de usuario de Jboss de Londres organizó unas charlas el mes pasado. La que me ha parecido mas interesante es la que dieron sobre tunning de aplicaciones sobre WoldFly/JBoss. Afortunadamente para todos, las grabaron en vídeo.

 

Te recomiendo que prestes mucha atención, sobre todo a la parte del “funnel”. Representa el comportamiento ideal de una petición. Es fundamental ya que la configuración inicial que hacemos de todos los parámetros del servidor java (JBossAS, WildFly o el que sea) se basa en este comportamiento ideal. Espero que te gusten.

 

Parte 1:

 

Parte 2:

Instalación de WordPress en un servidor Tomcat

¿Por que?

¿Y por que querría alguien instalar una aplicación php como puede ser WordPress en un servidor java? Buena pregunta. Como en cualquier disciplina, en general existe una colección de buenas practicas a la hora de instalar y administrar servidores de aplicaciones. Conocerlas es fundamental. Pero en ocasiones, por motivos que en condiciones normales ni se te ocurrirían, es necesario violar alguna de estas buenas practicas. ¿Y entonces para que queremos las buenas practicas si luego nos las saltamos? Porque así sabrás lo que estas haciendo. Sabrás que lo que haces conlleva riesgos y que lo haces por una buena razón.

¿Como se hace?

Partiremos de un Tomcat7 recién instalado y funcionando. Para una demo, basta con descomprimirlo y definir el JAVA_HOME en el fichero /bin/catalina.sh, asi que no hace falta que te compliques mas. Seguro que no hace falta que te lo diga, pero la pagina de descargas es http://tomcat.apache.org/download-70.cgi. Necesitaremos también la librería que nos permite conectar a nuestro Tomcat con MySQL. Para ello utilizaremos el conector apropiado, que encontraremos en
http://dev.mysql.com/downloads/connector/j/5.0.html. Descargaremos el zip o el tgz (requiere registro) y copiaremos la librería, que se llamara mysql-connector-java-5.1.33-bin.jar o similar, en la carpeta lib/ de nuestra instalación. También crearemos en nuestro MySQL una base de datos y un usuario de conexión para el WordPress.

Ahora hagamos posible la ejecución de código php en nuestro servidor java. Hay varias maneras, pero la mas sencilla que he encontrado es utilizar PHP/Java Bridge. Iremos a la pagina del proyecto en sourceforge y descargaremos el fichero JavaBridgeTemplate621.war en la carpeta temporal de nuestra maquina de pruebas. Para que funcione, la maquina tendrá que tener instalado php5-cgi y todas sus dependencias. Por último, realizaremos la instalación de PHP/Java Bridge y de WordPress. Si estamos situados en el directorio principal del Tomcat, ejecutaremos los siguientes comandos:

cd webapps/
mkdir wordpress
cd wordpress
unzip /tmp/JavaBridgeTemplate621.war
rm -rf index.php test.php
wget https://wordpress.org/latest.tar.gz
tar xvzf latest.tar.gz && rm -rf latest.tar.gz

Y ya esta. Ahora solo tendremos que arrancar Tomcat ejecutando el script startup.sh. Para proceder a instalar el WordPress abriremos en el navegador la url que corresponda. Como yo tengo el servidor instalado en una maquina virtual con Virtualbox la ruta es http://192.168.56.101/wordpress/, pero seguramente sera distinta en tu caso. Siguiendo el asistente de instalación, donde se nos pedirán los datos de conexión a la base de datos que creamos antes, podremos ver nuestro blog de prueba funcionando casi al instante.

¿Como se comporta?

Para estudiar el rendimiento de esta solución, utilicé uno de los temas que hay para WordPress que estoy valorando para emplear en este blog. El tema en cuestión tiene la opción de descargar contenido de prueba para que puedas ver lo que ofrece si lo configuras bien y utilizas texto e imágenes cuidadas. Una vez cargado ese contenido inicial, creé una prueba de carga con jmeter tal y como explique hace ya tiempo en este post. Y los resultado fueron sorprendentes.

En todas las pruebas se utilizan 25 hilos, con un periodo de subida de 50 segundos y dos iteraciones. Realmente no era necesario mas para este caso. Y en cada prueba lo que fui modificando fue en numero de cpus de la maquina virtual.

Maquina virtual monoprocesador

Si utilizamos una maquina de un solo procesador, los resultados en cuanto a rendimiento son extremadamente similares entre servir el blog con Tomcat o con Apache. Algo estupendo. Con Tomcat se sirven 9,6 objetos por segundo y con Apache 9,5. En las siguientes capturas puedes ver el informe agregado en cada caso. No hace falta que te dejes los ojos buscando el resultado, al final del post hay una tabla resumen.

Rendimiento de Apache sirviendo WordPress (1 core)

Rendimiento de Apache sirviendo WordPress (1 core)

Rendimiento de Tomcat sirviendo WordPress (1 core)

Rendimiento de Tomcat sirviendo WordPress (1 core)

Mientras se ejecutaba la prueba, tuve abierto un top en la maquina. Podéis verlos aquí:

Comportamiento del sistema con Apache sirviendo WordPress (1 core)

Comportamiento del sistema con Apache sirviendo WordPress (1 core)

Comportamiento del sistema con Tomcat sirviendo WordPress (1 core)

Comportamiento del sistema con Tomcat sirviendo WordPress (1 core)

Maquina virtual multiprocesador

Aquí es donde llegan las malas noticias: usando 2 o 4 procesadores el rendimiento de Apache aumenta linealmente con el numero de cores pero el de Tomcat disminuye casi en la misma proporción. Puedes verlo en la siguiente tabla:

 

1 core 2 cores 4 cores
Tomcat 9,6 8,4 2,5
Apache 9,5 16,8 30,6

Efectivamente, la caída de rendimiento es brutal. En las siguientes capturas se puede ver la posible causa:

Comportamiento del sistema con Apache sirviendo WordPress (2 core)

Comportamiento del sistema con Apache sirviendo WordPress (2 core)

Comportamiento del sistema con Tomcat sirviendo WordPress (2 core)

Comportamiento del sistema con Tomcat sirviendo WordPress (2 core)

Apache abre procesos conforme los va necesitado pero cuando es Tomcat quien ejecuta el php solo es capaz de abrir 5 procesos de php5-cgi. Esto puede deberse a algún tipo de limitación establecida en tiempo de compilación.

Conclusiones

Si necesitas ejecutar una aplicación php sobre Tomcat (o Jetty) puedes hacerlo. Si ademas necesitas alto rendimiento, tendrás que continuar donde yo lo he dejado, investigando si aumentando el numero de procesos que se pueden abrir de php5-cgi mejora el comportamiento.

Video del WebLogic Classloader Analysis Tool

Aquí os dejo un vídeo donde se muestra el uso del CAT de WebLogic. Como su nombre indica, se trata de un analizador del sistema de carga de clases. A primera vista puede parecer que estamos ante una herramienta para desarrolladores, un depurador mas. Si embargo, como administrador de sistemas de servidores Java, te va resultar de cierta utilidad. Te servirá para comprobar la calidad del equipo de desarrollo que te entrega ese war o ese ear. Si se han limitado a arrojar las librerías al proyecto, lo sabrás.

Administrando tu JBoss desde el telefono

Nos ha pasado a todos. En algún momento uno de nuestros servidores de aplicaciones se vuelve inestable en el peor momento. En mi caso se producía una vez al año. Se trataba de una aplicación utilizada para realizar un determinado tramite. El resto del año el servidor se estaba tocando las narices, pero en ese mes echaba humo. Como la aplicación tenia un leak de memoria, conforme iba recibiendo visitas disminuía la memoria que realmente podía utilizar. Este tipo de comportamientos es relativamente fácil de observar en la gráfica del Heap desde jconsole o visualvm. Finalmente, como no podía ser de otra manera, el servidor de aplicaciones dejaba de responder. ¿Que hacia en estos casos? Pues reiniciarlo de forma preventiva en las horas de menor afluencia. Ya se que no era la solución perfecta, pero hasta que no corrigieran el leak, no había otra. En el peor de los casos, el servidor colapsaba antes del siguiente reinicio: alarma en el móvil de guardia, carrera para arrancar el portátil, activar la VPN… ya sabes como va.

Afortunadamente, y como no estamos solos, hay quien se ha propuesto facilitarnos la vida: ya tenemos aplicaciones gratuitas para monitorizar y gestionar JBoss/WildFly desde nuestro smartphone. ¿No te fías? Pues puedes revisar, descargar y compilar el código tu mismo. La aplicación esta disponible para Android y para iOS. Y en github tienes el código tanto de una como de la otra.

Ahora podrás reiniciar ese servidor de aplicaciones maldito antes de que el teléfono de guardia desate el apocalipsis.

Configurando WebLogic para funcionar con proxy inverso

WebLogic ServerEn numerosas ocasiones es necesario poner nuestro servidor de aplicaciones detras de un proxy inverso (también conocido como “fachada”). Dentro de unos días espero publicar un articulo sobre las ventajas y desventajas del uso del proxy inverso. A pesar de que sobre el papel la acción de la fachada es transparente, en numerosos casos eso no es asi. Por ejemplo, cuando se utiliza SSL algunos de los extremos puede suponer que esta sufriendo un ataque de tipo man-in-the-middle. También dependerá de si la conexión segura llega hasta la fachada (si tenemos tarjetas aceleradoras SSL podemos aumentar el rendimiento) o hasta el servidor. Hay ocasiones en que el propio servidor se percata de la existencia del proxy: si conectamos con un Tomcat a través del conector AJP13 funcionará suponiendo que las peticiones no las realiza un cliente directamente sino que las realiza a través del proxy inverso.

En otras ocasiones, como en el caso de WebLogic es necesario indicarlo explícitamente. Utilizando la Consola de Administración tendrás que acceder a las propiedades del Dominio o del Cluster y marcar la opción WebLogic plugin Enabled. Efectivamente, no le han dado un nombre muy intuitivo que digamos. Si no lo hacemos, y siguiendo el ejemplo anterior del uso de SSL, veremos la petición denegada con un mensaje similar a este

[WSM_POLICY_NAME: oracle/wss11_saml_or_username_token_with_message_protection_service_policy] Failure in WS-Policy Execution due to exception.

Y en el log veremos la siguiente traza de error:

Caused by: oracle.wsm.common.sdk.WSMException: FailedCheck : failure in security check
Caused by: oracle.wsm.security.policy.scenario.policycompliance.PolicyComplianceException: WSM-00042 : The request must be made over SSL.

En resumen: un nombre de elección dudosa para una propiedad que nos puede dar muchos dolores de cabeza. Si quieres ver los pasos que hay que seguir dentro de la Consola de Administración o mas información sobre esto, puedes consultar el articulo original en ateam-oracle.com.

Ir arriba