메시지 플로우 응답 시간 최적화

시작하기 전에

메시지 플로우 노드에 대한 개념 주제를 읽으십시오.

메시지 플로우를 설계할 때, 내장 노드의 유연성 및 다양성은 흔히 다양한 방법으로 처리를 완료하여 필요한 최종 결과를 얻을 수 있음을 의미합니다. 그러나 솔루션이 다르면 성능도 다르며, 성능이 중요한 고려사항인 경우 기능뿐 아니라 성능도 설계해야 합니다.

다음 두 가지 방법으로 응용프로그램에서 성능을 인식할 수 있습니다.

  1. 응답 시간. 메시지 플로우가 메시지를 처리하는 시간을 표시합니다. 이는 특히 메시지 플로우를 설계한 방법에 따라 영향을 받습니다. 응답 시간은 이 주제에서 자세히 논의됩니다.
  2. 처리량. 메시지 플로우가 주어진 시간에 처리할 수 있는 특정 크기의 메시지 수를 표시합니다. 이는 주로 구성 및 시스템 자원 요소의 영향을 받으므로 다른 도메인 구성 정보와 함께 메시지 플로우 처리량 최적화에 설명되어 있습니다.

메시지 플로우 응답 시간에 영향을 주는 여러 가지 측면이 있습니다. 그러나 특정 비즈니스 요구사항을 충족시키는 최적의 결과에 도달하기 위해 메시지 플로우 설계를 작성 및 수정하기 때문에, 메시지 플로우의 복잡도도 고려해야 합니다. 가장 효율적인 메시지 플로우가 반드시 가장 이해하고 유지보수하기가 쉬운 것은 아닙니다. 요구에 가장 부합할 수 있는 솔루션 대한 경험이 중요합니다.

다음과 같은 여러 요소가 메시지 플로우 응답 시간에 영향을 미칩니다.

메시지 플로우에 포함시키는 노드의 수
모든 노드에는 약간의 처리 오버헤드가 있으므로, 서브플로우 사용을 비롯하여 메시지 플로우의 컨텐츠를 주의깊게 고려해야 합니다.

메시지 플로우 내에 되도록 적은 수의 노드를 사용하십시오. 메시지 플로우에 포함된 모든 노드는 브로커에서 오버헤드를 증가시킵니다. 단일 플로우 내의 노드 수에 대해 상위 한계가 제공됩니다. 이 한계는 시스템 자원, 특히 스택 크기에 의해 관리됩니다.

스택 크기에 대한 자세한 정보는 메시지 플로우 개발을 위한 시스템 고려사항을 참조하십시오.

메시지 플로우가 메시지를 라우트하고 처리하는 방법
일부 경우, 내장 노드 및 시스템에서 사용 가능한 기타 노드가 둘 이상의 방법으로 동일한 기능을 제공한다는 것을 알 수 있습니다. 가장 간단한 구성을 선택하십시오. 예를 들면, 각 메시지의 필드 값을 기초로 일부 특정 처리를 정의할 경우, 각각의 경우를 핸들링할 일정 순서의 Filter 노드가 있는 메시지 플로우를 설계할 수 있습니다. 해당될 경우, Filter 노드를 통해 메시지를 그룹화하여 각 메시지 유형이 처리되기 전에 통과해야 하는 노드 수를 줄일 수 있습니다.

예를 들면, 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 샘플은 메시지 플로우의 메모리 내 캐시에 있는 데이터베이스 테이블에 라우팅 정보를 저장할 수 있는 방법을 설명합니다.

메시지 플로우가 루프를 포함하는 경우
노드를 반복하는 루프를 피하십시오. 루프는 매우 비효율적이며 성능 및 스택 문제점을 유발할 수 있습니다. Compute 노드를 여러 PROPAGATE문과 함께 사용하면 일련의 노드를 반복하는 루프를 피할 수도 있습니다.
ESQL 효율성
메시지 플로우 노드에 대해 작성한 모든 ESQL 코드를 점검하십시오. 노드 개발 및 테스트시 메시지 처리를 완성하는 데 필요하지 않은 명령문을 유지보수할 수 있습니다. 두 개의 명령문으로 코드화한 것을 하나로 코드화할 수 있음을 발견할 수도 있습니다. ESQL 코드가 단순함과 성능 향상을 제공할 수 있는지를 점검하고 검토하는 데 시간을 할애하십시오.

이전 릴리스에서 메시지 플로우를 들여온 경우 버전 5.0에서 사용 가능한 ESQL에서 ESQL문을 점검하여 새 함수 또는 명령문을 통해 효율성을 향상시킬 수 있는지 확인하십시오.

지속 및 트랜잭션 메시지 사용
지속 메시지는 메시지 플로우 처리 중에 디스크에 저장됩니다. 입력, 출력 또는 둘 모두에 있는 메시지가 비지속적이면 저장되지 않습니다. 메시지 플로우가 비지속 메시지만을 핸들링할 경우에는 노드의 구성 및 메시지 플로우 자체를 점검하십시오. 메시지가 비지속이면, 트랜잭션 지원이 필요하지 않을 수도 있습니다. 일부 노드의 디폴트 구성에서는 트랜잭션성을 실시합니다. 이 등록 정보를 갱신한 후 메시지 플로우를 다시 전개하면 응답 시간이 향상될 수 있습니다.
메시지 크기
메시지의 크기가 크면 처리 시간도 길어집니다. 긴 메시지를 작은 정보 청크로 분할할 수 있으면, 메시지 플로우가 메시지를 핸들링하는 속도를 개선할 수 있습니다. Large Messaging 샘플은 잠재적으로 큰 메시지 처리 시 메시지 플로우 성능을 개선시키기 위한 메시지 플로우의 가상 메모리 요구사항을 최소화하는 방법을 설명합니다.
메시지 형식
WebSphere Message Broker가 여러 메시지 형식을 지원하고 한 형식에서 다른 형식으로 변환할 때 사용할 수 있는 기능을 제공하지만 이 기능으로 인한 오버헤드가 발생합니다. 불필요한 변환을 수행하지 않도록 하십시오.

메시지 플로우 성능에 대한 developerWorks 기사에서 메시지 플로우 성능 개선에 대한 자세한 정보를 볼 수 있습니다.

관련 개념
메시지 플로우 개요
전개 개요
메시지 플로우 개발을 위한 시스템 고려사항
관련 태스크
브로커 도메인 구성
메시지 플로우 처리량 최적화
메시지 플로우 설계
둘 이상의 입력 노드 사용
메시지 플로우 작성
메시지 플로우 컨텐츠 정의
구성 가능 등록 정보 편집
관련 참조
내장 노드
주의사항 | 등록상표 | 다운로드 | 라이브러리 | 지원 | 피드백
Copyright IBM Corporation 1999, 2006 마지막 갱신 날짜: 2006/08/21
ac00355_