Optimización del rendimiento del flujo de mensajes

El modo de funcionamiento de sus servidores de integración puede afectar al número de flujos de mensajes que puede utilizar; consulte Características y restricciones de IBM App Connect Enterprise que se aplican en cada modo de funcionamiento para obtener más información.

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.

La interfaz de usuario web le permite ver datos estadísticos y de contabilidad de flujo de mensajes, incluyendo el rendimiento del flujo de mensajes y los tiempos de CPU y transcurrido para las transacciones del flujo. Consulte Visualización de estadísticas de flujo de mensajes y datos de contabilidad para obtener más información sobre cómo puede acceder a los datos estadísticos.

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 servidor de integración inicia automáticamente una instancia del flujo de mensajes para cada nodo de entrada que contiene. Este comportamiento es el valor predeterminado. Si tiene un flujo de mensajes que maneja un gran número de mensajes, puede habilitar más mensajes para que se procesen asignando más instancias del flujo.

Puede actualizar la propiedad Instancias adicionales del flujo de mensajes desplegado en el archivo BAR; el servidor de integración inicia copia adicionales del flujo de mensajes en hebras independientes, proporcionando el proceso paralelo. Esta opción es la forma más eficaz de manejar esta situación si no está preocupado por el orden en que se procesan los mensajes.

Si el flujo de mensajes recibe mensajes de una IBM MQ cola, puede influir en el orden en que se procesan los mensajes configurando la propiedad Modo de ordenación 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.
• Si establece la Modalidad de orden en Definida por el usuario, puede ordenar los mensajes por cualquier elemento de mensaje, estableciendo una expresión XPath o ESQL en la propiedad Ubicación del campo orden. El nodo asegura que los mensajes con el mismo valor en el elemento de mensaje de campo de orden se procesen en el orden garantizado. Una instancia del flujo de mensajes no procesa un segundo mensaje con el mismo valor en el elemento de mensaje de campo de orden si otra instancia del flujo de mensajes está procesando actualmente un mensaje anterior con el mismo valor.

  Si el campo falta, se genera una excepción y el mensaje se restituye.

• Si establece la Modalidad de orden en Por ID de usuario o Definida por el usuario, y el flujo de mensajes utiliza nodos de transformación, es aconsejable establecer la Temporización del análisis en Inmediato.

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 divide el flujo de mensajes, tenga presente que no es posible ejecutar los distintos flujos de mensajes en la misma unidad de trabajo y 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 beneficioso dividir un flujo de mensajes:

1. En un flujo de mensajes que utiliza un RouteToLabel nodo, la cola de entrada puede aumentar de tamaño, lo que indica que el trabajo llega más rápido de lo que se procesa; esto podría indicar la necesidad de una mayor capacidad de procesamiento. Puede utilizar otra copia del flujo de mensajes en un segundo servidor de integración, pero esta opción no es adecuada si desea que todos los mensajes se manejen en el orden en el que se muestran en la cola. Puede considerar la posibilidad de 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. Esta opción puede ser apropiada, porque cuando el mensaje es enrutado por el RouteToLabel nodo al relevante Etiqueta nodo, tiene cierto nivel de independencia de todos los demás mensajes.

   Es posible que 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 ramificaciones del nodo Etiqueta cuando se haya realizado un 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 esta opción en el flujo de mensajes mismo o puede actualizar esta propiedad cuando despliegue el flujo de mensajes).
   2. Configure alias de IBM MQ cola para redirigir los mensajes de algunas aplicaciones a la cola alternativa y al flujo de mensajes.

   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 comprobar el tamaño de los mensajes de entrada y redirigir los mensajes grandes.

La frecuencia de las confirmaciones

Si un flujo de mensajes recibe mensajes de entrada en una IBM MQ cola, puede mejorar su rendimiento en algunos escenarios de flujo de mensajes modificando sus propiedades predeterminadas después de haberlo añadido 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:

• commitCount. Esta propiedad representa el número de mensajes procesados desde la cola de entrada por hebra de flujo de mensajes, antes de emitir un MQCMIT.
• commitInterval. Esta propiedad representa el intervalo de tiempo que transcurre antes de iniciar un MQCMIT.