Utilización de distintas soluciones para mejorar los tiempos de respuesta del flujo de mensajes.
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:
- 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.
- 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.