Optimizar los tiempos de respuesta de los flujos de mensajes

Antes de empezar:

Consulte el tema de concepto sobre nodos de flujos de mensajes.

Cuando diseña un flujo de mensajes, la flexibilidad y riqueza de los nodos incorporados a menudo significa que hay varias formas de conseguir el proceso y, por tanto, de conseguir el resultado final requerido. Sin embargo, es posible que también encuentre que estas distintas soluciones generan distintos rendimientos y, si este elemento es importante en su caso, debe diseñar de forma que obtenga un buen rendimiento así como una buena funcionalidad.

Las aplicaciones pueden percibir el rendimiento de dos formas:

  1. Tiempo de respuesta. Indica la rapidez con que el flujo de mensajes procesa cada mensaje. En este aspecto, tiene una gran influencia el diseño de los flujos de mensajes. Esto se trata más ampliamente en este tema.
  2. Rendimiento. Indica cuántos mensajes de un tamaño específico puede procesar un flujo de mensajes en un cierto periodo de tiempo. En este aspecto, tienen una gran influencia los factores de configuración y recursos del sistema y, por tanto, se trata en Optimizar el rendimiento del flujo de mensajes con otra información de configuración de dominios.

Hay varios aspectos que afectan a los tiempos de respuesta de los flujos de mensajes. Sin embargo, cuando crea y modifica el diseño del flujo de mensajes para obtener los mejores resultados que satisfagan los requisitos específicos del negocio, también debe tener en cuenta la eventual complejidad del flujo de mensajes. Los flujos de mensajes más eficaces no son necesariamente los más fáciles de entender y mantener; experimente las distintas soluciones disponibles hasta obtener el mejor equilibrio para sus necesidades.

Hay varios factores que afectan a los tiempos de respuesta del flujo de mensajes:

El número de nodos que se incluyen en el flujo de mensajes
Cada nodo aumenta la actividad general de proceso, por lo que debe tener muy en cuenta el contenido del flujo de mensajes, incluido el uso de subflujos.

En un flujo de mensajes, utilice el menor número posible de nodos; cada nodo que se incluye en el flujo de mensajes aumenta la actividad general en el intermediario. Hay un límite superior en el número de nodos en un solo flujo. Este límite lo controlan los recursos del sistema, especialmente el tamaño de pila.

Para obtener más información sobre los tamaños de pila, consulte Consideraciones acerca del sistema para el despliegue de flujos de mensajes.

Cómo el flujo de mensajes direcciona y procesa los mensajes
En algunas situaciones, puede encontrarse con que los nodos incorporados y quizás otros nodos que están disponibles en el sistema, proporcionan más de una forma de ofrecer la misma función. Intente elegir la configuración más sencilla. Por ejemplo, si desea definir algunos procesos específicos basados en el valor de un campo en cada mensaje, puede diseñar un flujo de mensajes que tenga una serie de nodos Filter para manejar cada caso. Si es adecuado, puede agrupar los mensajes mediante el nodo Filter para reducir el número por el que tiene que pasar cada tipo de mensaje antes de ser procesado.

Por ejemplo, supongamos que tiene un flujo de mensajes que maneja ocho mensajes distintos (Factura, Nota de despacho, etc.). Puede incluir un nodo Filter para identificar cada tipo de mensaje y direccionarlo según el tipo. Puede optimizar el rendimiento de esta técnica comprobando los tipos de mensaje más frecuentes en los primeros nodos Filter. Sin embargo, el octavo tipo de mensaje debe pasar a través de ocho nodos Filter.

Si puede agrupar los tipos de mensaje (por ejemplo, si el tipo de mensaje es numérico, y puede comprobar todos los tipos superiores a cuatro e inferiores a cuatro), puede reducir el número de nodos Filter necesarios. El primer nodo Filter comprueba si son superiores a cuatro y pasa el mensaje a dos nodos Filter más (conectados a los terminales verdadero y falso) que comprueban si son menores de dos y menores de seis respectivamente. A continuación, cuatro nodos Filter adicionales pueden comprobar si son uno o dos, tres o cuatro, etc. Aunque el número de nodos Filter necesarios sea el mismo, el número de nodos por el que pasa cada mensaje es menor.

Quizá encuentre que el uso de un nodo RouteToLabel con un conjunto de nodos Label ofrecen una alternativa mejor a una secuencia de nodos Filter. Cada mensaje pasa a través de un número más pequeño de nodos, mejorando el rendimiento. Sin embargo, debe tener en cuenta que la utilización de un nodo RouteToLabel significa utilizar un nodo Compute: la actividad general de este nodo puede exceder las ventajas que se obtienen. Si maneja un número limitado de tipos de mensajes, es más eficaz un número pequeño de nodos Filter.

El Ejemplo Reserva de vuelos muestra cómo puede utilizar los nodos RouteToLabel y Label en lugar de utilizar varios nodos Filter en el flujo de mensajes XML_PassengerQuery. El Ejemplo Direccionamiento de mensajes muestra cómo puede almacenar información de direccionamiento de una tabla de base de datos en una antememoria en memoria del flujo de mensajes.

Si el flujo de mensajes incluye bucles
Evite los bucles de nodos que se repiten; pueden ser muy ineficaces y causar problemas de rendimiento y de pila. Puede observar que un nodo Compute con varias sentencias PROPAGATE evita la necesidad de efectuar bucles de series de nodos.
La eficacia del ESQL
Compruebe todo el código ESQL que ha creado para los nodos de flujo de mensajes. Cuando desarrolla y prueba un nodo, quizá conserve sentencias que no son necesarias cuando ha finalizado el proceso del mensaje. Puede también encontrarse con que ha codificado como dos sentencias lo que se puede codificar en una. El dedicar un tiempo a la revisión y comprobación del código ESQL puede hacer que éste se simplifique y mejore el rendimiento.

Si ha importado flujos de mensajes de un release anterior, compruebe las sentencias ESQL en relación con el ESQL disponible en la Versión 5.0 para ver si puede utilizar nuevas funciones o sentencias para mejorar su eficacia.

El uso de mensajes persistentes y de transacciones
Los mensajes persistentes se guardan en el disco durante el proceso del flujo de mensajes. Esto se evita si puede especificar que los mensajes de entrada, salida o ambos, no son persistentes. Si el flujo de mensajes sólo maneja mensajes no persistentes, compruebe la configuración de los nodos y el flujo de mensajes mismo; si los mensajes son no persistentes, quizá no sea necesario el soporte de transacciones. La configuración por omisión de algunos nodos fuerza la transacciones; si actualiza estas propiedades y vuelve a desplegar el flujo de mensajes, quizá mejore los tiempos de respuesta.
Tamaño del mensaje
Cuanto más grande es el mensaje, más tiempo requiere su proceso. Si puede dividir los mensajes grandes en trozos de información más pequeños, quizá pueda mejorar la velocidad a la que los maneja el flujo de mensajes. El Ejemplo Mensajería grande muestra cómo minimizar los requisitos de memoria virtual para el flujo de mensajes a fin de mejorar el rendimiento de un flujo de mensajes al procesar mensajes potencialmente grandes.
Formato del mensaje
Aunque WebSphere Message Broker soporta varios formatos de mensaje y proporciona recursos que puede utilizar para transformar de un formato a otro, esto genera un aumento de la actividad general. Asegúrese de que no efectúa ninguna conversión ni transformación innecesaria.

Puede encontrar más información sobre cómo mejorar el rendimiento de un flujo de mensajes en este artículo de developerWorks sobre el rendimiento del flujo de mensajes.

Conceptos relacionados
Visión general de flujos de mensajes
Visión general del despliegue
Consideraciones acerca del sistema para el despliegue de flujos de mensajes
Tareas relacionadas
Configuración del dominio de intermediarios
Optimizar el rendimiento del flujo de mensajes
Diseñar un flujo de mensajes
Utilizar más de un nodo de entrada
Crear un flujo de mensajes
Definir el contenido del flujo de mensajes
Edición de propiedades configurables
Referencia relacionada
Nodos incorporados
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac00355_