BizTalk Server WCF 어댑터 성능 최적화
이 항목에서는 적절한 WCF 어댑터 또는 바인딩 유형을 선택하기 위한 권장 사항과 다양한 WCF 어댑터 구성 옵션을 적용하기 위한 지침을 제공합니다.
사용할 WCF 어댑터 또는 사용할 WCF-Custom/WCF-CustomIsolated 바인딩 유형을 선택할 때 고려 사항
메시지 크기가 증가하므로 반드시 필요하지 않은 경우 메시지 수준 보안을 사용하지 마세요. 그러면 솔루션의 전체 처리량을 최소화할 수 있습니다.
사용할 WCF 어댑터 또는 사용할 WCF-Custom/WCF-CustomIsolated 바인딩 유형을 선택할 때 호환성, 성능, 호스팅 플랫폼, 보안 및 지원되는 전송과 같은 애플리케이션 요구 사항을 신중하게 고려합니다. 아래에 나열된 지침은 일반적으로 WCF에 적용할 수 있으며 BizTalk Server 관련이 없습니다.
WCF 서비스가 ASMX 웹 서비스를 예상하는 WebSphere 웹 서비스 또는 .NET 1.1 애플리케이션과 같은 레거시 클라이언트를 지원해야 하는 경우 BasicHttpBinding을 사용해야 합니다. BasicHttpBinding은 기본적으로 보안을 구현하지 않으므로 메시지 또는 전송 보안이 필요한 경우 이 바인딩에서 명시적으로 구성해야 합니다. BasicHttpBinding을 사용하여 WS-I 기본 프로필 1.1을 준수하는 ASMX 기반 웹 서비스 및 클라이언트 및 기타 서비스와 통신할 수 있는 엔드포인트를 노출합니다. 전송 보안을 구성할 때 BasicHttpBinding은 기본적으로 클래식 ASMX 웹 서비스와 마찬가지로 자격 증명을 사용하지 않습니다. BasicHttpBinding을 사용하면 IIS 7.5 또는 IIS 7.0에서 WCF 서비스를 호스트할 수 있습니다.
인터넷을 통해 WCF 클라이언트에서 WCF 서비스를 호출하는 경우 WsHttpBinding을 사용해야 합니다. WsHttpBinding은 ASMX 웹 서비스를 예상하는 레거시 클라이언트를 지원할 필요가 없는 인터넷 시나리오에 적합하며 WsHttpBinding을 사용하면 IIS 7.5 또는 IIS 7.0에서 WCF 서비스를 호스트할 수 있습니다. 레거시 클라이언트를 지원해야 하는 경우 BasicHttpBinding을 대신 사용하는 것이 좋습니다. WsHttpBinding은 WCF 수신 위치를 노출하거나 WS-Security 또는 WS-AtomicTransactions와 같은 WS-* 프로토콜을 지원하는 송신 포트를 채택해야 할 때 사용해야 합니다.
인트라넷 내에서 클라이언트를 지원해야 하는 경우 NetTcpBinding을 선택하는 것이 좋습니다. NetTcpBinding은 전송 성능이 중요하고 IIS 대신 Windows 서비스에서 서비스를 호스트할 수 있는 경우 인트라넷 시나리오에 적합합니다. .NET-to-.NET 컴퓨터 간 통신을 위한 안전하고 신뢰할 수 있는 바인딩 환경을 제공하려는 경우 이 바인딩을 사용합니다. NetTcpBinding은 Windows 서비스 또는 IIS 7.5/7.0에서 호스트되어야 합니다.
서비스와 동일한 컴퓨터에서 WCF 클라이언트를 지원해야 하는 경우 NetNamedPipeBinding을 사용해야 합니다. 이 바인딩은 프로세스 간 동일한 컴퓨터 통신을 위한 안전하고 안정적인 바인딩 환경을 제공합니다. NamedPipe 프로토콜을 사용하려는 경우 이 바인딩을 사용합니다. NetNamedPipeBinding은 Windows 서비스 또는 IIS 7.5/7.0에서 호스트되어야 합니다.
연결이 끊긴 큐를 지원해야 하는 경우 NetMsmqBinding을 사용해야 합니다. 큐는 메시지 큐(MSMQ라고도 함)를 전송으로 사용하여 제공되므로 연결이 끊긴 작업, 오류 격리 및 부하 평준화를 지원할 수 있습니다. 클라이언트와 서비스가 동시에 온라인 상태일 필요가 없는 경우 NetMsmqBinding을 사용할 수 있습니다. 부하 평준화를 사용하여 들어오는 메시지 수를 관리할 수도 있습니다. 메시지 큐는 다른 메시지의 처리에 영향을 주지 않고 메시지가 실패할 수 있는 오류 격리를 지원합니다. NetMsmqBinding은 Windows 서비스 또는 IIS 7.5/7.0에서 호스트되어야 합니다.
이중 서비스를 지원해야 하는 경우 WsDualHttpBinding을 사용해야 합니다. 이중 서비스는 이중 메시지 패턴을 사용하는 서비스이므로 서비스가 콜백을 통해 클라이언트와 다시 통신할 수 있는 기능을 제공합니다. WsDualHttpBinding은 Windows 서비스 또는 IIS 7.5/7.0에서 호스트되어야 합니다.
WCF 바인딩 비교
바인딩은 채널 스택을 구성하기 위한 메커니즘을 제공합니다. 바인딩은 전송 채널, 메시지 인코더 및 프로토콜 채널 집합을 사용하여 채널 스택을 빌드하는 프로세스를 만듭니다. Windows Communication Foundation은 가장 일반적인 통신 시나리오를 해결하기 위해 미리 구성된 수많은 기본 제공 바인딩과 함께 제공됩니다.
| 바인딩 클래스 이름 | 전송 | 메시지 인코딩 | 보안 모드 | 신뢰할 수 있는 메시징 | 트랜잭션 흐름(기본적으로 사용하지 않도록 설정) |
|---|---|---|---|---|---|
| BasicHttpBinding | HTTP | 텍스트 | 없음 | 지원되지 않음 | 지원되지 않음 |
| WSHttpBinding | HTTP | 텍스트 | 메시지 | 사용 안 함 | WS-AtomicTransactions |
| NetTcpBinding | TCP | 이진 | 전송 | 사용 안 함 | OleTransactions |
| NetNamedPipesBinding | 명명된 파이프 | 이진 | 전송 | 지원되지 않음 | OleTransactions |
| NetMsmqBinding | MSMQ | 이진 | 메시지 | 지원되지 않음 | 지원되지 않음 |
| Custombinding | 결정합니다. | 결정합니다. | 결정합니다. | 결정합니다. | 결정합니다. |
통신 요구 사항에 따라 특정 바인딩을 선택할 수 있습니다. 예:
BasicHttpBinding 은 간단한 웹 서비스와의 상호 운용성을 위해 설계되었습니다. BasicHttpBinding은 전송에 HTTP를 사용하고 메시지 인코딩에 텍스트를 사용합니다.
WSHttpBinding 은 다양한 WS-* 프로토콜을 활용할 수 있는 고급 웹 서비스와의 상호 운용성을 위해 설계되었습니다. WSHttpBinding은 전송에 HTTP를 사용하고 메시지 인코딩에 대한 텍스트도 사용합니다.
NetTcpBinding 및 NetNamedPipeBinding 은 컴퓨터 또는 동일한 컴퓨터에서 각각 다른 WCF 애플리케이션과 효율적으로 개미 통신을 수행하도록 설계되었습니다.
런타임에 하나 이상의 사용자 지정 프로토콜 채널을 사용하여 최대 유연성이 필요한 경우 바인딩을 구성하는 바인딩 요소를 결정할 수 있는 CustomBinding 을 사용할 수 있습니다.
참고
바인딩은 응답 시간 및 처리량 측면에서 서로 다른 특성을 갖습니다. 따라서 성능을 높이기 위한 일반적인 조언은 가능한 경우 NetTcpBindind 및 NetNamesPipeBinding을 사용하는 것입니다.
TCP 전송 및 이진 메시지 인코딩을 사용하여 WCF 어댑터 처리량을 최대화하고 WCF 어댑터 대기 시간을 최소화합니다.
가능한 경우 WCF-NetTcp 어댑터를 사용하여 처리량을 최대화합니다. WCF-NetTcp 어댑터는 TCP/IP 전송 프로토콜 및 이진 메시지 인코딩을 사용하여 다른 WCF-* 어댑터에 비해 향상된 성능을 제공합니다.
또는 customBinding 바인딩 형식으로 WCF-Custom(또는 수신 위치에 대한 WCF-CustomIsolated 어댑터)를 구성할 수 있습니다. 그런 다음 binaryMessageEncoding 바인딩 확장을 추가하여 이진 메시지 인코딩 및 tcpTransport 바인딩 확장을 구현하여 TCP/IP를 메시지 전송 프로토콜로 구현합니다. 이 방법은 필요한 바인딩 요소만 선택하고 구성하고 BizTalk 메시징 엔진의 기본 동작을 확장하는 사용자 지정 채널을 만들 수 있기 때문에 매우 유연합니다. customBinding 바인딩 형식을 사용하여 WCF-Custom 어댑터를 구현하는 경우 바인딩 확장 구성 매개 변수에 대해 이러한 값을 지정하여 처리량을 최대화하고 대기 시간을 최소화합니다.
송신 포트 구성 값:
| 설정 | 기본값 | 권장되는 값 |
|---|---|---|
| TcpTransportBindingElement.ConnectionPoolSettings.maxOutboundConnectionsPerEndpoint - 연결 풀에 캐시된 각 엔드포인트에 대한 최대 아웃바운드 연결 수를 가져오거나 설정합니다. 고유의 각 원격 엔드포인트에 대해 캐시되는 연결 수를 제한합니다. 더 많은 활성 클라이언트 연결을 사용하여 이 값을 초과하면 서비스가 클라이언트에 응답하지 않는 것처럼 보일 수 있으며 각 고유 원격 엔드포인트에 대해 캐시되는 최대 예상 연결 수를 수용하도록 이 값을 조정해야 합니다. 이 속성에 대한 자세한 내용은 MSDN의 TcpConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint 속성 (https://go.microsoft.com/fwlink/?LinkId=157737)을 참조하세요. | 10 | Try >= 20 |
수신 포트 구성 값:
| 설정 | .NET Framework 4의 기본값 | .NET Framework 4에 권장되는 값 | .NET Framework 3.5의 기본값 | .NET Framework 3.5에 권장되는 값 |
|---|---|---|---|---|
| TcpTransportBindingElement.MaxPendingAccepts - 서비스에 들어오는 연결을 처리하는 데 사용할 수 있는 보류 중인 비동기 허용 작업의 최대 수를 가져오거나 설정합니다. 동시 연결 시작 수준이 높은 시나리오의 경우 이 값이 부적절할 수 있으며 더 높은 수준의 동시 클라이언트 연결 시도를 처리하도록 MaxPendingConnections 속성과 함께 조정해야 합니다. 서비스를 호스팅하는 시스템에 있는 프로세서 수보다 더 큰 값으로 이 속성을 설정할 필요는 없습니다. 이 속성에 대한 자세한 내용은 MSDN의 ConnectionOrientedTransportBindingElement.MaxPendingAccepts 속성 (https://go.microsoft.com/fwlink/?LinkId=157738)을 참조하세요. | 1 | 2*ProcessorCount | 1 | Try >= 20 |
| TcpTransportBindingElement.MaxPendingConnections - 서비스에서 디스패치를 기다리는 최대 연결 수를 가져오거나 설정합니다. 이 속성은 디스패치를 대기하는 동시 클라이언트 연결 수를 제한합니다. 이 값이 너무 작으면 서비스에서 클라이언트 연결 시도를 거부할 수 있습니다. 반면에 이 값이 너무 크면 로드량이 많을 때 서비스가 너무 느리게 표시되거나 클라이언트에 응답하지 않을 수 있습니다. 이 속성은 서비스를 최대 용량으로 실행할 수 있는 값으로 설정해야 하며 그 이상으로는 설정하지 말아야 합니다. 스택의 상위 계층이 AcceptDispatch를 호출하면 디스패치를 기다리는 연결 큐에서 해당 연결이 제거됩니다. 이 속성에 대한 자세한 내용은 MSDN의 ConnectionOrientedTransportBindingElement.MaxPendingConnections 속성 (https://go.microsoft.com/fwlink/?LinkId=157735)을 참조하세요. | 10 | 16*ProcessorCount | 10 | Try >= 20 |
| TcpTransportBindingElement.ListenBacklog - 보류 중일 수 있는 대기 중인 최대 연결 요청 수를 가져오거나 설정합니다. ListenBacklog 는 큐에 대기할 "보류 중인 수락" 요청 수를 설명하는 소켓 수준 속성입니다. 기본 소켓 큐가 최대 동시 연결 수를 초과하지 않는지 확인합니다. 이 속성에 대한 자세한 내용은 MSDN의 TcpTransportBindingElement.ListenBacklog 속성 (https://go.microsoft.com/fwlink/?LinkId=157734)을 참조하세요. | 10 | 16*ProcessorCount | 10 | Try >= 20 |
ServiceThrottlingBehavior 서비스 동작을 WCF-Custom 추가하거나 수신 위치를 WCF-CustomIsolated 다음 설정을 사용합니다.
참고
ServiceThrottlingBehavior 서비스 동작의 요소를 수정하려면 먼저 WCF-Custom* 전송 속성 대화 상자의 동작 탭에 serviceThrottling동작 확장을 추가해야 합니다. 동작 목록에 serviceThrottling을 추가하려면 WCF-Custom* 전송 속성 대화 상자의 동작 탭을 선택하고 동작에서ServiceBehavior를 마우스 오른쪽 단추로 클릭하고 확장 추가를 클릭한 다음 serviceThrottling을 선택한 다음 확인을 클릭합니다. 그런 다음 ServiceThrottlingElement 에서 사용할 수 있는 속성을 선택하고 필요에 따라 속성의 값을 변경합니다.
| 설정 | .NET Framework 4의 기본값 | .NET Framework 4에 권장되는 값 | .NET Framework 3.5의 기본값 | .Net Framework 3.5에 권장되는 값 |
|---|---|---|---|---|
| ServiceThrottlingBehavior.MaxConcurrentCalls - ServiceHost에서 적극적으로 처리 중인 최대 메시지 수를 지정하는 값을 가져오거나 설정합니다. MaxConcurrentCalls 속성은 ServiceHost 개체에서 적극적으로 처리 중인 최대 메시지 수를 지정합니다. 각 채널에는 WCF가 처리를 시작할 때까지 MaxConcurrentCalls 값에 계산되지 않는 보류 중인 메시지가 하나 있을 수 있습니다. 이 속성에 대한 자세한 내용은 MSDN의 ServiceThrottlingBehavior.MaxConcurrentCalls (https://go.microsoft.com/fwlink/?LinkId=157838)를 참조하세요. BizTalk WCF-Custom 및 WCF-CustomIsolated 수신 어댑터 MaxConcurrentCalls 속성의 기본값은 CPU당 16 입니다. 참고: BizTalk Server WCF 수신 어댑터 이외의 WCF-Custom 및 WCF-CustomIsolated 어댑터는 WCF-* 전송 속성 대화 상자의 바인딩 탭에 최대 동시 호출 속성을 노출하여 이 동작을 구성합니다. 최대 동시 호출 동작의 기본값은 200입니다. | 16*ProcessorCount | 16*ProcessorCount | - BizTalk WCF-Custom 및 WCF-CustomIsolated 수신 어댑터의 경우 16개입니다. - 다른 WCF 수신 어댑터의 경우 200입니다. |
- WCF-Custom 및 WCF-CustomIsolated 수신 어댑터에 대해 = 200을 사용해 보세요 >. - WCF-Custom 및 WCF-CustomIsolated 어댑터 이외의 BizTalk Server WCF 수신 어댑터에 대한 WCF-* 전송 속성 대화 상자의 바인딩 탭에서 최대 동시 호출 속성에 대해 200을 사용해 보세요>. |
| ServiceThrottlingBehavior.maxConcurrentInstances - 한 번에 실행할 수 있는 서비스의 InstanceContext 개체의 최대 수를 지정하는 값을 가져오거나 설정합니다. MaxConcurrentInstances 속성은 서비스의 InstanceContext 개체의 최대 수를 지정합니다. MaxConcurrentInstances 속성과 InstanceContextMode 속성 간의 관계를 염두에 두어야 합니다. InstanceContextMode가 PerSession인 경우 결과 값은 총 세션 수입니다. InstanceContextMode가 PerCall인 경우 결과 값은 동시 호출 수입니다. 최대 InstanceContext 개체 수가 이미 있는 동안 메시지가 도착하면 InstanceContext 개체가 닫히기 전까지 메시지가 유지됩니다. 이 속성에 대한 자세한 내용은 MSDN의 ServiceThrottlingBehavior.MaxConcurrentInstances 속성 (https://go.microsoft.com/fwlink/?LinkId=157897)을 참조하세요. WCF-Custom 및 WCF-CustomIsolated 수신 어댑터 MaxConcurrentInstances 속성의 기본값은 CPU당 116 입니다. 참고: WCF 수신 위치는 Microsoft.BizTalk.Adapter.Wcf.Runtime.dll 어셈블리에 포함된 BizTalkServiceInstance 클래스의 인스턴스로 구현되므로 이 클래스는 ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)로 표시되기 때문에 입니다. 들어오는 모든 요청은 동일한 싱글톤 개체에 의해 관리되며 이 매개 변수는 무시됩니다. 따라서 활성 인스턴스 수가 항상 1과 같기 때문에 특정 WCF-Custom 수신 위치에 maxConcurrentInstances 속성을 설정해도 아무런 효과가 없습니다. | 116*ProcessorCount | 116*ProcessorCount | 26 | Try >= 200 |
| ServiceThrottlingBehavior.MaxConcurrentSessions - MaxConcurrentSessions 속성은 ServiceHost 개체가 한 번에 허용할 수 있는 최대 세션 수를 가져오거나 설정합니다. 이 경우 세션은 신뢰할 수 있는 세션을 지원하는 채널로만 제한되지 않는다는 것을 이해하는 것이 중요합니다. 각 수신기 개체에는 WCF가 채널 세션을 수락하고 채널 세션 메시지 처리를 시작할 때까지 MaxConcurrentSessions 값에 계산되지 않는 보류 중인 채널 세션이 하나 있을 수 있습니다. 이 속성은 세션을 활용하는 시나리오에서 가장 유용합니다. 이 속성을 클라이언트 스레드 수보다 작은 값으로 설정하면 여러 클라이언트의 요청이 동일한 소켓 연결에 대기할 수 있습니다. 서비스와 함께 세션을 만들지 않은 클라이언트의 요청이 차단됩니다. 서비스에서 열려 있는 세션 수가 MaxConcurrentSessions에 지정된 값에 도달한 경우 서비스가 다른 클라이언트와의 세션을 닫을 때까지 차단된 상태로 유지됩니다. 그런 다음, 제공되지 않는 클라이언트 요청이 시간 초과되고 서비스가 세션을 닫습니다. 이러한 상황을 방지하려면 요청 메시지가 다른 소켓 연결에서 수락되도록 다른 애플리케이션 도메인에서 클라이언트 스레드를 실행하는 것이 좋습니다. 이 속성에 대한 자세한 내용은 MSDN의 ServiceThrottlingBehavior.MaxConcurrentSessions 속성 (https://go.microsoft.com/fwlink/?LinkId=157864)을 참조하세요. | 100*ProcessorCount | 100*ProcessorCount | 10 | Try >= 200 |
포트 구성 설정을 수정할 때 변경 내용을 체계적으로 적용합니다. 각 매개 변수를 개별적으로 수정하고 변경이 성능 및 전반적인 안정성에 미치는 영향을 테스트합니다. 언제나처럼 적용할 적절한 값은 특정 시나리오에 따라 달라집니다. 값이 너무 낮게 설정되면 확장성을 줄일 수 있습니다. 반면 값이 너무 높게 설정되면 애플리케이션 요구 사항이 컴퓨터의 물리적 리소스 용량을 초과할 수 있습니다. 또한 이러한 속성은 관련되므로 일관되고 일관된 방식으로 설정해야 합니다. ServiceThrottlingBehavior를 사용하여 WCF 서비스 성능을 제어하는 방법에 대한 자세한 내용은 MSDN에서 ServiceThrottlingBehavior를 사용하여 WCF 서비스 성능 제어 (https://go.microsoft.com/fwlink/?LinkId=157908)를 참조하세요.