메시지 플로우 노드에 대한 개념 주제를 읽으십시오.
메시지 플로우를 설계할 때, 내장 노드의 유연성 및 다양성은 흔히 다양한 방법으로 처리를 완료하여 필요한 최종 결과를 얻을 수 있음을 의미합니다. 그러나 솔루션이 다르면 성능도 다르며, 성능이 중요한 고려사항인 경우 기능뿐 아니라 성능도 설계해야 합니다.
다음 두 가지 방법으로 응용프로그램에서 성능을 인식할 수 있습니다.
메시지 플로우 응답 시간에 영향을 주는 여러 가지 측면이 있습니다. 그러나 특정 비즈니스 요구사항을 충족시키는 최적의 결과에 도달하기 위해 메시지 플로우 설계를 작성 및 수정하기 때문에, 메시지 플로우의 복잡도도 고려해야 합니다. 가장 효율적인 메시지 플로우가 반드시 가장 이해하고 유지보수하기가 쉬운 것은 아닙니다. 요구에 가장 부합할 수 있는 솔루션 대한 경험이 중요합니다.
다음과 같은 여러 요소가 메시지 플로우 응답 시간에 영향을 미칩니다.
메시지 플로우 내에 되도록 적은 수의 노드를 사용하십시오. 메시지 플로우에 포함된 모든 노드는 브로커에서 오버헤드를 증가시킵니다. 단일 플로우 내의 노드 수에 대해 상위 한계가 제공됩니다. 이 한계는 시스템 자원, 특히 스택 크기에 의해 관리됩니다.
스택 크기에 대한 자세한 정보는 메시지 플로우 개발을 위한 시스템 고려사항을 참조하십시오.
예를 들면, 8개의 다른 메시지(송장, 작업 지정 메모 등)를 핸들링해야 하는 메시지 플로우가 있을 수 있습니다. Filter 노드를 포함시켜 각 유형의 메시지를 식별한 다음 해당 유형에 따라 이를 라우트할 수 있습니다. 가장 앞에 있는 Filter 노드에서 가장 많은 메시지 유형을 테스트함으로써 이 기술의 성능을 최적화할 수 있습니다. 그러나 여덟 번째 메시지 유형은 항상 8개의 Filter 노드를 거쳐야 합니다.
메시지 유형을 그룹화할 수 있으면(예를 들면, 메시지 유형이 숫자일 경우, 4를 초과하는 또는 4 미만인 모든 유형을 테스트함) 필요한 Filter 노드의 수를 줄일 수 있습니다. 첫 번째 필터 노드는 테스트 결과 4를 초과하므로 두 개의 추가 Filter 노드(true 및 false 터미널에 접속되어 있으며 각각 2 미만인지와 6 미만인지를 테스트함)로 메시지를 전달합니다. 그런 다음 네 개의 추가 Filter 노드에서 1, 2, 3 또는 4인지를 테스트할 수 있습니다. 실제 필요한 Filter 노드 수는 동일하지만 각 메시지가 통과하는 노드의 수는 감소됩니다.
Label 노드 세트와 함께 RouteToLabel 노드를 사용하면 일정 순서의 Filter 노드에 비해 보다 나은 대안을 제공한다는 것을 알 수 있습니다. 각 메시지는 보다 적은 수의 노드를 통과하므로 처리량이 향상됩니다. 그러나, RouteToLabel 노드의 사용은 Compute 노드의 사용을 의미한다는 점도 고려해야 합니다. Compute 노드의 오버헤드가 노드 사용 시의 이점보다 클 수 있습니다. 제한된 수의 메시지 유형을 다룰 경우, 적은 수의 Filter 노드를 사용하는 것이 더 효율적일 수 있습니다.
Airline Reservations 샘플은 XML_PassengerQuery 메시지 플로우의 여러 Filter 노드를 사용하는 대신 RouteToLabel 및 Label 노드를 사용할 수 있는 방법을 설명합니다. Message Routing 샘플은 메시지 플로우의 메모리 내 캐시에 있는 데이터베이스 테이블에 라우팅 정보를 저장할 수 있는 방법을 설명합니다.
이전 릴리스에서 메시지 플로우를 들여온 경우 버전 5.0에서 사용 가능한 ESQL에서 ESQL문을 점검하여 새 함수 또는 명령문을 통해 효율성을 향상시킬 수 있는지 확인하십시오.
메시지 플로우 성능에 대한 developerWorks 기사에서 메시지 플로우 성능 개선에 대한 자세한 정보를 볼 수 있습니다.