test

Sun Java System Message Queue 3.7 UR1 관리 설명서

성능에 영향을 미치는 메시지 서비스 요소

메시징 응용 프로그램의 성능은 응용 프로그램 설계뿐만 아니라 메시지 라우팅 및 전달을 수행하는 메시지 서비스의 영향도 받습니다.

다음 절에서는 성능에 영향을 미칠 수 있는 여러 메시지 서비스 요소를 설명합니다. 이러한 요소의 영향을 이해하는 것은 메시지 서비스 크기를 지정하고 배포된 응용 프로그램에서 발생할 수 있는 성능 병목 현상을 진단하고 해결하는 데 중요합니다.

Message Queue 서비스에서 성능에 영향을 미치는 가장 중요한 요소는 다음과 같습니다.

아래의 절에서는 이러한 각 요소가 메시징 성능에 미치는 영향을 설명합니다.

하드웨어

Message Queue 브로커나 클라이언트 응용 프로그램 모두 CPU 처리 속도와 사용 가능한 메모리가 메시지 서비스 성능의 주요 결정 요소입니다. 처리량을 높이면 많은 소프트웨어 제한 사항을 제거할 수 있고 메모리를 추가하면 처리 속도와 용량을 모두 늘릴 수 있습니다. 그러나 일반적으로 하드웨어 업그레이드만으로 병목 현상을 극복하려면 비용이 많이 듭니다.

운영 체제

하드웨어 플랫폼이 같은 경우라도 각기 다른 운영 체제의 효율성으로 인해 성능은 다양할 수 있습니다. 예를 들어, 운영 체제에서 사용하는 스레드 모델은 브로커가 지원할 수 있는 동시 연결 수에 중요한 영향을 미칠 수 있습니다. 일반적으로 모든 하드웨어가 동일한 경우 Solaris가 Linux보다 빠르며 Linux가 Windows보다 빠릅니다.

Java 가상 머신(JVM)

브로커는 호스트 JVM에서 실행되고 지원되는 Java 프로세스입니다. 결과적으로 JVM 처리는 브로커가 얼마나 빠르고 효율적으로 메시지를 라우팅하고 전달할 수 있는지 결정하는 중요 요소입니다.

특히 JVM의 메모리 자원 관리는 중요할 수 있습니다. 메모리 로드 증가를 수용하기 위해 충분한 메모리를 JVM에 할당해야 합니다. 또한 JVM은 주기적으로 사용되지 않은 메모리를 재생 이용하며 이러한 메모리 재생 이용은 메시지 처리를 지연시킬 수 있습니다. JVM 메모리 힙이 클수록 메모리 재생 이용 중에 경험할 수 있는 잠재적 지연은 더 길어집니다.

연결

클라이언트와 브로커간 연결의 수와 속도는 메시지 서비스가 처리할 수 있는 메시지 수와 메시지 전달 속도에 영향을 미칠 수 있습니다.

브로커 연결 제한

브로커에 대한 모든 액세스는 연결을 통해서 이루어집니다. 동시 연결 수에 대한 제한은 브로커를 동시에 사용할 수 있는 생성자나 사용자 클라이언트 수에 영향을 미칠 수 있습니다.

일반적으로 브로커에 대한 연결 수는 사용 가능한 스레드 수에 의해 제한됩니다. 전용 스레드 모델이나 공유 스레드 모델 중 하나를 지원하도록 Message Queue를 구성할 수 있습니다( 스레드 풀 관리 참조).

전용 스레드 모델은 각 연결이 전용 스레드를 가지므로 아주 빠르지만 연결 수가 사용 가능한 스레드 수에 의해 제한됩니다(연결당 하나의 입력 스레드와 하나의 출력 스레드 필요). 공유 스레드 모델은 연결 수에 대한 제한이 없지만 많은 연결 사이에서 스레드를 공유하며 이러한 연결이 사용 중인 경우에는 상당한 오버헤드와 처리량 지연이 발생합니다.

전송 프로토콜

Message Queue 소프트웨어를 사용하면 클라이언트가 다양한 저급 전송 프로토콜을 사용하여 브로커와 통신할 수 있습니다. Message Queue는 연결 서비스에 설명된 연결 서비스와 해당 프로토콜을 지원합니다.

프로토콜은 응용 프로그램 요구 사항(암호화, 방화벽을 통한 액세스 가능)을 기반으로 선택하지만 이 선택은 전체 성능에 영향을 미칩니다.

그림 11–2 전송 프로토콜 속도

여러 전송 프로토콜의 상대 속도를 보여 주는 다이어그램. 결과는 텍스트에 설명되어 있습니다.

테스트를 통해 높은 안정성 시나리오(영구 가입이 있고 AUTO_ACKNOWLEDGE 확인 모드를 사용하는 주제 대상에 1k의 지속성 메시지를 보냄)와 높은 성능 시나리오(영구 가입이 없고 DUPS_OK_ACKNOWLEDGE 확인 모드를 사용하는 주제 대상에 1k의 비지속성 메시지를 보냄)의 두 가지 경우에 대해 TCP와 SSL의 처리량을 비교했습니다.

일반적으로 프로토콜은 높은 안정성 사례에서 미치는 영향이 더 적습니다. 이는 아마도 높은 안정성 사례에서 필요한 지속성 오버헤드가 처리량을 제한하는 데 프로토콜 속도보다 더 중요한 요소이기 때문일 것입니다. 또는

메시지 서비스 구조

Message Queue 메시지 서비스는 단일 브로커로 구현되거나 다중 상호 연결 브로커 인스턴스로 구성된 클러스터로 구현될 수 있습니다.

브로커에 연결된 클라이언트 수가 늘어나고 전달되는 메시지 수가 늘어나면 파일 설명자, 스레드, 메모리 제한 같은 브로커의 자원 제한 사항이 초과하게 됩니다. 늘어나는 로드를 수용하는 한 가지 방법은 Message Queue 메시지 서비스에 브로커 인스턴스를 추가하여 클라이언트 연결과 메시지 라우팅 및 전달을 여러 브로커에 걸쳐 분산시키는 것입니다.

일반적으로 이러한 확장은 클라이언트, 특히 메시지 생성자 클라이언트가 클러스터 전체에 균등하게 분산되어 있는 경우에 가장 잘 작동합니다. 클러스터에 있는 브로커 사이의 메시지 전달과 관련된 오버헤드로 인해 제한된 연결 수나 메시지 전달 비율을 갖는 클러스터는 단일 브로커보다 더 낮은 성능을 보일 수 있습니다.

또한 브로커 클러스터를 사용하여 네트워크 대역폭을 최적화할 수 있습니다. 예를 들어, 클러스터 내의 원격 브로커들 사이에는 느린 장거리 네트워크 링크를 사용하고 클라이언트와 해당 브로커 인스턴스의 연결에는 고속 링크를 사용할 수 있습니다.

클러스터에 대한 자세한 내용은 9 장, 브로커 클러스터 작업을 참조하십시오.

브로커 제한 및 동작

브로커가 처리해야 하는 메시지 처리량은 브로커가 지원하는 메시징 응용 프로그램의 사용 패턴에 달려 있습니다. 하지만 브로커는 메모리, CPU 사이클 등 자원이 제한되어 있습니다. 따라서 브로커가 넘치게 되어 응답하지 않거나 불안정하게 될 수 있습니다.

Message Queue 메시지 브로커에는 메모리 자원을 관리하고 브로커의 메모리 부족을 방지하기 위해 기본적으로 제공되는 메커니즘이 있습니다. 이러한 메커니즘은 브로커나 개별 물리적 대상이 보유할 수 있는 메시지 수나 메시지 바이트에 대한 구성 가능한 제한을 포함하며 물리적 대상 제한에 이르면 시작될 수 있는 동작 집합을 포함합니다.

이러한 구성 가능한 메커니즘은 세밀하게 모니터하고 조정하면 메시지 유입과 유출의 균형을 유지하여 시스템 과부하가 발생할 수 없도록 하는 데 사용할 수 있습니다. 이 메커니즘은 오버헤드를 사용하고 메시지 처리량을 제한하는 단점이 있지만 운영 무결성을 유지할 수 있습니다.

데이터 저장소 성능

Message Queue는 파일 기반 및 JDBC 기반 지속성 모듈을 모두 지원합니다. 파일 기반 지속성에서는 개별 파일을 사용하여 영구 데이터를 저장합니다. JDBC 기반 지속성은 JDBC™(Java Database Connectivity) 인터페이스를 사용하고 JDBC 호환 데이터 저장소가 필요합니다. 일반적으로 파일 기반 지속성은 JDBC 기반보다 빠르지만, JDBC 호환 저장소가 제공하는 중복 및 관리 제어 기능을 선호하는 사용자도 있습니다.

파일 기반 지속성의 경우 지속성 작업이 메모리 상태에서 데이터 저장소와 동기화되도록 지정하여 안정성을 최대화할 수 있습니다. 이렇게 하면 시스템 중단으로 인한 데이터 손실을 방지할 수 있지만 성능은 저하됩니다.

클라이언트 런타임 구성

Message Queue 클라이언트 런타임은 클라이언트 응용 프로그램에 Message Queue 메시지 서비스에 대한 인터페이스를 제공합니다. 이 클라이언트 런타임은 클라이언트가 물리적 대상에게 메시지를 보내고 대상으로부터 메시지를 받는 데 필요한 모든 작업을 지원합니다. 연결 팩토리 속성 값을 설정하여 클러이언트 런타임을 구성할 수 있으므로 연결 흐름 측정, 사용자 흐름 제한 및 연결 흐름 제한과 같은 다양한 동작 측면을 제어하여 성능 및 메시지 처리량을 향상시킬 수 있습니다. 이러한 기능과 기능을 구성하는 데 사용되는 속성에 대한 자세한 내용은 클라이언트 런타임 메시지 흐름 조정을 참조하십시오.