KR100874403B1 - 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법 및시스템 - Google Patents

논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법 및시스템 Download PDF

Info

Publication number
KR100874403B1
KR100874403B1 KR1020060133882A KR20060133882A KR100874403B1 KR 100874403 B1 KR100874403 B1 KR 100874403B1 KR 1020060133882 A KR1020060133882 A KR 1020060133882A KR 20060133882 A KR20060133882 A KR 20060133882A KR 100874403 B1 KR100874403 B1 KR 100874403B1
Authority
KR
South Korea
Prior art keywords
thread
client
connection
threads
server
Prior art date
Application number
KR1020060133882A
Other languages
English (en)
Other versions
KR20080059934A (ko
Inventor
박길철
김용태
신현호
Original Assignee
한남대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한남대학교 산학협력단 filed Critical 한남대학교 산학협력단
Priority to KR1020060133882A priority Critical patent/KR100874403B1/ko
Publication of KR20080059934A publication Critical patent/KR20080059934A/ko
Application granted granted Critical
Publication of KR100874403B1 publication Critical patent/KR100874403B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/30076Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/3009Thread control instructions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/20Handling requests for interconnection or transfer for access to input/output bus

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명은 쓰레드 서버 시스템에 있어서 클라이언트의 작업요청을 수행하는 서버의 쓰레드 관리 방법에 관한 것으로, 보다 구체적으로는 쓰레드(thread) 서버 환경에서 클라이언트의 요청(접속, 실행)에 대해 사용된 쓰레드가 다시 클라이언트의 요청에 대해 바로 실행할 수 있는 대기상태(wait)로 전환되도록 하여 클라이언트의 요청에 대한 서버의 접속 시간과 응답 시간을 향상하는 방법에 관한 것이다.
본 발명에 의하면 클라이언트의 작업요청에 의해 사용된 쓰레드를 논-블록킹(non-blocking)상태로 유지하여 우선 처리 가능한 작업을 한 후, 다시 나머지 작업을 할 수 있을 때까지 대기상태(wait)로 기다릴 수 있게 된다. 따라서 클라이언트의 작업요청에 대해 응답속도가 빠르다.
또한 설정시간동안 사용되지 아니한 쓰레드는 삭제하여 서버의 과부하를 방지하고 자원을 효율적으로 관리할 수 있다.
쓰레드, 서버, 클라이언트, 쓰레드 풀

Description

논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법 및 시스템{A thread management method and system of the server using non-blocking input and output}
도 1은 본 발명의 바람직한 실시예에 따른 시스템 구성도.
도 2는 클라이언트가 서버에 접속하는 과정의 흐름도.
도 3은 클라이언트가 서버에 작업을 요청하는 과정을 나타낸 흐름도.
도 4은 본 발명에 따라 쓰레드 풀로 전달된 클라이언트 요청을 처리하는 과정의 흐름도.
도 4a는 쓰레드를 생성하는 단계(S_322)를 나타낸 흐름도.
도 4b는 쓰레드가 클라이언트의 작업요청에 따라 작업을 수행하는 단계를 나타낸 흐름도.
도 5는 클라이언트가 접속 종료하는 과정을 나타낸 흐름도.
도 6은 쓰레드 풀에서 쓰레드를 관리하는 과정을 나타낸 흐름도.
** 도면의 주요부분에 대한 부호의 설명 **
100...서버 200, 201, 202, 20n...클라이언트
110...쓰레드 관리자 112, 113, 114...쓰레드
120...통신에이전트 121...연결처리부
122...접속부 123...연결저장소
130...셀렉터 300...인터넷
본 발명은 쓰레드 서버 시스템에 있어서 클라이언트의 작업요청을 수행하는 서버의 쓰레드 관리 방법에 관한 것으로, 보다 구체적으로는 쓰레드(thread) 서버 환경에서 클라이언트의 요청(접속, 실행)에 대해 사용된 쓰레드가 다시 클라이언트의 요청에 대해 바로 실행할 수 있는 대기상태(wait)로 전환하여 클라이언트의 요청에 대한 서버의 접속 시간과 응답 시간을 향상하는 방법에 관한 것이다.
인터넷이 생활화 되어 많은 사람들이 개인적인 오락의 목적, 사업 목적, 또는 둘 다 때문에 매일 인터넷을 사용하는데, 전자적인 정보와 비즈니스 서비스의 고객으로서, 사람들은 이제 전 세계적인 차원에서 소스(source)를 쉽게 액세스할 수 있다. 사용자가 인터넷을 통하여 소프트웨어 애플리케이션과 서로 상호 작용하고 콘텐츠를 요청할 때, 돌아오는 응답의 지연 또는 비효율성은 사용자의 만족도에 매우 부정적인 영향을 줄 수 있고, 심지어는 사용자들이 다른 소스로 옮겨가도록 할 수도 있다. 따라서 요청된 콘텐츠를 신속히 그리고 효율적으로 전달하는 것은 사용자의 만족도에 있어 매우 중요하고, 따라서 네트워크의 서버 측의 시스템이 가능한 한 효율적으로 동작하도록 보장하는 것이 중요해 지고 있다.
즉, 서비스가 많아지고 사용자가 늘어나게 되면서 이전의 서버성능으로는 시스템의 요구사항을 만족시킬 수 없게 되기 때문에 동일한 하드웨어 사양에서도 안정적이고 향상된 성능이 필요하게 되었다.
종래에는 클라이언트가 서버에 접속할 때마다 클라이언트의 요청을 처리할 쓰레드를 실시간으로 생성하여 접속을 처리하였으나, 실시간으로 쓰레드를 생성하는데 시간과 자원을 많이 사용하게 되어 다수의 클라이언트가 동시에 접속을 하게 될 경우 정상적인 동작이 불가능하였다.
이러한 문제점을 해결하기 위해서 쓰레드 풀(thread pool) 모델이 개발되었다.
쓰레드 풀이란 다수개의 쓰레드를 미리 만들어 두고 필요한 상황에서 하나씩 사용할 수 있도록 하는 것이다.
상기 쓰레드 풀 환경의 서버에서는 블록킹 입출력(blocking i/o)을 사용하여 클라이언트와 서버간의 통신을 하므로, 서버가 클라이언트의 데이터를 받거나 클라이언트로 데이터를 보내는 과정에서 쓰레드가 블록킹(blocking)되는 경우가 발생하여 많은 수의 클라이언트의 요청을 원활히 처리할 수 없었다.
상기의 블록킹 입출력 방법은 클라이언트의 요청에 대해 사용된 쓰레드가 메모리에서 제외되는 것으로, 상기 제외된 쓰레드가 클라이언트의 요청에 대해 다시 활성화되기 위해서는 대기상태(wait)가 되어야 하는 데, 상기 활성화(메모리에서 다시 로딩하여 대기상태로 변환)되기까지 많은 시간이 소요되고 리소스가 필요하게 되어 결국 클라이언트의 요청에 대한 접속시간과 응답시간이 길어지는 단점이 있다.
따라서 본 발명은 상기의 문제점을 해결하고자 하는 것으로, 쓰레드 서버 환경에서 클라이언트가 서버에 접속할 때의 접속속도와 응답속도를 개선하고자 하는데 그 목적이 있다.
상기의 목적을 이루고자 본 발명에서는 클라이언트에서 사용된 쓰레드를 논-블록킹(non-blocking)상태로 유지하여 클라이언트에서 데이터를 받거나 클라이언트로 데이터를 보내는데 쓰레드가 불록킹(blocking)되지 않고, 즉시 처리 가능한 작업을 하고 나머지 작업을 할 수 있을 때까지 대기상태(wait)를 유지할 수 있게 한다.
본 발명은 네트워크 상에서 서버와 클라이언트의 연결 방법에 관한 것으로 보다 구체적으로는 쓰레드(thread) 서버 환경에서 클라이언트의 요청(접속, 실행)에 대해 사용된 쓰레드가 다시 클라이언트의 요청에 대해 바로 실행할 수 있는 대기상태(wait)로 전환되도록 하여 클라이언트의 요청에 대한 서버의 접속 시간과 응답 시간을 향상하는 방법에 관한 것이다.
이하 본 발명에 대해서 상세히 설명한다.
쓰레드 서버 환경에서, 클라이언트가 서버에 접속하면 서버는 접속을 인증하고, 인증된 접속의 연결을 쓰레드 저장소에 저장한다.
상기의 쓰레드 저장소에 접속연결이 있으면, 상기 접속 연결을 셀렉터에 등록시키고 접속 완료임을 클라이언트에 전달한다.
상기 서버는 클라이언트의 작업 요청에 따라 클라이언트가 보낸 데이터를 읽을 수 있는 연결이 있을 때까지 기다리다가 데이터를 읽어 들일 수 있는 연결을 가져와 클라이언트가 보낸 데이터를 로딩한다.
데이터를 한번에 모두 로딩할 수 없을 수도 있으므로 모든 데이터를 로딩할 때가지 반복한다.
상기 데이터를 모두 로딩하면 쓰레드 풀에서 쓰레드를 가져온다.
상기 쓰레드 풀에서 로딩할 수 있는 쓰레드가 없으면 가능한 범위내에서 새로 쓰레드를 생성하여 사용한다.
상기 로딩된 쓰레드에 클라이언트가 요청한 작업을 수행하도록 한다.
상기 로딩된 쓰레드가 클라이언트가 요청한 작업을 모두 수행하면 작업의 결과를 클라이언트로 보내고 쓰레드는 대기상태(wait)가 되어 다시 쓰레드 풀에 저장된다.
상기 클라이언트가 서버로 접속종료요청을 보내면 서버는 셀렉터에서 접속종료요청을 한 클라이언트와 서버간의 연결에 대한 등록을 해제한다.
본 발명에서는 쓰레드 풀 모델을 사용한다.
상기 쓰레드 풀의 구조는 DEQUE(Double Ended Queue)를 사용하는데 상기 큐(Queue)는 삽입과 삭제가 목록의 양쪽 끝에서 허용되는 선형 목록(스택)의 형태이다.
상기 선형 목록의 큐에서 한쪽 끝은 클라이언트의 요청에 따른 쓰레드에 사용하고, 반대쪽 끝은 쓰레드 개수를 제한하는 쓰레드 관리에 사용한다.
예를 들어 클라이언트의 요청에 따른 쓰레드가 필요하게 되면 쓰레드 풀의 선형 목록 맨 좌측에서 쓰레드를 로드하고 사용된 쓰레드는 다시 맨 좌측부터 적재된다. 이러한 경우에 선형 목록의 맨 우측은 클라이언트의 요청이 없을 경우 거의 사용이 되지 않을 수 있다. 따라서 선형 목록의 쓰레드 중에서 맨 우측의 쓰레드가 사용된 시간을 검사하여 일정시간이 경과된 이후에 사용되지 아니한 쓰레드는 소멸하는 것이 서버 자원을 줄일 수 있다.
선형 목록, 즉 스택(stack)처럼 동작하여 마지막에 사용되었던 쓰레드를 다시 사용하는 것은, 최근에 사용된 쓰레드를 다시 동작상태(run)로 하는 것이 더 빠르기 때문이다.
본 발명에서는 상기의 쓰레드 풀을 하나의 스택처럼 사용하였으므로, 맨 하위(=맨 우측)의 쓰레드를 검사하면 상기 쓰레드가 언제 사용되었는지 알 수 있다.
따라서 맨 하위의 쓰레드를 하나씩 로딩하여 지정한 시간 이상 사용하지 않았으면 쓰레드를 삭제되게 설정한다.
상기에서 선형 목록이라 함은 일반적으로 가로 방향으로 길게 이루어진 형태의 구조이고, 스택은 상하로 길게 이루어진 형태의 구조이다. 이러한 선형 목록 또는 스택(stack)의 구조에서 적재방법은 각각 우측에서 좌측으로, 아래에서 위로 적재되는 것이 일반적인 상식이므로 선형 목록에서는 맨 우측의 쓰레드가 자주 사용하지 않게 되고, 스택에서는 맨 하위의 쓰레드가 자주 사용되지 않는다. 따라서 선형 목록이라고 기술한 부분에서는 맨 우측의 쓰레드를 검사해야 하고, 스택에서는 맨 하위의 쓰레드를 검사해야 한다.
상기 클라이언트의 접속이 많아서 상기 쓰레드 풀에서 더 이상 로드할 쓰레드가 없을 경우에는 새로운 쓰레드를 생성하여 상기 클라이언트의 요청을 수행하는 것이 바람직하나, 쓰레드 풀에서 생성할 수 있는 쓰레드의 개수는 일정 수 이상으로 한정하는 것이 바람직하다.
쓰레드를 필요한 만큼 계속 만들다보면 각 쓰레드의 문맥교환 시간이 늘어나 서비스에 영향을 줄 수 있기 때문이다.
본 발명에서는 사용된 쓰레드를 블록처리하지 않는다.
즉, 쓰레드 풀 서버 환경에서 사용된 쓰레드를 논-블록킹(non-blocking)처리하여 읽기/쓰기(read/write)시 쓰레드가 블록킹 되지 않도록 하여 클라이언트의 작업 요청에 따라 바로 쓰레드를 로딩하여 작업을 수행할 수 있다.
상기의 쓰레드는 클라이언트의 접속을 받아들이는 쓰레드와 클라이언트가 보내는 데이터를 받는 쓰레드를 별도로 두어 즉각적인 접속처리를 가능하게 한다.
또한 상기의 쓰레드는 클라이언트의 데이터를 받는 부분을 따로 두어 한 클라이언트 연결이 하나의 쓰레드를 계속 사용하지 않고 필요할 때만 쓰레드를 쓰레드 풀에 요청하여 사용하게 하여 동작상태(run)의 쓰레드 수를 줄일 수 있다.
상기에서 셀렉터는 등록된 서버와 클라이언트의 네트워크 연결에서 발생하는 I/O Event(connect, accept, read, write)를 감지하여 즉각 처리 가능한 I/O Event가 발생한 서버와 클라이언트의 네트워크 연결을 알려준다.
상기 셀렉터에서 알려준 연결에 대해서 즉각적인 처리가 가능하므로 이전의 읽기/쓰기(read/write) 동작이 가능할 때까지 블록킹(blocking)되던 현상을 없앨 수 있다.
상기에서 셀렉터에 등록시킨다는 의미는 셀렉터에서 그 연결의 I/O Event를 감지할 수 있도록 한다는 의미이다.
본 발명에서 클라이언트가 서버로 보내는 데이터는 모두 논-블록킹 입출력(non-blocking i/o)을 사용하여 하나의 쓰레드에서 수신하기 때문에, 종래의 클라이언트 연결에 대해 하나의 쓰레드가 계속 사용되었던 방법 대신, 클라이언트가 요청한 하나의 작업에 대해서 쓰레드를 쓰레드 풀에서 가져와 사용하고 다시 쓰레드 풀로 반환하는 방법이다.
쓰레드 환경에서 쓰레드를 생성하는 데에는 많은 자원을 소모하는데, 본 발명의 쓰레드 풀에 저장된 쓰레드는 클라이언트가 서버로 보낸 데이터를 받아오는 시간동안 쓰레드가 동작상태(run)가 아니라 대기상태(wait)이므로, 접속과 동시에 쓰레드를 생성하는 것보다 미리 쓰레드를 생성하고 사용하는 방법으로 반응속도, 즉 응답속도를 줄일 수 있다.
이하 첨부된 도면에 따라 상세히 설명한다.
도 1은 본 발명의 바람직한 실시예에 따른 시스템 구성도이다.
서버(100)는 쓰레드 풀(110)과 논-블록킹 입출력(non blocking i/o)을 사용하는 통신에이전트(120)를 통해 인터넷(300)을 통한 클라이언트(200)의 요청을 처리한다.
쓰레드 풀(110)은 스택구조로 된 쓰레드 저장소(111)에 미리 준비된 쓰레드(112, 113, 114)를 담고 있으며, 쓰레드 관리자(115)를 통해 불필요한 쓰레드를 제거한다.
통신에이전트(120)는 논-블록킹 입출력(non blocking i/o)을 사용하는 접속부(122)와 연결처리부(121)를 가지고 있다. 상기 접속부(122)는 클라이언트의 첫 접속을 받아들이는 역할을 하고, 상기 연결처리부(121)는 클라이언트 접속시 클라이언트 정보를 생성하거나 클라이언트가 보낸 데이터를 받아 쓰레드 풀(110)로 클라이언트의 요청을 전달하는 역할을 한다. 접속부(122)와 연결 처리부(121) 간의 클라이언트 연결 전달은 연결저장소(123)를 통한다.
셀렉터(130)는 등록된 서버와 클라이언트의 네트워크 연결에서 발생하는 I/O Event(connect, accept, read, write)를 감지하여 즉각 처리 가능한 I/O Event가 발생한 서버와 클라이언트의 네트워크 연결을 알려주는 것으로, 클라이언트(300)의 작업요청에 해당되는 쓰레드(112, 113, 114)를 선택하는 것이다.
도 2는 클라이언트가 서버에 접속하는 과정의 흐름도이다.
클라이언트(300)가 접속을 요청하는 단계(S_100);
서버(100)의 접속부(122)에서 접속을 수락하는 단계(S_110);
상기 접속을 수락한 클라이언트(200)와의 연결을 서버의 연결저장소(123)에 저장하는 단계(S_120);
상기 연결저장소(123)에 저장 후 연결 처리부로(121)로 wake-up message를 전송하는 단계(S_130);
상기의 wake-up message가 수신되면 서버(100)의 연결저장소(123)로부터 클라이언트(200)와의 연결을 가져와 허용된 접속 수가 초과되었는지 확인하는 단계(S_130);
상기의 S_130 단계에서 접속 수를 초과하지 않았으면 셀렉터(130)에 클라이언트와의 연결을 등록하는 단계(S_140);
상기 연결이 등록되면 접속 완료를 처리하고 상기 클라이언트(200)로 접속 성공을 전송하는 단계(S_150);
상기의 S_140 단계에서 접속 수를 초과하였으면 클라이언트와의 연결을 종료시키고 클라이언트는 접속에 실패를 전송하는 단계(S_160);
로 이루어진다.
다음으로 접속된 클라이언트에서 서버에 작업을 요청하는 단계를 흐름도로 설명한다.
도 3은 클라이언트가 서버에 작업을 요청하는 과정을 나타낸 흐름도이다.
클라이언트(200)가 서버(100)로 작업을 요청하는 단계(S_200);
상기 서버(200)의 셀렉터(130)로부터 데이터를 읽어 올 수 있는 클라이언트 연결이 있음이 확인되면 상기 클라이언트의 작업 요청에 따라 데이터를 로딩할 준비가 된 클라이언트 연결을 로딩하는 단계(S_210);
상기 연결이 로딩되고 상기 클라이언트가 보낸 데이터를 로딩하는 단계(S_220);
상기 클라이언트에서 데이터가 모두 로딩되었는지 확인하는 단계(S_230);
상기 클라이언트가 보낸 데이터를 모두 로딩되면 쓰레드 풀에 작업 수행을 요청하는 단계(S_240);
로 이루어진다.
상기 요청에 따라 작업을 처리하게 되는데 작업에 대해서 처리하는 과정은 도 4를 통하여 설명한다.
도 4는 본 발명에 따라 쓰레드 풀로 전달된 클라이언트 요청을 처리하는 과정을 흐름도로 나타낸 것이다.
상기 서버의 쓰레드 풀(110)에서 클라이언트의 작업수행 요청을 수신하는 단계(S_300);
상기 작업수행 요청에 대해 사용할 수 있는 쓰레드가 존재하는지 확인하는 단계(S_310);
사용할 수 있는 쓰레드가 존재하지 않으면, 현재 쓰레드의 수와 허용된 쓰레드 수와 비교하는 단계(S_320);
상기의 현재 쓰레드의 수와 허용된 쓰레드의 수를 비교(S_320)하여 쓰레드를 더 만들 수 있으면, 허용된 쓰레드 수를 넘지 않는 일정 개수만큼 쓰레드를 새로 생성하는 단계(S_321);
상기 생성된 쓰레드를 동작상태로 실행하는 단계(S_325);
상기 실행된 쓰레드를 대기상태로 전환하여 쓰레드 풀의 쓰레드 저장소(111)에 저장하는 단계(S_326);
상기의 현재 쓰레드 수와 허용된 쓰레드 수를 비교(S_320)하여 쓰레드를 더 만들 수 없으면, 클라이언트의 요청을 처리할 수 없다는 메시지를 생성(S_330) 클라이언트로 처리 불가 메시지를 전송하는 단계(S_331);
상기 사용할 수 있는 쓰레드가 존재하는지 확인하는 단계(S_310)에서 사용할 수 있는 쓰레드가 있으면, 쓰레드 저장소(111)에 쓰레드를 요청하는 단계(S_340);
상기 요청에 의해 로딩된 쓰레드에 처리할 작업을 전달하는 단계(S_350);
상기 쓰레드에 wake-up 메시지를 전달하는 단계(S_360);
상기 쓰레드가 상기 클라이언트가 요청한 작업을 수행하는 단계(S_370);
상기 쓰레드가 작업을 수행한 결과를 클라이언트에 전송하는 단계(S_380);
상기의 S_370 단계에서 작업을 수행한 쓰레드를 쓰레드 풀의 쓰레드 저장소(111)에 저장하는 단계(S_390);
로 이루어진다.
본 발명에서 처음 서버를 구동할 때 무한대로 쓰레드를 생성할 수 없으므로 설정된 수만큼 생성하고, 필요하면 더 생성하고 사용하지 않으면 삭제한다.
상기에서 생성된 쓰레드를 동작상태로 실행하는 것은 쓰레드를 생성하면 Tm레드는 준비상태(ready)가 된다. 그래서 쓰레드를 실행시켜주어야 쓰레드가 동작하게 되고, 다시 대기상태(wait)로 전환하여 쓰레드 풀의 쓰레드 저장소에 저장하여야 요청된 쓰레드가 클라이언트의 작업 요청에 대해 즉시 실행할 수 있다.
상기의 과정에서 상기 쓰레드를 생성하는 단계(S_322)를 도 4a를 통하여 설명한다.
일정 개수만큼 쓰레드를 생성가능 한지 확인하는 단계(S_322);
일정 개수만큼 쓰레드를 생성할 수 없으면 생성할 수 있는 최대 쓰레드의 개수로 수정하는 단계(S_323);
상기의 S_322 단계에서 일정 개수만큼 쓰레드를 생성할 수 있으면, 상기 일정 수만큼의 쓰레드를 생성하고, 일정 개수만큼 쓰레드를 생성할 수 없으면 수정된 개수만큼의 쓰레드를 생성하는 단계(S_324);
로 이루어진다.
상기의 과정에서 상기 쓰레드가 클라이언트의 작업요청에 따라 작업을 수행하는 단계(S_370)를 도 4b를 통하여 설명한다.
클라이언트의 작업요청을 처리하도록 한 쓰레드는 wake-up 메시지를 확인하는 단계(S_371);
wake-up 메시지를 받으면 클라이언트의 작업요청에 따른 작업을 수행하는 단계(S_372);
상기의 쓰레드에 사용된 시간을 저장하고 상기 쓰레드를 대기상태로 전환하는 단계(S_373);
로 이루어진다.
상기에서 사용할 쓰레드가 없을 때에는 새로운 쓰레드를 생성해 주어야 하는데 쓰레드가 부족할 때마다 하나씩 생성하면 자주 쓰레드를 생성하게 된다. 그렇기 때문에 한번에 일정한 개수만큼씩 생성해 준다. 상기의 일정한 수는 당업자에 의해서 조정됨이 바람직하다.
상기의 쓰레드는 대기상태(wait)로 작업을 처리하기를 기다리고 있어서 wake-up 메시지로 상태를 동작상태(run)로 바꾸어 주어야 작업을 처리할 수 있다.
쓰레드를 관리하는 과정에서 일정시간 이상 사용하지 않은 쓰레드를 삭제해 주어야 하기 때문에 마지막으로 사용한 시간(=유휴시간)을 저장한다.
상기와 같이 본 발명의 논-블로킹 입출력(non-blocking i/o) 상에서는 로딩 준비가 된 클라이언트 연결이라고 해도 전체 데이터를 모두 로딩할 수 있는 상태가 아닐 수 있기 때문에 전체 데이터를 받았는지 확인하여 다음 진행을 결정하여야 한다.
도 5는 클라이언트가 접속 종료하는 과정을 나타낸 흐름도이다.
클라이언트가 서버에 접속 종료를 요청하는 단계(S_400);
서버에서는 상기 클라이언트의 접속 종료 요청을 수신하는 단계(S_410);
서버는 접속 종료 요청을 수신하면 상기 접속 종료를 요청한 클라이언트의 연결을 셀렉터(130)에서 등록을 해제하고 종료하는 단계(S_420);
로 이루어진다.
본 발명에서는 서버와 클라이언트의 연결이 종료되었다 하더라도 셀렉터(130)에서는 계속 관리하게 된다. 따라서 종료된 클라이언트 연결에 대해서는 등록을 해제하는 과정이 필요하다.
일정시간 이상을 사용하지 않은 쓰레드는 쓰레드 풀에서 삭제해야 서버의 과부하를 방지하고 자원을 효율적으로 관리할 수 있다. 도 6은 쓰레드 풀에서 쓰레드를 관리하는 과정을 나타낸 흐름도이다.
지정된 시간을 경과하였는지 확인하는 단계(S_500);
지정된 시간이 경과하였으면 쓰레드 풀의 스택에서 맨 우측의 쓰레드부터 하나씩 검사하는 단계(S_510);
상기 검사에서 쓰레드를 로딩할 수 있는지 판단하는 단계(S_520);
상기 쓰레드를 로딩할 수 있으면 쓰레드의 유휴시간이 설정된 타임아웃시간 보다 큰지 판단하는 단계(S_530);
상기 판단에서 타임아웃시간보다 더 오래 되었다면 쓰레드를 종료하고 삭제하는 단계(S_540);
상기 쓰레드를 로딩할 수 없거나 타임아웃시간보다 더 오래되지 않았다면 상기 S_500 단계로 이동하여 다음 체크 시간까지 대기한다.
상기에서 유휴시간은 클라이언트의 요청에 따라 최종적으로 쓰레드가 사용된 시간을 의미한다.
상기의 과정은 서버의 쓰레드 풀 관리자(115)에서 실행한다.
본 발명의 쓰레드 풀의 구조는 상기에서 언급하였듯이 DEQUE(Double Ended Queue) 형태이고, 풀의 한쪽에서만 꺼내어 쓰고 다시 넣고 하기 때문에 사용하는 쪽의 반대쪽에서 하나씩 로딩하여 체크하면 쓰레드 유휴시간이 가장 오래된 쓰레드부터 가져올 수 있다. 상기 로딩된 쓰레드의 유휴시간이 타임아웃시간을 넘지 않았으면 상기 쓰레드 이후의 쓰레드는 모두 유휴시간을 넘지 않기 때문에 바로 다음번 체크시간을 기다리면 된다.
본 발명에 의하면 클라이언트의 작업요청에 의해 사용된 쓰레드를 논-블록킹(non-blocking)상태로 유지하여 즉시 처리 가능한 작업을 하고 나머지 작업을 할 수 있을 때까지 대기상태(wait)로 기다릴 수 있게 된다. 따라서 클라이언트의 작업요청에 대해 응답속도가 빠르다.
또한 설정시간동안 사용되지 아니한 쓰레드는 삭제하여 서버의 과부하를 방지하고 자원을 효율적으로 관리할 수 있다.

Claims (5)

  1. 쓰레드 환경의 서버 시스템에서,
    쓰레드 풀(110)과 논-블록킹 입출력(non blocking i/o)을 사용하는 통신에이전트(120)를 통해 인터넷(300)을 통한 클라이언트(200)의 요청을 처리하는 서버(100);
    스택구조로 된 쓰레드 저장소(111)에 미리 준비된 쓰레드(112, 113, 114)를 담고 있으며, 쓰레드 관리자(115)를 통해 불필요한 쓰레드를 제거하는 쓰레드 풀(110);
    논-블록킹 입출력(non blocking i/o)을 사용하는 접속부(122)와 연결처리부(121)를 포함하고 상기 접속부(122)는 클라이언트의 첫 접속을 받아들이는 역할을 하고, 상기 연결처리부(121)는 클라이언트 접속시 클라이언트 정보를 생성하거나 클라이언트가 보낸 데이터를 받아 쓰레드 풀(110)로 클라이언트의 요청을 전달하는 역할을 가지는 통신에이전트(120);
    접속부(122)와 연결 처리부(121) 간의 클라이언트 연결 전달을 수행하는 연결저장소(123);
    등록된 서버와 클라이언트의 네트워크 연결에서 발생하는 I/O Event(connect, accept, read, write)를 감지하여 즉각 처리 가능한 I/O Event가 발생한 서버와 클라이언트의 네트워크 연결을 알려주는 것으로, 클라이언트(300)의 작업요청에 해당되는 쓰레드(112, 113, 114)를 선택하는 셀렉터(130);
    로 구성됨을 특징으로 하는 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 시스템.
  2. 쓰레드 환경의 서버 시스템에서,
    클라이언트(200)가 서버(100)에 접속하면 상기 서버(100)는 접속을 인증하고, 인증된 접속의 연결을 쓰레드 저장소(111)에 저장하고,
    상기 쓰레드 저장소(111)에 저장된 접속 연결을 셀렉터(130)에 등록시키고 접속 완료임을 클라이언트(200)에 전달하고,
    상기 서버(100)는 클라이언트의 작업 요청에 따라 클라이언트가 보낸 데이터를 읽을 수 있는 연결이 있을 때까지 기다리다가 데이터를 읽어 들일 수 있는 연결을 가져와 클라이언트가 보낸 데이터를 로딩하고,
    상기 데이터를 모두 로딩하면 쓰레드 풀(110)에서 쓰레드(112, 113, 114)를 가져오되, 상기 쓰레드 풀(110)에서 로딩할 수 있는 쓰레드가 없으면 가능한 범위 내에서 새로운 쓰레드를 생성하고,
    상기 로딩된 쓰레드에 클라이언트가 요청한 작업을 수행하고,
    상기 쓰레드가 요청한 작업을 모두 수행하면 작업의 결과를 클라이언트로 보내고 쓰레드는 대기상태(wait)가 되어 다시 쓰레드 풀(110)에 저장됨을 특징으로 하는 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법.
  3. 클라이언트가 서버에 접속하면 서버는 접속을 인증하고, 인증된 접속의 연결을 연결 저장소에 저장하는 쓰레드 환경의 서버시스템에 있어서,
    상기 서버의 쓰레드 풀(110)에서 클라이언트의 작업수행 요청을 수신하는 단계(S_300);
    상기 작업수행 요청에 대해 사용할 수 있는 쓰레드가 존재하는지 확인하는 단계(S_310);
    사용할 수 있는 쓰레드가 존재하지 않으면, 현재 쓰레드의 수와 허용된 쓰레드 수와 비교하는 단계(S_320);
    상기의 현재 쓰레드의 수와 허용된 쓰레드의 수를 비교(S_320)하여 쓰레드를 더 만들 수 있으면, 허용된 쓰레드 수를 넘지 않는 일정 개수만큼 쓰레드를 새로 생성하는 단계(S_321);
    상기 생성된 쓰레드를 동작상태로 실행하는 단계(S_325);
    상기 실행된 쓰레드를 대기상태로 전환하여 쓰레드 풀의 쓰레드 저장소(111)에 저장하는 단계(S_326);
    상기의 현재 쓰레드 수와 허용된 쓰레드 수를 비교(S_320)하여 쓰레드를 더 만들 수 없으면, 클라이언트의 요청을 처리할 수 없다는 메시지를 생성(S_330) 클라이언트로 처리 불가 메시지를 전송하는 단계(S_331);
    상기 사용할 수 있는 쓰레드가 존재하는지 확인하는 단계(S_310)에서 사용할 수 있는 쓰레드가 있으면, 쓰레드 저장소(111)에 쓰레드를 요청하는 단계(S_340);
    상기 요청에 의해 로딩된 쓰레드에 처리할 작업을 전달하는 단계(S_350);
    상기 쓰레드에 wake-up 메시지를 전달하는 단계(S_360);
    상기 쓰레드가 상기 클라이언트가 요청한 작업을 수행하는 단계(S_370);
    상기 쓰레드가 작업을 수행한 결과를 클라이언트에 전송하는 단계(S_380);
    상기의 S_370 단계에서 작업을 수행한 쓰레드를 쓰레드 풀의 쓰레드 저장소(111)에 저장하는 단계(S_390);
    를 포함하는 것을 특징으로 하는 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법.
  4. 청구항 제 3항에 있어서,
    상기의 쓰레드를 생성하는 단계(S_322)는,
    일정 개수만큼 쓰레드를 생성가능 한지 확인하는 단계(S_322);
    일정 개수만큼 쓰레드를 생성할 수 없으면 생성할 수 있는 최대 쓰레드의 개수로 수정하는 단계(S_323);
    상기의 S_322 단계에서 일정 개수만큼 쓰레드를 생성할 수 있으면 상기 일정 수만큼의 쓰레드를 생성하고, 일정 개수만큼 쓰레드를 생성할 수 없으면 수정된 개수만큼의 쓰레드를 생성하는 단계(S_324);
    를 더 포함하는 것을 특징으로 하는 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법.
  5. 청구항 제 3항에 있어서,
    상기 쓰레드가 클라이언트의 작업요청에 따라 작업을 수행하는 단계(S_370)는,
    클라이언트의 작업요청을 처리하도록 한 쓰레드는 wake-up 메시지를 확인하는 단계(S_371);
    wake-up 메시지를 받으면 클라이언트의 작업요청에 따른 작업을 수행하는 단계(S_372);
    상기의 쓰레드에 사용된 시간을 저장하고 상기 쓰레드를 대기상태로 전환하는 단계(S_373);
    를 더 포함하는 것을 특징으로 하는 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법.
KR1020060133882A 2006-12-26 2006-12-26 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법 및시스템 KR100874403B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020060133882A KR100874403B1 (ko) 2006-12-26 2006-12-26 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법 및시스템

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020060133882A KR100874403B1 (ko) 2006-12-26 2006-12-26 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법 및시스템

Publications (2)

Publication Number Publication Date
KR20080059934A KR20080059934A (ko) 2008-07-01
KR100874403B1 true KR100874403B1 (ko) 2008-12-16

Family

ID=39812639

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020060133882A KR100874403B1 (ko) 2006-12-26 2006-12-26 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법 및시스템

Country Status (1)

Country Link
KR (1) KR100874403B1 (ko)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101067848B1 (ko) * 2009-06-24 2011-09-27 에스지네트워크(주) 홈 네트워크 환경에서 안정적인 멀티미디어 서비스 제공을 위하여 멀티 쓰레드를 이용한 바인딩 테이블 엔트리 관리방법
JP2017130189A (ja) * 2016-01-20 2017-07-27 株式会社リコー 情報処理システム、情報処理装置、及び情報処理方法
CN111722944B (zh) * 2020-06-15 2023-04-18 合肥哈工轩辕智能科技有限公司 一种基于nio的airt-ros通信方法及系统
KR102307641B1 (ko) * 2021-04-30 2021-10-01 나무기술 주식회사 클라우드 운영 데이터 분석을 위한 병렬 처리 제어 시스템

Also Published As

Publication number Publication date
KR20080059934A (ko) 2008-07-01

Similar Documents

Publication Publication Date Title
US11689489B2 (en) Message history display system and method
JP4569846B2 (ja) I/oノード制御方式及び方法
US7246167B2 (en) Communication multiplexor using listener process to detect newly active client connections and passes to dispatcher processes for handling the connections
US8874780B2 (en) Data buffering and notification system and methods thereof
US8359595B2 (en) Generic application server and method of operation therefor
US6477569B1 (en) Method and apparatus for computer network management
JP5680620B2 (ja) ソフトウェアアプリケーションの起動コストを低減するためのシステムおよび方法
CN108595282A (zh) 一种高并发消息队列的实现方法
US20070174839A1 (en) Method and system for managing programs within systems
US20030097401A1 (en) Method for determining on demand right size buffering within a socket server implementation
JPH10124470A (ja) ロー・コンテクスト・スイッチングのオーバーヘッドが小さいマルチプレックス化メッセージの呼出し処理のメカニズム
US10409656B2 (en) Efficiently receiving messages across a large number of messaging entities
KR100874403B1 (ko) 논 블록킹 입출력을 이용한 서버의 쓰레드 관리 방법 및시스템
CN112328362A (zh) 一种基于容器技术实现函数计算服务的方法
US8448182B2 (en) System and method for pause and resume message operations on destinations
US8086671B2 (en) Systems and methods that facilitate in-order serial processing of related messages
CN105830029B (zh) 用于在计算环境中支持自适应忙等待的系统和方法
US20060242258A1 (en) File sharing system, file sharing program, management server and client terminal
CN114296916B (zh) 一种提高释放rdma性能的方法、装置及介质
US8327380B2 (en) Method and interprocess communication driver for managing requests of a database client to a database server
CN117093387B (zh) 消息处理方法、装置、电子设备和存储介质
CN101739286B (zh) 一种多处理器的储存服务器的负载均衡方法
CN113535339B (zh) 一种调用服务的方法以及装置
US8620991B2 (en) Technologies for detecting erroneous resumptions in a continuation based runtime
CN115421889A (zh) 进程间的请求管理方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
N231 Notification of change of applicant
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20121207

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20131206

Year of fee payment: 6

LAPS Lapse due to unpaid annual fee