KR100628821B1

KR100628821B1 - 응답 시간에 기초하여 프로그램적으로 작업 부하를분산시키는 기술

Info

Publication number: KR100628821B1
Application number: KR1020030100105A
Authority: KR
Inventors: 브라이스크리스토퍼제임스; 쿠오모제나로에이; 도터트레이에릭에이; 호그스트롬매트알
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2002-12-31
Filing date: 2003-12-30
Publication date: 2006-09-27
Also published as: JP2004213625A; KR20040062410A; JP3817541B2; US20040139433A1; US7207043B2

Abstract

본 발명은 작업 부하를 일련의 실행 리소스에 걸쳐 프로그램적으로 분산시키는 방법, 시스템, 컴퓨터 프로그램 제품, 및 비지니스 수행 방법에 관한 것이다. 본 발명에 따르면, 멀티스레드 서버 환경에서, 소프트웨어 실행 및 리소스 사용의 효율성이 상승하면서 최종 사용자에 대한 응답 시간이 개선된다. 서버에 의해 서비스되는 다양한 요청 타입의 실행 시간 및 대기/큐잉 시간이 추적된다. 다수개의 논리적 스레드 풀을 사용하여 이들 요청을 서비스하고, 반입되는 요청을 이들 풀 중 선택된 하나로 지정하며, 이 경우 실행 시간 요건이 유사한 요청들은 그 풀에 있는 스레드에 의해 서비스된다. 스레드 풀의 수와 사이즈는 프로그램적으로 조율될 수 있으며, 분산 계산(즉, 반입되는 요청을 어느 풀에 지정해야 하는지 결정하는 단계)은 프로그램적 결정이다. 양호한 실시예에서는, 이들 변수 중 단 하나만이 한번에 조절되고, 그 결과를 모니터링하여 그 영향이 긍정적 또는 부정적이였는지 판정한다. 개시되는 기술은 요청을 추적하여 메소드명(및 선택적으로 파라미터)으로 분류하는 데에도 적용된다.

Description

응답 시간에 기초하여 프로그램적으로 작업 부하를 분산시키는 기술 {PROGRAMMATIC RESPONSE-TIME BASED WORKLOAD DISTRIBUTION TECHNIQUES}

도 1은 본 발명에 따라 동작하는 시스템의 개괄도.

도 2 내지 도 4는 본 발명의 양호한 실시예에서 타입을 어느 스레드 풀로 지정해야 하는지 결정하는 방법을 나타내는 흐름도.

도 5는 본 발명의 실시예에 이용될 수 있는 상태 천이를 나타내는 상태도로서, 이들 천이는 도 6 내지 도 8에 나타낸 로직과 함께 사용되어, 양호한 실시예에 따라, 풀의 수와 각 풀의 사이즈를 조율할 때의 변화를 분리하는 것인 도면.

도 6 내지 도 8은 소정의 작업 부하에 대하여 풀 사이즈 및/또는 풀 수를 동적으로 조율하는데 사용되는 로직의 흐름도.

<도면의 주요 부분에 대한 부호의 설명>

100 : 시스템

105 : 작업 요청

110 : 대기 큐 요소

115 : 분류

120 : 대기 큐 1

135 : 수행 가능 풀

150 : 전체 스레드 풀

155 : 상태 큐

<관련 발명>

본 발명은 발명의 명칭이 "Dynamic Thread Pool Tuning Techniques"인 동일 출원인의 미국 출원 제_호(본 발명의 우선권과 동시에 출원된 출원 일련 번호 제_호)에 관련되고, 이 문헌은 여기에 인용됨으로써, 본 명세서에 포함되는 것으로 한다.

본 발명은 컴퓨터 소프트웨어에 관한 것이며, 보다 구체적으로는 일련의 실행 리소스(및 특히 멀티스레드 서버 환경에서의 실행 스레드)에 걸쳐 작업 부하를 프로그램적으로 분산시키는 방법, 시스템, 컴퓨터 프로그램 제품, 및 비지니스 수행 방법에 관한 것이다.

많은 부분에 있어서 공중 인터넷과 그것의 "월드 와이드 웹"(또는 간단하게 "웹")에 대한 비지니스 및 소비자의 사용이 증가함에 따라, 최근에 클라이언트/서버 컴퓨팅의 인기가 급격하게 상승하고 있다. 기업 인트라넷 및 엑스트라넷 등의 다른 형태의 클라이언트/서버 컴퓨팅 환경도 점차적으로 대중화되고 있다. 솔루션 제공자들이 개선된 웹 기반의 컴퓨팅을 전달하는 데 집중함에 따라, 개발되는 많은 솔루션들이 다른 클라이언트/서버 컴퓨팅 환경에도 적응될 수 있다. 그에 따라, 본 명세서에서 인트라넷 및 웹의 언급은 예시적인 것이며 제한적인 목적이 아니다(더욱이, 용어 "인트라넷", "웹" 및 "월드 와이드 웹"은 본 명세서에서 교환 가능하게 쓰인다).

수백만명의 사람들은 개인적 오락이든 비지니스 목적이든지 혹은 양자의 목적이든지 간에 매일 인터넷을 이용한다. 전자 정보와 비지니스 서비스의 소비자로서, 이제 사람들은 세계적 수준에 있는 소스에 쉽게 액세스한다. 인간 사용자가 인터넷을 통해 소프트웨어 애플리케이션과 상호 작용하여 콘텐츠를 요청할 때, 응답 반환에 있어서의 지연 또는 비효율성은 사용자 만족도에 매우 부정적인 영향을 줄 수 있으며, 심지어 사용자가 다른 소스로 전환하는 원인이 된다. 따라서, 요청된 콘텐츠를 신속하고 효율적으로 전달하는 것은 사용자 만족도에 결정적이며, 그렇기 때문에, 네트워크의 서버측에 있는 시스템이 가능한 한 효율적으로 수행하게 하는 것이 중요하다.

이러한 형태의 환경에서 다양한 클라이언트에 대한 요청을 취급하는 애플리케이션 서버에 있어서, 수신되는 각종 요청에 걸쳐 최상의 처리량 및 응답 시간을 제공하려면, 통상적으로 리소스의 사용을 제약해야 한다고 알려져 있다. 관심있는 주요 리소스 중 하나가 실행 스레드(이후, 간단히 "스레드"라고 동등하게 칭함)이다. 스레드의 작성, 사용 및 폐기가 제약되지 않는다면, 기술적으로 공지되어 있는 다양한 이유로 인해 응답 시간과 처리량 모두에 손해가 미친다. 예를 들어, 너무 많은 스레드가 작성되면, 그 스레드를 관리하기 위한 시스템 오버헤드가 허용할 수 없을 정도로 높아질 수 있고, 이들 스레드의 다른 정보 및 시스템 상태를 저장하는 데 너무 많은 메모리가 필요하게 된다. 또한, 제한된 리소스에 대한 다수개의 스레드를 큐잉하게 되면 그 리소스에 대해 스래싱(thrashing)이 초래되기 때문에, 공유 리소스의 경합은 가용 스레드 수를 제약하는 주된 이유이다. 그러나, 한편 가용 스레드 수가 매우 적다면, 반입되는 요청은 스레드로 할당되기 전에 장시간 대기해야 하며, 그에 따라 최종 사용자에 대한 응답 시간이 증가하게 된다.

그러므로, 시스템에서 스레드 수를 조율하는 것이 유익하다. 폐기되지 않고 작성되는 스레드 세트를 본 명세서에서는 "스레드 풀(thread pool)이라고 칭한다. 특정 클라이언트/서버 환경에서 스레드 풀에 대해 작성되는 스레드 수는 서버 초기화시에 사용자에 의해 구성 파라미터로서 종종 지정된다. 통상적으로 소정의 애플리케이션의 세트에 대하여 스레드 풀의 사이즈를 조율하는 것은 애플리케이션이 적당한 상태에서 심하게 구동되는 환경에서 반복적인 연산이며, 이 경우 스레드 풀은 처리량과 응답 시간을 개선하려는 시도에서 그 사이즈가 다시 정해진다.

비슷한 작업 부하에 있어서, 요청들은 종종 매우 유사한 전체 시스템 응답 시간을 가지며, 스레드 풀의 사이즈를 반복적으로 다시 정하는 것은 시스템의 성능을 향상시키는 데 유용하다. 유사하게, 작업 부하에 혼합된 타입의 요청들이 있고 이 다른 요청들이 유사한 응답 시간을 갖는 경우에, 이러한 형태의 사이즈 재조율 연산도 확실히 유용하다, 그러나, 상당히 다양한 응답 시간들이 혼합된 작업 부하의 경우에는 그 문제가 보다 복잡해진다.

다양한 평균 응답 시간을 가진 요청 타입으로 이루어진 작업 부하에 스레드의 수가 제약된 단일 스레드 풀을 사용할 경우, 스레드 풀에 대한 "최상의 사이즈" 를 알아낼 수 있고, (평균적으로) 요청들이 적당한 시간량으로 처리된다. 그러나, 혼합된 작업 부하에 이러한 단일 스레드 풀을 사용하는 것은 차선택이 될 수도 있다. 구체적으로 설명해서, 이러한 접근법은 실행 시간이 더 짧은 요청들의 응답 시간을 비균형적으로 길게 한다.

이러한 현상에 대한 이유는 애플리케이션 서버의 단일 스레드 풀을 제약하게 되면, 전술한 바와 같이 그 애플리케이션 서버 내에서 리소스 사용을 제어하는 데에는 결정적이 되겠지만, 단일 스레드 풀은 또한 실행 시간이 더 긴 요청에 의해 포화되는 경향이 있으며, 그에 따라 실행 시간이 짧은 요청들이 사실상 굶주리기 때문이다. 실행 시간이 긴 요청들의 버스트는 실행 시간이 짧은 요청들이 단일의 제약된 스레드 풀의 스레드에 할당되는 것을 실제로 막을 수 있다. 그리고, 스레드가 스레드 풀로부터 할당된다면, 특정 요청이 그것의 스레드에 의해 고속 처리되었을 지라도, 그 요청은 스레드가 할당되기 이전에 장시간 대기해야 한다. 최종 사용자(또는 보다 일반적인 경우에는, 요청자)가 그러한 요청에 대해 인지하는 응답 시간은 따라서 과도하게 길어질 수 있다.

따라서, 종래 기술의 이러한 문제들을 해결할 수 있는 기술이 필요하다.

본 발명의 목적은 클라이언트/서버 네트워크의 성능을 향상시키고자 함이다.

본 발명의 다른 목적은 멀티스레드 서버의 성능을 향상시키고자 함이다.

또한, 본 발명의 다른 목적은 요청을 스레드 풀로부터의 스레드로 스케쥴링하는 개선된 기술을 제공하고자 함이다.

또한, 본 발명의 다른 목적은 멀티스레드 서버 환경에서 작업 부하를 동적으로 균형 맞추는 기술을 정의하고자 함이다.

본 발명의 또 다른 목적은 평균 응답 시간이 변하는 작업 부하에 대해 서버 성능을 향상시키도록 스레드 풀을 동적으로 조율하기 위한 기술을 정의하고자 함이다.

본 발명의 추가 목적은 단축된 실행 시간량을 필요로 하는 요청이 실행 대기 시간을 더 적게 소비하게 하는 기술을 정의하고자 함이다.

또한, 본 발명의 다른 목적은 짧은 실행 시간 요청에 대한 응답 시간을 단축시키도록 일련의 실행 리소스에 걸쳐 작업 부하를 프로그램적으로 분산시키는 기술을 정의하고자 함이다.

본 발명의 기타 목적과 장점은 이어지는 설명과 도면에서 부분적으로 설명할 것이며, 이 목적과 장점은 부분적으로 상세한 설명으로부터 또는 본 발명을 실시함으로써 명백해질 것이다.

본 명세서에서 넓게 기재하는 본 발명의 의도에 따라, 전술한 목적을 달성하기 위하여, 본 발명은 일련의 실행 리소스에 걸쳐 작업 부하를 프로그램적으로 분산시키기 위한 방법, 시스템 및 컴퓨터 프로그램 제품을 제공한다. 양호한 실시예에서, 이 기술은 가용 스레드 풀의 수를 결정하는 단계, 서버 상에서 작업 부하의 이력 통계로부터 실행 시간을 입수하는 단계, 및 입수한 실행 시간을 가용 갯수의 스레드 풀들에 걸쳐 프로그램적으로 분산시키는 단계를 포함한다. 반입되는 요청을 서버에서 수신할 경우, 수행 시간에, 그 요청들은 프로그램적으로 분산된 실행 시간에 따라 가용 스레드 풀에 지정될 수 있다. 그 스레드 풀은 논리적 스레드 풀인 것이 좋다.

프로그램적 분산은 실행 시간을 정렬하는 단계, 정렬한 실행 시간을 가용 갯우의 스레드 풀들에 걸쳐 (예컨대, 공평하게) 할당하는 단계를 더 포함하는 것이 좋다. 정렬한 실행 시간의 카운트가 결정될 수 있고, 이 경우에, 할당 단계는 정렬한 실행 시간의 카운트를 가용 스레드 풀의 수로 나누어 "N" 값을 구하는 단계와, 인덱스로서 "N"의 정수배를 이용하여 액세스될 때, 정렬한 실행 시간에 따라, 가용 스레드 풀마다 실행 시간에 대한 상한을 지정하는 단계를 더 포함하는 것이 좋다.

양호한 실시예에서는, 반입되는 요청이 서버에서 수신될 때, 수신한 요청의 분류키를 결정하고, 결정한 분류키를 사용하여 그 수신된 요청의 평균 실행 시간을 알아내어, (양호하게는, 알아낸 평균 시간을 지정된 상한 각각과 비교할 때, 그 비교되는 지정된 상한이 알아낸 평균 실행 시간보다 크거나 같을 때까지 반복적으로 비교함으로써) 그 수신된 요청이 실행되는 특정한 가용 스레드 풀을 알아내는 것이 좋다.

양호한 실시예에서는, 반입되는 요청을 서버에서 실행할 때, 그 요청의 실행 시간을 추적하고, 그 추적한 실행 시간을 반영하도록 작업 부하의 실행 시간을 수정한다. 프로그램적 분산은 수정한 실행 시간을 반영하도록 주기적으로 재계산되는 것이 좋다.

본 발명은 또한 비지니스를 수행하는 방법으로서 제공될 수 있다. 예를 들 어, 고객의 클라이언트/서버 네트워크 트래픽의 동작 특성을 모니터하여, 그 관측에 따라 프로그램적으로 실행 리소스를 조절함으로써, 고객에게 서비스를 제공할 수 있다. 이 서비스는 사용에 따른 과금(pay-per-use billing), 월간 또는 다른 주기적 과금 등과 같이, 다양한 수입 모델 하에서 제공될 수 있다.

이제, 도면 전체에 걸쳐서, 동일한 요소에 동일한 참조 번호를 부여한 첨부 도면을 참조하여 본 발명을 설명한다.

본 발명은 클라이언트/서버 네트워킹 환경의 멀티스레드 서버에서 일련의 실행 리소스에 걸쳐, 반입되는 요청을 동적으로 그리고 프로그램적으로 분산시킨다. 양호한 실시예에서, 실행 리소스는 스레드이고, 이들 스레드는 복수의 스레드 풀에 논리적으로 편성된다. (가용 스레드의 세트는 단일의 물리적 풀로부터의 것이며, 그 단일 물리적 풀은 복수의 논리적 풀로 하위 분배된다. 이에 대해서는 이하의 도 1의 요소(135, 140, 145, 150)에 대한 설명을 참고할 수 있다. 참조의 편의상, 논리적으로 편성된 풀을 본 명세서에서는 간단히 스레드 풀이라고 하고, 단일의 물리적 풀을 "전체" 스레드 풀이라고 한다.)

프로그램적 요청 분산 프로세스는 반입되는 요청을 어느 풀에 지정할 것인 지(필요하다면 요청은 지정된 풀의 대기 큐에 입력될 것임)를 프로그램적으로 결정하는 단계를 포함하는 것이 좋고, 선택적 향상을 위해, 사용되는 스레드 풀의 수 및/또는 사이즈도 프로그램적으로 조율될 수 있다. 프로그램적 분산 프로세스의 양호한 실시예에 있어서, 본 발명은 요청이 실행될 때 요청을 추적하고, 요청의 타입별로 평균 실행 시간과 대기 시간을 결정하며, 특정 풀에 대하여 요청 할당을 동적으로 (양호하게는 각 풀에서 처리될 요청의 평균 실행 시간에 대한 상한을 결정함으로써) 조절한다. 스레드 풀의 개수 및/또는 풀에서의 스레드 수도 동적으로 조절하는 양호한 실시예에서, 이들 변수(풀에 대한 평균 실행 시간의 상한, 스레드 풀 수, 풀에서의 스레드 수) 중 단 하나만 한 번에 조절되고, 그 결과가 긍정적 또는 부정적인지의 여부를 판정하기 위해 다른 스냅샷을 획득한다.

종래 기술에 따른, 단일의 한정된 스레드 풀을 사용하는 것에 관련된 문제는 이미 전술하였다. 이들 문제에 대한 한 해결법은, 종래 기술에서도 알려져 있는 것으로서, (그 수가 정적으로 사전에 정해지는)소수개의 스레드 풀을 셋업하여, 그 풀 각각에 입력될 수 있는 요청의 타입을 수동으로 구성하는 것이다. 그 후에, 기타 모든 요청은 "기타 모든" 풀에 의해 취급될 수 있다. 이 접근법에는 메커니즘으로부터 어떤 요청의 타입이 메커니즘으로부터 유리한지를 결정하기 위하여 시스템의 프로파일이 필요하고, 요청 타입과 풀과의 매핑을 기술하는 사이드 테이블 정보를 수동으로 구성해야 한다.

이 접근법의 이점과 결점은 다음과 같다. 한가지 이점은, 큐 시간이 과도하게 연장되며 실행 시간이 다른 모든 요청 타입에 비하여 실질적으로 짧은 요청 세트를 식별할 수 있다면, 이 식별된 세트는 이 정보를 적절하게 사용하여 이들 요청을 특정 스레드 풀로 지정할 수 있는(즉, 지시할 수 있는) 수행 시간에서 식별될 때 더 개선된 응답 시간을 달성할 수도 있을 것이다.

그러나, 이 접근법의 결점은 장점보다 우세하다. 그 중 하나에 있어, 이 접 근법은 (웹 애플리케이션에서 직면하게 되는 것과 같은)요청 스트림의 성질의 변화를 고려하지 못한다. 요청 타입의 매핑이 포함된 하드 코딩된 테이블은 최초에 측정된 코드의 특성이 변하거나 새로운 코드가 시스템의 다이나믹을 바꾸기 때문에, 시작부터 잘못되거나 시간에 따라 변경될 필요가 있을 것이다. 어떤 경우에서도, 확실한 것은 시작부터 잘못되었을 지라도, 정보가 신속하게 아웃데이트될 것이다.

더 나은 해결법은, 본 발명의 양호한 실시예에서 적용되는 것으로서, 소정의 요청 타입의 평균 실행 시간 및 대기 시간을 추적한 후, 각 타입의 요청을 그 실행 시간에 따라 스레드 풀로 지정하는 것이다.

애플리케이션 서버에 의해 취급된 다양한 요청 타입의 평균 실행 시간을 추적함으로써, 이들 요청 타입을 몇개의, 유사한 실행 시간의 카테고리로 그룹화하는 것이 가능하다. 한가지 접근법에 있어서, 카테고리는 실행 시간 대역의 빈도 분산을 구축함으로써 결정될 수 있다. 양호한 실시예에 적용되는 간단한 구현에서는 가용 스레드 풀의 (미리 정해진) 개수를 입수하고, 그 입수한 실행 시간을 이용해서 요청 타입을 이 스레드 풀의 수로 나눔으로써 그 대역을 계산할 수 있다. 이것은 통계 타일(tail)을 계산하는 단계로서 칭해질 수도 있는데, 이 때 타일 값(즉, 각 특정 대역의 상한)은 각 풀에 허용된 최대 실행 시간이 된다. 이 타일값을 계산한 후, 각 타일에 상응하는 실행 시간을 식별하는 매핑(또는 유사한 연관) 테이블을 작성하는 프로세스를 본 명세서에서는 "분산 계산" 또는 "풀 타깃 계산"이라고 한다. 이 정보를 이용하여 신규 도착하는 반입되는 요청이 지정되어야 하는 곳을 결정하는 프로세스를 본 명세서에서는 요청 "분류" 단계라고 한다. 실행 시간의 상한을 결정하는데 사용되는 수집된 데이터를 본 명세서에서는 전체적으로 "분류 데이터"라고 하고, 그 수집된 데이터에는 이하에서 상세하게 설명하는, 각 요청 타입에 대한 평균 실행 시간과 기타 정보가 포함된다.

예를 들어, 분류 데이터에 10,000개의 실행 시간과 10개의 스레드 풀이 있다면, 1,000개 중 최단 실행 시간을 갖는 요청 타입은 최초 풀에 있는 스레드에 의해 처리될 수 있고, 1,000개 중 최장 실행 시간을 갖는 요청 타입은 최종(10번째) 풀에 의해서 처리될 수 있다. 본 발명자들은, 분산 계산시에 각 실행 시간 대역에 속한 요청의 이력적 빈도를 자동으로 고려하기 때문에, 이 접근법이 알려진 풀 사이즈에도 적합하다고 판단하였다. 스레드 풀에 대하여 요청의 분류 또는 요청의 수행 시간 지정이 양호한 실시예에 따라 어떻게 수행될 수 있는 지에 대한 세부 사항에 대해서는 도 1(이하에서 설명)을 참조할 수 있다.

경험적으로, 복수의 논리적 스레드 풀의 유용성이 전체적 응답 시간과 처리량에 도움을 준다고 밝혀지고 있다. 전술한 바와 같이, 종래의 접근법은 요청을 복수의 풀에 통계적으로 할당하였다. 통계 할당의 단점에 대해서는 전술하였으며, 본 발명의 동적 분류 및 분산 계산 기술은 이 단점을 해결한다. 본 명세서에서 기재하는 기술은 또한 소정의 작업 부하에 대하여 풀 사이즈 및/또는 풀의 수를 동적으로 조율하는 것을 가능하게 한다. (이 조율이 어떻게 수행될 수 있는 지에 대한 상세한 설명은 도 5 내지 도 8을 참조하여 후술한다.)

스레드 풀의 수를 동적으로 조절하는 기술을 이용하지 않을 때에는, 양호한 실시예의 연산 중에 사용할 수 있는 풀의 수를 (구성 가능한 값일 수 있는)미리 정 해진 수로 지정하는 것이 좋다. 시스템의 작동을 검사함으로써 풀의 수를 동적으로 결정할 수 있다면, 본 명세서에서 설명하겠지만, 반복적인 접근법을 이용하는 것이 좋다. 후자의 경우에, 처음에 사용하는 풀의 수(및 또한 풀의 사이즈)는 (예컨대, 최근 최다 사용된 값에 대하여 기억된 상태 정보로서, 동적으로 결정될 수 있는)종래의 지식에 의해서 또는 최초 디폴트 구성으로 시작함으로써 결정될 수 있다.

풀에 대하여 요청 타입의 분산을 동적으로 재계산하는 것와 함께, 풀의 수와 풀의 사이즈를 동적으로 조율할 때, 이러한 형태의 수행 시간 조율은 3차원적 문제로서 접근될 수 있다. 1차원 문제는 요청 타입의 연관된 실행 시간에 대하여 타일을 계산하는 것이고, 다른 문제는 풀의 수를 조율하는 것이며, 또 다른 문제는 풀의 사이즈를 조율하는 것이다. 이 프로세스는 이들 조율 양상간의 상호작용 때문에 매우 복잡해 진다. (요청을 프로그램적으로 분산시키기 위한 타일값을 계산하는 것은 그 자체가 조율의 한 형태이기 때문에, 본 명세서에서 "조율"이라는 용어의 사용은 풀의 수 및 풀의 사이즈 조율 프로세스에만 독점적으로 언급하도록 의도되지 않는다.) 예를 들어, 풀의 사이즈 변경 또는 풀의 수 변경은 그 풀에 지정된 요청의 실행 시간에 여러번 영향을 미칠 것이다. 이것은, 다양한 요청 타입을 상이한 대역으로 강제할 수 있다. 이것을 예시하기 위하여, 4개의 대역을 가진 구성에서, (다음의 최장 실행 요청을 서비스 받는) 제3 대역에 "T"개의 스레드가 있다고 가정한다. 또한 이 스레드 수를 이용하여, 대역 3에 있는 요청은 일부 하한 "LB(3)"으로부터 어떤 상한 "UB(3)"에 이르는 시간 간격에서 그 실행이 완료된다. 대역 3에 대하여, 스레드 수, T가 변하면, 대역 3으로 지정된 요청 타입의 일부에 대한 실행 시간이 [LB(3) …UB(3)] 밖에 있을 수 있다. 이것은, 본 명세서에 이용된 접근법에 따르면, 그 요청 타입이 더이상 대역 3에 속하지 않는다는 것을 의미한다. 그러나, 그것들을 다른 대역으로 이동시키면 노트온(knock-on) 영향이 발생할 수 있으며, 그에 따라 그 대역에 있는 요청의 실행 시간이 변하게 된다(추가 요청 타입이 다른 대역으로 이동할 필요가 있다는 것을 나타냄). 이 영향을 제어하기 위하여, 양호한 실시예에서는 실행 시간(및 따라서 그 시간량으로 실행되는 경향이 있는 요청 타입)을 사이즈 조율 프로세스 시에 특정 실행 대역으로 묶고, 후속의 분산 계산(즉, 실행 데이터의 후속 분석 및 그로부터 유도된 매핑의 수정)이 있을 때에만 다시 묶는다. 분산 계산이 통상 풀 사이즈 조율과 동시에 이루어지는 것을(또한, 실행 시간을 묶지 않는 것이 좋을 때에는 풀 카운트 조율과 동시에 이루어짐) 주지해야 한다. 양호한 실시예에서는, 요청 타입의 분류 데이터에 플래그를 사용하여 묶고, 풀 사이즈 조율을 완료한 후에는 그 묶는 플래그를 제거한다.

다음과 같이, 멀티스레드 서버 환경에서 관측할 수 있는 다수의 동적 요소가 있다.

DE1: 소정의 요청 타입의 실행 시간은 그 요청 타입이 이용하는 리소스와 구비한 코드 경로에 따라 변할 수 있다.

DE2: 시스템에 입력되는 새로운 요청은 그 실행 시간에 따라 분류되어야 한다.

DE3: 풀 사이즈는 변경될 수 있고, 그 풀에 지정된 요청의 실행 시간에 영향을 미칠 것이다.

DE4: 실행 시간의 분산은 재계산될 수 있고 다양한 요청 타입은 결과적으로 대역을 바꿀 수 있다.

DE5: 대역 수와 대응 풀의 수가 변할 수 있다.

이상 열거한 동적 요소를 참조할 때, DE1와 DE2가 조율 프로세스와 독립적이라는 것을 주지해야 한다. 사실상, 이들은 동적 조율 능력이 필요한 주된 이유가 된다. 이와 다르게, 대역에서의 요청 타입의 분산은 한번에 계산되어, 다만 그 상태로 된다. (유사하게, DE1과 DE2의 부재시에 풀 사이즈와 풀의 수를 동적으로 계산함으로써 얻게 되는 것은 아주 약간이거나 없을 것이다.) 또한, 동적 요소 DE3, DE4, 및 DE5가 조율 프로세스에 직접 기여할 수 있다는 것도 주지해야 한다. 이러한 관측은 본 명세서에 기술한 조율 기술을 이용하여, 그 조율 프로세스를 성공적으로 수행하는데 사용된다.

본 명세서에 기재하는 동적 분산 및 조율 기술은 따라서 동적 요소의 세트에 걸쳐 평형을 달성하도록 설계된다. 가능한 오버헤드를 적게 발생시키려면, 경로 길이, 경합, 및 조율 빈도가 최소화되는 것이 좋다. 조율 시에 상호작용 및 노크온 영향을 피하기 위하여, 양호한 실시예에서는 하나의 변경만 행하고, 시스템으로 하여금 일정한 시간 간격 동안 이 상태로 실행하게 하여, 그 변경 결과를 측정한다. (이 접근법이 변화의 긍적적 또는 부정적인 영향을 분리하는 데에는 효과적이겠지만, 조율 프로세스의 전체 지속 시간을 연장할 수도 있다. 그렇기 때문에, 절대적으로 필요하지 않는다면, 최대 대역수를 처음에 비교적 작은 수로 설정하는 것이 유리하다. 시스템이 대형일수록 이 최대수는 더 큰 것이 좋다.)

본 발명의 조율 접근법의 3가지 주목표는 다음과 같다.

G1: 안정된 작업 부하 혼합에 대하여 가능한 한 유사 안정 상태에 신속하게 도달하려고 시도

G2: 과잉 제어로 야기될 수 있는 실행 시간에서의 무모한 변동을 피함

G3: 반입되는 요청에 대하여 가용 스레드 리소스와 실행 시간간의 평형 달성

이들 목표를 달성하기 위하여, 시스템에 의해 처리된 요청에 대한 실행 및 대기 또는 큐 시간의 이력 통계를 유지해야 한다. 그에 따라, 본 발명은 전술한 바와 같이, 이 정보를 추적한다. 조율 시에 행해진 결정은 이들 요소의 현재값과 과거값을 비교함으로써 평가될 수 있다. (이루어진 변화의 값을 한정하는 단계에서도 0의 레이트를 비롯한, 현재 요청의 레이트의 변화와, 신규 요청 타입에 대하여 시스템의 동적 성질을 고려하는 것이 좋다. 신규 직면하는 요청 타입은 도 2 내지 도 3을 참조하여 후술하겠지만, 본 발명의 분류 프로세스의 실시예에 의해 자동으로 처리된다. 특정 요청 타입에 대한 도착 레이트의 변화는 분산 계산에 의해 자동으로 도모되어, 실행 시간과 풀과의 매핑의 상한을 수정할 수 있다. 도착 레이트의 변화로, 그 요청의 타입을 서비스하는 스레드 풀 사이즈가 프로그램적으로 조율될 수 도 있다.)

동적 작업 부하 분산과 풀 조율을 고려할 때 그 자체적으로 직접 보이는 한가지 어려움은 가장 실질적인 애플리케이션 서버가 폐쇄 시스템이 아니라는 사실이다. 즉, 요청이 나타내는 실행 시간과 큐 시간은 수행되는 작업의 타입에 따라, 다 운스트림과 업스트림 결과에 의해 종종 영향을 받는다. 예를 들어, 특정 요청 타입은 (데이터베이스 호출과 같은)원격 호출을 할 수 있고, 그 실행 시간은 이들 호출된 리소스의 유용성 또는 그 리소스에 대한 경합에 따라 변동할 수 있다.

이러한 영향을 처리하기 위하여 복잡한 피드백 시스템을 구축하려고 시도하는 것보다, 본 발명의 실시예는 필터링 메커니즘을 적용하는데, 이 필터링 메커니즘은 풀 당 실행 시간 상한, 풀의 개수, 및 풀 당 스레스 수에 변화가 없을 시에 실행 시간과 대기 시간의 2개 이상의 스냅샷을 획득하는 단계를 포함한다. 조율과 무관하게 변동하는 요청, 즉 정상적으로 변동하는 요청을 검출하려는 시도에서 이들 스냅샷으로부터 수집된 데이터들을 비교된다. 변동하지 않는 요청은 이 프로세스에서 "필터링"될 수 있다. (즉, 요청이 표준 편차 내에 있다면, 더 우수한 성능을 위해 이 요청에 관하여 시스템을 조율하려는 것은 유익하지 않을 수 있다.) 양호하게는, 필터링 메커니즘은 통계적 접근법에 적용되고, 요청 타입에 변동이 있는지의 여부를 판정하는 근거로서, 요청 타입에 대하여 표준 편차를 사용한다. 조율 변화가 없을 때 상대적으로 표준 편차가 큰 실행 시간 패턴을 갖는 임의의 요청은 정상적으로 변동하는 요청 타입으로서 취급될 수 있다. 예를 들어, 조율 변화가 일어나지 않은 샘플링 간격에 이어, 하나 이상의 요청 타입의 실행 시간 데이터가 분석된다. 이들 요청 타입 각각의 표준 편차는 이 "무변화" 간격 동안 계산될 수 있다. 조율 변화가 활성된 다른 간격 동안 수집된 데이터는 조율 변화가 있는 요청 타입에 대하여 표준 편차를 결정하는 유사한 방식으로 분석될 수 있다. 무변화 간격 동안의 특정 요청 타입의 표준 편차를 조율 변화 간격 동안의 표준 편차와 비교 함으로써, 이 요청 타입의 실행 시간에 대한 조율 변화의 영향에 대하여 계획할 수 있다. (이 프로세스 시에는, 정상적으로 변동하지 않았다고 판정되는 요청 타입에 대해 초점을 맞추는 것이 유익하다.)

(넓게 변할 수 있는)외부 대기 시간뿐만 아니라 내부 경합으로 의해서도 변동이 야기될 수 있음을 주지해야 한다. 이러한 문제들을 나타내는 요청에 대한 스레드 풀 사이즈를 제약하는 많은 시간이 전체적인 처리량에 도움을 줄 수 있다. 따라서, 표준 편차를, 요청 타입의 실행 시간이 변동하고 있는지의 표식으로서 뿐만 아니라, 풀 사이즈 또는 풀 수의 변화가 유효한 지에 대한 표식으로서도 사용할 수 있다.

따라서, 이들 모든 인자를 고려하여, 실행 및 대기/큐 시간 추적에 기초해서 작업을 효율적으로 다수개의 스레드 풀에 분산시키기 위한 자체 조율 및 고처리량 메커니즘을 구축할 수 있다. 본 명세서에 개시하는 기술들은 전체 작업 부하에 걸쳐 동적으로 평형을 달성할 수 있고, 또한 작업 부하를 시간에 따라 특성이 변하게 하며, 한층 최적의 처리량과 응답 시간을 달성한다.

이제 도 1을 참조하면, 본 명세서에 개시되어 있는 바와 같이 동작하는 시스템(100)의 개괄도가 도시되어 있다. 작업 요청(105)(예컨대, 반입되는 클라이언트 요청)이 시스템에 입력될 때, 각 상기 요청에 대해, 양호한 실시예에 따라 대기 큐 요소("WQE")(110)가 생성된다. WQE는 요청이 처리될 때, 그 시스템을 "통과"하는 것으로서 간주될 수 있고, 그 요청 및 그것의 현재 처리에 관계되는 정보를 수집하는데 사용된다. 객체 지향 프로그래밍 관점에 있어서, WQE는 반입되는 요청에 대하여 "랩퍼(wrapper)"로서 구현되는 것이 좋다. 각각의 랩퍼는 요청의 타입과 같이, 그것의 연관된 요청을 식별하기 위한 정보를 포함한다. 이 식별 정보는 또한 반입되는 요청을 특정 스레드 풀에 지정하기 위한 목적에서 그 요청을 "분류"하는 데 사용되는 이전에 저장된 이력 통계를 알아내는 데 사용될 수 있다는 점에서 "분류키"라고 부를 수 있다. 이 분류키와 함께, WQE는 요청의 현재 실행 시간 및 현재 큐잉 시간을 기억한다. 양호하게는 WQE는 또한 이 요청 타입의 분류 데이터에 대한 레퍼런스를 유지하며, 이 경우에 그 분류 데이터는 그 WQE에 기억된 분류키를 이용하여 검색될 수 있다. 양호한 실시예에서, 이 분류 데이터는, 양호하게는 이동 평균으로서 기억되면 좋은 실행 시간, 이동 평균으로서 기억되면 좋은 큐잉 시간, 및 선택적으로, 그 요청 타입의 이력 실행 시간 및 큐잉된 시간 값에 대한 표준 편차값을 포함한다. 이들 표준 편차값도 이동값인 것이 좋다. 분류 데이터를 WQE로 기억하는 것은 통계 계산 스레드의 연산보다 효율적인데, 이것은 요청의 현재 실행 시간 및 대기 시간이 이력 통계에 고려되기 때문이다(요소 155와 160을 참조하여 보다 상세하게 설명할 것임). 이동 평균 및 이동 표준 편차값, 즉 각각의 신규 실행으로 갱신되는 값을 사용함으로써, 본 발명의 실시예들은 실행 및/또는 큐잉된 시간에 있어서 이전의 이상 현상을 저하시킨다.

(WQE와 함께)반입되는 요청은 분류 연산(115)에 입력된다. 이 분류에는 요청이 지정되어야 하는 스레드 풀을 결정하는 단계가 포함된다. 양호한 실시예에서, 이 타입(또는 와일드카드나 유사한 매칭 접근법이 지원된다면, 유사한 타입)을 갖는 요청의 평균 실행 시간을 결정하기 위해, 이 요청 타입에 대하여 이전에 계산된 분류 데이터(즉, 이력 통계)가 사용된다. 평균 실행 시간을 사용하여, 이 요청과 같거나 작용면에서 유사한 요청을 취급할 수 있는 풀을 식별할 수 있다. 그렇기 때문에, 종래 기술의, 단시간의 실행 요청을 다른 방법으로 차단하는 장시간의 실행 요청의 문제가 해결된다.

대안적 실시예에서, 분류 연산(115) 시에 적용 가능한 이력 통계를 알아내기 위하여, 분류키로서 요청 타입을 사용하는 것이 아니라, 인덱스로서 추가 또는 다른 정보를 사용한다. 예컨대, 요청 타입은 그 파라미터의 입력값(및 선택적으로는 파라미터명)을 사용하여 요청 타입을 추가로 한정할 수 있고, 이 파라미터와 요청 타입의 조합은 분류 데이터(이것은 보다 입상 레벨(granular level)에서 등록되면 좋다)를 인덱싱하는데 사용될 수 있다. URL(Uniform Resource Locator)의 URI(Uniform Resource Identifier) 부분이 사용되고, 파라미터명/값도 URI와 함께 사용될 수 있다. 또한, 웹 환경에서는 "요청 타입"이 요청의 분류화에 유용한 반면, 다른 환경에서는 다른 정보가 관련될 수 있다. 예컨대, Enterprise JavaBeans(등록 상표) 환경에서는, (메소드의 클래스 및 배치된 명칭을 포함한)메소드명을 요청 타입 대신에 사용할 수 있다. 원한다면, 추가 한정자로서 파라미터명/값과 함께 메소드명을 사용할 수 있다. ("Enterprise JavaBeans"는 선 마이크로시스템스사의 등록 상표이다.) 그에 따라, 본 명세서에서는 제한의 목적이 아니라 예시적으로 "요청 타입"을 언급한다.

다음 도 2를 참조하여, 분류 연산(115)에 대하여 보다 상세하게 설명한다. 블록 200에서, 입력 큐로부터 신규 반입되는 요청을 수신한다. 블록 205에서는 이 요청을 분석하여 그것의 분류키(또는 보다 상세하게는 그 요청을 식별하는 정보)를 결정한다. 본 발명의 특정 구현에서 반입되는 요청에서 분류키를 알아내는 방식은 요청 타입, 또는 요청 타입과 파라미터 값 등이 그 특정 환경에서 요청을 분류하는 데 중요한 지의 여부에 좌우될 것이다. 일단 분류키가 결정되면, 그 분류키는 이력 통계가 기록되는 매핑 테이블 또는 기타 리포지터리(repository)에 대한 인덱스로서 사용된다(블록 210).

블록 215에서는 이전에 기록된 분류 데이터(및 특히, 평균 실행 시간)가 이 분류키로 정해졌는지의 확인을 체크한다. 그렇지 않다면, 이 반입되는 요청은 "신규 도착하는" 요청 타입으로서 간주된다. (그 요청 타입이 이 시스템에 의해 이전에 처리되었지만, 가장 최근의 처리에 대해서 그 통계 데이터는 이미 오래된 것이 된다. 양호하게는, 최근 최소 사용(LRU : least recently used) 접근법을 이용하여 구현시에 특정의 "적당한" 레벨에서 이력 통계 데이터에 대해 소모된 기억량을 유지한다. 블록 220과 225는 신규 도착 요청 타입에 대해 추가 처리를 수행한다. 블록 220의 처리는 이 신규 요청 타입에 대한 통계를 기억하기 위해 분류 데이터의 신규 엔트리를 작성하는 단계를 포함하고, 이 신규 엔트리는 현 요청의 분류키에 의해 인덱싱된다. 그런 후에 블록 225는 평균 실행 시간을 네거티브 1("-1")과 같은 특수값에 설정함으로써 이 신규 엔트리를 초기화하는 것이 좋다. 이 특수값은 이후 도 3을 참조하여 추가 설명하겠지만 풀 지정 프로세스에서 검출된다. (이와 다르게, 그 값을 간단히 0으로 설정할 수도 있다.)

요청의 통계 데이터를 알아낸 후(즉, 블록 215의 결과가 긍적적일 때) 또는 새로운 통계 엔트리를 작성하여 초기화한 후에(블록 215의 결과가 부정적일 때), 블록 230에서 제어가 수행되어, 현재 반입되는 요청이 지정되어야 할 풀을 결정하여 지정하는 풀 지정 프로세스를 호출한다. 이 프로세스는 도 3에서 상세하게 설명한다. 현재 반입되는 요청의 처리를 완료한 후에, 블록 200으로 제어가 반환되어 후속 요청에 대해 도 2의 로직이 반복적으로 수행된다.

도 3은 도 2의 블록 230에서 호출된 풀 지정 프로세스가 양호한 실시예에서 어떻게 수행될 수 있는 지에 대한 추가 세부 사항을 제공한다. 이 프로세스는 도면에서 "poolNdx"라고 칭해진 풀 카운터 또는 인덱스를 초기화함으로써 개시된다(블록 300). 풀 세트를 루프 스루하는데 이 poolNdx 값을 사용하여, 현재 반입되는 요청이 지정되어 할 곳을 체크한다. 풀은 점진적으로 더 높은 실행 시간 작업을 허용하므로, 가장 높은 실행 시간을 갖는 작업이 최종 풀에 지정된다.

블록 305에서는 이 현재 반입되는 요청의 평균 실행 시간이 poolNdx의 값에 의해 인덱싱되는 풀의 타깃 상한과 같거나 작은지의 확인을 테스트한다. 그 요청의 평균 실행 시간은 이 요청 타입과 연관된 이력 통계로부터 입수되거나, 이 요청 타입의 이력 통계를 사용할 수 없다면 네거티브 1로 초기화될 수 있다(도 2의 블록 225). 후자의 경우에, 블록 305의 테스트가 도 3의 로직을 통과하는 처음 반복 시에는 긍적적일 것이며, 그에 따라 양호한 실시예에서는 신규 도착하는 요청 타입을, 최단 실행 시간을 갖는 요청을 처리하는 풀에 지정한다. (다른 실시예에서는 신규 도착하는 요청 타입을 처리하기 위해 풀을 선택하는 다른 접근법을 사용할 수도 있다.)

블록 305의 테스트의 결과가 긍정적이라면, 이 요청을 처리하기 위한 풀이 발견된다. 그러므로 제어가 블록 320으로 옮겨지고, 작업 요소가 poolNdx에 의해 인덱싱된 풀에 지정된다(즉 실행을 위해 지정된다). 이어서 도 3의 처리가 완료되고, 제어는 도 2의 호출 로직으로 반환된다. 이와 다르게, 블록 305의 테스트에서 부정적인 결과를 갖는다면, 풀 인덱스는 블록 310에서 증분되고, 블록 315에서는 타깃 상한이 체크되어야 하는 풀이 아직도 많은지의 확인을 체크한다. 이 체크 프로세스는 poolNdx의 현재 풀 인덱스를 풀의 전체 수에서 1을 뺀 값과 비교한다. (변수 "#pools"에는 현재 사용 중인 풀의 수가 기억된다.) 이 접근법으로 마지막 타일 값보다 실행 시간이 큰 요청 타입이 최종 풀로 항상 지정될 것이다. 체크되어야 하는 풀이 많다면, 제어는 블록 305으로 반환되고, 그렇지 않다면, 처리는 블록 320에서 계속되어, 현재 반입되는 요청이 현재(이 경우에는 마지막) 풀에 지정될 것이다.

도 3이 어떻게 연산하는 지의 예로서, 3개의 풀을 사용하고, 이들 풀에 대한 타일값(즉, 실행 시간 상한)이 10 시간 단위 및 20 시간 단위로 설정되는 구현을 가정한다. 도 3에 나타내는 접근법을 사용하여, 10 미만의 시간 단위를 사용해서 실행되는 임의의 요청 타입은 신규 도착하는 요청 타입과 함께, 제1 풀로 지정될 것이며, 10 이상의 20 미만의 시간 단위를 필요로 하는 요청 타입은 제2 풀로 지정될 것이다. 20 이상의 시간 단위를 필요로 하는 요청 타입은 제3 풀로 지정될 것이다. 반입되는 요청 타입의 이력 통계가 평균적으로 50 실행 시간 단위를 필요로 한다고 하자. 그러면, poolNdx 값이 0일 때, 블록 305에서 50과 10이 비교될 것이며, 이 테스트가 부정적인 결과를 가질 것이기 때문에, 블록 310에서 poolNdx이 1로 증분될 것이다. 블록 305를 통과하는 다음 반복에서는, 50과 20이 비교될 것이다. 이 테스트 역시 부정적인 결과를 가질 것이며, 블록 310에서 poolNdx은 2로 증분될 것이다. 블록 315의 테스트는 이어서 2(poolNdx 값)과 2(풀의 수에서 1을 뺀 값)을 비교할 것이고, 이 테스트가 부정적인 결과를 가질 것이기 때문에, 요청은 제3 풀(즉, 제로를 기초로 한 인덱싱법으로, 인덱스값이 2인 풀)에 지정될 것이다

도 4는 이종의 동적 가변성 작업 부하의 실행 및 대기 시간 특성을 분석하여, 타일값 또는 풀 당 실행 시간의 상한을 양호한 실시예에서는 어떻게 결정하는 지를 나타내는 로직을 제공한다. 이 프로세스를 본 명세서에서는 분산 계산 또는 풀 타깃 계산 프로세스라고 부른다. 양호하게는, 도 4의 로직은 도 1의 요소 160를 참조하여 이하에서 설명하겠지만, 상한을 수정하기 위해 주기적으로 호출된다.

블록 400에서는 현재의 분류키 집합(즉, 이력 통계의 집합)을 그것의 평균 실행 시간으로 정렬한다. 전술한 바와 같이, 이 평균 시간 값은 어떤 최근 간격을 따른 이동 평균을 나타내는 것이 좋다. 이런 식으로, 이전에 발생하였던 문제 상태 또는 기타 이상 상태(즉, 실행 시간이 과도하게 길어지는 타임아웃 상황 또는 실행 시간이 비정상적으로 짧아지는 예외 상태)가는 차후 결정을 왜곡하지 않는다. 양호한 실시예에서는 실행 시간을 어레이에 복사하고 이 어레이를 정렬한다. (이 어레에 대한 기억 장소가 할당되었으며, 그 기억 장소가 어레이 사이즈를 확대하기 위해 재할당을 필요로 하지 않는다면, 도 4의 후속 반복을 위해 유지되는 것이 좋다.)

블록 405는 이 정렬된 실행 시간의 집합에 대하여 "etas"("실행 시간 어레이 사이즈") 값을 설정한다. 이 "etas" 값은 거기에 얼마나 많은 실행 시간이 있는지에 대한 카운터로서 기능하고, 그 실행 시간은 풀의 세트간에 적절하게 분산될 수 있다. 블록 410은 풀 인덱스 값 poolNdx를 제로로 초기화한다.

블록 415에서, 타깃 상한이 지정되어야 하는 풀이 아직도 많은 지를 확인하기 위한 테스트가 수행된다. 이 체크 프로세스는 poolNdx의 현재 풀 인덱스 값을 전체 풀 수(이 총 수는 변수 "#pools"에 기억됨)에서 1을 뺀 값과 비교한다. 이 접근법으로, 존재하는 풀수에서 1을 뺀 값이 상한으로 지정되어, (도 3을 참조하여 설명한 바와 같이) 실행 시간이 최종 상한보다 높은 모든 요청 타입이 최종 풀로 지정될 것이다. 블록 415의 테스트가 긍정적인 결과를 갖는다면, 블록 420에서 처리가 계속되고, 부정적인 결과를 가지면, 지정되는 상한은 더 이상 없고, 그에 따라 제어는 호출 로직으로 반환된다.

블록 420에서, 현재 풀(즉, poolNdx에 의해 인덱싱되는 풀)로 지정되는 실행 시간 상한이 계산되어 지정된다. 양호한 실시예에서, 이것은 가용 풀에 대하여 실행 시간 통계의 총 수(및 그러므로 그 연관된 요청 타입)를 똑같이 분산하는 단계를 포함한다. 그에 따라, 정렬된 실행 시간으로부터의 "N번째" 요소를 구하여, 그 요소의 실행 시간을 현재 풀의 상한(도면에서는 "타깃" 속성으로서 칭해짐)으로서 지정한다. 블록 420에서와 같이, 정렬된 어레이에서 요소의 카운트("etas"의 값으로서 표현됨)를 가용 풀의 수(#pools)로 나눈 후에, 이것을 poolNdx값+1과 곱하고, 최종적으로 그 값에서 1을 감산함으로써, N번째 요소가 결정된다.

상한을 설정한 후에, 블록 425에서 그 풀 인덱스 값이 증분되고, 제어는 블록 415로 반환되어, 지정되어야 할 상한이 아직도 많은 지를 결정한다.

도 4의 논리가 어떻게 연산되는 지에 대한 예시로서, 현재 집합에 12개의 분류가 있다고 가정한다. (확실한 것으로서, 실제로 수백 또는 수천개의 분류가 있을 수 있다.) 또한, 4개의 가용 풀이 있다고 가정한다. 첫번째 반복에서, 블록 420의 처리가 풀(0)의 상한을 계산할 것이다. "etas"의 값은 이 예에서 12이고, 그에 따라 (etas/#pools)는 12/4, 즉 3이다. 이 값에 1을 곱하면 3이 되고, 1을 뺀 후에, 풀(1)의 상한은 sortedExecTimes[2]로부터 얻은 실행 시간이다. 후속 반복시에 풀(1)의 상한은 sortedExecTimes[5]로부터 얻은 실행 시간과 같이 계속 설정될 것이다.

도 4에 나타낸 접근법에서는 상한을 최근에 관측되었던 실행 시간의 분산에 기초한 값에 설정한다. 풀의 수를 조율할 때, 상한이 지정되어야 하는 풀의 수가 동적으로 변할 수 있다는 점을 주의해야 한다. (풀의 수를 조율하는 방법에 대한 더 많은 정보를 위해 도 5 내지 도 7의 설명을 참조하면 된다.) 도 4에 나타낸 로직은 풀의 수의 변화에 자동으로 적응한다.

이제 도 1에 나타낸 전체 처리에 대한 설명을 참조하면, 각 반입되는 요청이 도면 부호 115에서 분류될 때, 그 요청은 적절한 스레드 풀(도 2와 도 3의 처리를 이용해서 식별된 스레드 풀)로 지정된다. 종종, 요청은 대기 큐에 입력되어, 스레드가 이용 가능할 때까지 스레드를 대기한다. 그에 따라, 요청은 "N"개의 대기 큐(120, 125, 130) 중 하나로 지정되는 것과 같이 도 1에 도시되어 있으며, 각 대 기 큐는 시스템(100)에서 현재 사용되고 있는 N개의 논리적 스레드풀(130, 140, 145) 중 하나에 대응한다. (확실한 것으로서, 시스템(100)에서 풀의 수가 얼마 후에 상승하거나 감소하면, 대기 큐도 그에 따라 조절되어야 한다. 또한, 대기 큐의 사이즈도 큐잉된 요소의 수에 따라 변하고, 본 명세서에서 설명하는 동적 조율은 큐 사이즈를 변경하려는 것이 아니다.)

어떤 점에서, 큐잉된 요청은 그것이 큐잉되는 스레드 풀에 있는 스레드에 것이다. 대기 큐에서 소비한 시간량이 양호한 실시예에 따라 그것의 WQE에 기록된다. (요청이 분류 연산되었을 때 스레드를 이용할 수 있다면, 요청은 대기 큐를 무시할 수도 있다. 그 경우에, 대기 시간은 제로로서 기록된다. 그러나, 그러한 요청은 사실상 큐에 제출될 수 있고, 큐잉된 상태에서 단순히 매우 적은 시간량을 소비할 것이다. 본 명세서에서의 후속 설명은 구현시에 모든 분류된 요청이 큐로 보내진다고 가정한다.)

도 1은 대기큐에서 "수행 가능 풀"(135, 140, 145)로 통과하는 입력 요청을 도시하고 있다. 이들 수행 가능 풀은 본 명세서에서 설명한 논리적 스레드풀에 상응하며, 도 1이 예시하는 바와 같이, 이들 논리적 풀에 있는 스레드는 전체 스레드 풀에서 사실상 정해진다. 양호한 실시예에서, 수행 가능 풀은 (객체 지향 언어로 본 발명을 구현할 때) 제한된 수의 실행 가능한 랩퍼 객체를 포함하며, 그 각 랩퍼 객체는 논리적 스레드 풀에 지정된 스레드 중 하나를 나타낸다. (실행 가능한 랩퍼 객체는 또한 그 스레드에 대하여 인터페이스 메커니즘을 제공한다.) 그에 따라, 스레드 수와 마찬가지로, 실행 가능한 랩퍼 객체 수는 풀(132, 140, 145)간에 다를 수 있다. (특정한 수행 가능 풀 내에서, 실행 가능한 랩퍼 객체의 수는 본 명세서에 개시하는 풀 사이즈 조율 연산을 수행하기 때문에 변할 수 있다.) 그에 따라, 반입되는 요청과 그것의 WQE는 대기 큐와 연관된 수행 가능 풀에 있는 실행 가능한 랩퍼 객체가 이용 가능해 질 때까지 대기 큐에 남아 있는다. (실행 가능한 랩퍼 객체를 이용할 수 있다면, 정의에 의해 스레드도 이용할 수 있다.) 이런 식으로, 실행 가능한 랩퍼 객체는 풀 당 스레드의 수에 대한 제한을 강요하는데 효율적이며 합리적인 방법을 제공하지만, 그러나, 여전히 실질적으로는 스레드가 정해진 단일 글로벌 스레드 풀을 사용한다. (단일 전체 스레드 풀을 사용하게 되면 별도의 물리적 스레드 풀을 유지하는 것보다 실질적으로 오버헤드가 적어진다. 이것은 풀 당 스레드 수가 변하게 되는 조율 연산 중에 주로 사실로 판명되는데, 그 이유는 별도의 물리적 스레드 풀을 사용하여 행해졌다면, 양호한 실시예에서는 스레드를 작성하여 폐기하는 것이 아니라, 논리적 풀에서 이용할 수 있는 실행 가능한 랩퍼 객체의 수를 변경하여 더 많은 혹은 더 적은 스레드를 논리 풀에 간단히 할당하기 때문이다.)

각 스레드 풀(135, 140, 145)의 사이즈는 풀이 동시에 수행해야 하도록 지정되는 타입의 작업량에 따라 변하는 것이 좋다. 선택적 풀 사이즈 조율이 (도 5, 도 6 및 도 8을 참조하여 이하에서 설명하는 바와 같이) 구현될 때, 그 풀의 사이즈는 자체 조율될 것이다. 예를 들어, 하나의 풀이 데이터베이스 액세스가 필요한 요청을 서비스하고 있고 그 요청을 최적으로 실행하기 위해서는 데이터베이스 시스템으로의 접속수가 제한되어야 한다면, 풀 사이즈는 요청의 성능을 저하시키는 사이즈 를 초과하지 않도록 자체 조율될 것이다.

각 요청이 실행 시간의 일부량을 소비하고, 그 실행 완료 시에, 요청의 스레드는 그 수행 가능 풀로 복귀되며(즉, 실행 가능한 랩퍼 객체를 반환하거나 해제됨으로써), 요청의 WQE는 갱신되어 그 실행 시간이 기록된다. 클라이언트에 의해 요청된 콘텐츠는 종래의 기술(도 1에 도시되지 않음)을 이용하여 반환된다. WQE가 통계 처리를 위해 큐잉된 후에[통계큐(155) 참조], 통계 계산 스레드는 요소 160으로 표시하는 바와 같이, 사실상 WQE를 디큐하고 그것의 데이터를 처리한다.

본 발명의 목적에 있어서, 160에서 수행되는 처리는 큐잉된 WQE로부터 대기 시간 및 실행 시간을 처리하는 단계와, 최근 최소 사용(LRU) 트리밍 프로세스를 수행하는 단계 및/또는 풀 타깃 계산을 수행하는 단계를 포함한다. 통계 계산 스레드는 배경 프로세스로서 수행되게 구현되는 것이 좋고, 타이머 구동 방식으로 호출되는 것이 좋다. 양호한 실시예에서, 시간 간격이 구성될 수 있으며 그 값은 시스템 성능을 저하시키지 않는 최소 값(예컨대, 20초)을 갖는다.

양호한 실시예에 따라, 통계 계산 스레드가 실행되고 있을 때, 통계 큐 상에 엔트리가 있다면, 그 엔트리가 디큐되어 처리된다. 다른 연산도 발생한 타임아웃에 따라, 수행될 수 있다. 양호하게는 통계 계산 스레드의 호출마다 단 하나의 타임아웃이 처리되고, 큐(155)로부터의 통계 처리를 처리하는 것이 좋다. (이 큐에 대해 입력되는 통계는 분류를 갱신시키며, 그에 따라 분류가 시간 적절한 방식으로 실제 상태를 나타내도록 신속하게 처리되어야 만하다. LRU와 풀 타깃 계산은 전체 정보에 좌우되므로, 자주 실행될 필요는 없다.)

통계 큐 처리 시에, 통계 계산 스레드는 현재 실행 및 대기 시간 정보를 포함하도록 엔트리를 디큐하고 이력 통계를 수정한다. 전술한 바와 같이, 이력 통계에 대한 레퍼런스는 큐잉된 WQE에 유지되는 것이 좋고, 그 경우에 그 값은 유효한 방식으로 쉽게 이용할 수 있다. 후자의 경우, 통계 계산 스레드는 디큐된 엔트리로부터 먼저 식별 정보(예컨대, 요청 타입, 및 다른 실시예에서는 파라미터 값과 같은 상이한 정보나 추가 정보)를 입수하고, 이전에 계산된 이력 통계에 액세스하기 위한 분류키로서 그 식별 정보를 사용한다. 이력 통계에 유지되는 대기 시간 및 실행 데이터는 디큐된 엔트리로부터 정보를 반영하도록 수정되고, 표준 편차 정보도 이 정보가 특정 구현에 사용된다면 수정될 수 있다. 양호하게는, 통계 계산 스레드는 이벤트 구동되며, 입력되는 통계가 수신될 때 웨이크업된다. 웨이크업 이벤트는 또한 타임아웃시에 트리거되는 것이 좋다. (LRU 및 풀 타깃 계산은 그 연관된 타이머의 만료시에, 절대적으로 수행되는 것이 좋다.)

LRU 트리밍 프로세스와 풀 타깃 계산의 처리를 트리거링하는데 상이한 타이머 간격을 이용할 수 있다. LRU 트리밍 프로세스가 트리거되면, 최근에 사용되지 않은 분류 데이터는 폐기되는 것이 좋고, 그 데이터에 사용된 기억 리소스는 해제되는 것이 좋다. (예컨대, 최종 사용자는 상이한 웹 페이지로 이동하게 되어도 서버의 현재 작업 부하와 관계없는 이전에 수신된 요청 타입을 확인한다. 이 경우에, 그 요청 타입의 통계를 고려하는 것은 더 이상 유익하지 않다. 또한, 그 통계는 최종 사용자의 수집에 대한 전체 정보를 나타내고, 이들 사용자의 일부는 그들의 세션을 종료할 수 있다. 이 경우에, 수집된 데이터의 일부는 더이상 그 시스템의 현 재 동작하는 상태에 관한 것이 아닐 수 있다.) 풀 타깃 계산이 트리거되면, (전술한)도 4의 처리가 호출된다. 도면 부호 160에서 다수의 목적을 위해 단일 스레드를 사용하게 되면, 전술한 상이한 타입의 처리를 위해 별도의 스레드를 사용하는 것보다 오버헤드가 최소화되고 분류 데이터와 같은 공유 리소스에 대한 경합이 저감된다.

디큐된 WQE로부터 정보를 추출하여 도면 부호 160에서 처리한 후에, WQE는 후속 사용을 위해 해제 리스트(165)에 반환될 수 있다. (또는 WQE를 위해 사용된 기억 장소는 해제될 수 있다. 양호한 실시예는 오버헤드를 줄일 시도에서 WQE를 재사용한다.) 도 1의 처리가 각 반입되는 요청에 대하여 이 방식으로 반복된다.

도 5는 본 명세서에 기재되는 풀 조율 프로세스의 실시예에 사용될 수 있는 상태 천이를 예시하는 상태도이다. 도 6 내지 도 8에 도시된 로직과 함께, 이들 천이를 사용하여 풀의 수와 각 풀의 사이즈를 조율할 때의 변화를 분리할 수 있다.

도 5에 도시하는 바와 같이, 초기 상태 "S0"에서는, 풀의 수와 풀 사이즈에 대한 변화가 없다. 이어서, 풀의 수가 다음 상태, "S1"에서 조율된다. 마지막으로, 풀 사이즈는 상태 "S2"에서 별도로 조율될 수 있다. 양호하게는, 한 상태에서 다른 상태로의 천이는 타이머 구동식이며, 이 경우에 시스템은 일부 시간 간격 동안 특정 상태가 되어, 실행시 상태의 영향을 기록하여 분석하게 한다. 양호한 실시예에서, (다음 상태 천이가 허용되기 전에 블록 620에서 "휴면(sleep)" 연산이 구현되는)도 6의 로직에 의해 예시하는 바와 같이, 타이머가 조율 프로세스에서 설정된다. 이벤트 구동되는 접근법을 이용하는 등의 다른 방식으로 천이가 트리거되는 대 안적 실시예를 설계할 수도 있다. (이 대안적 접근법에 있어서, 예컨대 상태 S2로부터 상태 S0로의 천이는 도 8이 모든 풀에 대해 풀 사이즈 조율을 완료할 때 트리거될 수 있다.)

대안적 실시예에 있어서, 상태 S1과 S2의 순서 지정은 수정될 수 있다. 또 다른 실시예에 있어서, 풀의 수를 조율하는 프로세스와 풀의 사이즈를 조율하는 프로세스를 호출하는 기술은 상태 천이도에 의해 구동되지 않아도 된다.

도 6 내지 도 8은 소정의 작업 부하에 대하여 풀 사이즈 및/또는 풀 수를 동적으로 조율하는데 사용되는 로직의 흐름도이다. 도 6은 (도 5에 도시하는 상태도를 참조하여)다음의 조율 상태를 입수함으로써 (블록 600에서) 개시된다. 다음의 상태가 "변화 없음"이라면(블록 615), 제어는 블록 620으로 옮겨지고, 그렇지 않으면, 블록 625에서 처리가 계속된다.

블록 620에서 처리가 진행될 때, 도면에서 "TUNING_SETTLE_TIME", 즉 시스템이 안정 상태로 정착하는데 필요한 시간량으로서 칭해지는 구성된 간격 동안, 휴면 또는 지연이 수행되는 것이 좋다. 블록 605는 현재 통계를 입수하고, 그 통계를 베이스라인으로 사용한 후 블록 600으로 복귀함으로써 다음 조율 연산이 수행된다.

제어가 블록 625로 옮겨진다면. 다음의 조율 상태가 풀의 수를 조율하려고 하는지를 확인하기 위해 테스트가 수행된다. 그렇다면, 블록 630에서, 풀의 수를 조율하는 프로세스가, 도 7에 보다 상세하게 도시하는 바와 같이 수행된다. 그 프로세스가 완료될 때, 제어는 블록 620으로 옮겨진다.

블록 625에서의 테스트가 부정적인 결과를 갖는다면, 블록 635는 다음의 조 율 상태가 풀의 사이즈를 조율하려는 것인지의 여부 확인을 체크한다. 그렇다면, 블록 640에서는, 풀 사이즈 조율 연산이 도 8에 상세하게 도시하는 바와 같이 수행된다. 그 프로세스가 완료될 때에, 제어가 블록 620으로 옮겨진다.

블록 635의 테스트가 부정적인 결과를 갖는다면, 이것은 에러이다. 이 에러는, 블록 610에 나타낸 바와 같이, 도 6의 조율 프로세스가 TUNING_SETTLE_TIME 간격 동안 휴면한 후에, 제어가 블록 600으로 반환됨으로써 처리될 수 있다. 이와 다르게, 조율 프로세스는 정지될 수 있다(그리고 이 경우에 에러 메시지가 시스템 관리자에게 디스플레이되는 것이 좋다).

도 6의 로직이 반복되고, 이 경우에 풀 조율 프로세스가 반복적으로 수행된다.

풀의 수가 조율되는 때에 도 6의 블록 630으로부터 도 7의 로직이 호출된다. 블록 700은 확실한 변화가 필요한 지의 여부 확인을 체크한다. 예컨대, 분류 데이터에 있는 별개의 엔트리보다 더 많은 풀이 있다고 가정한다. 다양한 타일에 대한 상한이 이 경우에 복사될 수 있으며, 또는 간단하게, 존재하는 매핑 요청 타입보다 더 많은 풀이 있을 수 있다. 이것은 잘 조율되고 적절하게 수행하는 시스템에서 일어나서는 안 되지만, 이러한 형태의 에러가 발생할 수도 있다. 일반적으로, 블록 700은 이러한 형태의 명백한 문제에 대해 "캐치 올(catch all)"로 간주될 수 있다. 그러므로, 이 테스트가 긍정적인 값을 갖는다면, 임의의 풀의 수를 조율하는 계산을 수행하는 것 대신에, 블록 705로 제어가 옮겨져서, 변화가 수행된다. 제어는 이어서 (시스템이 이 변화에 이어 안정 상태로 정착하는데 시간을 가지는)도 6의 호 출 로직으로 반환된다.

확실한 변화가 필요없다면, 블록 710에서, 시스템의 현재 작업 부하에 의해 실행되고 있는 요청 타입의 현재 통계를 획득한다. 양호하게는 이 단계는 분류 데이터의 현재 스냅샷을 획득하는 단계를 포함하고, 이 단계에서 실행 시간과 대기 시간 정보(및, 선택적으로, 표준 편차 정보)가 갱신된다. 추가 풀이 추가된다(블록 715).

블록 720는 풀 개수의 이러한 변화가 반입되는 요청의 실행 시간 및 대기 시간(및, 선택적으로 표준 편차)에 어떻게 영향을 줄 것인 지에 대한 정보를 반영하도록 분류 데이터를 갱신시키는 "SETTLE_TIME"로서 칭해지는 시간 간격 동안 휴면 또는 대기 프로세스를 실시한다. 이 SETTLE_TIME 값은 구성 가능한 것이 좋고, 도 6에서 사용된 TUNING_SETTLE_TIME 값과 같거나 다를 수 있다. 양호하게는, SETTLE_TIME 값은 도 4의 분산 계산이 휴면을 처리하는 시간 간격보다 더 길면 좋고, 이 경우에 분산 계산은 SETTLE_TIME 휴면 동안 자동으로 트리거될 것이며, 그에 따라 블록 715에 추가된 풀을 반영하도록 실행 시간이 분산되는 풀의 수를 증가된다. 이와 다르게, 분산 계산은 블록 720에서의 휴면 전에 명백하게 호출될 수 있다. 분산 계산이 연산될 때, 풀의 상한 값이 수정될 것이다. 따라서, 예컨대 시스템이 이전에 4개의 풀을 사용하고 있었지만 이제는 5개의 풀을 사용할 예정이라면, 분산 계산은 실행 시간을 4 대신에 5 그룹으로 분산할 것이다.

대기 완료시에, 블록 725에서는 분류 데이터의 스냅샷을 획득하고, 블록 730은 블록 725로부터의 스냅샷의 통계가 블록 710의 것보다 개선되었는지의 여부, 즉 더 나은 것을 위한 변화가 있었는지의 여부를 테스트한다. 그렇다면, 이 추가된 풀은 유지되고 제어는 호출 로직으로 반환된다(블록 735). 그렇지 않다면, 추가된 풀이 반입되는 요청의 실행 시간과 대기 시간을 개선하지 않았을 때, 그 풀은 제거된다(블록 775). 또한, 실행 시간의 분산은 새롭게 계산되는 것이 좋으며, 이 경우에 각 풀의 상한은 이 더 적은 수의 풀에 기초한다. (블록 715와 720을 참조하여 전술한 바와 같이, 분산 계산은 휴면 연산을 수행하기 전에 대안적으로 명백하게 수행될 수 있거나, 또는 휴면 간격이 분산 계산 간격보다 더 길다면, 새로운 분산 계산이 휴면시에 자동 발생할 것이다. 추가 대안적 실시예에서와 같이, 상한은 블록 715에서 풀의 수를 변경하기 전에 기억되고, 블록 775에 진입할 때, 이 기억된 값은 간단히 복원될 수 있다.)

블록 770에서 개시하는 처리는 풀의 수를 줄이는 것이(풀의 수를 늘리는 것보다) 실행 시간과 대기 시간을 개선시키는 가의 여부를 확인하도록 설계된다. 블록 770은 추가된 풀을 제거한 후에 시스템이 안정 상태로 복귀하게 하도록 SETTLE_TIME 간격 동안 휴면을 실시한다. 블록 765은 현재 실행하는 요청에 대한 통계의 스냅샷을 획득한다. 블록 760은 풀의 수를 감분하고, 풀 당 실행 시간의 상한은 감소된 풀의 수를 반영하도록 재계산되는 것이 좋다. 또 다른 휴면이 블록 750에서 수행된다. (블록 775에 참조하여 설명하였지만, 상한은 블록 750의 휴면시에, 휴면 간격의 적절한 선택을 통해, 휴면 전에 확실한 호출에 의해 재계산될 수 있다.) 이 휴면 간격이 만료될 때, 블록 740에서는 새로운 스냅샷을 획득하고, 블록 745에서는 이 스냅샷과 블록 765로부터의 것을 비교한다. 새로운 통계가 더 좋 다면, 시스템은 호출 로직으로 복귀함으로써(블록 735) 풀의 수를 계속해서 저감시킨다. 이와 다르게, 반입되는 요청의 실행 시간 및 대기 시간이 풀을 제거한 후에 더 좋지 못할 때, 풀이 다시 추가되고(블록 755), 스레드 풀로의 실행 시간 분산은 호출 로직으로 복귀하기 전에 더 많은 수의 풀을 사용하도록 복원된다(또는 재계산된다).

도 8의 로직은 풀 사이즈 조율을 수행할 때에 호출된다. 블록 800에서 변수 "PoolCtr"(즉, 풀 카운터 인덱스)가 도면에서 "NumPools"라고 칭해지는 현재 활성된 논리적 스레드 풀의 수로 설정된다. 처음에, 제로를 기초로 한 인덱싱 방식을 사용하기 위하여, 블록 805는 이 풀 카운터 인덱스를 감분하고, 이어서 블록 810에서는 인덱스가 제로와 같거나 그 이상인지의 여부 확인을 체크한다. 그렇지 않다면, 풀 사이즈 조율 연산은 전체 풀에 대하여 시도되었으며, 도 6의 호출 로직으로 제어가 반환된다(블록 815),

대안적 실시예에서는 각 풀의 사이즈를 조율할 필요가 없다. 예를 들어, 반복 카운터를 사용하기 때문에, 현재 사용 중인 풀의 개수와 관계없이, 도 8의 로직을 통과하는 반복 수가 제한된다. 또 다른 대안적 실시에에서는, 풀 사이즈 조율이 가장 높은 번호의 풀이 아니라 최저 번호의 풀에서 시작될 수 있다. 당업자에게는 다른 접근법을 제공하기 위해 도 8의 로직을 어떻게 변경해야 하는지 명백할 것이며, 그러한 접근법도 본 발명의 범주 내에 있다.

풀 카운터 인덱스 값으로부터, 평가해야 할 풀이 여전이 많다고 나타나면, 제어는 블록 820으로 진입하여 풀의 스레드 수를 감분하도록 "현재 조절량"을 네거 티브 값으로 설정한다. 양호하게는, 구성 가능한 값(도면에서는 "POOL_DELTA"로서 칭해짐)을 그 조절량으로서 사용한다. 이 값은 퍼센티지로 표현되거나 (스레드 수를 간단히 1씩 변경하는 것과 같은) 절대값으로서 표현될 수 있다. 특정 구현에서 어떤 접근법이 가장 유리한 지는 스레드 풀의 상대적 사이즈와 같은 인자에 좌우되며, 그 어느 접근법도 본 발명의 범주 내에 있다.

도 8에 나타낸 접근법에서는 먼저 최장의 실행 요청을 갖는 풀을 조율한 후에, 최단의 실행 요청을 가진 풀을 향해 거꾸로 진행되는 것을 주의해야 한다. 최장의 실행 요청을 갖는 풀이 풀 사이즈 조율에 보통 가장 도움을 줄 것이라고 알려져 있다.

블록 825에서는 이 풀(즉, 풀 카운터에 의해 인덱싱되는 풀)의 스레드에 의해 현재 처리되는 요청 타입에 대한 실행 통계의 스냅샷이 획득된다. 그러한 스냅샷에 대한 세부 사항에 관해서는 앞에서, 블록 710의 설명을 참조하면 된다. (블록 825에서, 통계의 서브세트는 양호한 실시예에서 입수되며, 본 명세서에서는 현재 풀로부터의 스레드에 의해 처리되는 요청 타입만 관심있다. 이와 다르게, 전체 작업 부하에 대한 통계를 사용할 수도 있다.) 블록 830은 이들 요청 타입이 풀 사이즈 조율 절차의 기간 동안 이 풀에 대해 묶여있다는 것을 알아야 한다. 블록 835는 이어서 이 풀의 사이즈를 조율하고, POOL_DELTA의 퍼센티지를 이용하는 경우에, 이 단계는 그 풀에 지정된 스레드 수를 POOL_DELTA 퍼센티지 값만큼 저감시키는 단계를 포함한다. (풀에서 스레드 수를 줄이거나 늘릴 때에, 풀 당 실행 시간에 사용되는 상한 값을 수정할 필요가 없다. 그러나, 이것은 분산 계산이 배경으로 계속 수 행될 때 사실상 발생할 수 있다. 새로운 요청 타입과 LRU 처리에 의해 폐기되는 요청 타입은 풀 사이즈 조율 간격 중에 타깃 시간에 영향을 미칠 수 있다.)

블록 840은 "POOL_ADJUSTMENT_INTERVAL"로서 칭해지는 타이머 구간 동안 휴면 또는 대기 프로세스를 실시하여 일정 시간 동안 현재 풀의 신규 변하는 사이즈 하에서 동작하게 한다. 이 POOL_ADJUSTMENT_INTERVAL 값은 구성 가능한 것이 좋고, 도 7에서 사용된 SETTLE_TIME 값과 같거나 다를 수 있다. 대기 완료 후에, 블록 845는 블록 825를 참조하여 전술한 바와 같이, 이 풀의 스레드에 의해 실행되는 요청 타입의 스냅샷을 입수하고, 블록 850은 블록 845로부터의 통계가 블록 825의 것보다 개선되었는지 확인하기 위해, 즉 그 변화가 더 나은 것을 위한 것이였는지의 여부를 확인하기 위해 테스트한다. 그렇다면, 이 저감된 풀 사이즈가 유지될 것이며, 제어는 블록 805로 반환되어, 조율되어야 다른 풀이 있는지의 여부를 판정한다.

그렇지 않다면, 감분된 풀 사이즈가 반입되는 요청의 실행 기간 및 대기 시간을 개선시키지 못할 때(즉, 블록 850에서 부정적인 결과를 가질 때), 풀 사이즈는 그 이전 사이즈로 복원된다(블록 855). 블록 860에서 시작되는 처리는 이 풀의 사이즈를 저감하는 것이 아니라 증가하게 되면 실행 시간 및 대기 시간이 개선되는지의 여부 확인을 위해 설계된다. 블록 860에서는 POOL_ADJUSTMENT_INTERVAL 동안, 휴면을 실시하여 시스템으로 그 풀 사이즈로의 복원 후에 안정 상태로 복귀하게 한다.

휴면 간격이 만료된 후에, 블록 865는 풀 사이즈를 POOL_DELTA 퍼센티지만큼 증가하도록 현재 조절량을 설정한다. 블록 870에서는 이 스레드 풀의 스레드에 의해 처리되는 현재 실행되는 요청에 대한 통계의 스냅샷을 획득한다. 블록 875에서 주지한 바와 같이, 요청 타입은 이 절차 동안 이 풀에 묶이며, 이들 요청의 처리 시에 추가 스레드의 영향이 평가될 수 있다. 블록 880은 (포지티브) 조절량만큼 이 풀의 풀 사이즈를 조절하고, 이 경우에 풀은 이제 더 많은 스레드를 갖는다. (대안적 실시예에서, 퍼센티지 상승법을 사용하기 보다, 단순한 증분 접근법을 사용할 수도 있다. 이 대안적 실시예에서는, 스레드 수가 스레드 풀 사이즈를 조율할 때 다른 증분을 사용하는 것도 본 발명의 범위 내에서 벗어나는 것은 아니지만, 1씩 증가하는 것이 좋다.)

블록 885에서는 다른 휴면이 수행된다. 이 휴면 간격이 만료될 때, 블록 892에서는 신규 스냅샷을 획득하고 블록 895에서는 이 스냅샷을 블록 870의 것과 비교한다. 신규 통계가 더 좋다면, 시스템은 계속해서 스레드의 수를 증가시키고, 블록 805로 제어가 반환되며, 더 많은 스레드 풀이 조율되어야 하는지의 여부를 확인하기 위한 테스트가 수행된다. 그렇지 않다면, 반입되는 요청의 실행 시간 및 대기 시간이 풀 사이즈를 증가한 후에 더 좋지 않을 때(즉, 블록 895에서 부정적인 결과)에는 풀 사이즈가 복원된다(블록 800). 제어가 블록 805로 반환된 후에, 다른 슬립이 시작된다(블록 805).

종래 기술의 지침을 이용하여, 어떠한 이유에서 스레드 풀을 제약하는 것이 경험적으로 시스템 성능에 유리하다고 결정할 수 있다. 예를 들어, 데이터베이스 액세스를 필요로 하는 요청을 참조하면, 한번에 개방될 수 있는 최대개의 데이터베 이스 접속이 있을 수 있다. 스레드가 제한되지 않는다면, 풀은 데이터베이스에 액세스하려고 시도하는 요청에 의해 "방해"될 수 있다. 이 시나리오를 위해 스레드 풀을 제약하는 것은 그 목적을 지원하는 것이지만, 그 시스템에서 어떤 데이터베이스 액세스도 절대 필요로 하지 않는 다른 요청들이 영향을 받는다는 부작용도 있다. 본 명세서에 개시된 자체 조율된 동적 프로세스는 시스템 관리자의 간섭없이도 이러한 형태의 영향을 해결한다.

전술한 바와 같이, 본 발명은 작업 부하의 응답 시간 특성(및 구체적으로, 그 응답 시간의 실행 시간 및 대기 시간 성분)에 기초하여, 일련의 실행 리소스에 걸쳐 작업 부하를 프로그램적으로 분산시키는 유리한 기술을 제공한다. 그렇기 때문에 멀티스레드 서버의 전체 성능이 개선되며, 최종 사용자는 그들의 다수의 요청에 대해 저감된 응답 시간으로 혜택을 받을 수 있다. 이 프로그램적 분산은 본 명세서에 개시한 풀 조율 기술과는 독립적으로 사용될 수 있고, 성능 개선은 풀의 수 및/또는 이들 풀의 사이즈가 (적어도 일시적으로) 고정되어 있을 지라도 실현될 수 있다. 또는 풀 조율 기술 중 하나 또는 두가지 모두 구현될 수 있으며, 그 기술은 추가 성능 개선을 제공할 것으로 기대될 수 있다. 개시한 기술은 각종의 입력되는 작업 부하 타입에도 유리하게 사용될 수 있다. 전술한 실시예들은 데이터의 특정 타입을 이용해서, 반입되는 요청을 분류하는 것에 대하여 설명되었지만, 이것은 예시적인 것이며 제한하려는 것이 아니다. 대체로, 메시지 큐 작업 부하는 메시지 타입 및/또는 그 메시지에 포함된 데이터(메시지의 처리 목적지 - 예컨대 처리 목적지는 반입되는 작업에 대한 제1 레벨 핸들러를 정하고, 파라미터는 큐잉된 메시간 에 서로 다른 추가 로직을 구동할 수 있음 -, 코드 경로 및 사용되는 리소스를 포함하여, 여기에 한정되지 않음)에 의해 분류될 수 있다.

본 발명은 비지니스 수행 방법을 제공할 수 있다. 예를 들어, 클라이언트/서버 네트워크 트래픽을 모니터하고, 관측에 기초해서 실행 리소스에 대해 프로그램적으로 조절함으로써 고객에서 서비스를 제공할 수 있다. 본 명세서에 개시하는 기술은 이 서비스를 수행하기 위한 소프트웨어를 구현할 때에 이용될 수 있다. 이 서비스는 사용에 따른 과금, 월간 또는 다른 주기적 과금과 같은 다양한 수입 모델 하에서 제공될 수 있다.

당업자가 이해하고 있는 바와 같이, 본 발명의 실시예들은 방법, 시스템 또는 컴퓨터 프로그램 제품으로서 제공될 수 있다. 따라서, 본 발명은 전체적으로 하드웨어 구현, 전체적으로 소프트웨어 구현, 소프트웨어와 하드웨어 특징을 조합한 구현의 형태를 취할 수 있다. 또한, 본 발명은 컴퓨터 사용 가능 프로그램 코드로 구현되어 있는, 하나 이상의 컴퓨터 사용 가능한 저장 매체(예컨대, 디스크 기억 장치, CD-ROM, 광학 기억 장치 등을 포함하며, 여기에 한정되지는 않음)에 하나 이상 포함되는 컴퓨터 프로그램 제품으로 실시될 수 있다.

본 발명은 본 발명의 실시예에 따른 방법, 장치(시스템) 및 컴퓨터 프로그램 제품의 흐름도 및/또는 블록도를 참조하여 설명하였다. 흐름도 및/또는 블록도의 각 블록과, 흐름도 및/또는 블록도의 블록의 조합은 컴퓨터 프로그램 명령에 의해 실현될 수 있음을 이해하여야 한다. 이들 컴퓨터 명령은 범용 컴퓨터와 특용 컴퓨터의 프로세서, 내장형 프로세서 또는 기타 프로그램 가능 데이터 처리 장치에 제공되어, 머신을 형성하고, 그 경우에 (컴퓨터 또는 기타 프로그램 가능 데이터 처리 장치의 프로세스를 통해 실행되는)명령은 흐름도 및/또는 블록도의 블록 또는 블록들에 명시된 기능을 실현하기 위한 수단을 생성한다.

이들 컴퓨터 프로그램 명령은 하나 이상의 컴퓨터 판독 가능한 메모리에 기억될 수도 있고, 각각의 그러한 메모리는 컴퓨터 또는 기타 프로그램 가능한 데이터 처리 장치를 특정 방식으로 기능하게 하며, 그 경우에 그 컴퓨터 판독 가능한 메모리에 기억된 명령은 흐름도 및/또는 블록도의 블록 또는 블록들에 명시한 기능을 구현하는 명령 수단을 비롯한 제조품을 생성한다.

컴퓨터 프로그램 명령은 하나 이상의 컴퓨터 또는 기타 프로그램 가능한 데이터 처리 장치상에 로딩되어, 일련의 연산 단계가 컴퓨터 또는 기타 프로그램 가능한 장치에서 수행되게 해서, 각각의 그러한 장치 상에서, 그 장치에서 수행되는 명령이 흐름도 및/또는 블록도의 블록 또는 블록들에 명시된 기능을 구현하는 단계를 제공하도록 컴퓨터 구현된 프로세스를 생성한다.

본 발명의 양호한 실시예들을 설명하였지만, 당업자라면 본 발명의 기본 원리를 습득하였다면 그 실시예에 대한 추가 변경 및 수정이 가능할 수 있다. 그러므로, 첨부하는 청구범위는 양호한 실시예와, 본 발명의 기술 사상 및 범주 내에 있는 그러한 모든 변경 및 수정을 포함하도록 의도된다.

본 발명의 효과에 있어서, 멀티스레드 서버 환경에서 소프트웨어 실행 및 리소스 사용의 효율성이 상승하면서 최종 사용자에 대한 응답 시간이 개선된다.

Claims

서버의 리소스에 걸쳐 작업 부하를 프로그램적으로 분산시키는 방법으로서,

가용 스레드 풀의 수를 결정하는 단계와,

상기 서버상에서의 작업 부하의 이력 통계로부터 상기 작업 부하의 실행 시간들을 입수하는 단계와,

상기 실행 시간들을 정렬하는 단계와,

상기 정렬한 실행 시간들을 상기 가용 갯수의 스레드 풀들에 걸쳐 할당하는 단계

를 포함하는, 작업 부하를 프로그램적으로 분산시키는 방법.
삭제
제1항에 있어서, 상기 정렬된 실행 시간들은 상기 가용 갯수의 스레드 풀들에 걸쳐 공평하게 할당되는 것인, 작업 부하를 프로그램적으로 분산시키는 방법.
제1항에 있어서, 상기 정렬된 실행 시간의 카운트를 결정하는 단계를 더 포함하고, 상기 할당 단계는,

상기 정렬된 실행 시간들의 카운트를 상기 가용 스레드 풀의 수로 나누어 "N" 값을 구하는 단계와,

인덱스로서 "N"의 정수배를 사용하여 액세스될 때 상기 정렬된 실행 시간들에 따라, 상기 가용 스레드 풀들 각각에 대해 실행 시간에 관한 상한을 할당하는 단계를 더 포함하는 것인, 작업 부하를 프로그램적으로 분산시키는 방법.
제1항에 있어서,

상기 서버에서, 수행시, 반입되는 요청을 수신하는 단계와,

상기 정렬 단계 및 상기 할당 단계에 의해 분산된 실행 시간들에 따라, 상기 반입되는 요청들을 상기 가용 스레드 풀들에 지정하는 단계를 더 포함하는, 작업 부하를 프로그램적으로 분산시키는 방법.
제5항에 있어서,

상기 서버에서 상기 반입되는 요청이 실행될 때 그 반입되는 요청의 실행 시간을 추적하는 단계와,

상기 추적한 실행 시간을 반영하도록 상기 서버상에서의 작업 부하의 실행 시간을 수정하는 단계를 더 포함하는 작업 부하 분산 방법.
제6항에 있어서, 상기 수정된 실행 시간을 반영하도록, 상기 정렬 단계 및 상기 할당 단계에 의한 실행 시간들의 분산을 주기적으로 재계산하는 단계를 더 포함하는 작업 부하 분산 방법.
제1항에 있어서, 상기 정렬된 실행 시간들은 이동 평균 실행 시간(moving average execution times)인 것인 작업 부하 분산 방법.
제1항에 있어서, 상기 실행 시간들은 요청 타입에 따라 유지되는 것인 작업 부하 분산 방법.
제1항에 있어서, 상기 실행 시간들은 요청 타입 및 파라미터 값에 따라 유지되는 것인 작업 부하 분산 방법.
제1항에 있어서, 상기 실행 시간들은 메소드명에 따라 유지되는 것인 작업 부하 분산 방법.
제1항에 있어서, 상기 실행 시간들은 메소드명 및 파라미터 값에 따라 유지되는 것인 작업 부하 분산 방법.
제1항에 있어서, 상기 실행 시간들은 메소드명, 파라미터명 및 파라미터 값에 따라 유지되는 것인 작업 부하 분산 방법.
제1항에 있어서, 상기 실행 시간들은 URI(Uniform Resource Identifier)명 및 파라미터 값에 따라 유지되는 것인 작업 부하 분산 방법.
제1항에 있어서, 상기 실행 시간들은 처리 목적지에 따라 유지되는 것인 작업 부하 분산 방법.
제4항에 있어서,

반입되는 요청을 상기 서버에서 수신하는 단계와,

상기 수신한 요청의 분류키를 결정하는 단계와,

상기 결정한 분류키를 사용해서, 상기 수신한 요청의 평균 실행 시간을 알아내는 단계와,

특정의 가용 스레드 풀을 알아내는 단계를 더 포함하며,

상기 알아낸 평균 실행 시간을 상기 지정된 상한 각각과 비교하되, 상기 비교 대상의 지정된 상한이 상기 알아낸 평균 실행 시간보다 크거나 같을 때까지 반복적으로 비교함으로써, 상기 수신한 요청을 실행하는 것인 작업 부하 분산 방법.
제1항에 있어서, 상기 스레드 풀들은 논리적 스레드 풀들인 것인 작업 부하 분산 방법.
멀티스레드 서버에서 스레드 풀에 걸쳐, 반입되는 요청을 프로그램적으로 분산시키는 시스템으로서,

가용 스레드 풀들의 수를 결정하는 수단과,

상기 서버상에서의 작업 부하의 이력 통계로부터 상기 작업 부하의 실행 시간들을 입수하는 수단과,

상기 실행 시간들을 정렬하는 수단과,

상기 정렬한 실행 시간들을 상기 가용 갯수의 스레드 풀들에 걸쳐 할당하는 수단과,

상기 서버에서, 수행시, 상기 반입되는 요청을 수신하는 수단과,

상기 정렬 수단과 상기 할당 수단에 의해 분산된 실행 시간들에 따라, 상기 반입되는 요청을 상기 가용 스레드 풀에 지정하는 수단

을 포함하는 반입 요청 분산 시스템.
삭제
제18항에 있어서, 상기 정렬된 실행 시간의 카운트를 결정하는 수단을 더 포함하고, 상기 할당 수단은,

상기 정렬된 실행 시간의 카운트를 상기 가용 스레드 풀의 수로 나누어 "N" 값을 구하는 수단과,

인덱스로서 "N"의 정수배를 사용하여 액세스될 때 상기 정렬된 실행 시간에 따라, 상기 가용 스레드 풀들 각각에 대하여 실행 시간에 관한 상한을 지정하는 수단을 더 포함하는 것인, 반입 요청 분산 시스템.
제18항에 있어서,

상기 서버에서 상기 반입되는 요청이 실행될 때 그 반입되는 요청의 실행 시간을 추적하는 수단과,

상기 추적한 실행 시간들을 반영하도록 상기 서버상에서의 작업 부하의 실행 시간들을 수정하는 수단을 더 포함하는 반입 요청 분산 시스템.
제21항에 있어서, 상기 수정된 실행 시간을 반영하도록, 상기 정렬 수단 및 상기 할당 수단에 의한 실행 시간들의 분산을 주기적으로 재계산하는 수단을 더 포함하는 반입 요청 분산 시스템.
제18항에 있어서, 상기 정렬된 실행 시간은 이동 평균 실행 시간인 것인 반입 요청 분산 시스템.
제18항에 있어서, 상기 실행 시간은 요청 타입에 따라 유지되는 것인 반입 요청 분산 시스템.
제18항에 있어서, 상기 실행 시간은 메소드명에 따라 유지되는 것인 반입 요청 분산 시스템.
제18항에 있어서, 상기 실행 시간은 URL명에 따라 유지되는 것인 반입 요청 분산 시스템.
제18항에 있어서, 상기 실행 시간은 처리 목적지에 따라 유지되는 것인 반입 요청 분산 시스템.
제20항에 있어서, 상기 상한을 지정하는 수단은,

상기 수신한 요청의 분류키를 결정하는 수단과;

상기 결정한 분류키를 사용하여, 상기 수신한 요청의 평균 실행 시간을 알아내는 수단과;

상기 알아낸 평균 실행 시간을 상기 지정된 상한 각각과 비교하되, 상기 비교 대상의 상기 지정된 상한이 상기 알아낸 평균 실행 시간보다 크거나 같을 때까지 반복적으로 비교함으로써, 상기 수신한 요청이 실행될 특정의 가용 스레드 풀을 알아내는 수단

을 더 포함하는 것인, 반입 요청 분산 시스템.
제1항 내지 제17항 중 어느 한 청구항에 따른 방법을 컴퓨팅 환경에서 구현하는 컴퓨터 프로그램을 포함하는 컴퓨터 판독 가능 기록 매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
서버의 리소스에 걸쳐 작업 부하를 프로그램적으로 분산함으로써, 비지니스를 수행하는 방법으로서,

상기 서버에서의 작업 부하의 동작적 특성을 프로그램적으로 모니터링하는 단계와;

상기 서버의 리소스들에 걸쳐 통해 작업 부하를 프로그램적으로 분산시키는 단계로서, 가용 스레드 풀의 수를 결정하는 단계, 상기 작업 부하의 이력 통계로부터 실행 시간을 입수하는 단계, 상기 실행 시간들을 정렬하는 단계와, 상기 정렬한 실행 시간들을 상기 가용 갯수의 스레드 풀들에 걸쳐 할당하는 단계와, 상기 서버에서 수행시 반입되는 요청을 수신하는 단계, 및 상기 정렬 단계 및 상기 할당 단계에 의해 분산된 실행 시간에 따라 상기 반입되는 요청을 상기 가용 스레드 풀에 지정하는 단계를 포함하는, 상기 서버의 리소스에 걸쳐 통해 작업 부하를 프로그램적으로 분산시키는 단계와;

상기 프로그램적으로 모니터링하고 상기 프로그램적으로 분산하는 단계를 수행하는데 대한 요금을 청구하는 단계

를 포함하는 비지니스 수행 방법.