KR100481604B1

KR100481604B1 - 다중 쓰레드 소켓 폴링 서버 시스템

Info

Publication number: KR100481604B1
Application number: KR10-2002-0082392A
Authority: KR
Inventors: 강태근; 손강민; 함호상; 손덕주
Original assignee: 한국전자통신연구원
Priority date: 2002-12-23
Filing date: 2002-12-23
Publication date: 2005-04-08
Also published as: KR20040055920A

Abstract

본 발명은 다중 쓰레드 소켓 폴링 서버 시스템에 관한 것으로, 네트워크를 통해 전달된 하나의 연결 요청에 대해 하나의 클라이언트 소켓을 할당하는 서버소켓 쓰레드와, 서버소켓 쓰레드로부터 인가된 클라이언트 소켓을 저장하는 소켓 풀과, 복수의 쓰레드를 보유하여 클라이언트의 다중 요청을 처리하며 각 쓰레드는 데이터를 갖는 클라이언트 소켓의 요청을 한번만 처리하고 처리 완료 후 소켓 풀로 해당 클라이언트 소켓을 반환하는 쓰레드 풀과, 소켓 풀로부터 데이터를 갖고 있는 클라이언트 소켓을 등록된 순서대로 선택하여 쓰레드 풀의 각 쓰레드에 할당하는 폴링 쓰레드를 포함하며, 복수의 처리 쓰레드를 유지하고 연결 요청시 생성된 소켓을 이들 처리 쓰레드에 할당하여 작업을 수행함으로써, 클라이언트의 연결 요청이 많아지더라도 소켓 처리를 위해 대기할 필요가 없으며, 쓰레드 풀의 용량 보다 더 많은 수의 클라이언트 요청을 처리할 수 있으므로 서버 시스템의 효율성이 향상되는 이점이 있다.

Description

다중 쓰레드 소켓 폴링 서버 시스템{MULTI-THREADED SOCKET POLLING SERVER SYSTEM}

본 발명은 다중 쓰레드 소켓 폴링 서버 시스템에 관한 것으로, 더욱 상세하게는 다중 쓰레드 소켓 폴링 서버 시스템에 관한 것이다.

네트워크를 통해 전달된 다수의 클라이언트로부터 발생한 연결 요청을 동시에 처리해야 하는 고성능 서버 시스템의 성능은 입출력(네트워크 통신)에 많이 의존하게 된다. 즉, 서버 시스템의 중앙처리장치(CPU)는 외부 장치로부터의 입력(소켓 서버의 경우에는 네트워크로부터의 입력)을 기다리며 99.9%의 시간을 공전상태(idle)상태로 놓여있게 되는데 이러한 문제는 서버와 클라이언트간의 대역폭 차이가 클수록 더욱 악화된다.

이러한 서버 시스템에서 클라이언트 연결 요청을 처리하기 위해 생각할 수 있는 방법들 중에는 fork()함수를 이용하여 독립적인 자식 프로세스(child process)를 생성하거나 쓰레드를 이용하여 각각의 클라이언트 연결 요청을 처리하는 방법(이하 "단순 다중 쓰레드 모델"로 명명함)과 단일 쓰레드를 사용하고 소켓의 select() 함수를 활용하여 모든 클라이언트의 요청을 처리하는 방법(이하 "단일 쓰레드 소켓 폴링(socket polling) 모델"로 명명함)이 있다.

도 1은 단순 다중 쓰레드 모델의 구조도이다.

네트워크를 통해 서버소켓 쓰레드(10)에 전달된 하나의 연결 요청에 대해 하나의 클라이언트 소켓(20)이 할당되며, 서버소켓 쓰레드(10)로부터 인가된 클라이언트 소켓(20)은 쓰레드 풀(thread pool)(30)에 저장된다.

쓰레드(35-1, 35-2, 35-3, …, 35-n)는 할당된 클라이언트 소켓(20)으로부터 발생하는 자료의 송수신을 처리하는데, 각 클라이언트 소켓(20)은 전담 쓰레드(35-1, 35-2, 35-3, …, 35-n)에서 처리되므로 완료된 결과는 즉시 클라이언트(40-1, 40-2, 40-3, …, 40-n)로 전송된다.

이러한 단순 다중 쓰레드 모델은 구현이 간단하고 일정 수의 클라이언트로부터 연결 요청에 대해서는 빠른 처리 능력을 보여준다.

반면에, 클라이언트의 연결 수가 증가하면 동일한 수의 쓰레드가 생성되어야 한다. 즉 연결 요청 수가 증가할수록 이에 대한 처리 프로세스 또는 처리 쓰레드가 증가하여 이들의 작업 전환(task switching) 시간과 가상 메모리 할당(virtual memory allocation) 등에 소요되는 작업이 서버 시스템에 부담으로 작용하여 처리 속도가 느려지고 최악의 경우 동작불능 상태가 될 수도 있다. 이러한 문제는 쓰레드 풀(thread pool)을 사용하여 최대 프로세스 수 또는 쓰레드의 수를 조절하여 막을 수 있다.

그러나, 다중 쓰레드 모델의 근본적인 문제점은 클라이언트로부터 데이터가 전송될 때까지 해당 처리 쓰레드는 리소스를 차지하며 아무런 일도 하지 않고 공전(idle) 상태로 있게 됨으로 인해 서버 시스템의 자원이 낭비된다.

도 2는 단일 쓰레드 소켓 폴링 모델의 구조도이다.

네트워크를 통해 서버소켓 쓰레드(10)에 전달된 하나의 연결 요청에 대해 하나의 클라이언트 소켓(20)이 할당되며, 서버소켓 쓰레드(10)로부터 인가된 클라이언트 소켓(20)은 소켓 풀(socket pool)(50)에 저장된다.

단일 처리 쓰레드(60)는 할당된 클라이언트 소켓(20)으로부터 발생하는 자료의 송수신을 처리하는데, 폴링 과정을 통하여 데이터를 갖고 있는 클라이언트 소켓(20)들을 순서대로 선택하고 요청을 처리한 후 소켓 풀(50)에 반환한다.

이러한 단일 쓰레드 소켓 폴링 모델은 쓰레드보다 훨씬 부담이 적은 클라이언트 소켓용 메모리 공간만 증가하게 되므로, 클라이언트의 연결 수가 늘어나는 것에 큰 영향을 받지 않는다. 즉 단일 쓰레드를 사용하기 때문에 쓰레드 관리가 간단하면서 다수의 클라이언트로부터 연결 요청을 수용할 수 있는 장점이 있다.

그러나, 연결 요청하는 클라이언트의 수가 증가할수록 연결 요청에 대한 각각의 소켓이 실제적으로 처리되기 위하여 대기하는 시간이 증가하게 되는데 이것은 처리 쓰레드가 연결 요청된 순서대로 해당 소켓을 처리하기 때문에 발생하는 문제로서 이러한 대기 시간은 클라이언트와 서버간에 주고받는 데이터의 용량에 매우 종속적일 수밖에 없다. 따라서 단일 쓰레드 소켓 폴링 서버를 구현하기 전에 주고받는 데이터 양의 고려가 우선적으로 선행되어야 할 것이다.

또한, select() 함수를 사용하여 서버를 설계하고 구현하는 것이 fork() 함수를 사용하는 다중 프로세스 또는 다중 쓰레드를 이용하는 단순 다중 쓰레드 모델의 구현보다 어렵고 복잡하다는 단점이 있다.

본 발명은 상기와 같은 종래 기술의 문제점을 해결하기 위하여 제안한 것으로서, 복수의 처리 쓰레드를 유지하고 연결 요청시 생성된 소켓을 이들 처리 쓰레드에 동적으로 할당하여 작업을 수행함으로써 단일 쓰레드 모델의 단점을 보완하고 단순한 다중 쓰레드 모델보다 더 나은 성능을 가지도록 한 다중 쓰레드 소켓 폴링 모델을 제공하는 데 그 목적이 있다.

이와 같은 목적을 실현하기 위한 본 발명에 따른 다중 쓰레드 소켓 폴링 서버 시스템은, 네트워크를 통해 전달된 하나의 연결 요청에 대해 하나의 클라이언트 소켓을 할당하는 서버소켓 쓰레드와, 상기 서버소켓 쓰레드로부터 인가된 상기 클라이언트 소켓들을 저장하는 소켓 풀과, 복수의 쓰레드를 보유하여 클라이언트의 다중 요청을 처리하며, 상기 각 쓰레드는 상기 클라이언트 소켓이 할당되면 상기 클라이언트 소켓의 요청을 한번만 처리하고, 상기 처리 완료 후 해당 클라이언트 소켓을 상기 소켓 풀로 반환하는 쓰레드 풀과, 상기 소켓 풀에 저장되어 있는 상기 클라이언트 소켓들을 상기 쓰레드 풀의 복수 쓰레드에 할당하되, 그 할당 순서는 상기 클라이언트 소켓이 상기 소켓 풀에 저장된 순서대로 선택하여 할당하는 폴링 쓰레드를 포함한다.

본 발명의 실시예로는 다수개가 존재할 수 있으며, 이하에서는 첨부한 도면을 참조하여 바람직한 실시예에 대하여 상세히 설명하기로 한다. 이 실시예를 통해 본 발명의 목적, 특징 및 이점들을 보다 잘 이해할 수 있게 된다.

본 발명에 따른 다중 쓰레드 소켓 폴링 모델은 종래의 단순 다중 쓰레드 모델과 단일 쓰레드 소켓 폴링 모델의 장점을 취한 것으로서, 쓰레드 오버헤드 및 서버 시스템의 자원 낭비를 막고, 네트워크 연결 수에 영향을 받지 않으며 서버 시스템의 제한된 자원 요구량에 맞도록 쓰레드 풀의 용량을 제어할 수 있다.

도 3은 본 발명에 따른 다중 쓰레드 소켓 폴링 모델의 구조도이다.

서버소켓 쓰레드(10)로부터 인가된 클라이언트 소켓(20)은 소켓 풀(socket pool)(200)에 저장되며, 폴링 쓰레드(300)는 소켓 풀(200)로부터 데이터를 갖고 있는 클라이언트 소켓(20)을 선택하여 쓰레드 풀(400)의 각 쓰레드(450-1, 450-2, 450-3, …, 450-n)에 할당한다. 쓰레드 풀(400)은 클라이언트의 다중 요청을 처리한다. 즉 각 쓰레드(450-1, 450-2, 450-3, …, 450-n)는 데이터를 갖는 클라이언트 소켓(20)의 요청을 한번만 처리하고, 처리 완료 후 즉시 소켓 풀(200)로 해당 클라이언트 소켓(20)을 반환한다. 이와 같이 나머지 소켓들도 등록된 순서대로 선택, 할당, 반환된다.

이와 같은 본 발명의 다중 쓰레드 소켓 폴링 모델은 종래 단일 쓰레드 모델과 마찬가지로 연결 수에 영향을 받지 않고, 종래 단순 다중 쓰레드 모델처럼 다중 요청을 처리할 수 있다. 또한 쓰레드 풀(400)의 용량을 조절함으로써 서버 자원의 사용량을 제어할 수도 있다.

폴링 쓰레드(300)내의 소켓 버퍼(socket buffer)(350)는 쓰레드 풀(400) 내부의 각 쓰레드(450-1, 450-2, 450-3, …, 450-n)가 모두 사용 중인 경우에 폴링 쓰레드(300)가 공전상태에 놓이는 것을 방지한다. 즉 쓰레드 풀(400) 내부의 각 쓰레드(450-1, 450-2, 450-3, …, 450-n)가 모두 사용 중인 경우에도 폴링 쓰레드(300)는 소켓 버퍼(350)를 이용하여 쓰레드 풀(400)에 공급할 충분한 수의 클라이언트 소켓(20)을 확보하는 작업을 멈춤 없이 지속할 수 있다.

한편, select() 함수의 경우 보통 네트워크 디바이스 드라이버의 입출력(I/O) 인터럽트를 이용하여 구현되는데 대부분의 UNIX 컴퓨터에서는 select()가 시스템 호출로 제공된다. 자바 개발 도구 1.3까지는 비동기 입출력(I/O) 기능을 제공하지 않았기 때문에 자바에서는 select()함수가 제공되지 않았다. 현재 자바 개발 도구 1.4부터 java.nio 패키지에서 이러한 비동기 입출력 기능을 제공하면서 이러한 문제가 해결되었다. 그러나 많은 자바 응용프로그램들이 아직도 자바 개발 도구 1.3을 기반으로 개발되고 있기 때문에 폴링 기능을 사용하고자 한다면 select() 기능을 개발자가 구현할 필요가 있다.

자바 개발 도구 1.3에서 소켓 폴링을 구현하는데 필요한 select()함수가 제공되지 않더라도 몇 가지 함수를 조합하여 이를 구현할 수 있다. 자바언어에서 인풋스트림(InputStream)은 C/C++언어의 파일 디스크립터(file descriptor)와 유사한 역할을 한다. 네트워크 장치를 포함한 외부 장치로부터 전송되는 모든 데이터들은 이곳을 통하여 전달된다. 인풋스트림에는 현재 수행 흐름을 방해하지 않고 한번에 읽을 수 있는 데이터의 양을 바이트 단위로 알려주는 available()이라는 함수가 제공된다. 만약 읽어 들일 데이터가 없는 경우에는 0을 반환하고, 그렇지 않은 경우에는 0이 아닌 해당 데이터의 크기를 반환한다. 이러한 특성을 이용하여 select()와 유사한 기능을 구현할 수 있다.

이하, 종래 두 모델과 본 발명 모델에 대하여 그 성능을 비교 평가한 시뮬레이션 결과를 제시함으로써 본 발명에 따른 다중 쓰레드 소켓 폴링 모델이 복잡한 구조에도 불구하고 단순 다중 쓰레드 모델과 유사하거나 더 나은 성능을 보이고 쓰레드 풀의 용량보다 더 많은 수의 클라이언트 요청을 처리할 수 있다는 것을 보여준다.

종래 두 모델과 본 발명 모델에 대하여 각각 클라이언트 수, 메시지의 길이, 그리고 쓰레드 풀의 용량을 변화하며 실험을 수행하여 그 수행 완료 시간을 결과값으로 비교하여 본다.

도 4는 종래 두 모델과 본 발명 모델의 클라이언트 수를 변화에 따른 수행 시간(로그값) 결과 그래프로서, a는 종래 단순 다중 쓰레드 모델이며, b는 종래 단일 쓰레드 소켓 폴링 모델이고, c는 본 발명 다중 쓰레드 소켓 폴링 모델이다.

단일 쓰레드 소켓 폴링의 경우 클라이언트 수가 1일 때 가장 좋은 결과를 냈으나 나머지 실험에서는 모두 나머지 두 경우보다 안 좋은 결과를 보였다. 단순 다중 쓰레드 모델과 다중 소켓 폴링 모델의 경우 유사한 결과를 보였으나 측정 데이터를 비교할 경우 다중 소켓 폴링 모델이 약간 더 좋은 결과를 보이고 있다.

도 5는 종래 두 모델과 본 발명 모델의 메시지 크기(길이) 변화에 따른 수행 시간(로그값)을 측정한 결과 그래프로서, a는 종래 단순 다중 쓰레드 모델이며, b는 종래 단일 쓰레드 소켓 폴링 모델이고, c는 본 발명 다중 쓰레드 소켓 폴링 모델이다. 이 실험에서는 512, 1024, 2048, 4096 문자로 변화하였으나 세 모델의 성능에는 별다른 영향을 미치지 않았다.

도 6은 본 발명에 따른 다중 쓰레드 소켓 폴링 모델의 쓰레드 풀 용량 변화에 따른 평균 쓰레드 사용량과 수행 시간 결과 그래프로서, a는 비교를 위하여 단순 다중 쓰레드 모델의 쓰레드 풀 용량을 100으로 고정시키고 측정한 결과이며, c는 본 발명에 따른 다중 쓰레드 소켓 폴링 모델의 측정 결과이고, d는 평균 쓰레드 풀 사용량이다.

도 6에서 평균 쓰레드 사용량의 경우 해당 쓰레드 풀의 용량과 거의 유사한 결과를 보이고 있다. 이는 쓰레드 풀의 용량을 거의 다 사용함으로써 효율적으로 할당된 자원을 사용하고 있다는 것을 알려준다.

여기에서 주목할 점은 다중 쓰레드 소켓 폴링 모델(c)은 쓰레드 풀의 용량이 20인 시점부터 단순 다중 쓰레드 모델(a)의 결과와 거의 유사하거나 더 좋은 결과를 보여준다는 것이다. 이 실험 결과에서는 30의 쓰레드 풀 용량을 갖는 다중 쓰레드 소켓 폴링 모델이 100의 쓰레드 풀 용량을 갖는 단순 다중 쓰레드 모델과 동일한 성능을 보여주고 있다.

상기에서는 본 발명의 일 실시예에 국한하여 설명하였으나 본 발명의 기술이 당업자에 의하여 용이하게 변형 실시될 가능성이 자명하다. 이러한 변형된 실시예들은 본 발명의 특허청구범위에 기재된 기술사상에 포함된다고 하여야 할 것이다.

전술한 바와 같이 본 발명은 복수의 처리 쓰레드를 유지하고 연결 요청시 생성된 소켓을 이들 처리 쓰레드에 할당하여 작업을 수행함으로써, 클라이언트의 연결 요청이 많아지더라도 소켓 처리를 위해 대기할 필요가 없으며, 쓰레드 풀의 용량 보다 더 많은 수의 클라이언트 요청을 처리할 수 있으므로 서버 시스템의 효율성이 향상되는 효과가 있다.

도 1은 종래 기술에 따른 다중 쓰레드 모델의 구조도,

도 2는 종래 기술에 따른 단일 쓰레드 소켓 폴링 모델의 구조도,

도 3은 본 발명에 따른 다중 쓰레드 소켓 폴링 모델의 구조도,

도 4는 종래의 두 모델과 본 발명의 모델에 대해 클라이언트 연결 요청 수를 변화하며 성능을 측정한 결과 그래프,

도 5는 종래의 두 모델과 본 발명의 모델에 대해 전송하는 메시지의 크기(길이)를 변화하며 성능을 측정한 결과 그래프,

도 6은 종래의 다중 쓰레드 모델과 본 발명의 다중 쓰레드 소켓 폴링 모델에 대해 쓰레드 풀 용량의 변화에 따른 성능을 측정한 결과 그래프.

Claims

네트워크를 통해 전달된 하나의 연결 요청에 대해 하나의 클라이언트 소켓을 할당하는 서버소켓 쓰레드와,

상기 서버소켓 쓰레드로부터 인가된 상기 클라이언트 소켓들을 저장하는 소켓 풀과,

복수의 쓰레드를 보유하여 클라이언트의 다중 요청을 처리하며, 상기 각 쓰레드는 상기 클라이언트 소켓이 할당되면 상기 클라이언트 소켓의 요청을 한번만 처리하고, 상기 처리 완료 후 해당 클라이언트 소켓을 상기 소켓 풀로 반환하는 쓰레드 풀과,

상기 소켓 풀에 저장되어 있는 상기 클라이언트 소켓들을 상기 쓰레드 풀의 복수 쓰레드에 할당하되, 그 할당 순서는 상기 클라이언트 소켓이 상기 소켓 풀에 저장된 순서대로 선택하여 할당하는 폴링 쓰레드

를 포함하는 다중 쓰레드 소켓 폴링 서버 시스템.
제 1 항에 있어서,

상기 폴링 쓰레드는 상기 쓰레드 풀 내부의 모든 쓰레드가 모두 사용 중인 경우에 상기 소켓 풀에서 선택한 상기 클라이언트 소켓을 임시 저장하는 소켓 버퍼를 포함하는 것을 특징으로 한 다중 쓰레드 소켓 폴링 서버 시스템.