Buenas prácticas en Message Broker

Performance en Message Broker

• La capacidad de procesamiento de Message Broker depende de varios factores, incluyendo hardware, configuración, flujos de mensajes, formato de los mensajes, diseño e implementación de las soluciones, el numero de instancias por flujo, etc.
• Esta charla describe buenas prácticas para la implementación y desarrollo que esta ligada al performance y capacidad de procesamiento en los servicios de flujos de mensajes.

Message Flow – I/O vs CPU

Message Broker es una aplicativo orientado a la CPU, mas que al I/O, asi que es mejor evitar operaciones de escritura en disco o bases de datos siempre que sea posible.

Separar la lógica del negocio de la configuración del sistema siempre ha sido una buena practica en todas las soluciones, aquí es igualmente valida, pero hay que tener cuidado en la interacción de esta configuración con el proceso, ya que una configuración en tiempo real baja el performance notablemente vs una solución de almacenamiento en cache.

Message Flow – Parsing

Utilice métodos de conversión parcial siempre que le sea posible, a menos que necesidades del negocio le obliguen a realizar la conversión total del mensaje.

WebSphere Message Broker da soporte al análisis parcial. Si un mensaje individual contiene cientos o incluso miles de campos individuales, la operación de análisis requiere una cantidad considerable de memoria y recursos del procesador para poder completarse. Un flujo de mensajes individual puede hacer referencia sólo a algunos de estos campos o a ninguno de ellos, por tanto, no resulta práctico analizar cada mensaje de entrada por completo.

Message Flow – Reducir

Cuando sea posible reduzca el numero de nodos en el flujo de mensajes, también intente reducir las copias del mensaje que se crean, las copias de los mensajes pueden ocupar una buena cantidad de memoria especialmente si estos tienen una gran cantidad de elementos.

Los nodos de computo úselos solo cuando sea necesario, para evitar las copias de los mensajes.

Esto no solo trae mejoras de memoria sino de tiempo de ejecución.

Message Flow – Trace Nodes

Evite el uso de nodos tipo trace en ambientes de producción, sobre todo aquellos donde se utilice la expresión ${Root}, ya que esta causa una conversión completa del mensaje, incluso si el destino no se encuentra activo.

Message Flow – Uso

Use los flujos de mensajes, solamente para mediaciones como transformaciones, traducciones, conversiones de protocolo, enriquecimiento de los mensajes y enrutamiento.

Los flujos de mensajes deben ser maquinas de estado en las actividades de mediación.

Message Flow – Complejidad

Es altamente recomendado tener pocos nodos muy complejos, que tener una gran cantidad de nodos con actividades especificas.

ESQL – String Manipulation

Las manipulaciones de cadenas en ESQL son intensas para el procesador. Intente minimizarlas siempre que le sea posible.

ESQL vs Java

Ambas opciones dependen mucho de los skills del desarrollador, cuando elegir una u otra.

JAVA:

• Mensajes cortos
• Transformación de cadenas
• No existen skills en ESQL

ESQL:

• Mensajes Largos
• Obtener o alterar mucha información
• Recomendado sobre JAVA

Problemas de Performance

Los problemas con el performance de las integraciones realizadas con Broker, usualmente tienden a tomar 2 formas visibles.

1. Por alguna razón no se tienen los tiempos de procesamiento esperados.
2. Se obtienen los tiempos de procesamiento esperados pero el uso del CPU es demasiado alto.

Esto se puede dar debido a

• Falta de recursos para ejecutar el flujo.
• Una mala o pobre configuración del ambiente.
• Demora por dependencia a otras aplicaciones.
• Flujos ineficientes.
• Procesamiento ineficiente o excesivo en los nodos de computo.