| 이 문서에서는 WebLogic 8.1 SP2 기반의 J2EE 웹 서비스 구현 시 성능에 대해 살펴봅니다. 우선 웹 서비스 기술 및 관련 표준에 대한 소개와 개요부터 살펴보고 웹 서비스 구현의 다양한 시스템 레이어와 이와 관련된 기능, 제한 사항 및 가능한 성능 효과를 중점적으로 설명합니다. |
이 문서와 관련된 저자의 파일 다운로드 |
웹 서비스 개요
웹 서비스는 웹 상에서 동적으로 상호 작용할 수 있도록 소결합된 서비스 지향 애플리케이션입니다. 이 접근 방식에서는 웹 기반 분산 애플리케이션에 동적 공유 컴포넌트를 만들고 대규모 소프트웨어 시스템을 모듈 방식의 작은 컴포넌트로 분할할 수 있는 유연성을 추가할 수 있었습니다. 일반적으로 이러한 컴포넌트는 외부 소프트웨어 애플리케이션과 단절된 것으로 간주하는 기존의 백엔드 애플리케이션과 연결시켜줍니다.실제로 웹 서비스 개념은 다음과 같은 이기종 환경의 속성을 통합하여 RMI, COM 및 CORBA와 같은 기존의 서비스 지향 기술을 확장한 것입니다.
- 웹을 통한 접근 가능성
- XML 기반 설명 언어
- HTTP/s와 같은 표준 인터넷 프로토콜에서 사용하는 XML 메시지를 통한 통신
그러므로 웹 서비스를 평가하려면 상호 운용성, 편리하고 광범위한 접근 가능성, 이기종의 분산 애플리케이션 개발을 촉진하는 플랫폼 간, 언어 간 데이터 모델링(XML) 접근 방식 여부에 대해 모두 살펴보아야 합니다.
웹 서비스 표준
J2EE 웹 서비스가 웹 서비스 시스템을 구현하려면 다음 표준이 필요합니다.- 웹 상의 서버에서 호스트되는 J2EE 객체 구현
- 웹 서비스 및 클라이언트 간 데이터 전송 및 통신 표준
웹 서비스는 메시지 포맷 및 커넥션 프로토콜의 표준을 강조합니다. 이 웹 서비스는 집중되지 않은 분산 환경에서 정보 교환에 사용되는 적은 용량의 XML 기반 프로토콜인 SOAP(Simple Object Access Protocol)에서 수행됩니다. 이 프로토콜은 SOAP 메시지를 설명하는 엔벌로프(envelope)로 구성되고, 엔벌로프(envelope)에는 소유권 및 프로세싱 세부 사항을 정의하는 메시지 본문이 포함됩니다. 일련의 인코딩 규칙은 애플리케이션 특정 데이터 형식의 인스턴스 및 원격 프로시저 호출 및 응답을 나타내는 규정을 표시하기 위해 필요합니다.
이러한 정보는 MIME(Multipurpose Internet Mail Extensions) 인코딩된 패키지에 포함되어 있어서 HTTP 또는 다른 웹 프로토콜을 통해 전송할 수 있습니다. MIME는 ASCII가 아닌 메시지를 포맷하여 인터넷을 통해 전달할 수 있도록 한 규격입니다.
- WSDL(Web Services Description Language)은 클라이언트에게 웹 서비스를 설명하기 위한 표준을 제공합니다. 이것은 웹 서비스 작업, 입력 및 출력 파라미터, 클라이언트 애플리케이션이 웹 서비스에 연결되는 방법을 설명하는 XML 기반 규정입니다.
- 클라이언트 애플리케이션에서 웹 서비스를 호출하기 위해 필요한 표준
- 안전한 웹 서비스의 경우 SOAP 요청 및 응답을 디지털 서명 및 암호화하기 위한 표준이 필요합니다.
- UDDI 2.0(Universal Description, Discovery, and Integration) 사양은 웹 서비스의 검색 및 등록에 대한 표준을 제공합니다.
시스템 개요
시스템은 서로 다른 하드웨어와 환경에서 실행되는 여러 애플리케이션과 웹 서비스로 구성될 수 있습니다. 시스템의 성능 측면을 보려면 개별 웹 서비스 컴포넌트와 이러한 컴포넌트의 아키텍처 및 실행 환경에 초점을 맞추어야 합니다. 다음은 일반적인 웹 서비스 시나리오입니다. 웹 서비스 작업과 관련된 클라이언트 서버 통신 내의 관련 이벤트에 대해 알아보도록 하겠습니다.
Fig 1
- 클라이언트 애플리케이션은 네트워크를 통해 SOAP 메시지 요청을 애플리케이션 서버로 보냅니다.
- 해당 서버는 요청에 있는 URI를 바탕으로 호출된 웹 서비스를 식별합니다.
- 웹 서비스는 SOAP 메시지 요청을 읽고 실행해야 할 작업을 식별합니다. 이 작업은 나중 단계에서 호출될 백엔드 컴포넌트의 메서드에 해당됩니다. 호출된 작업의 웹 서비스 레이어에서 SOAP 메시지의 요청 파라미터에 대해 XML에서 Java로 변환이 실행됩니다. deserializer 클래스는 이러한 용도로 사용됩니다. deserializer 클래스는 내장된 데이터 형식에 대해 애플리케이션 서버에서 제공하는 클래스이거나 내장되지 않은 데이터 형식에 대해 사용자가 만든 클래스입니다.
- 필요한 Java 파라미터를 가진 해당 백엔드 컴포넌트 메서드가 호출됩니다.
- 호출이 완료되면 백엔드 컴포넌트는 웹 서비스로 응답을 보내 해당 serializer 클래스를 사용하여 다시 Java에서 XML로 변환한 다음 SOAP 메시지 응답으로 패키지합니다.
- 웹 서비스는 웹 서비스를 호출한 클라이언트 애플리케이션으로 다시 SOAP 메시지 응답을 보냅니다.
위에서 살펴본 아키텍처는 아주 기본적인 시나리오를 나타낸 것이며 여러 가지 이유로 실제 웹 서비스는 해당 기능을 바탕으로 중간 컴포넌트를 추가하기 때문에 시스템이 더욱 복잡해질 수 있습니다. 실제 웹 서비스는 SOAP 메시지를 처리, 암호화 또는 수정하기 위해 SOAP 메시지에 액세스해야 하는 경우도 있습니다. 이러한 의도로 설계된 것이 SOAP 메시지 핸들러이며 이 핸들러는 SOAP 메시지를 가로채기 위한 메커니즘을 제공합니다.
유스케이스에 따라 SOAP 메시지 핸들러는 성능을 향상시키거나 반대로 성능을 저하시킬 수 있습니다. 이 레이어에서 정적 응답 컨텐츠에 대해 구현된 캐싱 전략은 실제 웹 서비스와 백엔드 메서드 호출을 없애 성능 향상에 도움이 될 수 있습니다. 그러나 한편으로 SOAP 메시지 본문의 데이터를 보호하기 위해 암호화/암호 해제 작업에 핸들러를 사용할 경우 추가 프로세스 오버헤드가 생겨 성능에 악영향을 미칩니다.
웹 서비스를 구축하는 모든 컴포넌트는 성능에 영향을 미치며, 개별 컴포넌트의 기능 및 제한 사항을 올바로 이해하면 보다 나은 시스템 설계에 도움이 될 것입니다.
다음 그림은 통신에 관련된 다양한 레이어를 보여 줍니다. 각 컴포넌트에 대해 설명하고 가능한 선택, 기능, 제한 사항 및 성능에 미치는 영향에 대해 알아보겠습니다.
그림 2
백엔드 컴포넌트
이 컴포넌트는 비즈니스 메서드 실행을 담당하는 객체들입니다. 여기서 기존의 모든 J2EE 컴포넌트의 메서드를 직접 웹 서비스 작업으로 제공할 수는 없지만 현재로서는 다음 세 가지를 선택하여 기존 컴포넌트에 대해 웹 서비스 작업을 직접 제공할 수 있습니다.비상태유지 세션 EJB: 이 접근 방식을 사용하여 구현한 웹 서비스 작업은 인터페이스 중심으로, 이것은 기본 비상태유지 세션 EJB의 비즈니스 메서드가 웹 서비스 작업의 작동 방법을 결정한다는 것을 의미합니다. 비상태유지 세션 EJB 백엔드에는 다음과 같은 특징이 있습니다.
- 웹 서비스의 동작을 인터페이스로 표현할 수 있습니다.
- 웹 서비스는 데이터 지향적이 아니라 프로세스 지향적입니다.
- 웹 서비스는 지속성, 보안, 트랜잭션 및 동시성과 같은 EJB의 장점을 이용할 수 있습니다.
Java 클래스: Java 클래스를 사용하여 구현한 웹 서비스 작업은 EJB 메서드를 사용하여 구현한 작업과 유사합니다. 그러나 Java 클래스를 생성하는 작업은 EJB를 생성하는 작업보다 훨씬 간단하고 빠릅니다. 백엔드 컴포넌트로서의 Java 클래스는 지속성, 보안, 트랜잭션 및 동시성과 같은 EJB 기능의 오버헤드를 피할 수 있습니다.
Java 클래스를 웹 서비스로 제공하는 데는 몇 가지 제한 사항이 있습니다.
- 스레드로부터 안전한 작업을 제공해야 합니다.
- 클래스 내에서 여러 스레드를 시작하지 말아야 합니다.
- 인수가 없는 기본 생성자를 제공해야 합니다.
- 공용 메서드를 제공해야 합니다.
JMS 메시지 consumer 또는 producer . 웹 서비스 작업은 JMS 대상/대기열에서 데이터를 송/수신해야 하는 클라이언트를 위해 작성할 수 있습니다. 단일 웹 서비스 작업은 데이터 송수신을 동시에 수행할 수 없습니다. 클라이언트 애플리케이션이 데이터의 송/수신을 모두 수행하려면 두 개의 웹 서비스 작업을 만들어야 합니다. 서버에서 해당 메시지를 처리한 원래 메시지 드리븐 빈은 수신 웹 서비스 작업에 해당되는 JMS 대상에 응답을 보내기 때문에 송신 웹 서비스 작업은 수신 웹 서비스 작업과 관련되어 있습니다.
여기서 선택에 약간의 제한 사항이 있긴 하지만 사용자는 웹 서비스 작업으로 제공되지 않는 다른 기존의 컴포넌트에 액세스할 수 있도록 새로운 컴포넌트를 작성할 수 있습니다. 그러나 애플리케이션의 유스케이스 및 기능 요구 사항을 바탕으로 올바른 컴포넌트가 선택되게 됩니다.
또한 이 레이어에서 메서드에 사용되는 데이터 형식을 이해하는 것도 중요합니다. 이 형식은 백엔드 컴포넌트 위에 위치한 웹 서비스 레이어와 같이 백엔드 컴포넌트의 성능에 커다란 영향을 미치지는 않습니다. 또한 이러한 데이터 형식은 웹 서비스 하위 시스템의 복잡성에 영향을 미칠 뿐만 아니라 성능 및 응답 시간 차이의 원인이 됩니다.
다음 단원에서는 데이터 유형이 시스템의 복잡성 및 성능에 미치는 영향에 대해 자세히 알아봅니다.
또한 이러한 백엔드 컴포넌트가 다른 하위 시스템 및 외부 컴포넌트와 어떻게 상호 작용하는지 이해하는 것도 중요합니다. 예를 들어 웹 서비스 백엔드 컴포넌트가 하드웨어 및 환경이 다른 데이터베이스와 상호 작용할 수도 있습니다. 이 레이어를 적절하게 조정하고 최적화하면 응답을 기다리고 있는 웹 서비스 레이어로 응답을 보내는 데 도움이 됩니다.
웹 서비스 레이어
이 레이어는 클라이언트 요청에 대해 올바른 웹 서비스를 식별합니다. 이 레이어는 서비스를 호출하고 SOAP 메시지 요청을 읽은 다음 호출될 작업을 식별합니다. XML 구문 분석은 이 프로세스의 커다란 오버헤드입니다. 이 작업은 백엔드 컴포넌트의 메서드에 해당됩니다. deserializer 클래스의 도움으로 SOAP 메시지의 요청 파라미터에 대해 호출된 작업에서 XML에서 Java로의 변환이 수행됩니다. 응답을 받으면 이 레이어는 serializer 클래스의 도움을 받아 Java 응답을 XML로 변환한 다음 마침내 클라이언트로 응답을 보냅니다.데이터 형식에 대해 좀 더 자세하게 살펴보고 데이터 형식이 이 레이어에 미치는 영향에 대해 알아보겠습니다. 웹 서비스 작업은 내장된 데이터 형식 및 내장되지 않은 데이터 형식을 모두 파라미터로서 지원하고 백엔드 컴포넌트의 메서드 서명을 지원하기 위한 값을 반환합니다. 즉, XML 스키마를 사용하여 데이터 형식을 표시하기만 한다면 웹 서비스가 모든 데이터 형식을 처리할 수 있음을 의미합니다. 내장된 데이터 형식은 JAX-RPC 사양에서 지정한 데이터 형식입니다.
웹 서비스에서 내장된 데이터 형식만 사용한다면 애플리케이션 서버는 XML 및 Java 간 데이터 변환을 자동으로 처리합니다. 그러나 웹 서비스 작업이 좀 더 복잡해지고 내장되지 않은 데이터 형식을 파라미터나 반환값으로 사용한다면 다음을 수행해야 합니다.
- XML 및 Java 표시 사이에서 데이터를 변환하는 serialization 클래스를 만들어야 합니다.
- XML 스키마 표기법을 사용하여 데이터 형식의 XML 표시를 설명해야 합니다.
- 해당 데이터 형식의 Java 클래스 파일을 만들어야 합니다.
- 데이터 형식 매핑을 설명해야 합니다.
내장된 데이터 형식이냐 내장되지 않은 데이터 형식이냐에 따라 XML에서Java로 또는 Java에서 XML로 변환 시 deserializer/serializer 클래스가 사용됩니다. 이러한 serialization/deserialization 프로세스는 요청 프로세싱에 오버헤드를 추가하고 구현된 방법에 따라 성능에 영향을 미칩니다.
데이터의 크기 및 복잡성을 기준으로 한 성능 비교
| Clients >> Operations | 처리량 [1–user] | 처리량 [10-Users] |
|---|---|---|
| Simple Data Types [Float-String] | 597 | 1770 |
| Simple Data Types [String size 4k] | 394 | 1467 |
| Simple Data Types [String size 100k] | 41 | 73 |
| Complex Data Type [Java Objects] | 40 | 53 |
| Complex Data Types Array [Each element 4kb, Size 16] | 61 | 151 |
| Complex Data Types Array [Each element 4kb, Size 64] | 17 | 31 |
| Complex Data Types Array [Each element 4kb, Size 128] | 8 | 15 |
그림 3
RPC 또는 document 중심의 스타일
또 다른 한 가지 결정해야 할 중요한 선택은 RPC 중심의 웹 서비스와 문서 중심의 웹 서비스 중 어느 웹 서비스를 선택하는 것이 좋은가 입니다. 다음은 이 두 범주를 비교한 것입니다.|
Style / Category |
RPC 중심 |
Document 중심 | |
|
Sub category |
None |
Standard - Document |
Document - Wrapped |
|
SOAP 메시지 |
파라미터 및 리턴값 모두 포함 |
XML 문서 포함 |
XML 문서 포함 |
|
파라미터 & 리턴타입 |
파라미터 개수 제한 없이 허용 |
하나의 파라미터만 허용 |
파라미터 개수 제한 없이 허용 |
|
사용된 인코딩 |
SOAP 인코딩 |
Literal 인코딩 |
Literal 인코딩 |
세부 정보
- 기본 문서 중심의 웹 서비스 작업은 일반적으로 XML 문서로 된 하나의 파라미터만 사용합니다. 다시 말해 해당 작업을 구현하는 메서드도 파라미터를 하나만 가져야 한다는 것을 의미합니다. 반면 문서가 래핑된 웹 서비스 작업은 여러 개의 파라미터를 사용할 수 있습니다. 하지만 파라미터 값은 SOAP 메시지에서 하나의 복잡한 데이터 형식으로 래핑됩니다.
- 단일 WebLogic 웹 서비스의 모든 작업은 RPC 중심이거나 document 중심이어야 합니다. WebLogic Server는 동일한 웹 서비스 내에 두 스타일이 혼용되는 것을 지원하지 않습니다.
기본적으로 WebLogic 웹 서비스의 작업은 RPC 중심적 작업입니다. document 중심적 작업으로 수행하려면 사용자가 지정해야 합니다.
웹 서비스 보안 [WS-Security]
보안은 성능에 영향을 미치는 또 다른 중요한 구성 요소입니다. 이 사양은 안전한 웹 서비스 구축 시 무결성 및 기밀성을 구현하기 위해 사용될 수 있는 일련의 표준 SOAP 익스텐션을 제시합니다.이 사양은 보안 토큰 전파, 메시지 무결성 및 메시지 기밀성과 같은 3가지 메커니즘을 제공합니다. 이 메커니즘 자체로는 완벽한 보안 솔루션을 제공하지 못합니다. 대신 WS-Security는 광범위한 보안 모델과 암호화 기술을 수용할 수 있도록 다른 웹 서비스 익스텐션과 고급 수준의 특정 애플리케이션 프로토콜과 함께 사용될 수 있는 빌딩 블록입니다.
이러한 메커니즘은 보안 토큰 전파의 경우처럼 독립적으로 사용할 수도 있고, 메시지를 서명 및 암호화하고 서명 및 암호화에 사용된 키와 관련된 보안 토큰 계층을 제공하는 경우처럼 강력하게 통합된 방식으로 사용할 수도 있습니다.
WS-Security 개요
WebLogic 웹 서비스의 보안을 유지하려면 개념적으로 서로 다른 3가지 보안 유형 중 하나 이상을 구성해야 합니다.메시지 수준 보안(디지털 서명 및 암호화)
메시지 수준 보안은 클라이언트 애플리케이션과 호출되는 웹 서비스 간 SOAP 메시지가 디지털 서명되어야 하는지 또는 암호화되어야 하는지 여부를 지정합니다.
전송 수준 보안(SSL)
전송 수준 보안은 SSL(Secure Sockets Layer)을 사용하여 클라이언트 애플리케이션과 웹 서비스 간 커넥션의 보안을 유지하는 것을 말합니다. 이 보안은 서버가 클라이언트 애플리케이션에 대한 인증서를 제시해야 하는 경우 단방향 SSL을 구성하고, 클라이언트 애플리케이션 및 서버 모두 서로 인증서를 제시하는 경우 양방향 SSL을 구성할 수 있습니다.
액세스 제어 보안
액세스 제어 보안은 웹 서비스에 액세스할 수 있는 사용자를 제어하도록 웹 서비스를 구성하는 것을 말합니다. WebLogic 웹 서비스는 기본 J2EE 엔터프라이즈 애플리케이션으로 패키지되어 있습니다. 따라서 웹 서비스에 대한 액세스 보안을 유지하기 위해 다음과 같은 수준에서 액세스 제어를 구성할 수 있습니다.
- 전체 웹 서비스
- 웹 서비스 작업의 하위 세트
- 웹 서비스 URL
- 웹 서비스를 구현하는 비상태유지 세션 EJB
- 비상태유지 세션 EJB의 메서드 하위 세트
- WSDL 및 웹 서비스의 홈 페이지
WebLogic 웹 서비스에 액세스하려는 클라이언트는 기본 HTTP 인증 또는 SSL 인증을 사용할 수 있습니다. 이전의 컴포넌트 중 대다수가 표준 J2EE 컴포넌트이기 때문에 표준 J2EE 보안 프로시저를 사용하여 보안을 유지할 수 있습니다. 웹 서비스를 구현하는 백엔드 컴포넌트가 Java 클래스 또는 JMS 리스너일 경우 웹 서비스를 보호하는 유일한 방법은 전체 웹 서비스 또는 웹 서비스를 호출하는 URL에 보안 제약 조건을 추가하는 것입니다.
보안 구성에 의한 성능 영향은 잘 알려진 사안입니다. 애플리케이션 보안에 따라 이러한 영향은 달라집니다. 일반적인 비교에서는 SSL을 사용하는 HTTP가 일반 HTTP 프로토콜에 비해 성능이 약 30% 향상된 것으로 나타납니다.
가능한 클라이언트 시나리오
웹 서비스 호출이란 클라이언트 애플리케이션이 웹 서비스를 사용하기 위해 수행하는 동작을 말합니다. 웹 서비스를 호출하는 클라이언트 애플리케이션은 Java, Microsoft SOAP Toolkit, Microsoft .NET 등 어떤 기술을 사용해서도 작성할 수 있습니다.WebLogic Server는 독립 실행형 클라이언트 애플리케이션 개발 시 편의를 위해 웹 서비스를 호출하는 데 필요한 클래스를 포함하는 런타임 클라이언트 JAR 파일(옵션)을 제공합니다.
여기서는 독립 실행형 Java 클라이언트에서 가능한 클라이언트 시나리오에 대해 설명하겠습니다. 이러한 클라이언트는 다음과 같은 범주로 구분할 수 있습니다.
정적 클라이언트: 정적 클라이언트의 경우 정적으로 웹 서비스를 호출하기 위해 클라이언트 애플리케이션이 사용하는 JAX-RPC 사양에 의해 정의되고 스텁을 포함하는 웹 서비스 특정 JAR 파일을 생성할 수도 있습니다. 이러한 스텁은 스텁 및 서비스 같은 JAX-RPC 인터페이스를 구현합니다. 이것은 웹 서비스에 대해 특별히 작성되는 것이며 웹 서비스 특정 JAR 파일을 사용하지 않거나 원래 동적인 다른 클라이언트와 비교해 더 잘 수행될 수 있습니다.
동적 클라이언트: 동적 클라이언트는 최소한의 웹 서비스 클래스 세트를 사용합니다. 동적 클라이언트는 일반 애플리케이션을 제공하므로 제공된 속성을 바탕으로 다른 모든 웹 서비스와 상호 작용할 수 있습니다. 특정 서버의 jar 파일과 클래스에 의존하여 통신하지 않으며 특정 서비스에 의해 제한을 받지도 않습니다. 다음은 동적 클라이언트에 가능한 시나리오입니다.
- WSDL을 사용하는 동적 클라이언트 애플리케이션
- WSDL을 사용하지 않는 동적 클라이언트 애플리케이션
다양한 클라이언트 API에 대한 성능 비교
다음은 서로 다른 클라이언트 클래스(API)를 일반 동적 웹 서비스 클라이언트에서 사용한 경우를 비교한 것입니다. "echoString" 작업이 클래스 모두에서 호출되었습니다. 두 가지 사례의 유일한 차이점은 런타임 환경을 컴파일하고 제공하는 데 사용한 웹 서비스별 클라이언트 측 클래스입니다.| Clients >>Runtime | 1 | 10 | 25 | 50 | 100 | 150 |
|---|---|---|---|---|---|---|
| Client-Axis-API WLS Server | 57 | 108 | 110 | 110 | 118 | 116 |
| Client-Sun-API WLS Server | 146 | 382 | 320 | 319 | 373 | 385 |
그림 4
다른 성능 요소
서버측 JVM 효과[JRockit vs. Sun]
| 처리량 | [1–user] | Sun141_05[1-Users] | JRockit81sp2[10-Users] | Sun141_05[10-Users] |
|---|---|---|---|---|
| Simple Data Types | -------- | 564 | 1770 | 1748 |
| Simple Data Types[String size 4k] | 394 | 394 | 1467 | 1331 |
| Simple Data Types[String size 100k] | 41 | 38 | 73 | 59 |
| Complex Data Type [Java Objects] | 40 | 36 | 53 | 35 |
| Complex Data Types Array | 61 | 55 | 151 | 55 |
| Complex Data Types Array[Each element 4kb, Size 64] | 17 | 14 | 31 | 17 |
| Complex Data Types Array[Each element 4kb, Size 128] | 8 | 7 | 15 | 12 |
단일 사용자:
그림 5
여러 사용자:
그림 6
JVM 튜닝
서버에 배포된 웹 서비스에는 적절한 JVM 튜닝이 필요합니다. 메시지 크기가 크거나 복잡한 데이터 형식의 웹 서비스 작업의 경우 서버에 상당히 많은 임시 객체가 생성됩니다. 이것은 전반적인 힙(heap) 크기에 대한 적절한 튜닝이 필요할 뿐 아니라 이러한 임시 객체를 처리하기 위해 대형 nursery 크기도 구성해야 합니다. 애플리케이션의 특성에 따라 힙(heap)내에서 구세대 및 신세대 객체 공간에 맞게 적절한 GC 알고리즘을 미세 조정해야 합니다.클라이언트 측 JVM
서버 측 JVM과 마찬가지로 클라이언트 측 JVM은 성능 연구에서 아주 중요한 역할을 합니다. 구문 분석을 수행하는 serialization/deserialization 오버헤드는 클라이언트에도 적용됩니다. 그러므로 전반적인 시스템의 성능을 평가하는 동안 클라이언트 JVM의 영향을 살펴보는 것을 잊지 마십시오.프로토콜 성능 비교[SOAP/T3/IIOP]
다음 표는 WebLogic Server에서 유사한 작업을 호출하는 서로 다른 프로토콜의 성능을 비교한 것입니다. sendString 메서드/작업을 사용하여 비교 데이터를 얻었습니다. 3가지 테스트 사례 모두 서버에서 실행 중인 원격 서비스와 상호 작용하기 위해 100KB의 문자열로 된 다양한 요청을 보내는 클라이언트를 사용했습니다. 이 비교는 대중적인 다른 프로토콜과 비교해서 SOAP 기반 통신의 성능을 보여 줍니다.| SOAP | RMI | IIOP | |
|---|---|---|---|
| 1-User | 37 | 111 | 46 |
| 10-user | 59 | 172 | 81 |
그림 7
결론
위의 분석에서는 웹 서비스 시스템의 성능 관점에서 서로 다른 주요 속성을 강조하고 있습니다. 이 연구를 통해 현실적인 성능 목표 설정에 있어 충분한 정보를 얻고, 최적의 성능을 얻을 수 있는 웹 서비스 애플리케이션을 설계하고 아키텍처를 구축하는 데 많은 도움이 되기를 바랍니다.이러한 결과는 벤치마킹 결과와 마찬가지로 "실험" 환경에서 얻어진 것입니다. 그러므로 다른 파라미터를 사용하는 서로 다른 환경에서 동일한 테스트를 실행하면 이와 다른 성능 데이터가 나올 수 있습니다. 따라서 비교 가능한 자료를 얻으려면 다양한 벤치마크 시나리오 중에는 상대적인 차이가 있다는 사실을 주목해야 합니다.