Rendimiento

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.

Esto es lo que pasa cuando usas GlassFish para un proyecto

Que no lo vuelves a usar. Es a la conclusión que se se llega cuando lees el articulo de JavaHispano. Cuando tienes un proyecto desarrollado sobre GlassFish y te aparece un bug que afecta a tu modelo de negocio tienes un problema. Y de los gordos. Al tratarse de una implementación de referencia, el parche (o la siguiente versión) no tiene fecha prevista de llegada.

Facepalm

Fuente: Wikipedia

La solución “facil”: pasarse a Weblogic multiplicando de paso tu gasto en soporte por dos. Que Weblogic es bueno no lo duda nadie. Que es caro como él solo, tampoco.

Después de pasar por todo esto, en el siguiente proyecto la elección es clara. Cualquiera menos GlassFish. Hay muchos servidores java a elegir y muchas empresas que ofrecen soporte para ellos. Oracle esta en su derecho de establecer su política comercial, y tu estas en el tuyo de no seguirla. Por si no lo recuerdas, en este post tienes los criterios que yo sigo a la hora de escoger un servidor java.

Como elegir el mejor procesador para un servidor

¿Cual es el mejor procesador para un servidor (de aplicaciones)? No es una pregunta fácil. Para responderla, AODBC ha iniciado una serie de artículos sobre el tema. En esta primera parte da un apunte sobre el tema:

…para una granja de servidores web en un sitio de éxito puede que el nº de hilos por cpu gane importancia.

Esperemos que en las próximas entregas de la serie siga ahondando en este tema tan interesante. AODBC (a ojo de buen cubero) es uno de los blogs que sigo habitualmente, y te lo recomiendo para estar al día de todo el espectro TI.

Aprendiendo a usar Apache JMeter

Logo de Apache JMeter

Logo de Apache JMeter

En varias entradas, por ejemplo en esta, he comentado por encima el uso de Apache JMeter para medir el rendimiento de nuestro servidor de aplicaciones. Para dimensionar adecuadamente la memoria de nuestro servidor y optimizar los recursos de la maquina (física o virtual), el procedimiento es sencillo:

  1. Hacer una estimación de partida del consumo de memoria del servidor y sus aplicaciones.
  2. Realizar una prueba de carga contra las aplicaciones.
  3. Revisar los resultados de la prueba.
  4. Si creemos que es mejorable, modificar los parámetros de memoria del servidor y repetir.

Hace un tiempo ya escribí una entrada sobre como realizar la estimación de partida. En la entrada también se menciona el uso de JMX para supervisar el comportamiento del servidor mientras se realiza la prueba.

Para realizar la prueba de carga, la opción mas fácil es utilizar JMeter. Pero empezar a mirar la extensa documentación, la wiki o la referencia de funciones, puede resultar tedioso. Mi recomendación: descarga la aplicacion, descomprímela, y sin mirar nada mas, empieza directamente con el tutorial Recording Tests. Empezar por este tutorial es algo que seguramente no se te ocurriría, pero creo que seguir mi consejo te va a ahorrar mucho tiempo.

El tutorial tiene dos fases. En la primera, configuras JMeter para funcionar como proxy entre tu navegador y tu servidor de aplicaciones, de forma de va grabando tu navegación sobre la aplicación que quieres probar. En la segunda, ejecutas el test reproduciendo tu navegación y al acabar ves los resultados.

A partir de aquí te resultara mas sencillo buscar en la documentación de JMeter: ya sabrás para que sirve cada tipo de componente y podrás buscar aquello que necesites e ir mejorando tus tests para simular el comportamiento de los usuarios de forma mas realista.

Ir arriba