Apache CXF 웹 서비스 스택은 이 시리즈의 이전 기사에서 설명한 Apache Axis2 및 Metro 스택과 동일한 기술 중 일부를 기반으로 빌드된다. Axis2와 마찬가지로 Apache CXF 웹 서비스 스택은 Apache WSS4J WS-Security 구현을 사용한다. Metro와 마찬가지로 Apache CXF 웹 서비스 스택은 JAX-WS 2.x 웹 서비스 구성 및 JAXB 2.x 데이터 바인딩을 사용한다(두 스택 간 버전은 다를 수 있지만 Metro와 동일한 JAXB의 참조 구현을 사용함). 하지만 이러한 공통 컴포넌트 외에는 처리 엔진 및 WS-SecurityPolicy 구성 처리를 포함하여 여러 면에서 이들 스택은 차이가 있다.

이 시리즈의 지난 기사에서는 단순한 메시지 교환과 서로 다른 WS-Security 구성의 경우에서 Axis2의 성능과 Metro의 성능을 비교했다. 이 기사에서는 Axis2 및 Metro의 최신 릴리스와 CXF의 성능을 비교한다.

성능 살펴보기

웹 서비스 성능에 대한 이전의 기사("The high cost of (WS-)Security " 및 "Metro vs. Axis2 performance")와 같이 이 기사에서도 클라이언트와 서버가 둘 다 하나의 시스템에서 실행될 때 요청의 특정 순서를 실행하는 데 필요한 시간을 측정하는 접근 방식을 사용한다. 이 접근 방식은 네트워크 잠복과 오버헤드의 영향이 시간 결과에서 삭제되기 때문에 웹 서비스 처리 오버헤드를 비교하는 데 매우 효과적이다. 클라이언트 코드가 서버보다 엄청나게 느리지는 않다고 가정하면 수치는 로드 하에서 서버의 실제 성능을 나타내는 좋은 지표도 된다.

이 기사에서도 이전 기사와 동일한 테스트 애플리케이션인 지진 데이터 검색 서비스를 사용한다. 이 서비스는 일정 기간 동안 전세계에서 발생한 93,000회 이상의 지진에 대한 데이터베이스를 사용한다. 서비스로의 요청에서 시간 범위와 지리적 좌표 범위를 지정하면, 서비스는 지정된 범위 내의 모든 지진을 리턴한다. 테스트 애플리케이션과 샘플 요청/응답 메시지 쌍에 대한 전체 세부 사항을 보려면 "The high cost of (WS-)Security"를 참조한다.

이전 기사와 마찬가지로 성능 테스트를 위해 두 세트의 요청 시퀀스가 사용되었다. 첫 번째 세트는 전체 지진 데이터베이스의 적은 부분과 일치하도록 조정된 쿼리 매개변수가 포함된 1,000개의 요청을 사용한다(1,000개의 요청에 대해 일치하는 지진 데이터가 816개만 리턴됨). 두 번째 세트는 데이터베이스의 더 많은 부분과 일치하도록 조정된 100개의 요청을 사용한다(100개의 요청에 대해 일치하는 지진 데이터 176,745개가 리턴됨). 이러한 두 요청 시퀀스는 웹 서비스 스택의 서로 다른 성능 특성을 강조한다. 첫 번째 요청 시퀀스는 스택이 적은 데이터가 포함된 요청을 얼마나 신속하게 처리하는지 보여 주고 두 번째 요청 시퀀스는 데이터 볼륨 처리 속도를 강조한다. 각 요청 시퀀스는 다른 보안 구성에서 각 구성에 대한 최상의 시간만 결과에 보관된 상태로 여러 번 실행되었다.

테스트는 지정된 힙 크기에 대해 64비트 JVM보다 약간 나은 성능을 제공하는 Sun (Oracle) Java 1.6.0_18 32비트 JVM을 사용하여 Athlon X2 5400+ 프로세서와 4GB의 RAM이 설치된 Mandriva 2009.1 64비트 Linux 시스템에서 실행되었다. 서버 코드는 512MB 힙을 사용하는 클라이언트 코드로 1024MB 힙을 사용하도록 구성된 Tomcat 6.0.20에서 실행되었다. 웹 서비스 스택 버전은 다음과 같았다.

• CXF 2.1.7
• Metro 2.0
• Rampart의 1.5 릴리스가 설치된 Axis2 1.5.1

자체 하드웨어 및 JVM에서 테스트하려면 코드를 다운로드한다.

위로

WS-Security를 사용하지 않은 경우의 성능

그림 1에서는 WS-Security를 사용하지 않은 경우 Axis2, Metro 및 CXF에 대해 측정된 테스트 시간을 보여 준다. 도표에서 알 수 있듯이 요청 수는 많고 응답 수는 적은 경우에는 Metro가 Axis2와 CXF보다 상당히(약 25퍼센트) 빠르고 요청 수가 적고 응답 수가 많은 경우에는 Apache 스택과 속도가 거의 동일하다. (이 기사의 모든 도표에서는 길이가 짧은 막대가 더 빠른 시간을 나타내기 때문에 짧은 막대가 더 좋은 것이다.)

이러한 결과에서는 Metro 1.5와 Axis2 1.5.1 사이의 이전 비교와는 다른 흥미로운 차이점을 몇 가지 보여 준다. 시간을 보면 적어도 테스트 애플리케이션에서 사용하는 데이터의 경우 Metro 2.0이 요청별 처리에서 Axis2와 CXF보다 빠르다. XML로(부터)의 데이터 변환에서는 세 스택 모두 거의 동일한 속도로 실행된다. Metro와 CXF는 둘 다 변환을 위해 JAXB 참조 구현을 사용하기 때문에 이 둘의 경우에도 이러한 사항이 예상된다. 이러한 결과로 미루어 보아 기본 Axis2와 함께 기본적으로 사용되는 Axis2 데이터 바인딩 프레임워크(ADB) 바인딩 구현은 JAXB와 비슷한 속도로 실행된다.

위로

WS-Security를 사용한 경우의 성능

다음 그림에서는 다음과 같은 보안 구성에 대한 테스트 시간을 보여 준다.

• plain: 보안을 사용하지 않음(그림 1과 동일한 값)
• username: WS-Security 일반 텍스트(요청 시 UsernameToken)
• sign: 시간소인으로 본문과 헤더의 WS-Security 서명
• signencr: 시간소인으로 포함된 본문과 헤더의 WS-Security 서명 및 본문의 암호화

그림 2에서는 응답 수가 적은 1,000개의 요청에 대해 측정된 테스트 시간을 보여 준다.

그림 3에서는 응답 수가 적은 동일한 1,000개의 요청에 대한 상대적인 시간(CXF 결과로 정규화됨)을 보여 준다.

Axis2는 이 테스트 케이스의 모든 보안 구성에서 일관되게 가장 느린 스택이다. Metro는 일관되게 가장 빠르지만 Metro와 CXF 사이의 차이는 CXF와 Axis2 사이의 차이보다 훨씬 적다. Metro는 서로 다른 보안 구성에서 CXF보다 약 10퍼센트 빠르지만 Axis2는 CXF보다 두 배 이상 느리다.

그림 4에서는 응답 수가 많은 100개의 요청에 대해 측정된 테스트 시간을 보여 준다.

그림 5에서는 응답 수가 많은 동일한 100개의 요청에 대한 상대적인 시간(CXF 결과로 정규화됨)을 보여 준다.

이 두 번째 테스트의 경우에도 Axis2는 Metro와 CXF보다 훨씬(CXF 속도의 약 절반) 느리며 소량 응답 메시지에서 Metro와 CXF 사이의 차이는 반대로 CXF가 전반적으로 약 15퍼센트 더 빠르다.

CXF 2.1.7 대 2.1.6

이러한 테스트 시간은 CXF 버전 2.1.6과 2.1.7 사이의 현저한 성능 개선을 반영한다. 코드 조정이 부분적으로 도움이 되기는 하지만 이러한 성능 개선은 상당 부분 "WS-Security with CXF"에서 설명한 문제점에 대한 수정사항 덕분이다. CXF 2.1.6은 <sp:TransportBinding> 정책이나 암호화 또는 서명 정책의 일정 양식이 제공되지 않은 경우에는 UsernameToken WS-SecurityPolicy 구성을 처리하지 않았다. 일반적으로 이렇게 추가된 정책은 UsernameToken이 사용될 때 존재한다. 전송 레벨 또는 메시지 레벨 암호화 없이 사용자 이름 및 비밀번호를 전송 중에 관찰할 수 있기 때문에 특히 일반 텍스트 UsernameToken이 사용될 때 존재한다. 하지만 정책의 관점에서는 이 기사의 사용자 이름 구성에 있는 것과 같이 자체적으로 UsernameToken을 사용하는 것이 완전히 유효하며 CXF 2.1.7을 위해 구현된 수정사항이 이 경우를 처리한다. 수정사항의 일부로 CXF 2.1.7은 이 특정 경우의 응답 메시지 플로우에 WS-Security 처리를 추가하는 것을 건너뛴다.

사용자 이름 구성의 메시지 플로우에서 WS-Security가 제거됨으로써 CXF 2.1.6을 사용하여 실행된 동일한 테스트와 비교하여 전반적으로 일정 비율만큼 CXF의 결과가 개선되었다. 버전 사이의 이러한 개선은 안타깝게도 인위적인 면이 있다. 사용자 이름 테스트 케이스에서 전송 레벨 또는 메시지 레벨 암호화를 사용한 경우 WS-Security 처리가 응답 메시지 플로우에서 수행되어 해당 구성에 대한 CXF 시간 결과가 현저히 느려진다. 향후 CXF 버전에서는 필요한 경우에만 요청 또는 응답 메시지 플로우에서 WS-Security가 구성되도록 정책 분석을 확장하여 성능상 혜택을 더 넓은 범위의 유스 케이스(한 방향으로만 서명 또는 암호화가 필요한 유스 케이스 포함)까지 확장할 수 있기를 바란다.

위로

결론

이 기사에서 보고된 테스트 시간에 따르면 Metro 2.0이 Axis2 1.5.1 또는 CXF 2.1.7보다 기본적인 요청/응답 처리 속도가 빠르다. 하지만 WS-Security 처리의 경우에는 Metro의 XWSS 라이브러리가 Axis2와 CXF 모두에서 사용되는 WSS4J 라이브러리보다 전반적으로 빠르지 않다.

이러한 결과에서 가장 흥미로운 부분은 Axis2에 대한 의미이다. 이전 테스트에서는 WS-Security 처리에 있어서는 Axis2가 Metro보다 훨씬 느리다는 것을 보여줬다. 이러한 테스트 결과는 WS-Security 구현 코드 때문에 차이가 발생한 것이 아님을 보여 주므로 Axis2(및 Rampart 보안 모듈)가 WSS4J로(부터) 전달되는 메시지를 처리하는 방식이 이러한 차이의 원인이어야 한다. 이를 통해 "Metro vs. Axis2 performance"에서 설명한 결과를 확인한다. 또한 Axis2가 테스트를 실행하는 데는 다른 스택보다 훨씬 더 많은 메모리가 필요하다(특히 signenecr 구성의 경우 CXF는 48MB로도 충분히 실행되지만 Axis2는 클라이언트에 약 80MB의 메모리가 필요함). 이러한 문제는 Axis2가 WS-Security 처리의 일부로 서로 다른 메시지 표시 사이에서 불필요한 변환을 수행하면서 처리 시간과 메모리를 소모한다는 이전의 인상을 강화시킨다.

테스트한 모든 스택에 대해 WS-Security 서명 및 암호화 사용 시 성능 오버헤드는 상당한 수준이다. 이 오버헤드는 사용량이 많은 서비스의 경우에는 문제가 될 수 있다. 다음 기사에서는 클라이언트가 특정 서비스를 광범위하게 사용하는 경우 WS-Security 오버헤드를 줄일 수 있는 WS-Trust 및 WS-SecureConversation 추가 기능에 대해 살펴본다.

위로

다운로드 하십시오

다운로드 방식에 대한 정보

참고자료

• CXF: CXF는 Apache Software Foundation의 오픈 소스 웹 서비스 스택이다.
  
  
• Axis2: Axis 2는 Apache의 또다른 오픈 소스 웹 서비스 스택이다.
  
  
• Metro: Metro는 JAXB 2.x 및 JAX-WS 2.x Java 표준의 최신 참조 구현을 통합하는 오픈 소스 웹 서비스 스택이다.
  
  
• WSS4J: WSS4J는 WS-Security 처리를 위해 Axis2와 CXF에서 사용하는 Apache Software Foundation에서 나온 WS-Security의 오픈 소스 구현이다.
  
  
• XWSS: XWSS는 WS-SecurityPolicy 처리를 수행하는 Metro 컴포넌트이다.
  
  
• 웹 서비스 스펙 이해하기: 이 튜토리얼 시리즈는 많은 중요한 웹 서비스 표준을 다음과 같이 소개한다.
  • "Understanding Web Services specifications: WSDL(Web Services Description Language)"(Nicholas Chase저, developerWorks, 2006년 7월)
  • "Understanding Web Services specifications: WS-Security"(Nicholas Chase저, developerWorks, 2006년 8월)
  • "웹 서비스 스팩 이해하기: WS-Policy"(Tyler Anderson저, developerWorks, 2007년 2월).
  
  
• OASIS WSS(Web Services Security) TC: 이는 WS-Security 스펙 및 토큰 프로파일에 대한 책임을 맡고 있는 조직이다. 여기에서 이러한 표준의 모든 버전에 대한 링크를 찾을 수 있다.
  
  
• The W3C Web Services Policy Working Group: 이 그룹은 WS-Policy 스펙을 정의한다.
  
  
• OASIS WS-SX(Web Services Secure Exchange) TC: 이는 WS-SecurityPolicy와 관련 스펙에 대한 책임을 맡고 있는 조직이다.
  
  

필자소개

Dennis Sosnoski는 Java 기반 XML 및 웹 서비스를 전문으로 하는 컨설턴트 및 트레이너이다. 30년 이상의 전문 소프트웨어 개발 경력을 가지고 있으며 최근 10여년 동안에는 서버 측 XML 및 Java 기술에 주력하고 있다. 오픈 소스 JiBX XML 데이터 바인딩 프레임워크 및 연관된 JiBX/WS 웹 서비스 프레임워크의 책임 개발자이자 Apache Axis2 웹 서비스 프레임워크 개발에도 참여하고 있다. JAX-WS 2.0 및 JAXB 2.0 스펙의 전문가 그룹에도 참여했다. Java 웹 서비스 시리즈의 자료는 Dennis의 강의 자료를 바탕으로 한다.

아티클 순위

의견

위로

목차

• 성능 살펴보기
• WS-Security를 사용하지 않은 경우의 성능
• WS-Security를 사용한 경우의 성능
• 결론
• 다운로드 하십시오
• 참고자료
• 필자소개
• 의견