Optimizar los tiempos de respuesta de los flujos de mensajes

Utilización de distintas soluciones para mejorar los tiempos de respuesta del flujo de mensajes.

Antes de empezar:
Lea el siguiente tema conceptual:

Cuando se diseña un flujo de mensajes, la flexibilidad y prestaciones funcionales de los nodos incorporados a menudo indican que hay varias formas de conseguir el proceso y los resultados necesarios. Es posible que también encuentre que distintas soluciones generan distintos niveles de rendimiento y, si este elemento es importante en su caso, debe tenerlo en cuenta al diseñar su flujo de mensajes.

Las aplicaciones pueden percibir el rendimiento de cualquiera de estas formas:

  1. El tiempo de respuesta indica la rapidez con que el flujo de mensajes procesa cada mensaje. En el tiempo de respuesta tiene una gran influencia el diseño de los flujos de mensajes. En este tema se habla sobre el tiempo de respuesta.
  2. El rendimiento indica cuántos mensajes de un tamaño específico puede procesar un flujo de mensajes en un cierto periodo de tiempo. En el rendimiento, tienen una gran influencia los factores de configuración y recursos del sistema y se comenta en apartado sobre la optimización del rendimiento del flujo de mensajes demás información sobre configuración de dominios. Consulte el apartado Optimizar el rendimiento del flujo de mensajes.

Varios factores afectan a los tiempos de respuesta del flujo 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 cantidad de proceso necesaria en el intermediario, por lo que debe tener en cuenta especialmente 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 cantidad de proceso necesaria en el intermediario. Hay un límite superior en el número de nodos dentro de 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. Elija 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 de éstos 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. 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 que una secuencia de nodos Filter. Cada mensaje pasa a través de un número más pequeño de nodos, mejorando el rendimiento. No obstante, también debe tener en cuenta que la utilización de un nodo RouteToLabel significa utilizar un nodo Compute: el incremento en la cantidad de proceso necesaria en el intermediario causada en el nodo podría pesar más que las ventajas. Si maneja un número limitado de tipos de mensajes, es más eficaz un número pequeño de nodos Filter.

El siguiente ejemplo muestra cómo se pueden utilizar los nodos RouteToLabel y Label en vez de varios nodos Filter en el flujo de mensajes XML_PassengerQuery. El siguiente ejemplo muestra cómo se puede almacenar información de direccionamiento de una tabla de base de datos en una memoria caché interna del flujo de mensajes. Los ejemplos sólo pueden verse cuando se utiliza el centro de información que está integrado en el Kit de herramientas de Message Brokers.
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 pensar que un nodo Compute con varias sentencias PROPAGATE evita la necesidad de efectuar bucles de una serie 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 6.1 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. Puede evitar esta situación si especifica 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 unidades de información más pequeñas, quizá pueda mejorar la velocidad a la que los maneja el flujo de mensajes. El siguiente ejemplo 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. Los ejemplos sólo pueden verse cuando se utiliza el centro de información que está integrado en el Kit de herramientas de Message Brokers.
Formato del mensaje
Aunque WebSphere Message Broker da soporte a varios formatos de mensajes múltiples y proporciona recursos que puede utilizar para transformar de un formato a otro, esta transformación incrementa la cantidad de proceso necesaria en el intermediario. 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 rendimiento de 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 de WebSphere Message Broker
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, 2009Copyright IBM Corporation 1999, 2009.
Última actualización : 2009-02-16 13:53:29

ac00355_