脡ste es un art铆culo de Rahul Biswas, miembro del grupo Java Performance Engineering de Sun. Se trata de una de mis “traducciones”, para ver si me voy reenterando de los temitas java. El art铆culo orginal en ingl茅s lo pod茅is encontrar aqu铆.
La Java Persistence API, presentada en la especificaci贸n (JSR 220) de Enterprise JavaBeans (EJB) 3.0, simplifica el desarrollo de las aplicaciones empresariales en Java que usan persitencia de datos. Este articulito explica como tunear la implementaci贸n que hay en GlassFish de la Java Persistence API llamada Toplink Essentials.
El ejemplo que incluye este art铆culo est谩 basado en el ejemplo customer-cmp que viene con GlassFish. Este art铆culo cubre el tunning de rendimientopara una implementaci贸n de la JPA usada en diferentes modos: in-container y out-of container. Adem谩s tambi茅n se usa el framework Faban para demostrar los diferentes par谩metros de tunning del rendimiento.
Antes de comentar estos par谩metros, vamos a examinar los modos in-container y out-of container y el framework Faban.
Dos modos de ejecutar una implementaci贸n de la Java Persistence
Puedes usar implementaciones de la JPA que sean compatibles con la JSR-220 en cualquiera de estos dos modos: in-container y out-of container. Esta es una marcada diferencia con las primeras implementaciones de JPA, como por ejemplo la persistencia gestionada por el contenedor de las EJB2.1. Con este tipo de gesti贸n de persistencia s贸lo se pod铆a ejecutar dentro de una contenedor de aplicaciones.
El modo In-container significa que la JPA se usa dentro de un contenedor de EJBs. Los entity managers, los objetos que gestionan las entidades de persistencia, normalmente se crean por el contenedor de EJBs. Los Entity managers suelen ser gestores JTA, lo que quiere decir que funcionan bajo transacciones controladas por la Java Transaction Architecture (JTA). Sin embargo, la JPA debe soportar tanto a los entity managers JTA como a los entity managers resource-local, esto es, gestores en transacciones no gestionadas por JTA.
En el modo out-of-container la JPA es standalone o se ejecuta en un contenedor web. La aplicaci贸n es responsable de crear sus propios entity managers. Las transacciones suelen ser locales. Si la implementaci贸n funciona sola, no necesita soportar JTA.
The Faban Driver Framework
Faban es un driver framework de c贸digo abierto que permite a los desarrolladores crear, ejecutar y simular procesos de benchmarking. Para m谩s informaci贸n consultar la p谩gina del proyecto Faban.
Tunear la Aplicaci贸n de muestra
La aplicaci贸n de ejemplo customer-cmp interactua con una base de datos relacional para guardar y mostrar informaci贸n sobre las suscripciones de los clientes a publicaciones. La base de datos guarda informaci贸n como el nombre y la direcci贸n del cliente, as铆 como el tipo de peri贸dico al que el cliente est谩 suscrito — esto es, una revista, un bolet铆n o un diario. Los usuarios pueden enviar peticiones a la aplicaci贸n para mostrar informaci贸n relacionada con sus suscripciones.
Este tutorial se enfoca en una de las operaciones soportadas por la aplicaci贸n: encontrar a un usuario por su ID.
Cambiar el tama帽o de la Cache y el n煤mero de pools de conexiones
Vamos a examinar el impacto que tienen los par谩metros de tunning espec铆ficos sobre el rendimiento combinado de estas operaciones. Espec铆ficamente, vamos a examinar el impacto que tiene cambiar el tama帽o de la cache en Toplink Essentials y resetear el n煤mero de conexiones en la connection pool en GlassFish para las llamadas a la base de datos.
Toplink Essentials tiene un tama帽o de cache por defecto de 1000 por entidad. Para demostrar el efecto del cambio en el tama帽o de la cache, veamos el ratio de transacciones usando el valor por defecto. Y despu茅s cambiaremos el tama帽o a 5000 y compararemos los resultados.
Para establecer el tama帽o de la cache, necesitas modificar el fichero persistence.xml de tu proyecto y establece la propiedad toplink.cache.size.default como sigue:
<property name="toplink.cache.size.default" value="5000"/>
En este ejemplo, hay 20.000 clientes en la base de datos.
La configuraci贸n de la cache sirve para los dos modos comentados antes (in-container y out-of-container). La connection pool, sin embargo, se gestiona diferente seg煤n se use un modo u otro. Para dentro del contenedor, la connection pool se configura en el servidor, en Glassfish en este caso, y se controla por la configuraci贸n de una fuente de datos o data-source. En este modo, puedes configurar las conexiones con la consola de administraci贸n de GlassFish.
Dentro del contenedor, establece el n煤mero de conexiones del pool del contenedor con el n煤mero de threads para procesar peticiones a una instancia de GlassFish (en este caso, 40). 脡ste es el m谩ximo n煤mero de conexiones que necesita Toplink Essentials para las llamadas a la base de datos.
Para el uso fuera del contenedor, la configuraci贸n del pool de conexiones se hace en el fichero persistence.xml. La implementaci贸n Toplink Essentials tiene una configuraci贸n por defecto de la connection pool de ocho conexiones tanto para lecturas como escrituras. Ejecutaremos la aplicaci贸n en el modo out-of-container para ocho usuarios, de modo que estableceremos las conexiones de la connection pool a ocho.
Resultados
Si ejecutamos Toplink dentro del contenedor obtenemos los siguientes resultados:
| Tama帽o cache | Transacciones/segundo | ||
| 1000 (por defecto) | 1911.493 | ||
| 5000 | 3727.253 | ||
Ejecutando Toplink fuera del contenedor tenemos lo siguiente:
| Tama帽o cache/ Connection Pool |
Transacciones/segundo | ||
| 1000/por defecto* | 1456.153 | ||
| 5000/8 | 6510.0 | ||
* Los valores por defecto son:
toplink.jdbc.read-connections.min = 2
toplink.jdbc.read-connections.max = 2
toplink.jdbc.write-connections.max = 10
toplink.jdbc.write-connections.min = 5
N贸tese que cuando se usan los valores por defecto, el pool se inicializa con la configuraci贸n por defecto m铆nima y puede escalar al m谩ximo especificado por la configuraci贸n m谩xima por defecto. Poniendo un valor de 8 al pool, siempre habr谩 ocho conexiones en el pool.
Las configuraciones del sistema para los tests son:
Sun Fire V880, Solaris 10, 4 CPUs para el Sistema bajo test(SUT).
Sun Fire V880, Solaris 10, 12 CPUs para el sistema driver (v茅ase Faban framework).
N贸tese que el driver y el SUT son el mismo sistema para el test out-of-container. El sistema Driver y el SUT tienen una conexi贸n ethernet punto-a-punto, lo que quiere decir que no hay tr谩fico de red externo.
Resumen
Para obtener el mejor rendimiento de tu JPA, es importante entender los par谩metros de tunning inclu铆dos en la implementaci贸n de la JPA.
La configuraci贸n de la cache es un importante par谩metro de tunning de Toplink. Ajustar la connection pool de GlassFish tambi茅n es importante para obtener el mejor rendimiento de cualquier implementaci贸n de JPA dentro de GlassFish.
Si usas una JPA fuera del contenedor EJB, la cache y la connection pool tambi茅n juegan un papel importante en el rendimiento, aunque en este caso configuramos el pool en el fichero persistence.xml.
Hay otros par谩metros que pueden impactar en el rendimiento de una JPA. Uno es el statement cache. 脡ste se tiene que especificar expl铆citamente para algunas bases de datos como una Oracle. Este par谩metro se activa por defecto la base de datos Java DB que viene con GlassFish.
Adem谩s, la configuraci贸n de tu Java Virtual Machine (JVM) puede jugar un rol importante en el ajuste de la persistencia. Para tener informaci贸n detallada del ajuste de la JVM, mira el Java Tuning White Paper. Para la ejecuci贸n de la aplicaci贸n de este tip, las opciones de la JVM las pondremos as铆:
-server -XX:+AggressiveHeap -Xmx2500m -Xms2500m -Xss128k
-XX:+DisableExplicitGC
Para m谩s informaci贸n
Para m谩s informaci贸n sobre Java Persistence, ver The Java Persistence API - A Simpler Programming Model for Entity Persistence y el Java Persistence API FAQ.
Para m谩s informaci贸n sobre Toplink Essentials, ver TopLink Essentials - The Java Persistence API Implementation at GlassFish.
Ejecutar el c贸digo de ejemplo
Para instalar y ejecutar el c贸digo que acompa帽a esta propinilla:
GLASSFISH_HOME. Debe apuntar d贸nde hayas instalado GlassFish.ANT_HOME. Debe apuntar d贸nde tengas instalado el Ant (incluido en el paquete de GlassFish).JAVA_HOME. Apunta d贸nde tengas el JDK 5.0.A帽adir $JAVA_HOME/bin, $ANT_HOME/bin, y $GLASSFISH_HOME/bin a tu variable de entorno PATH.
<sample_install_dir>/ttmay2007jpaper, donde <sample_install_dir> es el direcotorio donde hayas puesto el paquete. El directorio ttmay2007jpaper contiene el c贸digo fuente adem谩s de otros ficheros para el ejemplo.javaee.server.passwordfile sea correcta. $GLASSFISH_HOME/bin/asadmin start-domain domain1 ant start-db: ant create-db ant setup ant generate-data ant configure-glassfish ant run_inc_default ant run_inc_optimized ant run_ooc_default ant run_ooc_optimized${runid} es el id de cada ejecuci贸n que muestra la consola durante la ejecuci贸n. Para ver los resultados, hay que ver el fichero summary.xml en ese directorio. Una vez termina la ejecuci贸n, puedes desahacer la configuraci贸n de tunning. Cambia al directorio samples/javaee5/enterprise/customer-cmp-ear/setup e introduce el siguiente comando: ant unconfigure_glassfish.[…] Fuente: Blog del Galifate. […]