BizTalk Server 대한 일반 최적화 - 2부

다음 권장 사항을 사용하여 BizTalk Server 성능을 높일 수 있습니다. 이 항목에 나열된 최적화는 BizTalk Server 설치 및 구성한 후에 적용됩니다.

기능별로 여러 BizTalk Server 호스트 및 별도의 호스트 인스턴스 만들기

보내기, 수신, 처리 및 추적 기능을 위해 별도의 호스트를 만들어야 합니다. BizTalk 그룹에서 워크로드를 구성할 때 여러 BizTalk 호스트를 만들면 유연성을 제공하며 BizTalk 그룹의 BizTalk 서버 간에 처리를 분산하는 기본 수단입니다. 또한 여러 호스트를 사용하면 다른 호스트에 영향을 주지 않고 한 호스트를 중지할 수 있습니다. 예를 들어 메시지의 인바운드 수신을 허용하면서 메시지 보내기를 중지하여 Messagebox 데이터베이스에서 큐에 대기할 수 있도록 할 수 있습니다. 호스트 인스턴스를 기능별로 구분하면 다음과 같은 이점이 제공됩니다.

• 각 호스트 instance .NET 스레드 풀의 메모리, 핸들 및 스레드와 같은 자체 리소스 집합이 있습니다.

• 또한 여러 BizTalk 호스트는 각 호스트에 Messagebox 데이터베이스에 고유한 작업 큐 테이블이 할당되므로 Messagebox 데이터베이스 호스트 큐 테이블에 대한 경합을 줄입니다.

• 제한은 호스트 수준의 BizTalk Server 구현됩니다. 이렇게 하면 각 호스트에 대해 서로 다른 제한 특성을 설정할 수 있습니다.

• 보안은 호스트 수준에서 구현됩니다. 각 호스트는 개별 Windows ID에서 실행됩니다. 예를 들어 다른 호스트가 파일 공유에 액세스하는 것을 허용하지 않으면서 FileShare_B 대한 Host_A 액세스 권한을 부여할 수 있습니다.

BizTalk Server 호스트 속성을 수정하는 방법에 대한 자세한 내용은 의 BizTalk Server 도움말에서 "호스트 속성을 수정하는 방법"을 https://go.microsoft.com/fwlink/?LinkId=101588참조하세요.

전용 추적 호스트 구성

BizTalk Server 처리량에 최적화되어 있으므로 기본 오케스트레이션 및 메시징 엔진은 비즈니스 프로세스를 실행하는 기본 작업에서 이러한 엔진을 전환하므로 실제로 메시지를 BizTalk 추적 또는 BAM 데이터베이스로 직접 이동하지 않습니다. 대신 BizTalk Server 메시지를 MessageBox 데이터베이스에 두고 BizTalk 추적 데이터베이스로 이동해야 하는 것으로 표시합니다. 백그라운드 프로세스(추적 호스트)는 메시지를 BizTalk 추적 및 BAM 데이터베이스로 이동합니다. 추적은 리소스를 많이 사용하는 작업이므로 추적 전용인 별도의 호스트를 만들어야 하므로 추적이 메시지 처리 전용 호스트에 미치는 영향을 최소화해야 합니다.

전용 추적 호스트를 사용하면 BizTalk Server 추적을 방해하지 않고 다른 BizTalk 호스트를 중지할 수도 있습니다. Messagebox 데이터베이스에서 추적 데이터를 이동하는 것은 정상 BizTalk Server 시스템에 매우 중요합니다. BizTalk 그룹의 추적 데이터 이동을 담당하는 BizTalk 호스트가 중지되면 추적 데이터 디코딩 서비스가 실행되지 않습니다. 이 경우의 영향은 다음과 같습니다.

• HAT 추적 데이터는 Messagebox 데이터베이스에서 BizTalk 추적 데이터베이스로 이동되지 않습니다.

• BAM 추적 데이터는 Messagebox 데이터베이스에서 BAM 기본 가져오기 데이터베이스로 이동되지 않습니다.

• 데이터는 이동되지 않으므로 Messagebox 데이터베이스에서 삭제할 수 없습니다.

• 추적 데이터 디코딩 서비스가 중지되면 추적 인터셉터가 계속 실행되고 추적 데이터가 Messagebox 데이터베이스에 기록됩니다. 데이터가 이동되지 않으면 Messagebox 데이터베이스가 부풀어 오르고 시간이 지남에 따라 성능에 영향을 줍니다. 사용자 지정 속성이 추적되지 않거나 BAM 프로필이 설정되지 않은 경우에도 기본적으로 일부 데이터가 추적됩니다(예: 파이프라인 수신/보내기 이벤트 및 오케스트레이션 이벤트). 추적 데이터 디코딩 서비스를 실행하지 않으려면 인터셉터가 데이터베이스에 데이터를 저장하지 않도록 모든 추적을 해제합니다. 전역 추적을 사용하지 않도록 설정하려면 의 BizTalk Server 도움말에서 "전역 추적을 끄는 방법"을 https://go.microsoft.com/fwlink/?LinkId=101589참조하세요. BizTalk Server 관리 콘솔을 사용하여 추적 이벤트를 선택적으로 사용하지 않도록 설정합니다.

  추적 호스트는 BizTalk Server 실행하는 두 대 이상의 컴퓨터에서 실행되어야 합니다(한 컴퓨터가 실패할 경우 중복성을 위해). 최적의 성능을 위해 Messagebox 데이터베이스당 하나 이상의 추적 호스트 instance 있어야 합니다. 추적 호스트 인스턴스의 실제 수는 (N + 1)이어야 합니다. 여기서 N = Messagebox 데이터베이스 수입니다. 추적을 호스트하는 컴퓨터 중 하나가 실패하는 경우 "+ 1"은 중복성을 위한 것입니다.

  추적 호스트 instance 특정 Messagebox 데이터베이스에 대한 추적 데이터를 이동하지만 특정 Messagebox 데이터베이스에 대한 데이터를 이동하는 instance 추적 호스트는 두 개 이상 없습니다. 예를 들어 3개의 Messagebox 데이터베이스와 두 개의 추적 호스트 인스턴스만 있는 경우 호스트 인스턴스 중 하나는 두 개의 Messagebox 데이터베이스에 대한 데이터를 이동해야 합니다. 세 번째 추적 호스트 instance 추가하면 추적 호스트 작업이 BizTalk Server 실행하는 다른 컴퓨터에 배포됩니다. 이 시나리오에서 네 번째 추적 호스트 instance 추가하면 더 이상 추적 호스트 작업을 배포하지 않지만 내결함성을 위한 추가 추적 호스트 instance 제공합니다.

  BAM Event Bus 서비스에 대한 자세한 내용은 BizTalk Server 도움말에서 다음 topics 참조하세요.

• 에서 "BAM Event Bus 서비스 관리"https://go.microsoft.com/fwlink/?LinkId=101590

• 에서 "BAM Event Bus 서비스의 인스턴스 만들기"https://go.microsoft.com/fwlink/?LinkId=101591

웹 또는 WCF 서비스로 게시된 오케스트레이션을 호스트하는 웹 애플리케이션에 대한 ASP.NET 스레드 사용 또는 동시에 실행 요청을 관리합니다.

웹 서비스로 게시된 오케스트레이션을 호스트하는 ASP.NET 웹 애플리케이션의 작업자 및 I/O 스레드 수(클래식 모드의 경우 IIS 6.0 및 IIS 7.0) 또는 동시에 실행되는 요청 수(IIS 7.0 통합 모드)는 다음 조건에서 수정해야 합니다.

• CPU 사용률은 호스팅 웹 서버에서 병목 상태가 아닙니다.

• ASP.NET Apps v2.0.50727\요청 대기 시간 또는 ASP.NET 앱 v2.0.50727\요청 실행 시간 성능 카운터의 값은 비정상적으로 높습니다.

• 웹 애플리케이션을 호스트하는 컴퓨터의 애플리케이션 로그에서 생성된 다음과 유사한 오류입니다.

  Event Type: Warning
  Event Source: W3SVC Event Category: None
  Event ID: 1013
  Date: 6/4/2009
  Time: 1:03:47 PM
  User: N/A
  Computer: <ComputerName>
  Description: A process serving application pool 'DefaultAppPool' exceeded time limits during shut down. The process id was '<xxxx>'
  

클래식 모드에서 실행되는 IIS 6.0 및 IIS 7.0에서 오케스트레이션을 호스트하는 웹 애플리케이션에 대한 ASP.NET 스레드 사용 관리

클래식 모드에서 실행되는 IIS 6.0 서버 또는 IIS 7.0 서버의 machine.config 파일의 autoConfig 값이 true로 설정된 경우 ASP.NET 2.0은 연결된 IIS 작업자 프로세스에 할당된 작업자 스레드 및 I/O 스레드의 수를 관리합니다.

<processModel autoConfig="true" />

ASP.NET 2.0 웹 애플리케이션의 작업자 및 I/O 스레드 수를 수동으로 수정하려면 연결된 machine.config 파일을 연 다음 maxWorkerThreads 및 maxIoThreads 매개 변수에 대한 새 값을 입력 합니다 .

<!-- <processModel autoConfig="true" /> -->
    <processModel maxWorkerThreads="200" maxIoThreads="200" />

ASP.NET 2.0 웹 애플리케이션에 대한 machine.config 파일의 튜닝 매개 변수에 대한 자세한 내용은 "ASP.NET 애플리케이션에서 웹 서비스 요청을 수행할 때 경합, 성능 저하 및 교착 상태" (https://go.microsoft.com/fwlink/?LinkID=66483)를 821268 Microsoft 기술 자료 문서를 참조하세요.

통합 모드에서 실행되는 IIS 7.0에서 오케스트레이션을 호스트하는 웹 애플리케이션에 대해 동시에 실행되는 요청 수 관리

ASP.NET 2.0이 통합 모드에서 IIS 7.0에서 호스트되는 경우 스레드 사용은 IIS 6.0 또는 클래식 모드의 IIS 7.0과 다르게 처리됩니다. ASP.NET 2.0이 통합 모드에서 IIS 7.0에서 호스트되는 경우 ASP.NET 2.0은 동시에 실행되는 요청의 스레드 수가 아니라 동시에 실행되는 요청 수를 제한합니다. 동기 시나리오의 경우 스레드 수를 간접적으로 제한하지만 비동기 시나리오의 경우 요청 및 스레드 수가 매우 다를 수 있습니다. 통합 모드에서 IIS 7.0에서 ASP.NET 2.0을 실행하는 경우 machine.config 파일의 maxWorkerThreads 및 maxIoThreads 매개 변수는 실행 중인 스레드 수를 제어하는 데 사용되지 않습니다. 대신 maxConcurrentThreadsPerCPU에 지정된 값을 수정하여 동시에 실행되는 요청 수를 CPU당 기본값 12에서 변경할 수 있습니다. maxConcurrentThreadsPerCPU 값은 reqistry 또는 aspnet.config 파일의 구성 섹션에서 지정할 수 있습니다. 다음 단계에 따라 maxConcurrentThreadsPerCPU 의 기본값을 변경하여 동시에 실행되는 요청 수를 제어합니다.

레지스트리에서 maxConcurrentThreadsPerCPU 값 설정

이 설정은 전역이며 개별 애플리케이션 풀 또는 애플리케이션에 대해 변경할 수 없습니다.

1. 시작 메뉴에서 실행 프롬프트를 찾아서 시작하고 regedit.exe입력한 다음 확인을 선택하여 레지스트리 편집기를 시작합니다.

2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0

3. 다음 단계에 따라 키를 만듭니다.

   1. 편집 메뉴에서 새로 만들기를 선택한 다음 키를 선택합니다.

   2. maxConcurrentThreadsPerCPU를 입력한 다음 Enter 키를 누릅니다.

   3. maxConcurrentThreadsPerCPU 키 아래에서 maxConcurrentThreadsPerCPU에 대한 새 값을 사용하여 DWORD 항목을 만듭니다.

   4. 레지스트리 편집기를 엽니다.

aspnet.config 파일의 구성 섹션에서 애플리케이션 풀에 대한 maxConcurrentThreadsPerCPU 값을 설정합니다.

1. 구성 파일에서 다음 값을 설정하는 데 필요한 Microsoft .NET Framework 3.5 서비스 팩 1을 다운로드하여 설치합니다. 전체 버전도 사용할 수 있습니다.

2. 애플리케이션 풀에 대한 aspnet.config 파일을 엽니다.

3. maxConcurrentRequestsPerCPU 및 requestQueueLimit 매개 변수에 대한 새 값을 입력합니다.

   <system.web>
       <applicationPool maxConcurrentRequestsPerCPU="12" requestQueueLimit="5000"/>
   </system.web>
   

   참고

   이 값은 레지스트리의 maxConcurrentThreadsPerCPU 에 지정된 값을 재정의합니다. requestQueueLimit 설정은 processModel/requestQueueLimit와 동일하며 ,aspnet.config 파일의 설정이 machine.config 파일의 설정을 재정의합니다.

BizTalk 호스트 인스턴스에 대한 CLR 호스팅 스레드 값 정의

Windows 스레드는 Windows 프로세스에 사용할 수 있는 가장 기본적인 실행 파일 단위이므로, BizTalk 호스트 인스턴스와 연결된 .NET 스레드 풀에 충분한 스레드를 할당하여 스레드 부족 문제를 방지하는 것이 중요합니다. 스레드 부족이 발생하면 성능에 부정적인 영향을 주는 요청된 작업을 수행할 수 있는 스레드가 충분하지 않습니다. 이와 함께, 호스트와 연결된 .NET 스레드 풀에 필요한 수보다 많은 스레드가 할당되지 않도록 주의해야 합니다. 호스트와 연결된 .NET 스레드 풀에 너무 많은 스레드를 할당하면 컨텍스트 전환이 늘어날 수 있습니다. 컨텍스트 전환은 Windows 커널이 한 스레드 실행에서 다른 스레드로 전환하여 성능 비용을 발생시키는 경우에 발생합니다. 과도한 스레드 할당은 과도한 컨텍스트 전환을 유발하여 전반적인 성능에 부정적인 영향을 줄 수 있습니다.

BizTalk Server의 레지스트리에서 적절한 CLR 호스팅 값을 만들어 BizTalk 호스트의 인스턴스와 연결된 .NET 스레드 풀에 사용할 수 있는 Windows 스레드 수를 수정합니다.

BizTalk 호스트의 각 인스턴스에 연결된 .NET 스레드 풀에서 사용할 수 있는 스레드 수를 수정하려면 다음 단계를 수행합니다.

1. BizTalk 호스트 instance 중지합니다.

2. 시작, 실행을 차례로 클릭한 다음 regedit.exe를 입력하고 확인 을 클릭하여 레지스트리 편집기를 시작합니다. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$hostname으로 이동합니다. 여기서 hostname은 호스트 instance 연결된 호스트의 이름입니다.

   참고

   BizTalk Server 2004에서 BizTalk Server 2006 설치를 업그레이드한 경우 이 레지스트리 키는 guid가 BizTalk Server 호스트의 각 instance 고유한 GUID인HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvcguid로 표시될 수 있습니다.

3. CLR 호스팅 키를 찾습니다. 이 키가 없으면 다음 단계에 따라 키를 만듭니다.

   1. 편집 메뉴에서 새로 만들기를 클릭한 다음 키를 클릭합니다.

   2. CLR 호스팅을 입력한 다음 Enter 키를 누릅니다.

4. CLR 호스팅 키 아래에서 표시된 값을 사용하여 다음 DWORD 항목을 만듭니다.

   DWORD 항목	기본값	권장되는 값
   MaxIOThreads	20	100
   최대작업자스레드	25	100 중요: 이 값을 100 이상으로 늘리면 BizTalk Server MessageBox 데이터베이스를 호스트하는 SQL Server 컴퓨터의 성능에 부정적인 영향을 줄 수 있습니다. 이 문제가 발생할 경우 SQL Server가 교착 상태에 빠질 수 있습니다. 이 매개 변수는 값이 100을 초과하지 않는 것이 좋습니다.
   MinIOThreads	1	25
   MinWorkerThreads	1	25

   참고

   이러한 권장 값은 대부분의 시나리오에 충분하지만 각 호스트 instance 실행되는 어댑터 처리기 또는 오케스트레이션 수에 따라 늘려야 할 수도 있습니다.

   참고

   이러한 값은 암시적으로 서버의 프로세서 수를 곱합니다. 예를 들어 MaxWorkerThreads 항목을 값 100으로 설정하면 4개의 CPU 서버에서 값 400이 효과적으로 설정됩니다.

5. 레지스트리 편집기를 닫습니다.

6. BizTalk 호스트 인스턴스를 다시 시작합니다.

추적이 필요하지 않은 경우 오케스트레이션, 송신 포트, 수신 포트 및 파이프라인에 대한 추적 사용 안 함

추적은 데이터를 MessageBox 데이터베이스에 쓴 다음 BizTalk 추적 데이터베이스로 비동기적으로 이동해야 함에 따라 BizTalk Server 내에서 성능 오버헤드가 발생합니다. 추적이 비즈니스 요구 사항이 아닌 경우 추적을 사용하지 않도록 설정하여 오버헤드를 줄이고 성능을 향상시킵니다. 추적 구성에 대한 자세한 내용은 의 BizTalk Server 도움말에서 "BizTalk Server 관리 콘솔을 사용하여 추적 구성"을 https://go.microsoft.com/fwlink/?LinkID=106742참조하세요.

높은 처리량 시나리오에서 DTA 제거 및 보관 작업의 제거 기간을 7일에서 2일로 줄입니다.

기본적으로 BizTalk Server 데이터를 추적하기 위한 제거 간격은 7일로 설정됩니다. 높은 처리량 시나리오에서 이로 인해 추적 데이터베이스에서 데이터가 과도하게 빌드되어 결국 MessageBox의 성능에 영향을 미치고 메시지 처리량에 부정적인 영향을 줄 수 있습니다.

높은 처리량 시나리오에서 하드 및 소프트 제거 간격을 기본값인 7일에서 2일로 줄입니다. 제거 간격을 구성하는 방법에 대한 자세한 내용은 의 BizTalk Server 도움말에서 "DTA 제거 및 보관 작업을 구성하는 방법"을 https://go.microsoft.com/fwlink/?LinkID=104908참조하세요.

최신 서비스 팩 설치

BizTalk Server 및 .NET Framework 모두에 대한 최신 서비스 팩을 설치해야 합니다. 여기에는 발생할 수 있는 성능 문제를 해결할 수 있는 수정 사항이 포함되어 있기 때문에 설치해야 합니다.

절대적으로 필요한 경우가 아니면 BizTalk 호스트를 클러스터하지 마세요.

BizTalk Server 2006 및 후속 버전의 BizTalk Server 사용하면 BizTalk 호스트를 클러스터 리소스로 구성할 수 있지만 여러 BizTalk 컴퓨터에서 호스팅할 수 없는 리소스에 고가용성을 제공해야 하는 경우에만 이 작업을 고려해야 합니다. 예를 들어 FTP 프로토콜이 파일 잠금을 제공하지 않으므로 FTP 어댑터를 사용하는 포트는 하나의 호스트 instance만 상주해야 하지만 이로 인해 단일 실패 지점이 발생하므로 클러스터링 이점을 얻을 수 있습니다. 파일, SQL, HTTP 또는 처리 전용 호스트와 같은 어댑터가 포함된 호스트는 컴퓨터 간에 내부적으로 부하를 분산할 수 있으며 클러스터링 이점을 얻을 수 없습니다.

BizTalk Server 설명서의 성능 최적화

BizTalk Server 설명서의 다음 권장 사항을 적절하게 적용합니다.

• "MessageBox 대기 시간 문제 해결" https://go.microsoft.com/fwlink/?LinkId=114747

• 에서 "성능 병목 상태 식별" https://go.microsoft.com/fwlink/?LinkID=104418

• 에서 "DBNETLIB 예외 방지" https://go.microsoft.com/fwlink/?LinkID=108787

• "TCP/IP 포트 소모 방지" https://go.microsoft.com/fwlink/?LinkID=101610

• 에서 "EPM 스레드 풀 크기 설정" https://go.microsoft.com/fwlink/?LinkId=114748