Optimizar el rendimiento del flujo de mensajes

Cada flujo de mensajes que diseñe debe proporcionar un conjunto completo de procesos para los mensajes recibidos de un origen específico. Sin embargo, esto puede dar como resultado unos flujos de mensajes muy complejos que incluyen gran número de nodos y provocan una disminución del rendimiento y posibles cuellos de botella. Al aumentar el número de flujos de mensajes que procesan los mensajes, se proporciona la oportunidad de realizar procesos paralelos y, por tanto, de mejorar el rendimiento.

También puede tomar en consideración la forma en que se confirman las acciones que toma el flujo de mensajes, y el orden en que se procesan los mensajes.

Tenga en cuenta las siguientes opciones para optimizar el rendimiento del flujo de mensajes:

Varias hebras de proceso de mensajes en un solo flujo de mensajes
Cuando despliega un flujo de mensajes, el intermediario automáticamente inicia una instancia del flujo de mensajes para cada nodo de entrada que contiene. Éste es el comportamiento por omisión. Sin embargo, si tiene un flujo de mensajes que maneja un gran número de mensajes, el origen de entrada (por ejemplo, una WebSphere MQ cola), puede convertirse en un cuello de botella.

Puede actualizar la propiedad Instancias adicionales del flujo de mensajes desplegados en el archivo bar: el intermediario inicia copias adicionales del flujo de mensajes en hebras aparte, que proporcionan procesos en paralelo. Esta es la forma más eficaz de manejar esta situación, si no es importante el orden en que se procesen los mensajes.

Si el flujo de mensajes recibe mensajes de una WebSphere MQ cola, puede influir, hasta cierto punto, en el orden en que se procesan los mensajes, estableciendo la propiedad Modalidad de orden del nodo MQInput:

  • Si establece la Modalidad de orden en Por ID de usuario, el nodo asegura que los mensajes de un usuario específico (identificado por el campo UserIdentifier en MQMD) se procesen en el orden prometido. Una instancia del flujo de mensajes no procesa un segundo mensaje de un usuario si otra instancia está procesando un mensaje anterior de este mismo usuario.
  • Si establece la Modalidad de orden en Por orden de cola, el nodo procesa un mensaje cada vez para mantener el orden en que los mensajes se leen de la cola. Por tanto, este nodo se comporta como si hubiera establecido la propiedad Instancias adicionales del flujo de mensajes en cero.

Para las aplicaciones de publicación/suscripción que se comunican con el intermediario a través de cualquier protocolo soportado, los intermediarios publican los mensajes para un tema específico en el mismo orden en que se reciben de los publicadores (sujeto a reordenación según la prioridad del mensaje, si es aplicable). Normalmente, esto significa que cada suscriptor recibe mensajes de un intermediario específico, sobre un tema específico, de un publicador específico, en el orden en que éste los ha publicado.

Sin embargo, es posible que los mensajes, ocasionalmente, se entreguen de forma desordenada. Esto puede suceder, por ejemplo, si falla un enlace en la red y los mensajes siguientes son direccionados por otro enlace.

Si tiene que asegurar el orden en que se reciben los mensajes, puede utilizar el parámetro SeqNum (número de secuencia) o PubTime (hora de publicación) del mandato Publish para cada mensaje publicado, para calcular el orden de publicación.

Para obtener más información sobre las técnicas recomendadas para todos los usuarios de MQI y AMI, consulte la publicación WebSphere MQ Application Programming Guide para los programas escritos para la MQI y la publicación WebSphere MQ Application Messaging Interface (disponible como SupportPac MA0F en la página web de WebSphere MQ SupportPacs) para programas escritos para la AMI.

WebSphere MQ Everyplace y las aplicaciones SCADA utilizando un método diferente de orden de mensajes tal como se describe en WebSphere MQ Mobile Transport y en WebSphere MQ Telemetry Transport respectivamente. El intermediario no ordena los mensajes recibidos a través de WebSphere MQ Web Services Transport,WebSphere MQ Real-time Transport, o WebSphere MQ Multicast Transport.

Varias copias del flujo de mensajes en un intermediario
Puede desplegar varias copias del mismo flujo de mensajes a distintos grupos de ejecución en el mismo intermediario. Esto tiene un efecto similar a aumentar el número de hebras de proceso en un solo flujo de mensajes, aunque normalmente proporciona una ganancia menos perceptible.

Esta opción también elimina la posibilidad de determinar el orden en que se procesan los mensajes. Esto se debe a que, si hay más de una copia del flujo de mensajes activa en el intermediario, cada copia puede estar procesando un mensaje al mismo tiempo, de la misma cola. El tiempo que se tarda en procesar un mensaje puede variar y, por tanto, varios flujos de mensajes accediendo a la misma cola podrían leer mensajes del origen de entrada en orden aleatorio. El orden de los mensajes generado por los flujos de mensajes podría no corresponder al orden de los mensajes originales.

Asegúrese de que las aplicaciones que reciben mensajes de estos flujos de mensajes pueden tolerar mensajes que no estén en orden.

Copias del flujo de mensajes en varios intermediarios
Puede desplegar varias copias del mismo flujo de mensajes a distintos intermediarios. Esta solución requiere cambios en la configuración, porque debe asegurar que las aplicaciones que proporcionan mensajes al flujo de mensajes puedan colocar los mensajes en el puerto o la cola de entrada correcta. A menudo puede efectuar estos cambios cuando despliega el flujo de mensajes estableciendo las propiedades configurables del flujo de mensajes.
El ámbito del flujo de mensajes
Puede encontrarse con que, bajo ciertas circunstancias, puede dividir un solo flujo de mensajes en varios flujos de mensajes para reducir el ámbito de trabajo que realiza cada flujo de mensajes. Si lo hace, tenga presente que no es posible ejecutar los distintos flujos de mensajes en la misma unidad de trabajo, y que si hay aspectos transaccionales en el flujo de mensajes (por ejemplo, la actualización de varias bases de datos), esta opción no proporciona una solución adecuada.

Los dos ejemplos siguientes muestran cuándo puede ser conveniente dividir un flujo de mensajes:

  1. En un flujo de mensajes que utiliza RouteToLabel, la cola de entrada se ha convertido en un cuello de botella. Podría utilizar otra copia del flujo de mensajes en un segundo grupo de ejecución, pero esto no es apropiado si desea que todos los mensajes se gestionen en el orden en que aparecen en la cola. Puede pensar en dividir cada rama del flujo de mensajes que empieza con un nodo Label, proporcionando una cola de entrada y un nodo de entrada para cada rama. Esto puede ser adecuado porque cuando el nodo RouteToLabel dirige el mensaje al nodo Label relevante, tiene cierto nivel de independencia con respecto a todos los demás mensajes.

    Quizá también tenga que proporcionar otra cola de entrada y otro nodo de entrada para completar cualquier proceso común al que se conecte la rama Label una vez realizado el proceso exclusivo.

  2. Si tiene un flujo de mensajes que procesa mensajes de gran tamaño que tardan un tiempo considerable en procesarse, puede:
    1. Crear otras copias del flujo de mensajes que utilicen una cola de entrada distinta (puede establecer esto en el flujo de mensajes mismo o puede actualizar esta propiedad cuando despliegue el flujo de mensajes).
    2. Establecer alias de cola de WebSphere MQ para redirigir mensajes de algunas aplicaciones a la cola y flujo de mensajes alternativos.

    También puede crear un nuevo flujo de mensajes que reproduzca la función del flujo de mensajes original (pero sólo procese mensajes de gran tamaño que el flujo de mensajes original le pasa inmediatamente) que ha modificado para que compruebe el tamaño de los mensajes de entrada y redirija los mensajes grandes.

La frecuencia de las confirmaciones
Si un flujo de mensajes recibe mensajes de entrada en una cola de WebSphere MQ, puede mejorar el rendimiento para algunos escenarios de flujos de mensajes modificando las propiedades por omisión después de añadirlo a un archivo bar. (Estas opciones no están disponibles si los mensajes de entrada los reciben otros nodos de entrada; las confirmaciones en estos flujos de mensajes se realizan para cada mensaje.)

Las propiedades siguientes controlan la frecuencia con que el flujo de mensajes confirma las transacciones:

  • Cuenta de confirmaciones. Representa el número de mensajes procesados desde la cola de entrada antes de emitir un MQCMIT.
  • Intervalo de confirmación. Representa el intervalo de tiempo que transcurre antes de invocar un MQCMIT.
Conceptos relacionados
Visión general de flujos de mensajes
Visión general del despliegue
Tareas relacionadas
Optimizar los tiempos de respuesta de los flujos de mensajes
Crear un flujo de mensajes
Definir el contenido del flujo de mensajes
Edición de propiedades configurables
Referencia relacionada
Nodos incorporados
Propiedades configurables del flujo de mensajes
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac00350_