Tips para optimización de la solución en POCs con Oracle Service

Tips para optimización de la solución en POCs
con Oracle Service Bus
Paulo Alesso
29 de Septiembre de 2008
Introducción
Las empresas luchan por ser ágiles con el objetivo de ser lo suficientemente flexibles para
aprovechar las oportunidades que ocurren en ambientes en constantes cambios. La
capacidad de presentar nuevos servicios y reutilizar los existentes al ritmo que se exige es
cada día un reto. Sin embargo, las Arquitecturas Orientadas a Servicio (SOA) permiten
lograr esto.
Oracle Service Bus aporta una infraestructura orientada a servicios alineada a sus
necesidades haciendo converger de forma uniforme las capacidades de integración de un
Bus de Servicios Empresarial (ESB) con gestión de servicios en un solo producto de
software. Esto acelera la configuración y el despliegue, y simplifica la gestión de
servicios compartidos sobre SOA.
Las caracterísitcas técnicas de Oracle Service Bus constituyen un diferenciador
importante frente a nuestros competidores. Sin embargo, la performance de la solución es
uno de los principales indicadores que nuestros clientes miden a la hora de seleccionar la
infraestructura que dará soporte a SOA. Es por ello, que en toda prueba de concepto
deben cuidarse ciertos aspectos que permiten que la performance sea aceptable.
En este documento se describen las consideraciones principales que permiten mejorar el
rendimiento de Oracle Service Bus y que normalmente no son abordados durante una
prueba de concepto (PoC). Realizando el tuning de service bus, la performance es
superior a al menos cercana a la de nuestros competidores.
2
Tips para optimizar la solución
Oracle Service Bus está optimizado para el procesamiento y ruteo de mensajes. Deben
tenerse en cuenta los siguientes puntos con el fin de asegrurar que el rendimiento no se
vea afectado por el diseño e implementación de la solución requerida:
1. Nunca se debe utilizar “//” en XPath o XQuery!!! Si uno de los objetivos de la
PoC es la performance, no se debe usar // en la expresiones, dado que esto obliga
al motor XQuery a buscar el elemento deseado por todo el documento XML
(equivalente a realizar un full scan en una tabla de la base de datos). La
performance puede mejorar entre 10 y 20 veces si la expresión contiene la
ruta directa al elemento en lugar de //.
2. Logueo, Monitoreo y JVM. Apagar el logueo de WebLogic Server (stdout y
http), desabilitar el monitoreo de OSB, no utilizar Pointbase, utilizar JRockit e
incrementar el heap de la JVM sobre 2 GB, eliminar las acciones de Log, si es
posible deshabilitar la persistencia de JMS, si es posible utilizar transacciones noXA, y deshabilitar el tracing de OSB.
3. Usar transporte “local” y Java Callouts. Para modularizar el diseño de los
proxy services invocar a otros proxys dentro del flujo usando el transporte
“local”, evitando el uso de HTTP y JMS si es posible. Utilizar invocaciones a
EJBs o POJOs para acceder a código externo cuando sea necesario. Al invocar
servicios externos tener simpre presente que EJB y JMS no persistentes son más
rápidos que HTTP.
4. Evitar el uso de XQuery dentro de ciclos For. Si se utilizan acciones del tipo
For-Each, se debe tratar de realizar las expresiones XQuery fuera de estos ciclos
siempre y cuando sea posible. Realizar expresiones XQuery dentro de los ciclos
provoca multiples inicializaciones del motor XQuery, en lo posible, se debe tratar
de escribir una expresión XQuery que genere un documento más grande previo a
iniciar el los ciclos repetitivos, donde cada elemento dentro de este documento
contiene el xml necesario dentro del ciclo For
5. Utilizar Self-Tuning de WebLogic Server. En general el self-tuning de
WebLogic Server permite lograr mejores resultados desde el punto de vista de
performance que cuando se utilizan los Work Managers. Es conveniente utilizar
los Work Managers por ejemplo en casos en los que se requiere que algún
servicio tenga un tiempo de procesamiento mínimo. No olvidar fijar un tiempo de
warmup en las pruebas de performance que le permitan a WebLogic Server
ajustar los threads previo a registrar los resultados oficiales.
6. Utilizar clusters. Si el ambiente en el que se realizaran las pruebas tiene más de 2
CPU (o más de 4 cores) se debe considerar la posibilidad de utilizar 2 instancias
en cluster en lugar de un simple instancia de OSB. Un sola instancia de OSB no
3
es capaz de realizar un uso óptimo de más de 2 CPUs o 2-3 GB de memoria, por
eso, si se dispone de estos recursos se deben aprovechar las ventajas del cluster o
de la utilización de instancias paralelas.
7. Problemas con acciones JMS Publish y Route. Si el caso de uso requiere
publicar mensajes a más de un destino JMS diferente, se pueden lograr mejores
resultados desde el punto de vista de la performance reemplazando la acción
Publish por un Java Callout a un POJO que realiza la publicación del mensaje
mediante JMS (el POJO debería hacer cache del JNDI). Esto se debe a que
OSB/WLS solo hacen cache del último JMS Producer.
8. Combinar acciones y XQuery. Mientras menor sea el número de ejecuciones
XQuery que OSB tenga que realizar, mejor será la performance. Por lo tanto, se
deben tratar de combinar acciones Assign, Replace y Rename dentro de una sóla
expresión XQuery cada vez que sea posible.
9. XQuery avanzado. Técnicas avanzadas de XQuery, tales como: maps, computed
constructors, permiten mejorar la performance. Por lo tanto, conseguir un buen
documento de XQuery o solicitar ayuda nunca estará demás.
4