Tunning Glassfish 2.1

Cuando realizamos un tuning o puesta a punto para mejorar el desempeño de una aplicación, muchos de nosotros no sabemos por dónde empezar. Con anterioridad hemos visto que lo mejor es iniciar tuning del código aplicativo, pues muchas veces es lo más fácil o que mayor impacto logra en el desempeño de la solución, para después ir bajando a las capas más abstractas de la arquitectura (contenedores de aplicaciones o middleware, luego sistema operativo y finalmente hardware). Ahora bien, con bastante regularidad, la mayoría de los encargados de hacer despliegues de aplicaciones saben qué parámetros modificar para hacer que la Máquina Virtual de Java (JVM) dé lo mejor de sí, pero en cuanto al servidor de aplicaciones, todos se quedan en blanco.

Hace poco ayudé a unos compañeros con este tipo de parámetros, pues su aplicación se caía con tan sólo un par de deployments, marcando el temido java.lang.OutOfMemoryError en muy poco tiempo. Entonces, aquí presento los parámetros más socorridos para mejorar el desempeño de una aplicación, con pequeños ejemplos para el servidor de aplicaciones Glassfish 2.1. No son en absoluto exhaustivos, pero pueden proporcionarnos una línea base a partir de la cual podemos ir trabajando:

1. La versión de la Máquina Virtual de Java

Obviamente es un cliché, pero hemos comprobado la diferencia que puede hacer una versión de Java. Siempre es una buena práctica instalar la última versión en los servidores donde correrá la aplicación. No es necesario contar con el root del servidor si se instala mediante un ejecutable (por ejemplo, j2sdk-1_6_0_18-solaris-sparc.sh) lo que permite instalar una nueva versión de Java sin impactar dominios de aplicaciones desplegados previamente. Primero, hay que instalar la nueva versión de la JVM y luego deberemos cambiar el path desde donde la toma Glassfish:

$GLASSFISH_HOME/config/asenv.conf

propiedad a modificar: AS_JAVA=<java_installations>/j2sdk1.6.0_18

2. Modo de ejecución de la Máquina Virtual de Java

Los servidores Glassfish corren por default en modo "cliente". Esto hace que levanten más rápido en un ambiente de desarrollo, pero esta modalidad de ejecución no es ideal en producción. Adicionalmente, por default la JVM tiene un límite de consumo de memoria de 64 Megabytes. Si nuestro servidor productivo tiene más que eso, lo mejor es incrementar los valores de acuerdo al disponible de memoria con el que contamos:

• Ingresar a http:<hostname>:4848

• Firmarse con usuario/password administrador.

• Click en nodo de application server a editar > JVM Settings > JVM Options.

• Editar las opciones de la JVM o agregar nuevas en el campo de texto correspondiente: -server -Xmx1500m -Xms1500m

• Click en Save del lado derecho.

• Reiniciar el servidor.

En el ejemplo Xms es la cantidad de memoria inicial (aquí se definieron 1500 MB o 1.5 Gigabytes) y Xmx es la cantidad de memoria máxima a usar por la JVM.

3. Número de threads de acceso

Los threads de acceso (acceptor threads) son hilos de ejecución asignados a un socket para que el servidor procese peticiones HTTP. El número por default es uno, pero es mejor designar el número de threads de acuerdo al número de cores (núcleos de procesador) que tiene la máquina donde corre el servidor, usando una proporción de 1 thread por cada 1 a 4 cores. Puede ser necesario probar la aplicación con diferentes parámetros para encontrar el óptimo. Ejemplo:

Una M3000 con 2 procesadores dual core puede tener un mínimo de (2 CPUs x 2 dual cores / 4 threads por core) = 1 thread o un máximo de (2 CPUs x 2 dual cores / 1 thread por core) = 4 threads.

Para modificar los valores en Glassfish, seguimos los siguientes pasos:

• Ingresar a http:<hostname>:4848

• Firmarse con usuario/password administrador.

• Click en nodo de application server a editar: Configuration > HTTP Service > HTTP Listeners

• Click en http-listener-1

• Editar el campo Acceptor Threads en la sección Advanced

• Click en Save del lado derecho.

• Reiniciar el servidor.

4. Número de threads de procesamiento

Los threads de procesamiento son los que ejecutan las peticiones HTTP. El default es 5, pero debe modificarse de acuerdo al número de cores que posee la máquina en proporción 1 a 1. Si la aplicación ocupa mucho uso de disco (I/O), es recomendable que el valor sea multiplicado por dos. Ejemplo:

Una M3000 con 2 dual cores puede tener 2 CPUs x 2 dual cores = 4 threads; si la aplicación usa mucho I/O, el número se multiplica por dos, quedando en 8 threads.

Nuevamente, para implementar este cambio, podemos seguir los siguientes pasos:

• Ingresar a http:<hostname>:4848

• Firmarse con usuario/password administrador.

• Click en nodo de application server a editar: Configuration > HTTP Service > Tab RequestProcessing

• Cambiar el valor Thread Count al número correspondiente.

• Click en Save del lado derecho.

• Reiniciar el servidor.

5. Subsistema Keep-alive

El keep-alive se utiliza para optimizar el uso de red. Normalmente, una petición HTTP requiere abrir la conexión – enviar datos – cerrar la conexión. Pero si una misma conexión envía información en diferentes tiempos, ¿no sería mejor dejarla siempre abierta para no pasar por el trabajoso proceso de abrirla? Siempre se recomienda cambiar el número de threads a 1 por cada 8 cores en la máquina para mejorar el uso de estos recursos. Ejemplo:

Una M3000 con 2 dual cores puede tener 2 CPUs x 2 cores = 4; por default debe tener 1 thread asignado. Si dicha M3000 tuviera 4 CPUs quad core, tendría 2 CPUs x 4 cores = 16; un default de 2 threads asignados.

• Ingresar a http:<hostname>:4848

• Firmarse con usuario/password administrador.

• Click en nodo de application server a editar:

...