설계한 각 메시지 플로우는 특정 소스에서 수신한 메시지에 대한 완전한 처리 세트를 제공해야 합니다. 그러나 이는 수많은 노드를 포함하는 매우 복잡한 메시지 플로우를 생성하여 성능 오버헤드 및 잠재적 병목 현상을 유발할 수 있습니다. 메시지를 처리하는 메시지의 플로우의 수가 증가하면 병렬 처리 기회가 제공되므로 처리량이 증가됩니다.
또한 메시지 플로우에서 취하는 조치를 확약하는 방법 및 메시지가 처리되는 순서를 고려할 수 있습니다.
최적 메시지 플로우 처리량에 대한 다음 옵션을 고려하십시오.
Bar 파일에서 전개된 메시지 플로우의 추가 인스턴스 등록 정보를 갱신할 수 있습니다. 브로커는 별도의 스레드에서 병렬 처리를 제공하는 메시지 플로우의 추가 사본을 시작합니다. 메시지 처리 순서가 중요하지 않은 경우, 이 방법이 병목 현상을 핸들링하는 가장 효율적인 방법입니다.
메시지 플로우가 WebSphere MQ 큐에서 메시지를 수신하는 경우, MQInput 노드의 순서 모드 등록 정보를 설정하여 어느 정도까지 메시지 처리 순서를 지정할 수 있습니다.
지원되는 모든 프로토콜을 통해 브로커와 통신하는 Publish/Subscribe 응용프로그램의 경우, 지정된 토픽의 메시지는 publisher에서 수신한 것(적용되는 경우, 메시지 우선순위를 기초로 재정렬)과 동일한 순서대로 브로커에서 publish됩니다. 이는 일반적으로 각 subscriber가 특정 토픽에 대해 특정 publisher로부터 publisher가 publish한 순서대로 특정 브로커로부터 메시지를 수신한다는 의미입니다.
그러나 간혹 메시지가 순서를 따르지 않고 전달될 수도 있습니다. 예를 들어, 네트워크의 링크가 실패하거나 후속 메시지가 다른 링크를 통해 라우트되는 경우에 발생할 수 있습니다.
메시지가 수신되는 순서를 확인해야 할 경우, publish된 각 메시지에 대해 Publish 명령의 SeqNum(순서 번호) 또는 PubTime(publish 시간 소인) 매개변수를 사용하여 publish 순서를 계산할 수 있습니다.
모든 MQI 및 AMI 사용자에게 권장되는 자세한 기술 정보는 MQI로 작성된 프로그램의 경우 WebSphere MQ Application Programming Guide를, AMI로 작성된 프로그램의 경우에는 WebSphere MQApplication Messaging Interface(WebSphere MQ SupportPacs 웹 페이지)를 참조하십시오.
WebSphere MQ Everyplace 및 SCADA 응용프로그램은 각각 WebSphere MQ Mobile Transport 및 WebSphere MQ Telemetry Transport에서 설명하는 것처럼 다른 방법으로 메시지 순서를 정렬합니다. 브로커는 WebSphere MQ Real-time Transport 또는 WebSphere MQ Multicast Transport를 통해 수신된 메시지에 대한 메시지 순서 정렬을 제공하지 않습니다.
또한 이 옵션은 메시지가 처리되는 순서를 판별하는 기능을 제거합니다. 그 이유는 브로커에 둘 이상의 메시지 플로우 사본이 있는 경우, 동일 큐에서 각 사본이 메시지를 동시에 처리할 수 있기 때문입니다. 메시지를 처리하는 데 소요되는 시간은 차이가 있을 수 있으며 그에 따라 동일 큐에 액세스하는 다중 메시지 플로우는 임의 순서대로 입력 소스에서 메시지를 읽을 수 있습니다. 메시지 플로우로 형성된 메시지 순서는 원래 메시지의 순서와 일치하지 않을 수 있습니다.
이러한 메시지 플로우에서 메시지를 수신하는 응용프로그램이 순서대로 정렬되지 않은 메시지를 허용하는지 확인하십시오.