Optimización de la productividad de los flujos de mensajes

Cada flujo de mensajes que diseña debe ofrecer un conjunto de proceso completo para los mensajes que se reciben desde un origen determinado. Sin embargo, el resultado pueden ser flujos de mensajes muy complejos que incluyan numerosos nodos, lo que puede causar posibles atascos y una saturación del rendimiento. Al aumentar el número de flujos de mensajes que procesan los mensajes se posibilita el proceso paralelo y, por consiguiente, se mejora la productividad.

También debe tener en cuenta el procedimiento utilizado para confirmar las acciones que se llevan a cabo en el flujo de mensajes y el orden en el que se procesan los mensajes.

Para optimizar la productividad de los flujos de mensajes, tenga en cuenta las opciones siguientes:

Varias hebras de proceso de mensajes en un único flujo de mensajes
Cuando difunde un flujo de mensajes, el intermediario inicia automáticamente una instancia del flujo de mensajes para cada nodo de entrada que contiene. Éste es el funcionamiento por omisión. Sin embargo, si un flujo de mensajes maneja numerosos mensajes, el origen de entrada (por ejemplo, una cola WebSphere MQ) se puede convertir en un atasco.

Puede actualizar la propiedad Instancias adicionales del flujo de mensajes difundido en un archivo bar: el intermediario inicia copias adicionales del flujo de mensajes en hebras separadas, facilitando el proceso paralelo. Es el modo más eficaz para manejar esta situación, siempre que no importe el orden en el que se procesan los mensajes.

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

  • Si establece Modalidad de orden en Por ID de usuario, el nodo garantiza que los mensajes de un usuario específico (identificado por el campo UserIdentifier de MQMD) se procesen en el orden establecido. Una instancia del flujo de mensajes no procesa un segundo mensaje de un usuario si otra instancia del flujo de mensajes está procesando un mensaje anterior del mismo usuario.
  • Si establece Modalidad de orden en Por orden de cola, el nodo procesa un mensaje cada vez a fin de mantener el orden de lectura de los mensajes de la cola. Por consiguiente, este nodo se comporta como si se 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 para el que se ofrece soporte, los intermediarios publican los mensajes relacionados con cualquier tema especificado en el mismo orden que los reciben de los publicadores (reordenándolos en base a la prioridad de los mensajes, si procede). Generalmente, significa que cada suscriptor recibe mensajes de un intermediario determinado, sobre un tema específico, desde un publicador concreto, en el orden que los publica el publicador.

Sin embargo, en algunas ocasiones, es posible que se entreguen los mensajes sin seguir ningún orden. Puede suceder, por ejemplo, si un enlace de la red da error y otro enlace direcciona los mensajes siguientes.

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

Para obtener más información sobre las técnicas que se recomiendan para todos los usuarios MQI y AMI, consulte la publicación WebSphere MQ Application Programming Guide para los programas escritos para MQI y la publicación WebSphere MQ Application Messaging Interface para los programas escritos para AMI.

Las aplicaciones WebSphere MQ Everyplace y SCADA utilizan un método de ordenamiento de mensajes diferente, tal como se describe en los apartados WebSphere MQ Mobile Transport y WebSphere MQ Telemetry Transport, respectivamente. El intermediario no proporciona ningún método de ordenamiento para los mensajes que se reciben 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
También puede difundir varias copias del mismo flujo de mensajes a grupos de ejecución diferentes del mismo intermediario. Ofrece efectos similares al aumento del número de hebras de proceso en un único flujo de mensajes aunque, por lo general, sus ventajas suelen ser menos perceptibles.

Esta opción también elimina la posibilidad de determinar el orden en el que se procesan los mensajes, puesto que si existe más de una copia del flujo de mensajes activa en el intermediario, cada copia puede procesar un mensaje al mismo tiempo, de la misma cola. El tiempo que se tarda en procesar un mensaje puede variar y, por consiguiente, varios flujos de mensajes pueden acceder a la misma cola y leer mensajes del origen de entrada siguiendo un orden aleatorio. El orden de los mensajes que proceden los flujos de mensajes puede no corresponder al orden de los mensajes originales.

Asegúrese de que las aplicaciones que reciben mensajes de los flujos de mensajes puedan tolerar mensajes sin ordenar.

Copias del flujo de mensajes en varios intermediarios
Puede difundir varias copias del mismo flujo de mensajes a intermediarios diferentes. Esta solución cambia la configuración, puesto que debe asegurarse de que las aplicaciones que suministran mensajes al flujo de mensajes pueden transferir los mensajes a la puerta o cola de entrada correcta. Puede realizar estos cambios con frecuencia al difundir el flujo de mensajes estableciendo las propiedades configurables del flujo de mensajes.
Ámbito del flujo de mensajes
En algunas ocasiones es posible que considere que puede dividir un solo flujo de mensajes en varios flujos diferentes a fin de reducir el ámbito de trabajo que realiza cada flujo de mensajes. Si lo hace, tenga en cuenta que no se pueden ejecutar flujos de mensajes diferentes en la misma unidad de trabajo y, si existen aspectos transaccionales en relación con el flujo de trabajo (por ejemplo, la actualización de varias bases de datos), esta opción no ofrece una solución adecuada.

En los dos ejemplos siguientes se muestra cuándo es posible que desee dividir un flujo de mensajes:

  1. En un flujo de mensajes que utiliza RouteToLabel, se ha producido un atasco en la cola de entrada. Puede utilizar otra copia del flujo de mensajes en un segundo grupo de ejecución, pero no resulta adecuado si desea que todos los mensajes se manejen en el orden que aparecen en la cola. Puede considerar la posibilidad de dividir cada rama del flujo de mensajes que empiece con un nodo Label proporcionando una cola de entrada y un nodo de entrada para cada rama. Puede ser lo adecuado, puesto que cuando el nodo RouteToLabel direcciona el mensaje al nodo Label pertinente, tiene cierto nivel de independencia con respecto a todos los demás mensajes.

    Es posible que también necesite proporcionar otra cola de entrada y otro nodo de entrada para completar cualquier proceso común al que se conectan las ramas Label cuando se realizan procesos exclusivos.

  2. Si tiene un flujo de mensajes que procesa mensajes muy grandes que requieren mucho tiempo de proceso, es posible que pueda:
    1. Crear otras copias del flujo de mensajes que utilicen una cola de entrada diferente (puede establecerlo en el mismo flujo de mensajes o puede actualizar esta propiedad al difundir el flujo de mensajes).
    2. Establecer alias de colas WebSphere MQ para redireccionar mensajes de algunas aplicaciones a la cola y el flujo de mensajes alternativos.

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

Frecuencia de las confirmaciones
Si un flujo de mensajes recibe mensajes de entrada en una cola WebSphere MQ, puede mejorar su productividad para determinados escenarios de flujos de mensajes al modificar sus propiedades por omisión después de añadirla a un archivo bar. (Estas opciones no están disponibles si otros nodos de entrada reciben los mensajes de entrada; las confirmaciones de estos flujos de mensajes se realizan para cada mensaje).

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

  • Cuenta de confirmaciones. Representa el número de mensajes procesados de 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
Flujos de mensajes
Difusión de aplicaciones de flujos de mensajes

Tareas relacionadas
Optimización de los tiempos de respuesta de los flujos de mensajes
Creación de un flujo de mensajes
Definición del contenido del flujo de mensajes
Edición de propiedades configurables

Referencia relacionada
Nodos incorporados
Propiedades de flujos de mensajes configurables

página Web de la biblioteca de WebSphere MQ