BizTalk Server 계층의 병목 상태
BizTalk 계층은 다음과 같은 기능 영역으로 나눌 수 있습니다.
수신
처리
전송
추적
기타
이러한 영역의 경우 시스템 리소스(CPU, 메모리 및 디스크)가 포화 상태인 것처럼 보이면 애플리케이션의 특성에 따라 플랫폼을 확장하거나 확장하여 서버를 업그레이드합니다. 시스템 리소스가 포화 상태가 아닌 경우에는 이 섹션에 설명된 단계를 수행하십시오.
수신 위치의 병목 현상
메시지가 수신 위치에서 빌드되는 경우(예: 파일 수신 폴더가 커짐) 시스템이 들어오는 로드를 따라잡을 만큼 빠르게 데이터를 흡수할 수 없음을 나타냅니다. 이는 내부 제한 때문입니다. 즉, BizTalk Server 구독자가 데이터를 빠르게 처리할 수 없어 데이터베이스 테이블에서 백로그가 빌드되는 경우 수신 속도를 줄입니다. 하드웨어 제한으로 인해 병목 현상이 발생하는 경우 스케일 업해 보세요. 스케일 업에 대한 자세한 내용은 BizTalk Server 2010 설명서의 다음 topics 참조하세요.
BizTalk Server 계층 확장(https://go.microsoft.com/fwlink/?LinkId=158073).
SQL Server 계층 확장(https://go.microsoft.com/fwlink/?LinkId=158077).
수신 처리기에 매핑된 호스트에 호스트 instance(서버)를 추가하여 스케일 아웃할 수도 있습니다. 스케일 아웃에 대한 자세한 내용은 BizTalk Server 2010 설명서의 다음 topics 참조하세요.
BizTalk Server 계층(https://go.microsoft.com/fwlink/?LinkId=158076)을 확장합니다.
SQL Server 계층 확장(https://go.microsoft.com/fwlink/?LinkId=158075).
Perfmon을 사용하여 시스템의 리소스 사용을 모니터링합니다. 외부 수신 위치가 병목 상태의 원인이 아님을 확인하는 것이 중요합니다. 예를 들어 높은 디스크 I/O로 인해 원격 파일 공유가 포화 상태인지, 원격 나가는 큐를 호스트하는 서버가 포화 상태가 아닌지 또는 HTTP 로드를 생성하는 데 사용되는 클라이언트가 스레드에서 부족하지 않은지 확인합니다.
병목 상태 처리
호스트 큐 – 길이 성능 카운터가 상승하는 경우 오케스트레이션이 충분히 빠르게 완료되지 않음을 나타냅니다. 자세한 내용은 이 항목의 Perfmon 카운터 테이블을 참조하세요. 이 현상은 메모리 경쟁이나 CPU 포화로 인해 발생할 수 있습니다.
오케스트레이션 서버가 병목 상태인 경우 Perfmon을 사용하여 출처를 확인합니다.
서버가 CPU 제약을 더 많이 받는 상태인 경우 다음을 고려하십시오.
워크플로가 복잡한 경우 오케스트레이션을 여러 작은 오케스트레이션으로 분할하는 것이 좋습니다.
참고
오케스트레이션을 여러 개의 워크플로로 분할하면 대기 시간이 늘어나고 복잡성이 증가할 수 있습니다. 여러 워크플로로 인해 BizTalkMsgBoxDb에 게시되고 사용된 메시지 수가 증가하여 데이터베이스에 추가적인 부담이 가중될 수 있습니다.
복잡한 맵을 사용하는 경우 수신/보내기 포트로 이동할 수 있는지 여부를 고려합니다. 추가 대역폭이 있는 포트를 확인해야 합니다.
추가 처리 서버를 구성하여 하드웨어를 확장하거나 스케일 아웃하는 것이 좋습니다.
병목 상태 전송
송신 어댑터를 호스트하는 서버가 리소스(예: 디스크, 메모리 또는 CPU)에 포화 상태인 경우 서버를 확장하거나 추가 송신 호스트 서버로 스케일 아웃하는 것이 좋습니다. 대상(BizTalk 외부)이 충분히 빠르게 데이터를 수신할 수 없는 경우 송신 계층이 병목 상태가 될 수 있습니다. 이렇게 되면 MessageBox 데이터베이스에 메시지가 쌓이게 됩니다(Application SendHostQ).
모든 엔드포인트가 토폴로지의 scope 내에 있는 경우 대상에서 원인을 격리합니다. 예를 들어 HTTP 위치가 부하를 수신하도록 최적으로 구성되어 있는지 확인합니다. 그렇지 않은 경우 스케일 아웃을 고려합니다. 또한 BizTalk에서 전달된 과도한 출력 메시지로 인해 대상이 증가하는지 확인합니다. 그렇다면 대상 메시지를 보관하고 제거하려면 유지 관리 계획이 필요할 수 있습니다. 대상 폴더에 많은 수의 파일이 있는 경우 BizTalk 서비스가 디스크 드라이브에 데이터를 커밋하는 기능에 심각한 영향을 미칠 수 있습니다.
병목 상태 추적
추적 호스트 instance MESSAGEBox 데이터베이스(TrackingData 테이블)에서 BizTalk 추적 및/또는 BAM 기본 가져오기 데이터베이스 테이블로 BAM(비즈니스 활동 모니터링) 및 HAT(상태 및 활동 추적) 데이터를 이동하는 작업을 담당합니다. 여러 MessageBox 데이터베이스가 구성된 경우 추적 호스트 instance MessageBox 데이터베이스당 4개의 스레드를 사용합니다.
추적 호스트 instance CPU 바인딩된 것일 수 있습니다. 이 경우 호스트 추적을 사용하도록 설정된 추가 서버를 구성하여 서버를 스케일 업하거나 스케일 아웃하는 것이 좋습니다. 여러 호스트 인스턴스는 구성된 여러 MessageBox 데이터베이스에 대해 자동으로 부하를 분산합니다. 크기 조정에 대한 자세한 내용은 솔루션 크기 조정 (https://go.microsoft.com/fwlink/?LinkId=158078) 항목을 참조하세요.
MessageBox 데이터베이스의 TrackingData 테이블이 커지면 일반적으로 BizTalk 추적 및/또는 BAM 기본 가져오기 데이터베이스의 데이터 유지 관리 작업이 구성된 대로 실행되지 않아 BizTalk 추적 및/또는 BAM 기본 가져오기 데이터베이스가 증가하기 때문입니다. 이러한 데이터베이스가 너무 커지면 추적 호스트가 TrackingData 테이블에 데이터를 삽입하는 기능에 부정적인 영향을 미칠 수 있습니다. 이렇게 하면 추적된 데이터가 MessageBox 데이터베이스 테이블에 백업됩니다. TrackingData 테이블의 증가로 인해 제한이 시작됩니다.
기록된 데이터의 양을 줄이고 병목 상태를 추적할 위험을 낮추기 때문에 애플리케이션에 필요한 최소 추적만 사용하도록 설정해야 합니다. 오케스트레이션 및 송신/수신 포트와 같은 개별 항목에 대한 추적 설정을 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 추적을 사용하지 않도록 설정하는 방법 (https://go.microsoft.com/fwlink/?LinkId=160064)을 참조하세요.
기타
서로 다른 기능은 각각 격리된 전용 호스트 인스턴스에서 실행되도록 배포 토폴로지를 구성하십시오. 이렇게 하면 각 호스트 instance 자체 리소스 집합(예: 32비트 시스템, 2GB 가상 메모리 주소 공간, 핸들, 스레드)을 가져옵니다. 서버에 여러 호스트 인스턴스를 호스트하기에 충분한 CPU 헤드룸 및 메모리가 있는 경우 동일한 물리적 컴퓨터에서 실행되도록 구성할 수 있습니다. 그렇지 않은 경우 기능을 전용 서버로 이동하여 스케일 아웃하는 것이 좋습니다. 여러 서버에서 동일한 기능을 실행하면 고가용성 구성도 구현할 수 있습니다.
BizTalk 시스템 성능 카운터
| Object | 인스턴스 | 카운터 | 모니터링 목적 |
|---|---|---|---|
| 프로세서 | _Total | % Processor Time | 리소스 경쟁 |
| 프로세스 | BTSNTSvc | 가상 바이트 | 메모리 누수/팽창 |
| 프로세스 | BTSNTSvc | 프라이빗 바이트 | 메모리 누수/팽창 |
| 프로세스 | BTSNTSvc | 핸들 개수 | 리소스 경쟁 |
| 프로세스 | BTSNTSvc | 스레드 개수 | 리소스 경쟁 |
| 물리적 디스크 | _인스턴스 | % 유휴 시간 | 리소스 경쟁 |
| 물리적 디스크 | _인스턴스 | Average Disk Queue Length | 리소스 경쟁 |
CPU 경합
프로세서가 포화된 경우 송신 및 오케스트레이션에서 수신을 분리하여 애플리케이션을 조각화할 수 있습니다. 이렇게 하려면 별도의 호스트를 만들고, 호스트를 특정 기능(수신/보내기/오케스트레이션/추적)에 매핑하고, 이러한 개별 호스트에 전용 서버를 추가합니다. 오케스트레이션 기능은 CPU를 많이 사용하는 경우가 많습니다. 오케스트레이션이 별도의 전용 서버에서 실행되도록 시스템을 구성하는 경우 전체 시스템 처리량을 개선하는 데 도움이 될 수 있습니다.
여러 오케스트레이션이 배포된 경우 다른 전용 오케스트레이션 호스트에 등록할 수 있습니다. 다른 물리적 서버를 전용 오케스트레이션 호스트에 매핑하면 서로 다른 오케스트레이션이 격리되고 동일한 물리적 주소 공간이나 동일한 서버에서 공유 리소스에 대해 경합하지 않습니다.
사용되지 않는 호스트 인스턴스를 중지합니다. 사용하지 않는 호스트 인스턴스는 메시지 처리를 위해 MessageBox를 정기적으로 확인하여 CPU 및 메모리 리소스에 대해 경쟁할 수 있습니다. 또한 사용되지 않는 수신 위치, 송신 포트 및 오케스트레이션을 중지합니다.
스풀 테이블 증가
다운스트림 병목 상태 및/또는 리소스 경합으로 인해 스풀이 과도하게 증가하기 시작하고 전반적인 성능이 저하될 수 있습니다. 자세한 내용은 MessageBox Database1에서 병목 상태를 식별하는 방법의 "스풀 테이블 증가"를 참조하세요.
메모리 부족
처리량이 많은 시나리오에서는 시스템 메모리에 대한 요구가 증가할 수 있습니다. 32비트 프로세스는 사용할 수 있는 메모리 양에 의해 제한되므로 각 호스트가 자체 2GB 주소 공간을 수신하도록 수신/프로세스/보내기 기능을 별도의 호스트 인스턴스로 분리하는 것이 좋습니다. 또한 여러 호스트 인스턴스가 동일한 물리적 서버에서 실행되는 경우 실제 메모리에서 디스크로 데이터를 교환하지 않도록 4/8GB 메모리로 업그레이드할 수 있습니다. 장기 실행 오케스트레이션은 할당된 메모리를 더 오래 유지할 수 있습니다. 이로 인해 메모리가 부풀어 오르고 제한이 시작될 수 있습니다. 메시지가 크면 메모리 사용량이 많을 수도 있습니다.
특정 호스트에 대한 CPU 값당 내부 메시지 큐 크기 및 In-process 메시지를 낮추어 큰 메시지가 처리될 때 발생하는 메모리 bloat 문제를 완화할 수 있습니다.
참고
대기 시간이 중요한 경우 시스템의 종단 간 대기 시간이 증가할 수 있으므로 CPU당 내부 메시지 큐 크기 및 In-process 메시지를 변경해야 합니다.
디스크 경합
디스크가 포화 상태인 경우(예: 많은 수의 FILE/MSMQ 전송) 여러 스핀들로 업그레이드하고 RAID 10으로 디스크를 스트라이프하는 것이 좋습니다. 또한 FILE 전송을 사용할 때마다 수신 및 송신 폴더가 50,000개 파일보다 크지 않도록 하는 것이 중요합니다.
수신 폴더는 BizTalk Server 들어오는 데이터를 시스템으로 제한하는 경우 커질 수 있습니다. 이 폴더의 증가가 추가 데이터를 작성하는 BizTalk Server 기능에 영향을 주지 않도록 보내기 폴더에서 데이터를 이동하는 것이 중요합니다. 트랜잭션이 아닌 MSMQ 큐의 경우 BizTalk Server 디스크 경합이 줄어들도록 수신 큐를 원격으로 만드는 것이 좋습니다.
또한 원격 비 트랜잭션 큐 구성은 큐를 호스트하는 원격 서버를 클러스터할 수 있으므로 고가용성을 제공합니다.
기타 시스템 리소스 경합
전송 유형에 따라 HTTP용 IIS와 같은 시스템 리소스(예: MaxIOThreads, MaxWorkerThreads)를 구성해야 할 수 있습니다.
ASP.NET 2.0 및 ASP.Net 4 <를 사용하면 machine.config 파일의 processModel autoConfig="true"> 설정이 최적의 성능을 위해 다음 설정을 자동으로 구성합니다.
최대 작업자 스레드
최대 IO 스레드
httpRuntime 요소의 minFreeThreads 특성
httpRuntime 요소의 minLocalRequestFreeThreads 특성
connectionManagement> 요소(<네트워크 설정) 요소의 maxConnection 특성
어댑터 성능에 영향을 주는 매개 변수를 구성하는 방법에 대한 자세한 내용은 processModel 요소(https://go.microsoft.com/fwlink/?LinkId=158080)에 대한 ASP.NET 구성 설정을 참조하세요.
BizTalk Server 어댑터에 영향을 줄 수 있는 구성 설정에 대한 자세한 내용은 어댑터 성능에 영향을 주는 구성 매개 변수(https://go.microsoft.com/fwlink/?LinkID=154200)를 참조하세요.
BizTalk Server 애플리케이션을 최적화하는 것 외에도 동일한 서버에서 실행되는 다른 ASP.NET 애플리케이션은 전반적인 성능에 영향을 줄 수 있습니다. 모든 ASP.NET 애플리케이션을 최적화하여 시스템 리소스에 대한 수요를 줄이는 것이 중요합니다. 자세한 내용은 ASP.NET 성능 (https://go.microsoft.com/fwlink/?LinkId=158081)을 참조하세요.
최대 성능을 위해 구성할 때 전체 BizTalk 솔루션의 일부인 메시징 엔진(메시지 큐, MQSeries), 애플리케이션, 데이터베이스, Active Directory 등과 같은 다른 외부 시스템을 최적화하는 것이 좋습니다. 이러한 다른 외부 시스템의 성능 병목 현상은 BizTalk 솔루션에 부정적인 영향을 미칠 수 있습니다.
다운스트림 병목 현상
다운스트림 시스템이 BizTalk에서 데이터를 충분히 빠르게 수신할 수 없는 경우 이 출력 데이터는 BizTalk 데이터베이스에 백업됩니다. 이로 인해 bloat이 발생하고, 제한이 시작되고, 수신 파이프가 축소되고, BizTalk 시스템의 전체 처리량에 영향을 줍니다. 이에 대한 직접적인 표시는 스풀 테이블 증가입니다. 병목 상태 및 스풀 테이블에 대한 자세한 내용은 MessageBox Database1에서 병목 상태를 식별하는 방법을 참조하세요.
제한 영향
제한은 결국 시스템이 복구할 수 없는 상태에 도달하지 못하도록 보호하기 시작합니다. 따라서 제한을 사용하여 시스템이 정상적으로 작동하는지 확인하고 문제의 원인을 검색할 수 있습니다. 제한 상태에서 병목 현상의 원인을 식별한 후 다른 성능 카운터를 분석하여 문제의 원인을 확인합니다. 예를 들어 MessageBox 데이터베이스에서 높은 경합은 메모리 부족 조건으로 인해 디스크에 과도하게 페이징하여 발생하는 높은 CPU 사용 때문일 수 있습니다. MessageBox 데이터베이스에서 높은 경합은 포화 디스크 드라이브로 인해 높은 잠금 경합으로 인해 발생할 수도 있습니다. 가끔 제한은 성능에 큰 위협이 되지 않지만 영구 제한은 더 중요한 기본 문제를 나타낼 수 있습니다. BizTalk Server 제한을 사용하는 조건에 대한 자세한 내용은 BizTalk Server 호스트 제한을 구현하는 방법(https://go.microsoft.com/fwlink/?LinkID=155286)을 참조하세요.
BizTalk Server 제한이 사용 가능한 리소스의 사용을 관리하고 리소스 경합을 최소화하는 방법에 대한 자세한 내용은 호스트 제한을 통해 리소스 사용 최적화(https://go.microsoft.com/fwlink/?LinkID=155770)를 참조하세요.
BizTalk 애플리케이션 카운터
| Object | 인스턴스 | 카운터 | Description |
|---|---|---|---|
| BizTalk 메시징 | RxHost | Documents Received/Sec | 들어오는 속도 |
| BizTalk 메시징 | TxHost | Documents Processed/Sec | 나가는 속도 |
| XLANG/s 오케스트레이션 | PxHost | Orchestrations Completed/Sec. | 처리 속도 |
| BizTalk: MessageBox: 일반 카운터 | MsgBoxName | Spool Size | 모든 호스트 큐의 누적 크기 |
| BizTalk: MessageBox: 일반 카운터 | MsgBoxName | Tracking Data Size | MessageBox의 TrackingData 테이블 크기 |
| BizTalk:MessageBox:호스트 카운터 | PxHost:MsgBoxName | 호스트 큐 - 길이 | 특정 호스트 큐의 메시지 수 |
| BizTalk:MessageBox:호스트 카운터 | TxHost:MsgBoxName | 호스트 큐 - 길이 | 특정 호스트 큐의 메시지 수 |
| BizTalk:Message Agent | RxHost | 데이터베이스 크기 | 게시(PxHost) 큐의 크기 |
| BizTalk:Message Agent | PxHost | 데이터베이스 크기 | 게시(TxHost) 큐의 크기 |
| BizTalk:Message Agent | HostName | Message Delivery Throttling State | XLANG 및 아웃바운드 전송에 영향을 미칩니다. |
| BizTalk:Message Agent | HostName | Message Publishing Throttling State | XLANG 및 인바운드 전송에 영향을 미칩니다. |
시작 단계
각 호스트 instance 대한 메시지 배달 제한 상태 및 메시지 게시 제한 상태를 모니터링하는 것이 좋습니다. 이러한 카운터의 값이 0이 아니면 BizTalk 시스템의 제한을 나타내며 병목 현상의 원인을 추가로 분석할 수 있습니다. 다른 성능 카운터에 대한 설명은 데이터베이스 계층의 병목 상태를 참조하세요.
오케스트레이션 엔진 성능 카운터
지속적인 오케스트레이션 탈수\리하이드레이션 및 지속성 지점이 전체 성능에 심각한 영향을 미칠 수 있으므로 오케스트레이션 런타임 설정을 미세 조정하는 것이 좋습니다. 여러 지속성 지점 및 트랜잭션 범위를 포함할 수 있는 복잡한 오케스트레이션을 테스트할 때 다음 카운터를 사용해야 합니다.
| 카운터 | 의견 |
|---|---|
| Orchestrations dehydrated/sec(디하이드레이션된 오케스트레이션 수/초) | 초당 디하이드레이션된 평균 수입니다. |
| Orchestrations rehydrated/sec(리하이드레이션된 오케스트레이션 수/초) | 초당 리하이드레이션된 평균 수입니다. |
| Persistence points/sec | 초당 지속된 오케스트레이션 인스턴스의 평균 수입니다. |
| Orchestrations resident in memory | 호스트 인스턴스에서 현재 호스팅 중인 오케스트레이션 인스턴스 수입니다. |
| Orchestrations completed/sec(완료된 오케스트레이션 수/초) | 초당 완료된 평균 수입니다. |
| Orchestrations suspended/sec(일시 중단된 오케스트레이션 수/초) | 초당 일시 중단된 평균 수입니다. |
| Transactional scopes committed/sec | 초당 커밋된 평균 수입니다. |
| Transactional scopes aborted/sec | 초당 중단된 평균 수입니다. |
| Transactional scopes compensated/sec | 초당 보정된 평균 수입니다. |
백로그 빌드
1-1 배포 시나리오에서 1 메시지가 처리되고 전송된 1 메시지의 결과를 수신하는 경우 나가는 속도가 들어오는 속도와 같지 않으면 시스템에 백로그가 있습니다. 이 경우 스풀 크기를 모니터링할 수 있습니다. 나가는 속도에서 병목 현상의 원인을 확인할 때 한 번에 단일 사용 사례 시나리오를 실행합니다. 오케스트레이션을 격리하고, 위치를 수신하고, 위치를 별도의 호스트로 보냅니다.
성능 모니터 로그에 BizTalk:Message Box:Host 카운터를 추가하여 호스트를 모니터링합니다. 호스트 큐 - 길이: 카운터는 특정 호스트 큐의 총 메시지 수를 추적합니다. 이러한 카운터 중 하나 이상이 시간이 지남에 따라 계속 증가하는 경우 해당 호스트에서 실행되는 아티팩트에서 특히 주의해야 합니다.
스풀이 선형적으로 증가하는 경우 스풀 증가를 담당하는 애플리케이션 큐를 결정합니다.
애플리케이션 큐가 증가하지 않으며 스풀이 계속 증가하는 경우 제거 작업을 계속할 수 없음을 의미할 수 있습니다. 에이전트가 실행되고 있지 않거나 SQL Server 다른 시스템 리소스 경합이 있는 경우에 발생합니다.
애플리케이션 큐 중 하나가 증가하는 경우 이 증가의 원인을 진단합니다. 특정 애플리케이션 큐를 드레이닝할 수 없는 시스템의 시스템 리소스를 모니터링합니다(예: 서버의 CPU 부족으로 인해 오케스트레이션 호스트-Q가 증가하고 있습니다). 또한 특정 호스트 instance 대한 제한 카운터의 값을 확인합니다.
BizTalk:Message Agent 메시지 배달 제한 상태 및 메시지 게시 제한 상태 성능 카운터가 0이 아닌 경우 값을 검사 제한 이유를 확인합니다(예: 메모리 임계값이 초과됨, 진행 중인 메시지 수가 너무 많음 등).
Stand-Alone Profiler
성능 카운터를 사용하여 높은 수준에서 병목 상태의 위치를 감지할 수 있습니다. 그러나 축소되면 문제를 완화하기 위해 코드를 보다 면밀히 검토해야 할 수 있습니다. Visual Studio 2010과 함께 제공되는 Stand-Alone Profiler는 코드가 대부분의 주기를 소비하는 위치를 진단하는 데 도움이 되는 매우 유용한 도구일 수 있습니다. 자세한 내용은
L2/L3 캐시
하드웨어 관점에서 온보딩 CPU 캐시를 사용하여 가장 큰 이점을 얻을 수 있습니다. CPU 캐시의 성능이 높을수록 캐시 적중률이 높아지므로 시스템에서 메모리와 디스크 간 데이터 페이징이 줄어듭니다.
64비트 성능 병목 현상
64비트 시스템의 성능이 32비트 시스템의 성능보다 낮아 보입니다. 이것은 몇 가지 이유로 가능, 가장 중요 한 메모리 되 고.
메모리가 2GB인 32비트 시스템에서 성능을 측정하고 2GB 메모리가 있는 유사한 64비트 시스템과 결과를 비교하는 것은 동일한 것을 비교하지 않습니다. 64비트 시스템은 disk-I/O 바인딩(낮은 % 디스크 유휴 시간 & 높은 디스크 큐 길이) 및 CPU 바인딩(최대 CPU 및 높은 컨텍스트 전환)으로 표시됩니다. 그러나 64비트 시스템에서 파일 I/O를 수행하는 것이 더 비싸기 때문은 아닙니다.
64비트 시스템은 메모리 집약적(64비트 주소 지정)이므로 운영 체제에서 사용 가능한 2GB 메모리의 대부분을 소비하게 됩니다. 이 경우 대부분의 다른 작업으로 인해 파일 하위 시스템에 스트레스가 발생하는 디스크에 페이징이 발생합니다. 따라서 시스템은 데이터와 코드 모두 메모리 내/외부로 페이징하는 CPU 주기를 소비하며 높은 디스크 대기 시간 비용의 영향을 받습니다. 결과적으로 디스크 경쟁이 심해지고 CPU 소비가 늘어나게 됩니다.
이 문제를 완화하는 방법은 메모리를 업그레이드하여 서버를 스케일 업하는 것입니다. 8GB까지 스케일 업하는 것이 좋지만 메모리를 더 추가해도 메모리 부족으로 인한 CPU 부족 문제가 문제의 원인인 경우가 아니면 처리량을 개선하는 데 도움이 되지 않습니다.
BAM을 사용하여 병목 상태 및 대기 시간이 긴 문제 식별
짧은 대기 시간이 중요한 경우 BAM을 사용하여 시스템이 BizTalk Server 시스템 내의 각 단계를 완료하는 데 걸리는 시간을 측정할 수 있습니다. HAT을 사용하여 메시지 상태를 디버그하고 라우팅 메시지의 문제 원인을 진단할 수 있지만 BAM을 사용하여 메시지 흐름을 통해 다양한 지점을 추적할 수 있습니다. 연속 작업을 사용하여 활동을 정의하는 BAM 추적 프로필을 만들면 시스템의 여러 부분 간의 대기 시간을 측정하여 워크플로 프로세스 내에서 가장 비용이 많이 드는 단계를 추적할 수 있습니다.
HAT에서 오케스트레이션 디버거를 사용하여 일시 중단된 instance 쿼리하고, 디버그 모드에서 instance 다시 시작하고, 기술 세부 정보 보기를 사용하여 적절한 중단점을 추가할 수 있습니다. 이렇게 하면 활동과 디버그 메시지를 단계별로 추적할 수 있습니다.
중단점을 설정하여 다음 이벤트를 추적할 수 있습니다.
오케스트레이션 시작 및 완료
셰이프 시작 및 완료
메시지 송신 또는 수신
예외
각 중단점에서 로컬 변수, 메시지 및 해당 속성, 포트, 역할 링크에 대한 정보를 확인할 수 있습니다.