Priya Dhawan
Microsoft Developer Network
2002년 9월
적용 대상:
Microsoft .NET Remoting
Microsoft ASP.NET Web Service
요약: HTTP를 통해 WSDL 및 SOAP를 완벽하게 지원하며 가장 높은 수준의 상호 운용성을 제공하는 Microsoft ASP.NET Web Service와 공용 언어 런타임 유형의 시스템용으로 설계되고 추가 데이터 형식과 통신 채널을 지원하는 Microsoft .NET Remoting의 상대적인 성능을 비교합니다(14페이지/인쇄 페이지 기준).
MSDN Code Center에서 BDADotnet.msi sample code 
를 다운로드하십시오.
목차
소개
소개
ASP.NET Web Service 및 .NET Remoting은 분산 응용 프로그램에서 프로세스 간 통신을 위한 모든 디자인 옵션을 제공합니다. 일반적으로 ASP.NET Web Service에서는 HTTP를 통해 WSDL 및 SOAP를 완벽하게 지원하며 가장 높은 수준의 상호 운용성을 제공하는 반면, .NET Remoting은 공용 언어 런타임 유형 시스템용으로 설계되었고 추가 데이터 형식과 통신 채널을 지원합니다. 자세한 내용은 ASP.NET Web Services or .NET Remoting: How to Choose 를 참조하십시오.
이 기사에서는 두 기술의 상대적인 성능 비교에 촛점을 맞춥니다.
ASP.NET Web Service
ASP.NET에서는 SOAP, XML 및 WSDL 같은 산업 표준을 지원하는 Microsoft IIS 호스트 인프라를 제공합니다. .NET Remoting에서는 HTTP를 통해 IIS 호스팅과 SOAP를 지원하지만 ASP.NET는 SOAP Section 5 및 document/literal에 대한 지원을 비롯하여 높은 수준의 SOAP 상호 운영성 수준을 제공하도록 설계되었습니다.
ASP.NET에서는 보안이나 로깅 같이 IIS와 함께 사용 가능한 기능을 이용할 수 있습니다. IIS 호스팅은 종료되면 Aspnet_wp.exe를 다시 재생하는 점에서 강력합니다. 또한 ASP.NET Web Service는 서버나 클라이언트 모두 구성이 단순하기 때문에 .NET Remoting을 사용하여 노출된 서비스보다 더 쉽게 작성 및 소비할 수 있습니다.
자세한 내용은 .NET Framework 개발자 가이드의 Building XML Web Services Using ASP.NET 을 참조하십시오.
.NET Remoting
.NET Remoting은 다른 전송 프로토콜과 serialization 형식을 사용하는 개체 간의 통신이 가능하다는 점에서 더 융통성이 있고 확장 가능성이 높습니다. TCP, HTTP 및 사용자 지정 프로토콜은 Binary, SOAP 및 사용자 지정 형식으로 지원됩니다. Singleton, SingleCall 및 Client-Activated를 포함하여 복수 개체 생성 모드 및 작동 기간 모드가 지원됩니다. Remoting에는 IIS가 될 수 있는 호스트 프로세스나 .NET으로 작성한 Microsoft Windows 서비스나 실행 파일이 필요합니다.
ASP.NET를 사용하여 IIS에서 호스트할 경우 SOAP 포맷터를 사용한 .NET Remoting 개체를 XML Web Service로 노출할 수 있습니다. 페이로드는 HTTP를 통해 SOAP으로 인코딩되기 때문에 SOAP 인코딩 형식을 지원하는 클라이언트는 인터넷을 통해 개체를 액세스할 수 있습니다. HTTP 프로토콜 사용할 경우 대부분의 방화벽에서 일반적으로 장애없이 전달된다는 장점이 있습니다. 서버와 클라이언트가 모두 .NET Framework에서 실행되는 인트라넷 환경에서 TCP 채널과 Binary 포맷터를 사용할 수 있습니다. HTTP보다 더 효율적인 사용자 정의 프로토콜을 사용하여 네트워크에서 데이터를 전송하는 데 원시 소켓을 사용하기 때문에 성능면에서 이 방법이 최적입니다. 이 방법은 닫힌 환경에서는 뛰어난 성능을 제공하지만 클라이언트가 .NET Framework 기반이 아닌 플랫폼 사이의 시나리오에서는 이 방법을 사용할 수 없습니다.
IIS 호스팅에서는 SSL(Secure Sockets Layer)을 사용하여 연결 레벨 보호를 위한 보안 통신을 제공하므로 IIS 및 ASP.NET 인증도 이용할 수 있습니다. 비 IIS 호스팅이 있는 HTTP 채널뿐만 아니라 TCP 채널에서는 보안 소켓 전송을 지원하지 않기 때문에 데이터는 일반 텍스트로 전송됩니다. IIS 이외 프로세스에서 호스팅되는 HTTP 채널이나 TCP 채널을 사용하는 경우 사용자 고유의 보안을 구현해야 합니다.
자세한 내용은 .NET Framework 개발자 가이드의 .NET Remoting Overview 를 참조하십시오.
테스트 시나리오
분산 응용 프로그램의 프로세스간 통신 성능은 다음 요소 수에 따라 결정됩니다.
원격 경계의 응용 프로그램 간에 메시지를 전송하는 데 사용한 TCP 및 HTTP와 같은 채널은 많은 오버헤드를 부과합니다. TCP 소켓은 HTTP보다 더 효율적입니다.
Serialization은 또 다른 요소입니다. Serialize된 스트림은 XML, SOAP 또는 압축 이진 표현을 사용하여 인코딩할 수 있습니다. ASP.NET Web Service에서는 XMLSerializer 클래스를 사용하여 개체를 XML 스트림으로 serialize합니다. XML 스트림은 XML 구문 분석과 연관된 일부 오버헤드가 있다는 점만 제외하고 매우 빠릅니다. Remoting에서는 BinaryFormatter와 SOAPFormatter를 사용하여 개체를 각각 이진 및 SOAP 형식으로 serialize합니다. 이 포맷터에서 리플렉션을 사용하기 때문에 참조된 개체에는 빠르지만 리플렉션 API를 통해 전달하도록 boxed 및 unboxed해야 하는 값 형식에서는 느릴 수 있습니다. SOAPFormatter에는 인코딩된 SOAP 메시지를 생성하는 또 다른 오버헤드가 있습니다.
이 비교에 사용한 테스트는 고객과 주문 데이터를 액세스하는 일반 비즈니스 시나리오를 기준으로 합니다. 가능한 한 테스트를 현실적으로 만들기 위해 데이터베이스에는 100,000개 이상의 고객 계정 행이 포함되어 있습니다. 데이터는 Microsoft SQL Server™ 2000 데이터베이스와 SQL Server에 연결하는 데 사용된 SQL Server .NET 데이터 공급자에 있습니다.
성능 비교에 다음 메서드를 사용합니다.
GetOrderStatus
GetOrderStatus 메서드는 OrderId를 받아서 주문 상태를 나타내는 정수를 반환합니다.
GetCustomers
GetCustomers 메서드는 CustomerId와 매개 변수를 받아서 읽을 고객 행 번호를 지정합니다. Web Service에 전달된 CustomerId보다 더 큰 CustomerId가 있는 상위 n 행을 읽습니다.
페이지 크기(예: 20 및 50)가 다른 일부 고객 행 세트를 전체적으로 페이징하여 테스트를 수행했습니다.
테스트 도구 및 전략
이 테스트에서 ASPX 웹 페이지는 테스트 코드가 포함된 원격 개체를 호출합니다. 웹 서버 뒤에서가 아니라 기술을 직접 테스트할 경우 더 나은 절대적인 성능을 얻을 수 있지만 일반 응용 프로그램 시나리오는 상태 비저장 환경에서 테스트하는 것이 더 실제적입니다. 다중 스레딩된 테스트와 신뢰할 수 있는 성능 통계를 제공하는 웹 페이지를 강조할 수 있는 사용 가능한 여러 테스트 도구가 있습니다.
이 테스트의 경우 테스트 웹 서버에 역점을 두어 ASPX 페이지와 테스트에서 사용한 구성 요소를 포함한 웹 응용 프로그램의 성능 및 확장성 문제를 분석할 수 있도록 설계된 Microsoft ACT(Application Center Test)를 사용했습니다. 테스트를 작성 및 실행하는 방법에 대한 자세한 내용은 ACT 설명서를 참조하십시오. Application Center Test에서는 서버에 대한 복수 연결을 열고 HTTP 요청을 신속하게 전송하여 많은 사용자 그룹을 시뮬레이션할 수 있습니다. 또한 임의의 매개 변수 값 세트를 사용하여 같은 메서드를 호출할 수 있는 실질적인 테스트 시나리오를 구성할 수도 있습니다. 같은 매개 변수 값을 가진 동일한 메서드를 여러 번 호출하지 않아도 되기 때문에 중요한 기능입니다. 다른 유용한 기능으로 Application Center Test에서 웹 응용 프로그램의 성능에 대한 가장 중요한 정보를 제공하는 테스트 결과를 기록합니다.
이전에 언급한 것처럼 원격 개체에 대한 두 가지 유형의 활성화, 즉 서버 활성화와 클라이언트 활성화가 있습니다. 서버는 서버 활성 개체의 작동 기간을 직접 제어합니다. 서버 활성 개체에 대한 두 가지 활성화 모드가 있는데, 바로 Singleton 및 SingleCall입니다. Singleton 형식에는 한 번에 실행 중인 인스턴스가 둘 이상 될 수 없습니다. 모든 클라이언트 요청을 단일 인스턴스에서 사용하므로 이 활성화 모드를 사용하면 클라이언트간의 상태를 유지할 수 있습니다. 한편 SingleCall 형식의 경우 모든 클라이언트 요청을 별도의 인스턴스에서 사용합니다. 클라이언트 활성화 개체는 서버에 작성되지만, 호출 응용 프로그램 도메인에서 이 개체의 수명을 제어합니다. 이 모드를 사용하면 동일한 클라이언트의 요청 사이에서 상태를 유지할 수 있습니다. ASP.NET에서만 SingleCall을 지원합니다. 즉, 모든 요청을 새 인스턴스에서 사용합니다. 서비스가 상태 저장일 경우 쿠키와 SessionState 또는 사용자 정의 SOAP 헤더를 사용하여 관리해야 합니다. 다양한 원격 옵션을 비교하기 위해 수행한 모든 테스트에서는 공정한 비교를 위해 SingleCall 모드를 사용합니다.
ASP.NET Web Service에서 SOAP, HTTP-GET 및 HTTP-POST 옵션을 지원하지만 일관성을 위해 테스트에서는 SOAP 옵션만 사용했습니다.
HTTP/1.1에서는 하나의 클라이언트에서 단일 서버에 대해 연결을 두 개까지만 가질 수 있도록 권장합니다. 따라서 HTTPChannel 및 ASP.NET이 있는 원격에서처럼 통신용 HTTP 프로토콜을 사용할 경우 기본적으로 지정한 시간에 지정한 서버에 대해 2개의 연결만 엽니다. 반면 TCP 채널은 서버에 요청을 한 스레드 수만큼 엽니다. 원격 개체에 동시 요청을 전송하는 복수 클라이언트를 시뮬레이션하기 위해 클라이언트의 구성 파일을 사용하여 클라이언트당 서버에 대한 연결을 기본값 2에서 100으로 변경했습니다.
HTTP 채널을 사용하여 원격을 수행할 경우 클라이언트 .config 파일의 clientConnectionLimit 특성을 사용합니다.
<system.runtime.remoting>
<application>
<channels>
<channel ref="http" clientConnectionLimit="100">
<clientProviders>
<formatter ref="soap" />
</clientProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
ASP.NET Web Service의 경우 클라이언트 .config 파일의 <system.net>에 있는 maxConnection 속성을 사용합니다.
<system.net>
<connectionManagement>
<add address="*"
maxconnection="100"
/>
</connectionManagement>
</system.net>
"localhost"에 무제한 HTTP 연결이 허용되기 때문에 즉, 클라이언트와 서버가 모두 동일한 시스템에 있을 경우 구성 파일을 변경하지 않아도 됩니다.
시스템 구성
다음 표에서는 테스트를 실행하기 위해 사용한 테스트 기반 구성에 대한 간단한 요약을 제공합니다.
표 1. 클라이언트 컴퓨터 구성
| 클라이언트 수 |
컴퓨터/CPU |
CPU 수 |
메모리 |
디스크 |
소프트웨어 |
| 1 |
Compaq Proliant 1130MHz |
2 |
1GB |
16.9GB |
- Windows 2000 Advance Server SP 2
- Application Center Test
|
표 2. 웹 서버 구성
| 서버 수 |
컴퓨터/CPU |
CPU 수 |
메모리 |
디스크 |
소프트웨어 |
| 3 |
Compaq Proliant 1000MHz |
2 |
1GB |
16.9GB |
- Windows 2000 Advance Server SP 2
- .NET Framework SP1의 릴리스 버전
|
표 3. 응용 프로그램 서버 구성
| 서버 수 |
컴퓨터/CPU |
CPU 수 |
메모리 |
디스크 |
소프트웨어 |
| 1 |
Compaq Proliant 1126MHz |
2 |
1GB |
16.9GB |
- Windows 2000 Advance Server SP 2
- .NET Framework SP1의 릴리스 버전
|
표 4. 데이터베이스 서버 구성
| 서버 수 |
컴퓨터/CPU |
CPU 수 |
메모리 |
디스크 |
소프트웨어 |
| 1 |
Compaq Proliant 700MHz |
4 |
4GB |
18GB |
- Windows 2000 Advance Server SP 2
- SQL Server Enterprise Edition SP 2
|
성능 테스트 결과
성능차에 대한 주요 지표는 처리량과 대기 시간입니다. 반환할 데이터의 양을 지정할 경우 지정한 특정 시간(대개 초) 안에 처리한 클라이언트 요청 수를 처리량이라고 합니다. 사용 가능성 관점을 볼 때 받아들일 수 없는 응답 시간에 최대 처리량이 발생할 수 있기 때문에 대기 시간을 추적했습니다. 대기 시간은 각 테스트 실행마다 Application Center Test에서 생성한 보고서를 사용하여 응답 시간으로 측정합니다.
컴퓨터간 시나리오
컴퓨터간 시나리오에서 원격 클라이언트와 원격 개체는 서로 다른 컴퓨터에 있습니다. ACT 클라이언트는 ASPX 웹 페이지로 요청을 전송하고, 그 다음 이 페이지에서 원격 개체에 대한 메서드를 호출합니다.
그림 1. 컴퓨터간 시나리오
그림 1에서 보여주듯이 테스트는 웹 서버 뒤에서 실행되고 데이터베이스 액세스가 있으며 네트워크는 외부 컴퓨터로 홉핑되어 오버헤드를 추가시킵니다. 따라서 처리량과 대기 시간에 대해 생성된 성능 숫자는 이 기술을 비교하기 위한 기준 역할을 할 뿐입니다. 이 숫자가 절대적인 성능을 나타내지는 않습니다. ASP.NET Web Service와 .NET Remoting을 사용하여 구성된 분산 시스템의 정확한 처리량과 대기 시간은 사용한 아키텍처에 따라 달라집니다.
GetOrderStatus
여기서는 데이터베이스에서 하나의 값을 가져올 때 다양한 기술적인 작업을 비교합니다.
그림 2. GetOrderStatus: 처리량 및 대기 시간
참고:
- ASMX: ASP.NET Web Service
- 다른 모든 옵션은 다양한 .NET Remoting 구성을 나타냅니다.
- 다른 모든 옵션에서 이름은 사용할 호스트, 전송 프로토콜 및 형식 즉, Host_TransaportProtocol_Format을 나타냅니다.
- 'WS'는 원격 형식을 호스트하는 Windows Service의 약어로 사용됩니다.
- IIS_HTTP_Binary/SOAP는 ASP.NET를 사용하여 IIS에서 호스팅됩니다.
그림 2에 보여주듯이 Windows 서비스의 역할을 하는 호스트와 함께 WS_TCP_Binary는 개체가 TCP 채널과 Binary 포맷터를 사용하도록 구성됩니다. 이는 다른 분산 기술보다 성능이 뛰어납니다. 이런 이유는 이진 데이터를 HTTP보다 더 효율적인 원시 TCP 소켓을 통해 전송하기 때문입니다. 데이터를 인코딩/디코딩하지 않아도 되기 때문에 처리 오버헤드가 더 적습니다. WS_TCP_Binary와 가장 느린 방법 사이에 60% 정도의 성능이 흩어져 있습니다.
IIS_HTTP_Binary에서는 WS_HTTP_Binary와 같이 동일한 이진 페이로드를 생성하지만, IIS(Inetinfo.exe)에서 Aspnet_wp.exe로 추가 프로세스 홉이 있기 때문에 더 느립니다. IIS_HTTP_SOAP와 WS_HTTP_SOAP간의 성능 차이도 이와 동일한 이유로 설명됩니다.
WS_HTTP_Binary 및 WS_TCP_SOAP는 매우 유사한 성능을 제공합니다. 전자에는 HTTP를 구문 분석하는 추가 오버헤드가 있고, 후자에는 SOAP를 구문 분석하는 추가 오버헤드가 있지만, 이 경우 HTTP 구문 분석과 SOAP 구문 분석의 오버헤드는 같습니다.
ASP.NET XML serialization이 .NET Remoting SOAP serialization보다 더 효율적이기 때문에 ASP.NET Web Service는 IIS_HTTP_SOAP 및 WS_HTTP_SOAP보다 성능이 더 좋습니다. 그림 2에서 보여주듯이 ASP.NET Web Service는 성능면에서 IIS_HTTP_Binary와 매우 유사합니다.
GetCustomers 사용자 정의 클래스 사용
이 절에서 원격 메서드는 데이터베이스의 고객 레코드를 DataReader로 읽어들이고, DataReader의 데이터를 사용하여 Customers 개체를 채우고, Customers 개체를 반환합니다. 반환된 데이터 양이 성능에 미치는 정도를 확인하기 위해 20개 내지 50개 행의 결과 세트를 가지고 테스트를 실행했습니다.
그림 3. GetCustomers(n=20): 처리량 및 대기 시간
여기서는 Customers 개체를 마샬링하는 비용이 중요한 요소이기 때문에 다른 옵션의 상대적인 성능은 대부분 WS_TCP_Binary를 통해 얻어집니다. 이 테스트에서는 이전 테스트의 정수를 serialize하는 것과 비교하여 20명의 고객이 포함된 Customers 개체를 serialize합니다.
앞에서 언급한 전자의 경우에 추가 프로세스 홉이 포함되어 있기 때문에 IIS_HTTP_Binary가 WS_HTTP_Binary보다 약간 더 느립니다. ASP.NET Web Service에서는 IIS_HTTP_Binary와 매우 유사한 성능을 제공합니다.
WS_TCP_SOAP의 성능이 데이터가 많아지면서 상당히 떨어졌고 이제는 WS_HTTP_SOAP 및 IIS_HTTP_SOAP와 비교할 수 있습니다. 성능에 영향을 미치는 중요한 요소이므로 이 경우 데이터를 serialize하는 데 많은 시간을 들입니다.
그림 4. GetCustomers(n=50): 처리량 및 대기 시간
참고:
- ASMX_SOAPExtn: SOAPExtension을 사용하여 ASP.NET로 인한 버퍼링 문제를 해결합니다.
그림 4에서 보여주듯이 데이터 크기가 늘어나면서 WS_TCP_Binary와 다른 옵션 간의 성능 차이가 더욱 줄어들었습니다.
ASP.NET Web Service는 IIS_HTTP_Binary보다 성능이 떨어집니다. ASP.NET의 대용량 메시지 버퍼링으로 인한 문제이며 이 문제는 다음 버전에서 수정되었습니다. 이전 테스트에서 볼 수 있듯이 버퍼링 문제점이 해결되면 ASMX 옵션은 IIS_HTTP_Binary와 일치하게 됩니다.
XmlSerializer와 네트워크간에 일부 버퍼링을 제공하는 SOAPExtension을 구현하여 버퍼링 문제를 해결했습니다. 그래프에서 보여주듯이 구현한 ASMX_SOAPExtn 옵션은 ASMX 옵션보다 많이 개선되었지만 IIS_HTTP_Binary보다는 약간 뒤쳐집니다. SOAPExtension은 .NET 다운로드 가능 샘플 코드를 사용한 분산 응용 프로그램 구성에 포함되어 있습니다.
WS_TCP_SOAP, WS_HTTP_SOAP 및 IIS_HTTP_SOAP는 약간 더 빠른 WS_TCP_SOAP와 성능면에서 유사합니다.
GetCustomers DataSet 사용
다음 테스트 세트에서 원격 메서드는 데이터베이스의 고객 레코드를 클라이언트로 반환되는 DataSet로 읽어들입니다.
그림 5. GetCustomers(n=20): 처리량 및 대기 시간
여기서는 Dataset 마샬링과 연관된 오버헤드가 중요한 요소가 되었으므로 WS_TCP_Binary와 다른 방법간의 상대적인 성능이 줄어들었습니다.
IIS_HTTP_Binary는 WS_HTTP_Binary보다 약간 선두를 유지합니다. 후자의 추가 프로세스 홉 비용은 데이터 마샬링 비용과 비교해 볼 때 대수롭지 않습니다.
ASP.NET Web Service의 성능이 많이 떨어졌기 때문에 WS_TCP_SOAP, WS_HTTP_SOAP 및 IIS_HTTP_SOAP와 유사한 성능을 갖습니다. 이 성능 저하는 앞으로의 ASP.NET의 알려진 두 가지 문제 때문이며 이 문제는 다음 버전에서 수정될 것입니다. 하나는 이전에 설명한 버퍼링 문제이고, 다른 하나는 ASP.NET의 DataSet serialization과 관련된 것입니다. 이 문제가 해결되면 ASP.NET Web Service는 거의 IIS_HTTP_Binary와 호환 가능하게 됩니다. 대용량 메시지의 버퍼링 문제를 해결되었으므로 그림 5에서 볼 수 있듯이 ASMX_SOAPExtn은 ASMX보다 나아졌습니다. 그러나 DataSet serialization 문제점 때문에 성능은 여전히 떨어집니다.
그림 6. GetCustomers(n=50): 처리량 및 대기 시간
Dataset 크기가 이전 테스트에서보다 더 크기 때문에 WS_TCP_Binary와 다른 접근 방법 간의 상대적인 성능이 크게 떨어졌습니다. WS_HTTP_SOAP 및 IIS_HTTP_SOAP에서 제공하는 매유 유사한 성능을 볼 수 있습니다.
ASP.NET Web Service 접근 방법의 성능이 뒤떨어진 이유는 이전에 논의되었으며 알려진 문제입니다. 버퍼링 문제점을 해결하여 ASMX_SOAPExtn은 ASMX보다 크게 우위를 차지하게 되었습니다.
결론
이 테스트에서 보여주듯이 ASP.NET Web Service와 .NET Remoting과 함께 사용할 수 있는 다양한 디자인 선택 사항에는 여러 가지 오버헤드의 양에 따라 성능면의 특징이 크게 다릅니다. 전달할 데이터 크기에 따라 다른 디자인 선택 사항 간의 차이를 더욱 두드러지게 합니다. 이 비교에서는 상태 비저장, 동기화 원격 프로시저 호출만 다루고, 분산 응용 프로그램의 성능에 영향을 미치는 다른 중요한 요소인 인증 및 데이터 암호화의 성능 관련 문제는 다루지 않습니다.
.NET Remoting 인프라와 ASP.NET Web Service 모두에서 프로세스간 통신을 구현할 수 있지만 두 기술 모두 각각 다른 대상을 위한 특정한 수준의 전문 기술과 융통성을 사용하여 설계했습니다. 응용 프로그램에 다른 플랫폼이나 운영 체제와의 상호 운영성이 필요한 경우 ASP.NET Web Service 사용을 중지하는 것이 좋습니다. SOAP Section 5와 Document/Literal을 지원하는 점에서 더 융통성이 있기 때문입니다. 더 강력한 개체 지향 프로그래밍 모델이 필요한 경우에는 .NET Remoting을 사용하십시오. 자세한 내용은 ASP.NET Web Services or .NET Remoting: How to Choose 를 참조하십시오. 보안 및 프로세스 수명 주기 관리가 쟁점 사항이 아니라 성능이 주요 요구 사항인 시나리오에서는 .NET Remoting TCP/Binary가 실행 가능한 옵션입니다. 그러나 시스템에 몇 대의 컴퓨터를 추가하여 IIS-호스팅 구현의 성능을 증가시킬 수 있지만, .NET Remoting TCP/Binary 구현을 사용할 경우에는 불가능할 수 있습니다.
화면 맨 위로
최종 수정일: 2002년 11월 5일
ⓒ 2003 Microsoft Corporation. All rights reserved. 사용권에 대한 고지 사항 | 개인정보보호정책