Entradas etiquetadas con instalacion

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.

Instalando el JDK en servidores en la nube

Hace unos meses publique una entrada explicando la instalación del JDK en linux. Ese articulo lo escribí teniendo en mente el bajo precio de la memoria RAM y su abundancia en la mayor parte de entornos actuales. Sin embargo no contemplaba un escenario que esta cogiendo fuerza por momentos: la computación en la nube. Con un enfoque iaas, contratamos maquinas virtuales a un proveedor y este nos factura en función del dimensionamiento y/o del consumo. En estos casos, es muy importante la optimización de los recursos para reducir los costes todo lo posible. Así que he editado el articulo para contemplar estos casos. Creo que ha quedado mucho mas completo y espero que sea de utilidad.

Instalación de Jetty 9 sobre Linux

En esta entrada veremos con instalar un Jetty 9.0.3 sobre Linux. En concreto con cualquiera de la familia Red Hat y compatibles. Seguramente cambiará un poco entre distribuciones, pero en el peor de los casos tendrás una guía sobre la cual basarte. La instalación y configuración es bastante sencilla. Empezaremos con la descarga. La pagina oficial de descarga es esta

http://download.eclipse.org/jetty/stable-9/dist/

pero para hacer mas sencilla la instalación, utilizaremos un mirror.

cd /opt
wget http://mirrors.linux-bg.org/eclipse/jetty/stable-9/dist/jetty-distribution-9.0.3.v20130506.tar.gz

Una vez que tenemos el paquete, procederemos a descomprimirlo:

tar xvzf jetty-distribution-9.0.3.v20130506.tar.gz
rm -rf jetty-distribution-9.0.3.v20130506.tar.gz
mv jetty-distribution-9.0.3.v20130506 jetty
chmod 755 jetty

Ahora crearemos el usuario no privilegiado con el cual arrancaremos el servidor:

groupadd jetty
useradd -g jetty jetty
chown -R jetty:jetty /opt/jetty

Si no queremos que Jetty arranque en el puerto 8080, buscaremos la propiedad jetty.port en el fichero /opt/jetty/start.ini:

jetty.port=8580

Para completar la instalación, solo necesitamos un script de arranque. Jetty incluye un script que solo necesitaremos configurar:

cp /opt/jetty/bin/jetty.sh /etc/init.d/jetty

Editaremos el fichero /etc/init.d/jetty y le añadiremos estas lineas:

JAVA_HOME=/usr/java/jdk1.7.0_21
JAVA=$JAVA_HOME/bin/java
JETTY_USER=jetty
JETTY_HOME=/opt/jetty
JETTY_LOGS=$JETTY_HOME/logs/
JAVA_OPTIONS="-server -Xmx2g"
NO_START=0

Con esas lineas hemos definido sobre qué JDK correrá el servidor de aplicaciones, el usuario que lo arrancará y opciones de arranque. Las opciones de arranque de la maquina virtual también se pueden configurar en el fichero start.ini, sin embargo no te lo recomiendo. Si lo haces así, se lanzara un segundo proceso, el script de inicio funcionara peor, aumentará (ligeramente) el consumo… en general será menos elegante.

Por último, configuraremos el arranque automático del servicio:

chkconfig --add jetty
chkconfig jetty on

Y ahora, iniciando el servicio, podrás ver tu servidor en el puerto 8580:

service jetty start

Un consejo: si vas a usar tu servidor en producción, empieza quitando los ejemplos:

cd /opt/jetty/start.d
mv 900-demo.ini 900-demo.ini.disabled

Espero que esta entrada te haya ayudado. Si te surge alguna duda, puedes dejar un comentario.

Instalación del JDK en linux

Introducción

Instalar la Maquina Virtual Java de Oracle en un servidor Linux es algo sencillo. Sin embargo, de como lo hagamos dependerá como de fácil sera instalar y actualizar nuestros servidores de aplicaciones. Dedicar unos minutos a realizar una instalación consistente nos puede ahorrar mucho tiempo en el futuro y nos protegerá de cometer errores que aunque triviales pueden ser difíciles de identificar.

Descarga

Salvo contadas excepciones, nuestro servidor no dispondrá ni de entorno gráfico ni de navegadores en modo texto, por lo cual empezaremos realizando la descarga del paquete en nuestra maquina cliente, para posteriormente subirlo al servidor. Normalmente necesitaremos la última revisión de la versión del JDK que estemos utilizando. Para la versión 7, iremos a la correspondiente página de descarga. En el caso de que necesitemos una revisión anterior tendremos que ir al histórico, siempre teniendo en cuenta que esto no es lo recomendado.

Elección del paquete

Una vez en la página de descargas, encontramos que para nuestro sistema operativo hay 4 paquetes disponibles.

Primero tendremos que decidir si utilizaremos una máquina virtual de 32 o de 64 bits. Como recomendación general, descargaremos la versión de 64 bits si nuestro hardware lo soporta. Afinando mas, hay que tener en cuenta que una aplicación puede llegar a consumir hasta un 50% mas de heap si usa el JDK de 64 en lugar del de 32. Por otro lado, con la de 64 bits podremos direccionar de media el doble de heap: con la de 64 podremos llegar a 4 Gigas frente a los 2 Gigas de la versión de 32 bits. En este post del blog de plumbr podéis encontrar mas detalles sobre esto.

Aunque la memoria es un recurso que se ha abaratado muchísimo en los últimos años y los servidores de la organización seguramente tengan de sobra, hay otros escenarios donde esto no será la norma. Si utilizamos computación en la nube, del tipo iaas, la facturación que nos hagan de los servidores contratados se realizara sobre todo en base a la cantidad de RAM. No es raro ver servidores con 1 Giga de RAM. Seguiremos entonces las siguientes indicaciones:

  • Si vamos a asignar al servidor de aplicaciones menos de 2 Gigas de Heap: utilizaremos la maquina de 32 bits.
  • Si le vamos a asignar de 2 Gigas a 4 Gigas de Heap: entonces utilizaremos la maquina de 64 bits.

Una vez decidido esto, elegiremos el formato del paquete: RPM o bin/tgz. Al margen de si nuestra distribución soporta RPM, utilizaremos siempre el paquete bin/tgz. El motivo de hacer esto es evitar que durante la instalación del RPM se registre la variable JAVA_HOME en nuestro sistema. En mi experiencia, nunca debe haber un JDK en nuestro path. Con esto conseguimos lo siguiente:

  • Evitar que un servidor de aplicaciones arranque con una versión incorrecta del JDK. Esto podría conducir a errores que en ocasiones son difíciles de identificar.
  • Evitar que un servidor mal configurado arranque. Si hemos olvidado indicar el JDK, seguramente hemos olvidado mas cosas.
  • Ser capaces de identificar qué versión del JDK esta usando un servidor de aplicaciones simplemente mirando su fichero de configuración.

Instalación

Como comentábamos antes, una vez descargado el paquete en nuestra maquina cliente, procederemos a subirlo a la maquina servidor, a la carpeta /usr/java/. En el caso de que la carpeta no exista, la crearemos. Utilizamos esta ruta por ser la convención mas extendida. Nos conectaremos por ssh como root y procederemos a la instalación propiamente dicha. Para el JDK7 de 64 bits:

cd /usr/java/
tar xvzf jdk-7u17-linux-xxxx-x64.tar.gz
mv jdk1.7.0_17 jdk1.7.0_17-x64

Con esto, tendriamos el JDK7 instalado en la ruta /usr/java/jdk1.7.0_17-x64. De esta manera podemos saber cuales de los JDK instalados son de 64 y cuales de 32. Incluso podemos tener dos instalaciones del mismo JDK, una de cada tamaño de palabra.Y para el JDK6 de 32:

cd /usr/java/
chmod u+x jdk-6u43-linux-xxxx-i586.bin
sh jdk-6u43-linux-xxxx-i586.bin
mv jdk1.6.0_43 jdk1.6.0_43-i586

Y ya tendríamos el JDK6 en /usr/java/jdk1.6.0_43-i586. Solo en el caso de que tengamos varios servidores de aplicaciones que obligatoriamente usen la misma versión del JDK (un cluster por ejemplo) utilizaremos un enlace simbólico que apunte a dicha versión:

cd /usr/java/
ln -s jdk1.7.0_17-x64 jdk_cluster

Ahora podríamos configurar los servidores de aplicaciones para que buscaran la maquina virtual en la ruta /usr/java/jdk_cluster. Con esto perderemos la capacidad de ver la versión que están utilizando los servidores al ver directamente su configuración, pero ganaremos en facilidad de actualización: para actualizar el JDK de todos los miembros del cluster que haya en esa maquina solo tenemos que cambiar el enlace simbólico al nuevo JDK y reiniciar los servidores.

Conclusión

Con esto ya tendremos instalado el JDK. A partir de ahora, indicaremos la ruta donde ha quedado instalado en los ficheros de configuración de los servidores de aplicaciones. Como hemos visto, el proceso es sencillo, pero siguiendo estos pasos de forma consistente simplificaremos la instalación y mantenimiento de los servidores. Y facilitaremos el trabajo de nuestros compañeros, pues sabrán siempre como esta todo configurado y podrán intervenir aunque no estemos presentes.

Ir arriba