Socket, RMI및 JMS를 이용한 통신 프로그램의 성능 비교..

2004년도에 작성한 자료네요. 이런 테스트 결과가 어떻게 논문감인지 살짝 의구심이 들지만, 좋은 내용이다.

情報通信 論文紙 第 8 輯 (2004)

Journal of Telecommunications and Information, Vol. 8, 2004.

Socket, RMI및 JMS를 이용한 통신 프로그램의 성능 비교

강 동 현*, 김 화 종**

Performance Comparison between

 Network Program Using Socket, RMI, JMS

Dong-Hyun Kang*, Hwa-Jong Kim**

Abstract

This
paper compares the performances among network programs using Socket,
RMI(Remote Method Invocation) and JMS(Java Message Service). Socket is
used for data transmission and RMI is used in distributed computing
environment by invoking method running on remote computer. JMS  supports
message-based middleware. Even if there are basic different between the
methods, this paper presents guidline for programmers to select
appropriate method to implement proper network program.

    <Keywords : JMS, Socket, RMI>

I. 서 론1)

일반적인 네트워크 통신은 다른 모든 기술의 기반이 되는 네임드 파이프나 TCP/IP 소켓 등이 사용된다. 이러한 로우 레벨 기술을
사용하여 애플리케이션 간의 통신을 수행하기 위해서 개발자는 상대방 네트워크의 상태를 관리하고, 메시지를 처리하는 최선의 방법을 결정하기 위해 많은 노력을 기울여야 한다.

본 논문에서는 엔터프라이즈 메시징 환경을 구축하기 위한 방법으로 자바의 Socket, RMI 및 JMS로 구현할때 각 방식이
제공하고 있는 기본적인 특성 및 고유 기능에는 차이가 있으나 이들을 이용하는 클라이언트-서버 통신 프로그램의 수용 용량, 서비스 처리시간 등의 성능 비교함으로써 엔터프라이즈 환경을 구축할 때 어떤 방식이 유리할지를 선택하는 기준을 제공하고자 한다.


논문의 구성은 2장에서는 성능측정을 위한 전반적인 기술을 소개하고, 3장에서는 성능 측정 및 분석 방법으로 성능 측정 방법을
설명하고 4장에서는  성능 비교를 통한 실제 결과값을 보인다. 5장에서는 성능에 따른 문제점과 보안점을 제시한다.

II. 관련기술

2.1 엔터프라이즈 시스템 구조

엔터프라이즈 메시징에서 통신하는 애플리케이션이 많아질수록 애플리케이션간의 연결이 많아질 것이다. 그림 1 은 복잡한 애플리케이션 간의 상관관계를 보여준다. 각 화살표는 각 애플리케이션의 목적지의 집합을 나타낸다.

그림 1. 엔터프라이즈 애플리케이션 구성도

엔터프라이즈 메시징 애플리케이션은 각각의 애플리케이션과 연결을 생성해야 한다. 새로운 애플리케이션을 생성하면, 새로 생성된 애플리케이션과 통신 하기위해 기존의 애플리케이션을 변경해야 하는 문제점이 있다. 이러한 문제점을 해결할 수 있는 방법으로 Hub ans Spoke 구조를 사용할 수 있다. 이 구조에서는 메시지 브로커(Message Mboker) 또는 메시지
서버(Message Server) 라고 불리는 중계 애플리케이션을 정의한다. 메시지 브로커는 모든 애플리케이션의 목적지가 되고
메시지 내의 정보를 사용하여 해당하는 대상 애플리케이션들에게 메시지를 라우트한다. 그림 2 는 메시지 브로커의 구성도를 보여주고 있다.

그림 2. 메시지 브로커 구성도

2.2 Socket

 소켓은 소프트웨어로 작성된 통신 접속점이라고 할 수 있는데 네트워크 응용 프로그램은 소켓을 통하여 통신망으로 IP 패킷을 송수신하게 된다[1]. 자바에서도 유닉스 소켓(socket) 또는 윈도우 소켓(Winsock)과 같은 소켓 프로그래밍 인터페이스를
지원한다. 소켓 관련 클래스는 java.net 패키지가 제공하는데 연결형 서비스(TCP)를 위하여 Socket과
ServerSocket 클래스가 있으며, 비연결형 서비스(UDP)를 위하여 DatagramSocket과
DatagramPacket이 정의되어 있다.

2.3 RMI(Remote Method Invocation)

네트워크에서 분산 작업을 처리하기 위해  RPC(Rtmote Procedure Call)가 널리 사용된다. RMI 프로그램에서는
서버는 원격 객체에 잘 알려진 부팅 레지스트리와 함께 스텁을 등록하게 되고 클라이언트는 잘 알려진 부팅 레지스트리를 통해서 서버 객체(스텁)의 첫 참조를 얻는다. 클라이언트는 이제 스텁을 통해서 서버와 통신할 수 있다. 통신이 되면 레지스트리는 더 이상
필요하지 않다.

 그림 3 RMI가 동작하는 전체 흐름을 보여주고 있다

그림 3. RMI 프로그램 동작 다이어그램

2.4 JMS

JMS(Java MessageService)는 자바로 개발된 MOM(Message-Oriented Middleware) 벤더와 DB개발 업체
그리고 인터넷 관련 업체가 메시징 기반 제품을 사용하는데 접근하기 위한 공통의 자바 API를 제공하기 위해 만들어 졌다.
MOM(Message Oriented Middleware)이란 메시지 기반 미들웨어로서 메시징시스템을 비즈니시 시스템에 적용했을때
엔터프라이즈 메시지 시스템 또는 메시지 기반 미들웨어라고 한다.

메시징 제품은 Point-to-Point(이하 PTP) 또는 Publish/Subscribe(이하 pub/sub)으로 구분하며
PTP는 메시지 큐(Queue)에 관한 개념이며 각각의 메시지가 큐로 전달하면 메시지를 수신하는 클라이언트가  큐로부터 메시지를
수신하는 동작원리를 가지고 있다. Pub/Sub는 다수의 메시지 생성자가 토픽(Topic)으로 전달하여 다수의 메시지 소비자에게
메시지를 전달하는 메시지 모델이다.

JMS는 인터페이스를 구현하고 관리와 제어 기능을 제공하는 메시징 시스템을 JMS 제공자(Provider)라고 한다. 메시지
클라이언트는 JMS 클라이언트와 비 JMS 클라이언트로 나눌수 있다. JMS 클라이언트는 자바 언어로 작성하고, JMS API를
사용하여 메시지를 보내고 받는 프로그램이다. 프로그래밍 언어에 상관없이 다른 프로그램은 비-JMS 클라이언트이다. 두 종류의
클라이언트는 서로 통신할 수 있다.

JMS가 사용하고 있는 관리객체와 인터페이스 개발순서를 보면 관리객체는 시스템 관리자가 생성하는 객체로서 JMS
Configuration Information을 포함하는 객체를 말하고 이 객체는 클라이언트가 사용하는데 관리자는 이 객체를
네이밍 서비스의 네임스페이스(JNDI1))내에 둔다.

III. 성능 측정 및 분석

 이 장에서는 엔터프라이즈 환경을 구성하는 시스템 구조와 엔터프라이즈 메시징 환경에서의 애플리케이션들 사이의 통신을 수행하는 방법인 보통 네트워크, RPC 및 MOM을 사용하는 방식에서 클라이언트-서버의 환경의 최대 수용용량, 클라이언트 수에 따른 서비스 처리시간, 메시지 크기에 따른 서비스 처리시간을 한 클라이언트가 다른 전체 클라이언트에게 전체 발송하는 Broadcast 방식과 클라이언트와 서버가 통신하는 Echo 방식으로 나누어 테스트하였다.

3.1 서버의 최대 수용 용량

소켓, RMI 및 JMS의 클라이언트-서버 모델로 구성하여 서버가 받아 들일 수 있는 최대 수용용량을 측정 하였다. 최대 수용 용량 측정시 클라이언트가 다른 클라이언트에게 메시지를 보내는 boradcast 방식으로 측정하였다.

3.2 메시지 변동량에 따른 성능 비교

클라이언트와 서버 사이의 통신 성능 측정에서 클라이언트 연결 수와 전송할 메시지의 수를 증가시켜 가면서 통신 성능 상태를
측정하였다. 소켓, RMI 및 JMS는 같은 방법으로 프로그램되었으며 Broadcast 방식과 Echo 방식으로 나누어
테스트하였다.

3.3 메시지 크기에 따른 성능 비교

클라이언트-서버 사이에 주고 받는 메시지 크기를 변동하여 그에 따른 클라이언트수와 메시지 변동량 사이의 송수신 시간을 측정 하였다. 메시지 크기에 따른 송수신 시간을 측정하는 것은 소켓, RMI및 JMS에서 Boadcast 방식과 Echo 방식으로
테스트하였다.

IV. 통신 프로그램의 성능 비교

소켓, RMI 및 JMS를 클라이언트-서버로 구성하여 최대 클라이언트 수용용량, 서비스 처리시간, 메시지에 따른 서비스 처리 시간을 brocast 방식과 echo 방식으로 성능 비교를 하였다.

4.1 데이터 전송 속도

소켓, RMI 및 JMS를 서버와 클라이언트로 구성하여 메시지를 서버에 보내고 다시 그 데이터를 받는 작업을 반복해서 실행하고
반복횟수를 증가시키며 전송시간을 측정한다. 표 5 는 전송 속도 측정 결과 이다. 그림 4에서 보듯 데이터를 전송하는 방식에서는
Socket방식이 데이터를 전송하는데 가장 좋은 성능을 나타냄을 알 수 있다.


표 5. 데이터 전송 속도 측정 결과

횟수

100

200

300

400

500

600

700

800

900

소켓

(sec)

0.031

0.032

0.047

0.062

0.063

0.078

0.078

0.094

0.109

RMI

(sec)

0.22

0.422

0.614

0.846

1.00

1.14

1.338

1.594

1.719

JMS

(sec)

0.843

1.203

1.472

1.905

2.243

2.515

2.853

3.343

3.625

 


그림 4. 데이터 전송 속도 비교

데이터 전송 측정 시간결과 소켓이 가장 좋은 성능을 보이고 있음을 알 수 있다. RMI는 내부적으로 TCP/IP 상에서 소켓을
이용하는 분산 시스템이다[4].  RMI와 JMS의 차이점은 RMI에서 객체는 임의의 장소에 상주하고 가상머신의 범주내에 있다.
반면 JMS 에서의 메시지(객체)는 네트워크를 통해서 물리적으로 한 JVM에서 다른 JVM으로 비동기적으로 돌아 다닌다.

4.2 최대 클라이언트 수용용량

소켓, RMI 및 JMS를 서버와 클라이언트로 구성하여 하나의 서버가 수용할 수 있는 최대 수용용량을 측정하기 위해 클라이언트의
수를 증가시켜 최대 클라이언트를 수를 측정하였으며, 각 클라이언트는 전체 메시지 발송을 하게 하여 클라이언트 증가에 따른 메시지 전송 속도도 함께 측정하였다.

표 6. 최대 클라이언트 수용용량

방식/횟수

100

300

500

700

900

 Socket Client(sec)

0.594

3.235

9.110

17.125

29.891

 RMI Client(sec)

4.62

30.672

80.734

160.953

160.953

 JMS Client(sec)

9.484

69.672

197.797

417.625

697.767

 


그림 5. 최대 연결수에 따른 연결 시간

표 6 과 그림 5의 측정 결과는 한계를 900 까지 정해 놓고 동일한 조건상의 시간을 나타낸 것이다.  최대 수용용량에 관한
테스트 결과 최대 연결부분에서는 소켓이 1250개의 연결을 지원하고 있으며 서버와 클라이언트의 송수신에 걸리는 차이는 네트웍상의 속도에 따라 미묘한 차이가 있다.

RMI는 최대 연결부분에서는 1300까지 측정하였으나 그 이상의 측정은 하지 않았다. RMI는 원격 메소드를 호출하는 구조로서 스레드의 사용이 없고 메모리 사용량이 적어 다른 방식에 비해 많은 연결을 지원하고 있다.

JMS
는 최대 900개의 연결을 할 수 있으나 테스트에 사용된 웹 로직 6.0이 j2sdk1.4와의 버그로 생기는 메모리 누수로 인해 그
이상의 연결시도나 메시지 전송시 서버가 다운되었다.  JMS의 경우 클라이언트의 메시지를 서버가 다시 채널에 등록하는 시간은
다른 방식보다 좋다. 하지만 클라이언트의 수신시간은 한

PC 상에서 많은 클라이언트를 동작시키기 위해 Thread를 사용하였고 웹 로직에 접근하는 수신 대기 시간이 길어져 많은 차이가 발생하였다.

4.3 클라이언트의 수와 메시지 전송량

소켓, RMI 및 JMS를 서버와 클라이언트로 구성하여 클라이언트 수와 메시지의 수를 증가시켜 전송량에 따른 서비스 시간을
측정하였다. 전송량에 따른 성능비교는 broadcast 방식과 Echo 방식 두가지로 나누어 하였다. 표 7은 Broadcast
방식에서의 클라이언트수와 메시지 전송량에 대한 성능 비교이고,  표 8 은 Echo 방식에서의 클라이언트수와 메시지 전송량에 대한 성능 비교 표이다.


표 7. broadcast방식의 연결수와 메시지 전송량의 성능비교

Socket

클라이언트수

메시지수

시간(sec)

100

10

3.39

100

35.718

300

104.203

300

10

29.938

100

305.734

300

961.86

500

10

86.046

100

866.688

300

2587.656

 

RMI

클라이언트수

메시지수

시간(sec)

100

10

36.031

100

336.734

300

1056.766

300

10

305.671

100

3042.032

300

9086.485

500

10

836.922

100

8963.516

300

25455.72

JMS

클라이언트수

메시지수

시간(sec)

100

10

8.828

100

915.859

300

3147.577

300

10

978.500

100

에러 

300

에러

500

10

에러

100

에러

300

에러

 

클라이언트 수와 메시지 전송량에 대한 비교로 보았을때 broadcast 방식은 적은 수의 클라이언트가 많은 양의 전송량을 보내는
것이 유리하고  Echo 방식에서는 또한 적은 수의 클라이언트가 많은 양의 전송량을 보내는 것이 조금더 성능이 좋아 지는 것을
보였다. 표에는 작성되지 않았지만 broadcast 방식에서나 Echo 방식에서의 소켓은 서버가 보내는 시간이나 클라이언트들중
처음 보내는 클라이언트나 마지막으로 메시지를 보내는 클라이언트나 속도 차이는 없다. 하지만 RMI 경우 Echo 방식에서는 차이가 없었으나 broadcast 방식에서는 클라이언트들중 처음 보내는 클라이언트가 가장 오랜시간 동안 대기하여 메시지를 전송받고
마지막으로 보낸 클라이언트가 가장 짦은 수신 시간을 얻었다. 이것은 소켓은 tm레드를 통한 평균적인 수신시간을 얻지만 RMI의
경우 서버의 객체가 동작을 완료할 때까지 대기 해야 되는 문제점이 발생하게  된다.

4.4  메시지 크기에 따른 성능 비교

소켓, RMI 및 JMS를 서버와 클라이언트로 구성하여 클라이언트 수와 메시지의 크기를 증가시켜 전송량에 따른 서비스 시간을
Echo 방식으로 측정하였다.  표 9 는 각 방식에서 하나의 클라이언트가 서버에게 1000개의 메세지 송수신 하는데 각 메시지의
크기를 1000byte씩 증가시켜 각각에 걸리는 시간을 측정한 표이다.

표 9 . 메시지 크기에 따른 성능 비교

크기

1000

2000

3000

4000

5000

socket

400

520

640

760

890

RMI

1920

2040

2400

2530

2954

JMS

3750

4109

4640

5047

6062

 

크기

6000

7000

8000

9000

10000

Socket

1016

1125

1250

1359

1485

RMI

3078

3350

3530

4047

4203

JMS

6375

6468

6938

8437

8853

 

그림 6 은 메시지 크기에 따른 성능 비교를 나타내고 있다. 서버에게 하나의 클라이언트가 1000개의 메시지를 전송시 각 메시지를
1000byte씩 증가 시키는데에 따른 각 방식의 시간을(ms) 비교한 그림이다. 메시지의 크기에 따른 전송 성능 역시 소켓이
가장 뛰어남을 볼 수 있다.

그림 6. 메시지 크기에 따른 성능 비교

V. 결 론

본 논문에서는 엔터프라이즈 메시징 환경을 구축하기 위한 방법으로 자바의 Socket, RMI 및 JMS를 각각 사용할 때
클라이언트-서버 통신 프로그램의 수용 용량, 서비스 처리시간 등의 성능 비교함으로써 엔터프라이즈 환경을 구축할 때 어떤 방식이 유리할지를 선택하는 기준을 제공하였다.

각 프로그램 방식의 장점과 단점을 보고 성능을 비교하므로써 엔터프라이즈 환경을 구축시에 서버와 클라이언트의 연결 수와 메시지의 전송량에 따른 성능을 보기 위해 본 논문을 작성 하였다.

서비스 처리시간에서는 Socket이 가장 우수 하였다.RMI와 JMS방식은 내부적으로 TCP/IP의 소켓을 사용하고 있으므로
Broadcast나 Echo로 테스트한 클라이언트의 증가량에 따른 메시지 처리시간, 클라이언트와 메시지의 증가량에 대한 처리시간
메시지의 크기에 대한 처리시간 모두 소켓보다 낮은 성능을 내고 있다.

각 방식으로 엔터프라이즈 환경을 구축할 때 프로그램의 편리성과 좀더 유동적인 환경에서는 RMI와 JMS가 소켓자체를 작성하지 않기 때문에 편리하고 좀더 유동적인 환경과 상대적으로 쉬운 유지보수를 할 수 있다. 본 논문에서는 성능만을 측정하였으나 실제
엔터프라이즈 환경을 구축할시 고려해야 할 중요한 부분이다. 

MOM의 호환성 문제를 해결하기 위해 JMS를 측정한 결과에서 서비스 처리시간, 수용용량 모두 낮은 성능을 나타내고 있다. 이것은 J2SDK1.4  버전과 웹 로직 6.0의 버그로 인한 문제점으로 밝혀져 웹 로직7.0과 서비스 팩을 확장하였으나 높은
CPU사용과 메모리 점유율로 인해 서버의 기능을 제대로 하지 못하였다. 웹 어플리케이션 서버의 장점인 다양한 미들웨어 제품에 대한 서비스처리를 할 수 있는 장점에 비해 JMS처럼 특정 부분에 대한 서비스 처리는 낮은 것으로 나왔다.

앞으로의 연구과제는 웹로직의 문제점을 해결하기 위해  JMS의 최신 스펙을 지원하고 안정된 서비스를 지원하는 SwiftMQ, SpirtWave, SonicMQ등의 제품을 사용하여 JMS에 대한 성능을 정확히 측정하는 것이다.

참고 문헌

[1] 김화종 저, “컴퓨터 네트워크 프로그래밍”, 홍릉과학출판사, 2000

[2] Chad Darby, “Beginning Java Networking”, wrox, 2002

[3] Subrahmany Allamaraju, “ProFessional Java Server Programming J2EE 1.3 Edition” wrox, 2002

[4] 박천구, 문창수 저, “Enterprise Java Beans EJB & WebLogic” 가메 출판사, 2001

[5] Ken Arnold, James Gosling, David Holmes, “The Java(TM) Programming Language(3rd Edition)”, Addison-Wesley, June 2002

[6] McGraw-hill, “Java(TM)2 NetWorking”, couch, 2001

[7] JStrom 박지훈 저, “Enterprise JavaBeans”, 대청, 2001[]]

[8] David A, “Java Message Service”, o’reilly , 2000

[9] IBM Developer Home, http://www-903.ibm.com/

[10] The Source for Java Technology

,

* Reference
http://blog.naver.com/an5asis/60022142872

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.