DTA 추적의 MST를 찾기 위한 팁 및 트릭
정의상 MST는 일정한 부하를 사용하여 시스템 성능을 재현 가능하게 측정하기 위한 벤치마크입니다. MST를 아는 것이 특히 유용한 경우는 다음과 같습니다.
시스템에서 가장 낮은 대기 시간이 필요한 경우. MST를 초과하면 시스템에서 백로그가 발생하여 메시지 대기 시간이 늘어납니다. 일시적인 경우에도 백로그는 대기 시간에 즉각적인 악영향을 미칩니다. 따라서 시스템 MST를 알면 개별 메시지 처리의 대기 시간이 급증(예: 구성에 따라 초에서 분으로 증가)하기 전에 얻을 수 있는 절대 최대 처리량을 알 수 있습니다.
다른 시스템과 비교할 때. 예를 들어 다른 시스템(예: 이 항목의 시나리오, 사례 연구 또는 사용자 환경의 다른 시스템)과 비교하여 예상 MST를 얻고 있는지 확인하려는 경우입니다. 일정한 입력을 사용하여 MST를 측정하면 비교에 사용할 수 있는 재현 가능하고 명확한 표준이 제공됩니다.
그러나 MST를 측정하려면 많은 시간이 걸릴 수 있습니다. 따라서 MST 측정을 시작하기 전에 그 이점을 평가해야 합니다. 대부분의 프로덕션 시스템에서는 MST에 의해 측정되는 것과 같은 일정한 입력이 발생하지 않으며 시간에 따라 부하가 변경됩니다. 프로덕션 전에 시스템을 인증하기 위해 궁극적으로 테스트해야 하는 것이 이 부하 프로필입니다. MST 측정에 사용되는 것과 동일한 방법으로 프로덕션 부하 프로필의 유지 가능성을 평가할 수 있습니다. BizTalkDTADb 데이터베이스 데이터 보존 기간이 하나 이상 포함될 만큼 부하 프로필을 충분히 오래 실행한 다음 KPI(핵심 성과 지표)를 관찰하면 됩니다.
MST 또는 부하 프로필이든 관계없이 빈 BizTalkDTADb 데이터베이스를 사용하여 테스트 실행을 시작하는 것이 중요합니다. BizTalkDTADb 데이터베이스에 저장된 데이터는 시간이 중요하므로 각 테스트를 실행할 때마다 처음부터 데이터를 다시 모으지 않으면 결과가 잘못될 수 있습니다. 데이터 보존 기간에 따라 MST를 찾는 데 걸리는 시간이 훨씬 늘어날 수 있습니다. 이 문제를 완화시키려면 테스트 실행 중에 "즉시" 부하를 조정하는 것이 MST를 더 빨리 찾는 데 도움이 될 수 있습니다.
예를 들어 첫 번째 보존 기간이 지났으며 KPI에서 처리량이 향상될 수 있는 여유 리소스가 나타나면(예: 디스크 유휴 시간이 여전히 0보다 큼) 부하를 조금씩 늘려서 그 결과를 관찰할 수 있습니다. 그러나 이런 방식으로 MST 추정을 조정한 후 빈 BizTalkDTADb 데이터베이스로 테스트를 실행하여 추정을 확인하는 것이 중요합니다.
권장 사항
BizTalk Server 추적 시스템 아키텍처는 다양한 정보를 추적할 수 있으며 신중하게 관리하고 모니터링해야 합니다. MST에 표시된 대로 시스템 성능에 가장 영향을 미치는 요소는 다음과 같습니다.
원하는 시스템의 처리량
시스템의 각 메시지 및 서비스 인스턴스에 대해 추적되는 정보량. 이 값에 따라 BizTalkDTADb 데이터베이스의 크기가 증가하는 속도 및 BizTalkDTADb 데이터베이스가 뒤쳐지지 않도록 제거해야 하는 빈도가 결정됩니다.
BizTalkDTADb 데이터베이스에 데이터를 보존할 기간(데이터 보존 기간). 이 기간이 길수록 BizTalkDTADb 데이터베이스가 더 커져서 처리량에 영향을 줍니다.
BizTalkDTADb 데이터베이스 데이터를 보관 및 제거할지, 아니면 BizTalkDTADb 데이터베이스 크기를 유지하기 위해 제거만 할지 여부
BizTalk Server 추적을 위한 지속 가능한 최대 처리량을 찾는 프로세스에는 다음 세 가지 주요 성능 지표가 포함됩니다.
DTAdb 데이터 파일에 대한 디스크 하위 시스템의 실제 디스크 유휴 시간
스풀 깊이
BizTalkDTADbData 깊이
세 가지의 핵심 성과 지표를 모니터링하고 다음을 확인하여 시스템의 MST를 찾거나 프로덕션 프로필 처리량을 확인합니다.
안정적인 스풀 및 trackingdata 테이블 깊이
BizTalkDTADb 데이터베이스 데이터 파일 실제 디스크 유휴 시간이 0 근처이지만 계속 0은 아님
DTA 추적 기능을 사용하면 성능에 영향을 줍니다. 기본 추적을 사용하면 솔루션이 프로덕션에 있을 경우 필요 이상으로 추적될 수 있지만 광범위한 문제 해결 정보가 제공되므로 개발과 초기 테스트 및 디버깅이 더 편리합니다. 따라서 개발 및 초기 테스트 중에는 기본 추적을 사용하는 것이 좋습니다. BizTalk에 배포된 솔루션이 안정되고 성능 테스트를 비롯한 프로덕션 인증을 받을 준비가 되면 프로덕션에서 추적해야 하는 정보량과 BizTalkDTADb 데이터베이스에 보관해야 하는 기간을 신중하게 검사하여 적절하게 조정하는 것이 좋습니다.
예를 들어 비거부 또는 문제 해결 용도로 메시지 본문을 추적할 필요가 없으면 메시지 본문 추적을 설정하지 마십시오. 이 점을 설명하기 위해 DTA 추적의 MST 측정을 위한 테스트 시나리오에 설명된 예제 시나리오에서 추적 구성의 메시지 본문 추적 구성 요소가 제거되었을 때 MST는 초당 40개 메시지로 두 배로 증가했습니다.
또한 문제가 발생해도 모든 경우는 아니지만 많은 경우에서 메시지가 MessageBox 데이터베이스에 일시 중단되어 있으며 메시지 본문을 추적하지 않고도 검색하여 검사할 수 있습니다.
시스템에 배치할 부하의 유지 가능성에 중점을 두십시오.
정상 유지 관리 활동에서도 시스템이 프로덕션 부하 프로필을 무제한으로 유지할 수 있습니까?
계획되었거나 계획되지 않은 BizTalkDTADb 데이터베이스 정전 등의 문제가 발생하여 시스템이 백로그를 유지하면 어떻게 됩니까?
최악의 경우 시나리오를 기반으로 목표를 설정하고 해당 목표까지 테스트하는 것이 좋습니다. 예를 들어 계획된 정기 유지 관리 주기가 있고 이 기간 동안 BizTalkDTADb 데이터베이스가 오프라인 상태가 될 경우 테스트 실행 중에 이 정전을 에뮬레이트하여 결과로 생성된 백로그를 복구하는 시스템의 능력을 평가합니다.
참고 항목
유지 가능한 최대 추적 처리량 측정
DTA 추적 성능 동작 이해
DTA 추적 MST를 측정하기 위한 테스트 시나리오
추적 데이터베이스 크기 조정 지침