KR100586283B1

KR100586283B1 - 동적 쓰레드 풀 조정 방법

Info

Publication number: KR100586283B1
Application number: KR1020030086276A
Authority: KR
Inventors: 블리드크리스토퍼제임스; 쿠오모게나로에이; 도트리에릭에이; 호그스트롬매트알
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2002-12-31
Filing date: 2003-12-01
Publication date: 2006-06-07
Also published as: US7237242B2; US20040139434A1; JP2004213624A; KR20040062393A; JP3944154B2

Abstract

다중 쓰레드 서버에서 서버의 수신 작업 부하로부터 관찰된 통계에 기초하여, 쓰레드 풀이 프로그램적으로 조정된다. 다중 쓰레드 서버 환경에서, 엔드 유저에 대한 응답 시간이 향상되며, 소프트웨어 실행과 리소스 사용의 효율성이 증가된다. 서버에 의해 서비스되는 요청의 다양한 유형에 대하여, 실행 시간과 대기/큐 대기 시간이 추적된다. 다중 논리 쓰레드 풀이 사용되어 이러한 요청에 대하여 서비스하고, 수신되는 요청은 이러한 풀들 중 선택된 풀로 향해져서, 유사한 실행 시간 요구를 가진 요청이 그 풀의 쓰레드에 의해 서비스된다. 쓰레드 풀의 개수와 사이즈는 프로그램적으로 조정될 수 있고, 분배 계산(즉, 수신 요청이 어느 풀에 할당되어야 하는지 결정하는 것)은 프로그램적으로 결정하는 것이다. 바람직한 실시예에서, 이러한 변수 중 하나만이 한번에 조정되고, 결과를 모니터링하여, 효과가 긍정적인지 부정적인지 결정한다. 개시된 기술은 메서드 이름(및 선택적으로 파라미터)으로 요청을 추적하고 분류하는 것에 적용된다.

동적 조정, 쓰레드 풀, 요청 유형, 작업 부하, 다중 쓰레드 서버

Description

동적 쓰레드 풀 조정 방법 {DYNAMIC THREAD POOL TUNING TECHNIQUES}

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

도 2 내지 도 4는 본 발명의 바람직한 실시예에서 어떤 요청 유형이 어떤 쓰레드 풀에 할당되어야 하는지 결정할 수 있는지를 나타내는 흐름도.

도 5는 본 발명의 실시예들과 함께 사용될 수 있는 상태 전이를 나타내는 상태도(이 전이는 도 6 내지 도 8의 로직과 조합하여 사용될 수 있음).

도 6 내지 도 8은 바람직한 실시예들에 따라 각 풀의 사이즈와 각 풀의 개수를 조정할 때 변화를 분리시키는 로직을 나타내는 도면.

본 발명은 컴퓨터 소프트웨어에 관한 것으로서 보다 구체적으로는 (예를 들어, 다중 쓰레드 서버 환경에서 서버 작업 부하의 균형을 맞추기 위하여) 실행 시에 쓰레드 풀을 프로그램적으로 조정함으로써 사업을 행하는 방법, 컴퓨터 프로그램 제품, 시스템, 및 방법에 관한 것이다.

사업이 성장하고 고객들이 공공 인터넷 및 "월드 와이드 웹"(또는 간단히 "웹")이라고 알려진 인터넷의 부분 집합을 사용함에 따라, 최근 클라이언트/서버 컴 퓨팅은 상당히 보편화되었다. 회사 인트라넷과 익스트라넷과 같은 다른 유형의 클라이언트/서버 컴퓨팅 환경도 점점 더 보편화되고 있다. 솔루션 제공자들이 향상된 웹 기반 컴퓨팅을 제공하는데 초점을 맞추고 있기 때문에, 개발되는 많은 솔루션들이 다른 클라이언트/서버 컴퓨팅 환경에 적용될 수 있다. 따라서, 본 명세서에서 인터넷과 웹을 언급하는 것은 설명의 목적일 뿐이며, 이에 한정되는 것은 아니다. (또한, 본 명세서에서 "인터넷", "웹", "월드 와이드 웹"이란 용어는 서로 혼용된다.)

많은 사람들이 매일 인터넷을 사용하는데, 개인적인 오락의 목적, 사업 목적, 또는 둘 다 때문에 사용한다. 전자적인 정보와 비즈니스 서비스의 고객으로서, 사람들은 이제 전세계적인 차원에서 소스(source)를 쉽게 액세스할 수 있다. 사용자가 인터넷을 통하여 소프트웨어 애플리케이션과 서로 상호 작용하고 콘텐츠를 요청할 때, 돌아오는 응답의 지연 또는 비효율성은 사용자 만족에 매우 부정적인 영향을 줄 수 있고, 심지어는 사용자들이 다른 소스로 옮겨가도록 할 수도 있다. 따라서, 요청된 콘텐츠를 신속히 그리고 효율적으로 전달하는 것은 사용자의 만족도에 있어 매우 중요하고, 따라서 네트워크의 서버 측의 시스템이 가능한 한 효율적으로 동작하도록 보장하는 것이 중요하다.

지금까지의 경험은, 이러한 유형의 환경에서 다양한 클라이언트에 대한 요청을 처리하는 애플리케이션 서버에 있어서, 수신되는 다양한 요청에 대하여 최상의 쓰루풋과 응답 시간을 제공하기 위하여 리소스의 사용을 제한하는 것이 일반적으로 필요하다는 것을 보여주었다. 관심의 대상이 되는 주요 리소스들 중 하나는 실행 쓰레드(본 명세서에서 간단히 "쓰레드"라고 부름)이다. 쓰레드를 제한 없이 생성하고 사용하고 파괴하는 것은 당업계에 알려진 여러 가지 이유로 응답 시간과 쓰루풋 모두에 악영향을 끼칠 수 있다. 예를 들어, 너무 많은 쓰레드가 생성된다면, 쓰레드를 관리하는 시스템 오버 헤드가 감당할 수 없을 만큼 크고, 시스템 상태와 이러한 쓰레드에 대한 다른 정보를 저장하는데 너무 많은 메모리가 필요할 수 있다. 또한, 공유하고 있는 리소스를 차지하기 위하여 경쟁하는 것은 이용 가능한 쓰레드의 수를 제한하는 주요 이유가 된다. 왜냐하면, 제한된 리소스를 위하여 많은 수의 쓰레드가 큐에 대기하는 것은 일반적으로 이러한 리소스에 대한 쓰레싱(thrashing)을 초래하기 때문이다. 그러나, 반대로 너무 적은 수의 쓰레드가 이용 가능하다면, 들어오는 요청이 쓰레드에 할당되기까지 오랜 시간 동안 기다려야 할 수 있으므로, 엔드 유저에 대한 응답 시간을 증가시킨다.

따라서, 시스템에서 쓰레드의 수를 조정하는 것은 유용하다. 생성되었지만 아직 파괴되지는 않은 쓰레드의 집합을 본 명세서에서는 "쓰레드 풀(thread pool)"이라 부른다. 특정한 클라이언트/서버 환경에서 쓰레드 풀을 위하여 생성될 쓰레드의 수는 서버를 초기화할 때 종종 사용자(예를 들어, 시스템 관리자)에 의해 구성(configuration) 파라미터로서 지정된다. 일반적으로, 주어진 애플리케이션 집합에 대한 쓰레드 풀 크기를 조정하는 것은, 쓰루풋과 응답 시간을 향상시키려고 쓰레드 풀의 사이즈를 재조정하도록, 애플리케이션이 적당히 또는 심하게 구동되는 환경에서 반복적인 연산을 하는 것이다.

성격이 비슷한 작업 부하의 경우에 요청들은 종종 전체적인 시스템 응답 시 간이 매우 유사할 것이고, 따라서, 쓰레드 풀의 사이즈를 반복적으로 조정하는 것은 시스템의 성능을 향상시키는데 효과가 좋다. 마찬가지로, 작업 부하가 요청 유형이 혼합되어 있지만 이 다양한 요청들이 유사한 응답 시간을 가지고 있을 때, 이러한 유형의 사이즈 조정 동작은 매우 효과가 좋다. 그러나, 응답 시간이 매우 다양한 작업 부하들이 섞여 있을 때, 문제는 좀 더 복잡해진다.

제한된 수의 쓰레드를 가진 단일 쓰레드 풀이 다양한 평균 응답 시간을 가진 요청 유형들로 구성된 작업 부하와 사용될 때, (평균적으로) 요청들이 합리적인 시간 내에 처리되는, 쓰레드 풀에 대한 "최선의 사이즈(best size)"를 구할 수 있다. 그러나, 혼합된 작업 부하에 대하여 이렇게 단일 쓰레드 풀을 사용하는 것은 차선이다. 특히, 이러한 방식은 더 짧은 실행 시간을 가진 요청들의 응답 시간을 불균형적으로 증가시킨다.

이러한 현상이 나타나는 이유는 전술한 바와 같이 애플리케이션 서버의 단일 쓰레드 풀을 제한하는 것이 이 애플리케이션 서버 내에서 리소스 이용을 제어하는데 중요한 반면, 단일 쓰레드 풀은 또한 더 긴 실행 시간을 가진 요청들로 포화되는 경향이 있어, 더 짧은 실행 시간을 가진 요청들은 사실상 결핍을 느끼게 될 것이다(starved). 더 긴 실행 시간을 가진 요청들의 버스트는 본질적으로 더 짧은 실행 시간을 가진 요청들이 단일의 제한된 쓰레드 풀로부터의 쓰레드로 할당되는 것을 방해한다. 그리고, 일단 쓰레드가 쓰레드 풀로부터 할당되었다면 특정한 요청이 그 쓰레드에 의해 매우 신속하게 처리되었을지라도, 이 요청은 쓰레드가 할당되기 전에 매우 오랜 시간 동안 기다려야 했을 수도 있다. 따라서 이러한 요청에 대하여 엔드 유저(또는 더 일반적인 경우 요청자)가 인식하는 응답 시간은 지나치게 길 수가 있다.

이러한 종래 기술의 문제점을 극복하는 기술이 필요하다.

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

본 발명의 다른 목적은 다중 쓰레드 서버의 성능을 향상시키는 것이다.

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

본 발명의 다른 목적은 다중 쓰레드 서버 환경에서 동적으로 작업 부하의 균형을 맞추는 기술을 규정하는 것이다.

본 발명의 다른 목적은 다양한 평균 응답 시간을 가지는 작업 부하에 대한 서버 성능을 향상시키기 위하여 쓰레드 풀을 동적으로 조정하는 기술을 규정하는 것이다.

본 발명의 다른 목적은 더 짧은 실행 시간을 필요로 하는 요청들이 실행 대기 시간이 더 짧을 수 있도록 하는 기술을 규정하는 것이다.

본 발명의 다른 목적은 짧은 실행 시간을 가지는 요청에 대한 응답 시간을 줄이기 위하여 실행 리소스의 집합에 걸쳐 작업 부하를 프로그램적으로 분배하는 기술을 규정하는 것이다.

본 발명의 다른 목적 및 장점은 일부는 뒤따라 나오는 발명의 상세한 설명과 도면에 설명되어 있고, 일부는 발명의 상세한 설명으로부터 명백해질 것이며, 또는 발명의 실시에 의해 알게 될 수도 있을 것이다.

전술한 목적을 달성하기 위하여, 그리고, 여기서 넓게 설명된 본 발명의 목적에 따라, 본 발명은 다중 쓰레드 서버의 쓰레드 풀을 동적으로 조정하는 방법, 시스템, 컴퓨터 프로그램 제품을 제공한다. 바람직한 실시예에서 이 기술은 다중 쓰레드 서버에서 동적으로 변하는 작업 부하에 대한 기준 런 타임 통계를 축적하는 단계로서, 이 기준 통계는 동적으로 변하는 작업 부하의 첫 번째 복수의 요청을 실행하는 것에 관한 것이고, 이 요청들은 복수의 쓰레드 풀에 의해 서비스되는 것인 상기 축적 단계와; 이 쓰레드 풀들을 프로그램적으로 변경하는 단계와, 동적으로 변하는 작업 부하에 대한 새로운 런 타임 통계를 축적하는 단계로서, 이 새로운 통계는 동적으로 변하는 작업 부하의 두 번째 복수의 요청을 실행하는 것에 관한 것이고, 이 요청들은 프로그램적으로 변경되는 쓰레드 풀에 의해 서비스되는 것인 상기 축적 단계와; 새로운 런 타임 통계와 기준 런 타임 통계의 비교가 프로그램적인 변경의 결과로 성능이 저하되었음을 나타낸다면, 프로그램적인 변경을 프로그램적으로 반전시키는 단계를 포함한다. (또한, 만일 변경의 결과로 성능이 향상되지 못한다면, 이 변경이 프로그램적으로 반전될 수 있다.)

바람직하게는 쓰레드 풀은 물리적 쓰레드 풀을 논리적으로 조직화하여 그룹화한 것이다.

프로그램적인 변경은 또한 동적으로 변하는 작업 부하를 서비스하기 위하여 추가적인 쓰레드 풀을 추가하는 단계를 더 포함할 수 있다. 이 경우에, 조정은 또한 새로운 런 타임 통계를 축적하는 단계 이전에, 추가된 쓰레드 풀을 고려하여, 동적으로 변하는 작업 부하를 복수의 쓰레드 풀로 할당한 것을 프로그램적으로 재조정하는 단계를 더 포함할 수 있다. 이 프로그램적인 재조정은 또한 쓰레드 풀에 의해 서비스될 요청들의 실행 시간에 대한 상한선을 계산하는 단계를 더 포함할 수 있다. 프로그램적인 반전은 추가된 쓰레드 풀을 프로그램적으로 제거하고, 제거된 쓰레드 풀을 고려하여 동적으로 변하는 작업 부하를 복수의 쓰레드 풀로 할당한 것을 재조정하는 단계를 더 포함할 수 있다.

기준 런 타임 통계와 새로운 런 타임 통계는 바람직하게는 변하는 작업 부하를 포함하는 요청들을 서비스하는데 걸리는 평균 실행시간과 평균 큐 대기 시간이고(이 숫자들의 표준 편차를 포함할 수 있음), 요청 유형에 따라, 요청 유형과 파라미터 값에 따라, 요청 유형과 파라미터 이름과 파라미터 값에 따라, 메서드 이름에 따라, 메서드 이름과 파라미터 값에 따라, 메서드 이름과 파라미터 이름과 파라미터 값에 따라, URI 이름에 따라, URI 이름과 파라미터 값에 따라, 및/또는 처리 목적지에 따라, 다양한 방식으로(이에 한정되는 것이 아님) 유지될 수 있다.

프로그램적인 변경 단계는 또한 동적으로 변하는 작업 부하를 서비스하는 복수의 쓰레드 풀로부터 하나의 쓰레드 풀을 제거하는 단계를 더 포함한다. 이 경우에, 조정은 새로운 런 타임 통계를 축적하기 전에, 제거된 쓰레드 풀을 고려하여 동적으로 변하는 작업 부하를 복수의 쓰레드 풀로 할당한 것을 재조정하는 단계를 더 포함한다. 프로그램적인 반전은 다른 쓰레드 풀을 프로그램적으로 추가하고, 추가된 쓰레드 풀을 고려하여 동적으로 변하는 작업 부하를 복수의 쓰레드 풀로 할당한 것을 재조정하는 단계를 더 포함한다.

프로그램적인 변경 단계는 새로운 런 타임 통계를 축적하기 전에 쓰레드 풀들 중 선택된 것에 할당된 쓰레드의 수를 증가시키는 단계를 더 포함하고, 프로그램적인 반전 단계는 쓰레드 풀들 중 선택된 쓰레드 풀에 할당된 쓰레드의 수를 감소시키는 단계를 더 포함한다. 프로그램적인 변경 단계는 새로운 런 타임 통계를 축적하는 단계 이전에, 쓰레드 풀들 중 선택된 쓰레드 풀로 할당되는 쓰레드의 수를 감소시키는 단계를 더 포함하고, 프로그램적인 반전 단계는 쓰레드 풀들 중 선택된 쓰레드 풀로 할당된 쓰레드의 수를 증가시키는 단계를 더 포함한다.

본 발명은 사업 방법을 제공한다. 예를 들어, 서비스가 고객에게 제공됨으로써 그들의 클라이언트/서버 네트워크 트래픽의 동작 특성이 모니터링되고, 쓰레드 풀 할당에 대한 조정이 이 모니터링에 기초하여 프로그램적으로 행해진다. 이 서비스는 사용에 따른 과금, 월별 과금 또는 다른 주기적인 과금 등과 같이, 다양한 수익 모델 하에 제공될 수 있다.

이제 본 발명에 대하여 뒤에 첨부된 도면을 참조하여 설명하겠다. 본 명세서에 걸쳐 유사한 참조 번호는 동일한 구성 요소를 나타낸다.

본 발명은 클라이언트/서버 네트워킹 환경의 다중 쓰레드 서버에서 실행 리소스의 집합에 걸쳐 수신되는 요청을 동적으로 그리고 프로그램적으로 분산한다. 바람직한 실시예에서 실행 리소스는 쓰레드이고, 이러한 쓰레드는 복수의 쓰레드 풀로 논리적으로 조직화된다. (이용 가능한 쓰레드의 집합은 하나의 물리적 풀로부터 오는 것으로 생각할 수 있으며, 이 물리적 풀은 복수의 논리적 풀로 그 후 세분된다. 이하에서 도 1의 구성 요소 135, 140, 145, 150에 대하여 설명한다. 참조의 편의를 위하여, 논리적으로 조직화된 풀을 여기서 단순히 쓰레드 풀이라고 칭하고, 하나의 물리적 풀을 "글로벌(global)" 쓰레드 풀이라고 칭한다.)

프로그램적인 요청 분배 프로세스는 바람직하게는 어느 수신 요청이 어느 풀에 할당되어야 하는지 프로그램적으로 결정하는 것을 포함하고(필요하다면, 요청들이 그 풀에 대한 대기 큐로 들어올 것임), 선택 사양으로서 더 개선된 방식에서는 사용중인 쓰레드 풀의 개수 및/또는 사이즈가 또한 프로그램적으로 조정될 수 있다. 프로그램적인 분배 프로세스의 바람직한 실시예에서, 본 발명은 요청들이 실행될 때 이들을 추적하고, 요청 유형별로 평균 실행 시간과 대기 시간을 결정하며, (바람직하게는 각 풀에서 처리될 요청에 대한 평균 실행 시간에 대한 상한선을 결정함으로써) 특정 풀로 요청을 할당하는 것을 동적으로 조정한다. 풀에서 쓰레드 풀의 개수 및/또는 쓰레드의 개수를 동적으로 조정하는 바람직한 실시예에서, 이러한 변수(풀 당 평균 실행 시간의 상한선, 쓰레드 풀의 개수, 및 풀에서 쓰레드의 개수) 중 하나만이 한번에 조정되고, 효과가 긍정적인지 부정적인지 결정하기 위하여 다른 스냅샷을 찍는다.

종래 기술에 따라 하나로 제한된 쓰레드 풀을 사용하는 경우에 문제점은 이미 설명되었다. 종래에 알려진 이러한 문제점에 대한 한가지 해결책은 작은 수(이 숫자는 통계적으로 미리 정해짐)의 쓰레드 풀을 설정하고, 각 풀에 들어올 수 있는 요청 유형을 수동으로 구성하는 것이다. 다른 모든 요청이 "다른 모든" 풀에 의해 처리될 수 있다. 이러한 방식은 시스템의 프로파일링이 이 메카니즘으로부터 이익 을 받는 요청 유형이 어느 요청 유형인지 결정하고, 요청 유형을 풀에 맵핑하는 것을 나타내는 사이드 테이블을 수동으로 작성하도록 요구한다.

이 방법에는 장점과 단점이 있다. 한가지 장점은 어떤 집합의 요청이 큐 시간이 비정상적으로 길어지고 실행 시간이 다른 모든 요청 유형에 비하여 충분히 짧다고 인식되는 경우, 이 정보를 적절히 이용할 수 있고 이러한 요청들을 특정 쓰레드 풀로 인도할 수 있는 런 타임까지 인식될 때, 이 인식된 요청의 집합은 아마 향상된 응답 시간을 얻을 수 있다. .

그러나, 이 방법은 단점이 장점을 능가한다. 첫째 이 방법은 (웹 애플리케이션에서 만나는 것과 같은) 요청 스트림의 변화 특성을 고려하지 않는 것이다. 요청 유형의 맵핑을 포함하는 하드 코딩된 테이블은 시작이 잘못되거나, 아니면, 오버 타임이 변화될 필요가 있을 가능성이 크다. 그 이유는 원래 측정된 코드의 특성이 변화되었거나 아니면 새로운 코드가 시스템의 다이나믹스를 변화시켰기 때문이다. 알 수 있는 바와 같이, 정보가 시작이 잘못되지 않았다 할지라도, 어떤 경우라도 정보는 매우 빨리 낡은 정보가 될 확률이 크다.

본 발명의 바람직한 실시예에서 사용되는 것인 더 나은 해결책은 주어진 유형의 요청에 대하여 평균 실행 시간과 대기 시간을 추적하고, 그 후 그 실행 시간에 따라 각 유형의 요청을 쓰레드 풀에 할당하는 것이다.

애플리케이션 서버에 의해 처리되는 다양한 요청 유형에 대한 평균 실행 시간을 추적함으로써 이러한 요청 유형을 실행 시간이 비슷한 여러 개의 카테고리로 그룹화하는 것이 가능하다. 한가지 방식에서 실행 시간의 주파수 분배 대역을 구 축함으로써 카테고리가 결정될 수 있다. 바람직한 실시예에서 사용되는 단순한 구현 방법은 이용가능한 쓰레드 풀의 (미리 정해진) 개수를 정하고, 축적된 실행 시간을 사용하여 요청 유형을 이러한 수의 쓰레드 풀에 걸쳐 나눔으로써, 대역을 계산할 수 있다. 이는 또한 통계 타일(tile)을 계산하는 것이라고 부를 수 있는데, 여기서 타일 값(즉, 각 특정한 대역의 상한선)은 각 풀에 허용된 최대 실행 시간이 될 것이다. 타일 값을 계산하고, 어느 실행 시간이 각 타일에 해당하는지 확인하는 맵핑(또는 유사한 관련) 테이블을 생성하는 프로세스를 여기서는 "분배 계산(distribution calculation)" 또는 "풀 목표 계산(pool target calculation)"이라 부른다. 이 정보를 사용하여 새로 도착하는 수신 요청이 어디로 향할 것인지 결정하는 프로세스를 여기서는 요청을 "분류(classify)"하는 것이라고 부른다. 실행 시간의 상한선을 결정하는데 사용되는 축적 데이터는 여기서 일반적으로 "분류 데이터"로 불리고, 이하에서 더 자세히 설명할 다른 정보 뿐만 아니라 각 요청 유형에 대한 평균 실행 시간을 포함한다.

예를 들어, 분류 데이터에 10000 개의 실행 시간이 있고, 10 개의 쓰레드 풀이 사용될거라면, 1000 개의 가장 짧은 실행 시간을 가진 요청 유형들은 제1 풀로부터의 쓰레드들에 의해 처리될 수 있고, 1000 개의 가장 긴 실행 시간을 가진 요청 유형들은 마지막(10번째) 풀에 의해 처리될 수 있다. 본 발명자들은 분배 계산이 각 실행 시간 대역 내에 해당하는 요청들의 이력적 빈도를 자동적으로 고려하기 때문에, 풀 사이즈가 알려진 경우에 이러한 방법이 잘 동작한다는 것을 알아냈다. 도 1을 참조하면, 바람직한 실시예들에 따라 어떻게 요청들을 쓰레드 풀로 분류하 는지 또는 어떻게 요청들을 쓰레드 풀로 런 타임시 인도하는지에 대한 세부 사항이 도시되어 있다.

실험을 통하여, 복수의 논리적 쓰레드 풀을 이용하는 것은 전체적인 응답 시간과 쓰루풋에 도움이 된다는 것이 밝혀졌다. 전술한 바와 같이, 종래 기술에서는 요청들을 복수의 풀에 동적으로 할당한다. 정적(static) 할당의 단점이 이미 설명되었는데, 본 발명의 동적 분류 및 분배 계산 방법에 의해 이러한 단점을 피할 수 있다. 여기서 개시된 기술은 풀 사이즈 및/또는 풀의 개수를 주어진 작업 부하로 동적으로 조정할 수 있게 한다. (어떻게 이렇게 조정이 이루어지는지에 대한 자세한 내용은 도 5 내지 도 8을 참조하여 아래에서 설명한다.)

쓰레드 풀의 수를 동적으로 조정하는 기술이 사용되지 않을 때, 바람직한 실시예들의 동작 동안 사용되는 풀의 개수는 바람직하게는 소정의 수(외부에서 조정할 수 있는 값임)로 할당된다. 시스템의 동작을 관찰함으로써 풀의 개수가 동적으로 결정될 때, 바람직하게는 반복적인 방법이 사용되는데, 이하에서 설명한다. 후자의 경우, 초기에 사용될 풀의 개수 (및 풀 사이즈)는 종래 지식(예를 들어, 가장 최근에 사용된 값에 대한 저장된 상태 정보임, 이것은 동적으로 결정되었을 수 있음)에 의해서 결정되거나, 최초 디폴트 구성으로 시작된다.

요청 유형을 풀에 분배하는 것을 동적으로 재계산할 뿐만 아니라, 풀의 개수와 풀의 사이즈를 동적으로 조정할 때, 이러한 유형의 런 타임 조정은 3차원적인 문제로 접근될 수 있다. 하나의 차원은 요청 유형의 관련된 실행 시간에 대한 타일을 계산하는 것이고, 다른 차원은 풀의 개수를 조정하는 것이며, 또다른 차원은 풀의 사이즈를 조정하는 것이다. 이러한 프로세스는 상기 조정의 측면 간에 상호작용 때문에 더 복잡해진다. (요청들을 프로그램적으로 분배하는 것에 대한 타일 값을 계산하는 것은 그 자체로 일종의 조정이고, 따라서, 여기서 사용되는 "조정"이란 용어는 문맥에서 달리 표현하지 않는 한, 풀 개수와 풀 사이즈 조정 프로세스만을 독점적으로 의미하려고 한 것이 아니라는 것을 유의해야 한다.) 예를 들어, 풀의 사이즈를 변경하거나, 풀의 개수를 변화시키는 것은 풀에 지정된 요청들의 실행 시간에 복수 영향을 미친다. 차례로 이것은 다양한 요청 유형들을 상이한 대역으로 보낼 수있다. 이를 설명하기 위하여, 4 개의 대역을 가진 구성이 있고, 제3 대역(두 번째로 가장 긴 요청이 서비스됨)이 "T" 개의 쓰레드를 가지고 있다고 가정하자. 또한, 이러한 수의 쓰레드를 사용하여 제3 대역 내의 요청들이 어떤 하한선 "LB(3)"으로부터 어떤 상한선 "UB(3)"에 이르는 시간 간격 동안 실행을 완료한다고 가정하자. 만일 제3 대역에 대하여 쓰레드의 개수, T가 변경된다면, 제3 대역으로 보내진 어떤 요청 유형에 대한 실행 시간은 [LB(3)...UB(3)]의 범위를 벗어날 수 있다. 이것은 여기서 사용된 방법에 의해 이러한 요청 유형이 더 이상 제3 대역에 속하지 않는다는 것을 의미한다. 그러나, 이들을 다른 대역으로 옮기는 것은 도미노 효과를 가질 수 있고, 이에 따라 그 대역 내의 요청들의 실행 시간이 변경된다(이는 추가적인 요청 유형이 다른 대역들로 이동될 필요가 있을 수 있다는 것을 나타냄). 이러한 효과를 제어하기 위하여, 바람직한 실시예에서는 실행 시간 (및 그 시간 양 동안 실행하기 쉬운 요청 유형들)을 풀 사이즈 조정 프로세스 동안 특정 실행 대역과 결합시키고, 후속적인 분배 계산(즉, 이로부터 유도된 실행 데이터의 후속적인 분석 및 맵핑의 정정)이 일어나는 경우에만 이들을 재결합한다. 분배 계산은 일반적으로 풀 사이즈 조정과 함께 일어난다는 것을 유의해야 한다(또한, 바람직하게는 실행 시간이 묶여있지 않을 때 풀 카운트 조정과 함께 일어난다). 바람직한 실시예에서, 이 결합은 요청 유형의 분류 데이터 내의 플래그를 사용함으로서 수행되고, 결합 플래그는 풀 사이즈 조정이 완료된 다음에 클리어된다.

다음과 같이 많은 수의 동적 원소를 다중 쓰레드 환경에서 볼 수 있다.

DE1: 주어진 요청 유형의 실행 시간은 그것이 사용하는 리소스에 따라 그리고, 선택한 코드 경로에 따라, 변경될 수 있다.

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

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

DE4: 실행 시간의 분배는 다시 계산될 수 있고, 결과적으로 다양한 요청 유형이 대역을 변경할 수 있다.

DE5: 대역의 수와 대응 풀의 수는 변경될 수 있다.

위에 나열된 동적 원소를 참조하면, DE1과 DE2는 조정 프로세스와 독립적이라는 것을 유의해야 한다. 사실, 이들은 동적 조정 능력을 요구하는 주된 이유이다. 그렇지 않은 경우, 요청 유형들을 대역으로 분배하는 것은 한번 계산되어, 그냥 내버려두어질 수 있다. (마찬가지로, DE1과 DE2가 없는 경우에 풀 사이즈와 풀 의 개수를 동적으로 조정함으로써 이득이 거의 얻어지지 않거나 전혀 얻어지지 않을지도 모른다.) 또한, 동적 원소 DE3, DE4, DE5는 직접 조정 프로세스로 돌릴 수 있다는 것을 유의해야 한다. 이러한 관찰들이 여기서 개시된 조정 기술에 의해 사용되어서, 조정 프로세스를 성공적으로 이끈다.

따라서, 여기서 개시된 동적 분배 및 조정 기술은 동적 원소 집합에 걸쳐 균형을 이루도록 설계되어 있다. 가능한 한 작은 오버헤드를 초래하기 위하여, 패스 길이, 경쟁, 조정의 빈도가 바람직하게는 최소화된다. 조정시 상호 작용과 도미노 효과를 피하기 위하여, 바람직한 실시예에서는 한번만 변경을 하고, 시스템이 어떤 시간 간격 동안 이러한 상태로 실행할 수 있도록 하며, 변경의 효과를 측정한다. (이러한 방법이 변경의 긍정적 효과 또는 부정적 효과를 단절시키는데 유리할지 몰라도, 조정 프로세스의 전체적인 지속 시간을 연장시킬 수 있다. 따라서, 절대적으로 필요하지 않는 한, 최대 대역 수를 처음에 상대적으로 작은 수로 설정하는 것이 이롭다. 바람직하게는 시스템이 클수록, 이러한 최대 수가 더 커질 것이다.)

본 발명의 조정 방법의 세 가지 주요 목적은 다음과 같다.

G1: 안정된 작업 부하의 혼합을 위하여 가능한 한 빨리 준 정상 상태(quasi-steady state)에 도달하려고 시도하는 것

G2: 과도한 제어에 의해 초래될 수도 있는 실행 시간의 과격한 변동을 피하는 것

G3: 이용 가능한 쓰레드 리소스와 수신되는 요청의 실행 시간 간에 균형을 이루는 것

이러한 목적을 달성하기 위하여, 시스템에 의해 처리된 요청들에 대한 실행 시간과, 대기 시간 또는 큐 시간에 대한 이력 통계를 보유하는 것이 필요하다. 따라서, 본 발명은 전술한 바와 같이 이 정보를 추적한다. 조정 동안 이루어진 결정은 이러한 원소에 대하여 알려진 현재 값 대 과거 값의 비교에 기초하여 평가될 수 있다. (변경 값의 수정은 바람직하게는 새로운 유형의 요청들과 현재의 요청의 속도의 변화(속도 0을 포함)에 대하여 시스템의 동적 특성을 고려할 것이다. 새로 만난 요청 유형은 도 2와 도 3을 참조하여 아래에서 설명하는 바와 같이, 본 발명의 분류 프로세스의 실시예에 의해 자동적으로 처리된다. 특정한 요청 유형에 대한 도착 속도의 변화는 분배 계산에 의해 자동적으로 조정되어서, 실행 시간의 상한선 대 풀 맵핑을 변경할 수 있다. 도착 속도의 변화는 또한 이러한 요청 유형을 서비스하는 쓰레드 풀 사이즈를 프로그램적으로 조정하는 것을 초래할 수 있다.

동적인 작업 부하의 분배와 풀 조정을 고려할 때 즉각적으로 나타나는 어려움은 대부분의 실제 애플리케이션 서버가 밀폐 시스템이 아니라는 사실이다. 즉, 요청에 의해 나타나는 실행 시간과 큐 시간이, 수행되는 작업의 유형에 따라 다운 스트림의 영향력과 업스트림의 영향력에 의해 종종 영향을 받는다. 예를 들어, 특정한 요청 유형이 원격 호출(예를 들어, 데이터베이스 호출)을 하고, 그 실행 시간이 이 호출된 리소스의 이용가능성 또는 이 호출된 리소스에 대한 경쟁에 따라 변동이 심할 수 있다.

본 발명은 이러한 효과를 처리하기 위하여 복잡한 피드백 시스템을 구축하려 고 시도하는 것보다, 바람직하게 필터링 메카니즘을 적용하는데, 이러한 필터링 메카니즘은 풀에 따른 실행 시간의 상한선, 풀의 개수, 및 풀 당 쓰레드의 개수에 대한 변화가 없을 때 실행 시간 및 대기 시간의 두개 이상의 스냅을 찍는 단계를 포함한다. 이러한 스냅으로부터 모아진 데이터는 조정과 무관하게 변동하는 요청들(즉, 정상적으로 변화하는 요청들)을 검출하려는 시도로 비교된다. 만일 요청이 변화하지 않는다면, 이것은 이 프로세스에서 "필터링 아웃(filtered out)"된다. (즉, 만일 요청이 표준 편차 내에 있다면, 이 요청에 관한 더 나은 성능을 위하여 시스템을 조정하려고 시도하는 것이 유용하지 않을 수 있다.) 바람직하게는, 필터링 메카니즘은 통계학적인 방법을 적용하고, 요청 유형이 변동이 있는지 여부를 결정하기 위한 기준으로서 요청에 따라 표준 편차를 사용한다. 조정의 변화가 없을 때 표준 편차가 상대적으로 큰 실행 시간 패턴을 가진 모든 요청 유형은 통상적인 변동(normally-fluctuating) 요청 유형으로서 취급된다. 예를 들어, 하나 이상의 요청 유형에 대한 실행 시간 데이터는 조정 변동이 이루어지지 않은 샘플링 간격 후에 분석될 수 있다. 이러한 요청 유형의 각각에 대한 표준 편차가 이러한 "변동 없는(no-change)" 간격 동안 계산될 수 있다. 그 시간 간격 동안 조정 변화가 활성화되어 있었던 다른 시간 간격 동안 모여진 데이터는 조정 변화가 있는 경우에 요청 유형의 표준 편차를 결정하는 것과 비슷한 방식으로 분석될 수 있다. 변동 없는 간격 동안 특정한 요청 유형에 대한 표준 편차와 조정 변동 간격동안의 표준 편차를 비교함으로써 이 요청 유형의 실행 시간에 대한 조정 변화의 영향에 대하여 추정을 할 수 있다. (이 프로세스 동안, 정상적으로 변동하지 않는 걸로 결정된 요청 유형들에 촛점을 맞추는 것이 유용할 수 있다.)

변동은 (매우 크게 변할 수 있는) 외부 대기 시간 뿐만 아니라, 내부 경쟁에 의해서도 초래될 수있다는 것을 유의해야 한다. 이러한 문제를 나타내는 요청들에 대한 쓰레드 풀 사이즈를 제한하는 것은 전체적인 쓰루풋에 자주 도움이 될 수 있다. 결과적으로 요청 유형의 실행 시간이 변동하느냐 여부에 대한 표시로서뿐만 아니라, 풀 사이즈 또는 풀의 개수가 변화하는 효과성에 대한 표시로서 표준 편차를 사용하는 것이 가능하다.

따라서, 이러한 모든 인자를 고려함으로써, 실행 시간과 대기/큐 시간 추적에 기초하여 다중 쓰레드 풀로 작업을 효과적으로 분배하기 위한, 자체 조정되고 높은 쓰루풋을 가지는 메카니즘을 구축할 수 있다. 여기서 개시된 기술은 전체적인 작업 부하에 걸쳐 동적으로 균형을 이룰 수 있도록 하고, 작업 부하가 시간에 따라 특성이 변화할 수 있고 여전히 최적화된 쓰루풋과 응답 시간을 얻을 수 있도록 한다.

이제 도 1을 참조하면, 여기서 개시된 것처럼 동작하는 시스템(100)의 개략도가 도시되어 있다. 바람직한 실시예에 따르면, 작업 요청(105)(예를 들어, 수신되는(inbound) 클라이언트 요청)이 시스템으로 입력될 때, 대기 큐 원소("WQE")(110)가 이러한 각 요청에 대하여 생성된다. 요청이 처리될 때, WQE는 시스템을 "통과(flowing through)"하는 것으로 간주될 수 있으며, WQE는 요청과 현재의 요청의 처리에 대한 정보를 얻는데 사용된다. 바람직하게는, 객체 지향 프로그래밍 용어로 WQE는 수신되는 요청에 대한 "래퍼(wrapper)"로서 구현된다. 각 래퍼는 요청의 유형과 같이, 그 래퍼와 관련된 요청을 식별하는 정보를 포함한다. 이러한 식별 정보는, 이전에 저장된 이력 통계(수신되는 요청들을 특정한 쓰레드 풀로 인도할 목적으로 이들을 분류하는데 사용됨)의 위치를 찾는데 이용될 수 있다는 점에서 "분류 키(classification key)"로 칭할 수 있다. 이러한 분류 키에 더하여, WQE는 요청의 현재 실행 시간과 현재 큐 대기 시간을 저장한다. 바람직하게는, WQE는 이러한 요청 유형에 대한 분류 데이터에 대한 참조를 저장하므로, 분류 데이터는 WQE에 저장된 분류 키를 사용하여 탐색될 수 있다. 바람직한 실시예에서 이러한 분류 데이터는 바람직하게 이동 평균으로서 저장되는 실행 시간; 바람직하게 이동 평균으로서 저장되는 큐 대기 시간; 및 선택적으로 요청 유형의 과거의 실행 시간과 큐 대기 시간 값에 대한 표준 편차 값을 포함한다. 이러한 표준 편차 값은 바람직하게는 또한 이동 값이다. 이러한 분류 데이터를 WQE와 함께 저장함으로써, (도면 부호 155, 160을 참조하여 더욱 자세히 설명되는) 통계 계산 쓰레드가 더 효율적으로 동작하는데, 이는 요청의 현재 실행 시간과 대기 시간을 하나의 요인으로 이력 통계에 포함시키기 때문이다. 이동 평균과 이동 표준 편차 값, 즉, 새롭게 실행할 때마다 갱신되는 값을 사용함으로써, 본 발명의 실시예는 실행 및/또는 큐 대기 시간에 있어 과거의 비정상적인 효과를 희석시킨다.

(WQE와 함께) 수신되는 요청은 분류 동작(115)으로 입력된다. 이러한 분류는 어느 쓰레드 풀로 이 요청이 할당될 것인지 결정하는 단계를 포함한다. 바람직한 실시예에서, 이러한 요청 유형에 대하여 이전에 계산된 분류 데이터(즉, 이력 통계)가 사용되어 이러한 유형(와일드카드 또는 유사한 매칭 방식이 지원된다면 유 사한 타입도 포함)을 가진 요청에 대한 평균 실행 시간을 결정한다. 평균 실행 시간을 사용하여 이 요청과 유사하거나 행동이 유사한 요청들을 처리하는 풀이 식별될 수 있다. 따라서, 오래 실행되는 요청들이 신속하게 실행될 수 있을 요청들을 방해하는 종래 기술의 문제점이 회피된다.

다른 실시예에서, 분류 키로서 요청 유형을 사용하는 것이 아니라, 분류 동작(115) 동안 적용 가능한 이력 통계의 위치를 찾는 인덱스로서 추가적인 또는 상이한 정보가 사용될 수 있다. 예를 들어, 요청 유형이 이들의 파라미터의 입력 값(및 선택적으로 파라미터 이름)을 사용함으로써 자격이 될 수 있고(qualified),, 요청 유형과 파라미터의 혼합은 분류 데이터(이러한 more-granular level로 기록됨)를 인덱스하는데 사용될 수 있다. URL(Uniform Resource Locator)의 URI(Uniform Resource Identifier) 부분이 사용될 수 있고, URI와 함께 파라미터 이름/값이 사용될 수 있다. 또한, 웹 환경에서는 "요청 유형"이 요청을 카테고리화하는 유용한 방법인 반면, 다른 환경에서는 다른 정보가 적절할 수 있다는 것을 유의해야 한다. 예를 들어, Enterprise JavaBeans^ⓡ 환경에서는 (클래스 또는 디플로이된(deployed) 이름을 포함하는) 메서드 이름이 요청 유형 대신에 사용될 수 있다. 원한다면 파라미터 이름/값이 추가적인 자격자(qualifier)로서 메서드 이름과 함께 사용될 수 있다. ("Enterprise JavaBeans"는 선 마이크로 시스템사의 등록 상표이다.) 따라서, "요청 유형"은 설명의 목적으로 사용되는 것일 뿐, 이에 한정되지는 않는다.

이제 도 2를 참조하여, 분류 동작(115)에 대하여 더 자세히 설명한다. 블록(200)에서 새롭게 수신되는 요청이 입력 큐로부터 수신된다. 블록(205)은 이러한 요청을 분석하여, 그 분류 키(더욱 구체적으로는 그 식별 정보)를 결정한다. 본 발명의 특정한 구현에서 분류 키를 수신되는 요청에 위치시키는 방식은 요청 유형, 요청 유형과 파라미터 값 등이 그 특정 환경에서 요청들을 분류하는데 중요한 것인지 여부에 달려있을 것이다. 일단 분류 키가 결정되면, 분류 키는 맵핑 테이블 또는 이력 통계가 기록된 다른 저장소에 대한 인덱스로서 사용된다(블록 210).

블록(215)은 이전에 기록된 분류 데이터(그리고, 특히, 평균 실행 시간)가 이 분류 키에 대하여 위치되었는지 여부를 알기 위하여 검사한다. 만일 아니라면, 이 수신되는 요청은 "새로 도착하는" 요청 유형으로서 간주된다. (우연히 요청 유형이 이 시스템에 의해 미리 처리되었을 수도 있지만, 가장 최근의 처리에 대한 통계 데이터는 이미 시간이 오래된 것이라는 것은 명백하다. 바람직하게는 이력 통계 데이터를 위해 사용되는 저장 장치의 크기를 구현에 따른 "합리적인" 레벨로 유지하기 위하여, "LRU(least-recently-used)"방식이 사용된다.) 블록(220)과 블록(225)은 새로 도착하는 요청 유형에 대하여 추가적인 처리를 수행한다. 블록(220)의 처리는 이 새로운 요청 유형에 대한 통계를 저장하기 위하여 분류 데이터에 새로운 항목을 생성하는 단계를 포함하는데, 이 새로운 항목은 현재의 요청의 분류 키에 의해 인덱스된다. 블록(225)은 그 후 이 새로운 항목을 초기화하는데, 바람직하게는 -1과 같은 특정한 값으로 평균 실행 시간을 설정함으로써 초기화한다. 이러한 특정한 값은 풀-할당 프로세스에서 검출되는데, 도 3을 참조하여 후 에 설명한다. (다른 방법으로서 이 값이 단순히 0으로 설정될 수 있다.)

요청의 통계 데이터를 위치시킨 후에(즉, 블록(215)이 양의 결과를 가질 때) 또는 새로운 통계 항목을 생성 및 초기화한 후에(블록(215)이 음의 결과를 가질 때), 어느 풀로 현재의 수신되는 요청이 할당되어야 하는지 결정하고 이 할당을 행하는 풀 할당 프로세스를 호출하는 블록(230)에 제어가 다다른다. 이 프로세스는 도 3을 참조하여 상세히 설명한다. 현재 수신되는 요청을 처리하는 것을 완료했다면, 제어를 블록(200)으로 되돌려줌으로써 후속적인 요청에 대하여 도 2의 로직이 반복적으로 수행된다.

도 3은 어떻게 바람직한 실시예가 도 2의 블록(230)으로부터 호출된 풀 할당 프로세스를 구현할 수 있는지에 대한 상세한 내용을 도시한다. 이 프로세스(블록 300)는 도면에서 "poolNdx"라고 불리는 풀 카운터 또는 인덱스를 초기화함으로써 시작된다. 이 poolNdx 값은 현재 수신되는 요청이 할당되어야 하는 것을 검사하면서 풀의 집합을 통과하여 순환하는데 사용된다. 풀은 점진적으로 더 높은 실행 시간을 가진 작업을 수용하고, 가장 높은 작업 시간을 가진 작업은 마지막 풀에 할당한다.

블록(305)은 만일 현재 수신되는 요청에 대한 평균 실행 시간이 poolNdx의 값에 의해 인덱스되는 풀에 대한 목표 상한선 이하인지 알아보기 위하여 테스트한다. 요청에 대한 평균 실행 시간은 바람직하게는 이 요청 유형과 관련된 이력 통계로부터 구해지거나, 만일 이 요청 유형에 대한 이력 통계가 이용가능하지 않다면 -1로 초기화될 수 있다(도 2의 블록(225)). 후자의 경우에, 블록(305)의 테스트는 도 3의 로직을 통하여 첫 번째 반복이 있을 때 들어맞을 것이고, 따라서, 바람직한 실시예에서는 새로 도착하는 요청 유형을 가장 짧은 실행 시간을 가진 요청을 처리하는 풀에 할당한다. (새로 도착하는 요청 유형을 처리하는 풀을 선택하기 위한 다른 방식이 다른 실시예에서 사용될 수 있다.)

만일 블록(305)의 테스트가 양의 결과를 가지고 있다면, 이 요청을 처리하는 풀이 발견되었다. 따라서, 작업 원소가 poolNdx에 의해 인덱스되는 풀로 지정되는(즉, 실행을 위해 할당되는) 블록(320)으로 제어가 넘어간다. 도 3의 처리는 그 후 완료되고, 제어는 도 2의 호출 로직으로 돌아간다. 그렇지 않고, 블록(305)의 테스트가 음의 결과를 가지고 있을 때, 풀 인덱스는 블록(310)에서 증가되고, 블록(315)에서 목표 상한선이 검사될 수 있는 풀들이 아직 더 있는지 확인하기 위하여 검사한다. 이러한 검사 작업은 poolNdx의 현재 풀 인덱스 값과 풀의 총 개수보다 하나 적은 값을 비교한다. (변수 "#pools"는 현재 사용 중인 풀의 개수를 저장한다.) 이 방식은 실행 시간이 마지막 타일 값보다 높은 요청 유형을 항상 마지막 풀에 할당하는 결과를 낳는다. 만일 검사될 수 있는 풀이 더 많이 있다면, 제어가 블록(305)으로 돌아가고, 아니라면, 현재 수신되는 요청이 현재의 풀(이 경우, 마지막 풀)로 지정되도록 되어 있는 블록(320)에서 처리가 계속된다.

어떻게 도 3이 동작하는지에 대한 예로서, 구현이 3개의 풀을 사용하고 있고, 이 풀들에 대한 타일 값(즉, 실행 시간의 상한선)이 10 타임 유닛과 20 타임 유닛으로 설정되어 있다고 가정한다. 도 3에 도시된 방법을 쓰면, 10 이하의 타임 유닛을 사용하여 실행하는 임의의 요청이 새로 도착하는 요청 유형과 함께 제1 풀 로 지정될 것이고, 10보다 크고 20 이하인 타임 유닛을 요구하는 요청 유형은 제2 풀로 지정될 것이다. 20을 초과하는 타임 유닛을 요구하는 요청 유형은 제3 풀로 지정될 것이다. 수신되는 요청 유형의 이력 통계가 수신되는 요청 유형이 평균적으로 50 실행 타임 유닛을 요구한다는 것을 나타낸다고 가정하자. poolNdx 값이 0일 때, 50이 블록(305)의 10과 비교되고, 이러한 테스트가 음의 결과를 가지기 때문에 블록(310)은 poolNdx를 1로 증가시킨다. 블록(305)을 통과하는 다음의 반복 때, 50이 20과 비교된다. 이 테스트는 또한 음의 결과를 가질 것이고, 블록(310)은 poolNdx를 2로 증가시킨다. 그 후, 블록(315)의 테스트는 2(poolNdx 값)와 2(풀의 개수보다 1 작은 값)를 비교할 것이다. 이 테스트는 음의 결과를 가질 것이기 때문에, 요청은 제3 풀(즉, 제로 기반 인덱싱(zero-based indexing)을 사용하여, 인덱스 값 2를 가지고 있는 풀)로 지정된다.

도 4는 바람직한 실시예에서 동질의 동적으로 변하는 작업 부하의 실행 및 대기 시간 특성을 분석함으로써, 어떻게 타일 값, 즉, 풀 당 실행 시간의 상한선을 결정하는지 나타내는 로직을 도시한다. 이 프로세스는 여기서 분배 계산 또는 풀 목표 계산 프로세스로 불린다. 바람직하게는, 도 1의 도면 부호 160을 참조하여 설명되는 바와 같이, 도 4의 로직은 주기적으로 상한선을 수정하기 위하여 호출된다.

블록(400)은 평균 실행 시간에 의해 현재의 분류의 수집(즉, 이력 통계의 수집)을 소팅한다. 전술한 바와 같이, 이러한 평균적인 실행 시간 값은 바람직하게는 어떤 최근의 기간 동안 이동 평균을 나타낸다. 이러한 방식으로 과거에 발생한 문제 상태 또는 다른 비정상(예를 들어, 지나치게 긴 실행 시간을 초래한 타임 아웃 상황, 비정상적으로 짧은 실행 시간을 초래한 예외 조건)이 미래의 결정을 왜곡시키지 못한다. 바람직한 실시예에서 실행 시간을 어레이로 복사하고, 이 어레이를 소팅한다. (이 어레이에 대한 기억 장치가 일단 할당되면, 어레이 사이즈를 증가시키기 위하여 재할당이 요구되지 않는 한, 바람직하게는 도 4의 후속적인 반복 동안 저장 장치가 유지된다.)

블록(405)은 값 "etas(execution time array size)"를 실행 시간을 소팅해서 모아놓은 것의 사이즈로 설정한다. 실행 시간이 풀의 집합에 적당하게 분배될 수 있도록, 이 "etas" 값은 얼마나 많은 실행 시간이 있는지에 대한 카운터로서 기능한다. 블록(410)은 풀 인덱스 값 poolNdx를 0으로 초기화한다.

블록(415)에서, 목표 상한선이 할당될 필요가 있는 풀이 더 있는지 여부에 대한 테스트가 이루어진다. 이러한 검사 과정에서 poolNdx의 현재 풀 인덱스 값을 풀의 총 개수(이 총 개수는 변수 "#pools"에 저장됨)보다 하나 작은 값과 비교한다. (도 3을 참조하여 설명하는 것처럼) 이 방식은 실행 시간이 상한선의 마지막보다 더 큰 모든 요청 유형이 마지막 풀로 지정되도록, 풀이 있는 것보다 하나 적은 상한선을 할당하는 결과를 낳는다. 만일 블록(415)의 검사가 양의 결과를 가진다면, 블록(420)에서 처리가 진행되고, 만일 음의 결과를 가진다면, 더 이상 할당될 상한선이 없으므로, 제어는 호출 로직으로 돌아간다.

블록(420)에서 현재 풀(즉, poolNdx에 이해 인덱스되는 풀)로 지정되는 실행 시간의 상한선이 계산되고 할당된다. 바람직한 실시예에서 이는 이용가능한 풀에 걸쳐 실행 시간 통계(및 그들의 관련된 요청 유형)의 총 개수를 똑같이 분배하는 단계를 포함한다. 따라서, 소팅된 실행 시간의 N번째 원소가 위치가 정해지고, 이 원소로부터의 실행 시간이 현재 풀의 상한선(도면에서 "목표" 속성으로 칭함)으로서 할당된다. 블록(420)에서 도시된 것처럼, 소팅된 어레이의 원소의 카운트("etas"의 값으로 나타냄)를 이용가능한 풀의 개수(#pools)로 먼저 나누고, 이것을 poolNdx 값 + 1로 곱하며, 마지막으로 이 값에서 1을 뺌으로써 N 번째 원소가 결정된다.

상한선을 설정한 다음에, 블록(425)은 풀 인덱스 값을 증가시키고, 할당될 상한선이 더 있는지 결정하는 블록(415)으로 제어가 돌아온다.

도 4의 로직이 어떻게 동작하는지에 대한 예로서, 현재의 수집에 12개의 분류가 있다고 가정하자. (알 수 있는 바와 같이, 실제로 수백, 수천의 분류가 있을 수 있다.) 또한, 이용가능한 4개의 풀이 있다고 가정하자. 첫 번째 반복에서, 블록(420)의 처리는 pool(0)에 대한 상한선을 계산한다. 이 예에서 "etas"의 값은 12이고, 따라서, (etas/#pools)은 12/4, 즉, 3이다. 이 값에 1을 곱하면 3이 되고, 1을 뺀 후에 pool(0)에 대한 상한선은 sortedExecTimes[2]로부터 선택된 실행 시간이다. 후속적인 반복에서, pool(1)에 대한 상한선은 sortExecTimes[5]로부터의 실행 시간으로 설정되는 식으로 된다.

도 4에 도시된 방식은 최근에 관찰된 실행 시간의 분배에 기초하는 값으로 상한선을 설정하는 결과를 낳는다. 상한선이 할당되어야 하는 풀의 개수는 풀의 개수가 조정됨에 따라 동적으로 변할 수 있다는 것을 유의해야 한다. (풀의 개수 가 어떻게 조정되는지에 대한 더 자세한 내용은 도 5 내지 도 7을 참조하여 설명한다.) 도 4에 도시된 로직은 자동적으로 풀의 개수의 변화에 적응한다.

도 1에 도시된 전체적인 처리를 다시 설명하면, 수신되는 각 요청이 분류될 때(115), 그것은 적당한 쓰레드 풀(즉, 도 2 및 도 3의 처리를 사용하여 식별되는 쓰레드 풀)로 보내진다. 종종 요청은 대기 큐에 들어가서, 쓰레드가 이용가능해질 때가지 기다려야 한다. 따라서, 도 1에서 요청들은 "N" 대기 큐(120, 125, 130) 중 하나로 보내지는 것으로 도시되어 있는데, 여기서 각 대기 큐는 시스템(100)에서 현재 사용되고 있는 N 개의 논리 쓰레드 풀(135, 140, 145) 중 하나에 해당한다. (알 수 있는 바와 같이, 시스템(100)의 풀의 개수가 후의 어느 시점에 증가되거나 감소된다면, 대기 큐의 수는 그 에 따라 조정되어야 한다. 또한, 대기 큐의 사이즈는 큐에 들어 있는 원소의 개수에 따라 변하는데, 여기서 개시된 동적 조정은 큐 사이즈를 변경하기 위한 것이 아니다.)

어느 시점에, 큐에 있는 요청이 그 큐에 대한 쓰레드 풀로부터의 쓰레드로 할당될 것이다. 바람직한 실시예에서 요청이 대기 큐에서 보낸 시간의 양이 WQE에 기록된다. (요청이 분류 동작을 마칠 때 쓰레드가 이용가능하다면, 요청이 대기 큐를 거치지 않을 수 있다. 이 경우에 대기 시간을 0으로 기록된다. 그러나, 사실상 이러한 요청들은 큐로 제공될 수 있고, 큐 대기 상태에서 단지 매우 짧은 시간 동안 시간을 보낼 것이다. 다음에서는 구현은 모든 분류된 요청을 큐로 전송한다고 가정하자.)

도 1은 대기 큐로부터 "실행 가능 풀(runnable pool)(135, 140, 145)"로 트 래버스하는, 수신되는 요청을 도시한다. 이러한 실행 가능 풀은 여기서 설명된 논리적인 쓰레드 풀에 대응하고 도 1이 도시하는 바와 같이, 이러한 논리적 풀 내의 쓰레드는 실제로 글로벌 쓰레드 풀(150)에 정의되어 있다. 바람직한 실시예에서, 실행 가능 풀은 (본 발명을 객체 지향 언어로 구현할 때) 제한된 수의 실행 가능 래퍼 객체를 포함하고 있는데, 각 래퍼 객체는 논리적 쓰레드 풀에 할당된 쓰레드 중 하나를 나타낸다. (실행 가능 래퍼 객체는 또한 쓰레드에 대한 인터페이스 메카니즘을 제공한다.) 따라서, 쓰레드의 개수와 마찬가지로, 실행 가능 래퍼 객체의 수가 풀(135, 140, 145)마다 달라질 수 있다. (특정한 실행 가능 풀 내에서, 실행 가능 래퍼 객체의 수는 여기서 개시된 풀 사이즈 조정 동작을 수행하는 것 때문에 달라질 수 있다.) 따라서, 대기 큐에 관련된 실행 가능 풀 내의 실행 가능 래퍼 객체 중 하나가 이용가능하게 될 때까지, 수신되는 요청 및 그 WQE는 그 대기 큐에 머무른다. (실행 가능한 래퍼 객체가 이용가능하다는 것은 그 정의대로 쓰레드가 이용가능하다는 것을 의미한다.) 이러한 방식으로 실행 가능 래퍼 객체는 풀 당 쓰레드의 개수에 대한 제한을 실행하는 효율적이고 신뢰성 있는 방법을 제공하며, 여전히 쓰레드가 실제로 정의되어 있는 단일의 글로벌 쓰레드 풀을 사용한다. (단일의 글로벌 쓰레드 풀을 사용함으로써 물리적 쓰레드 풀을 별개로 유지하는 것보다 오버헤드가 상당히 감소한다. 이는 특히 풀 당 쓰레드의 수가 변화하고 있는 조정 동작 동안 해당된다. 별개의 물리적인 쓰레드 풀이 사용될 경우 행해지는 것처럼 쓰레드를 생성하고 파괴하는 것이 아니라, 바람직한 실시예에서는 논리 풀 내의 이용가능한 실행 가능 래퍼 객체의 수를 변경함으로써 다소의 쓰레드를 단지 논 리 풀에 할당한다.)

각 쓰레드 풀(135, 140, 145)의 사이즈는 바람직하게는 풀에 지정되어 있는 유형의 작업이 얼마나 많이 동시에 실행되어야 하는지에 따라 달라진다. 선택적인 풀 사이즈 조정이 구현될 때(도 5, 6, 8을 참조하여 아래에서 설명하는 바와 같이), 풀이 사이즈는 자체로 조정될 것이다(self-tuning). 예를 들어, 하나의 풀이 데이터베이스 액세스를 필요로 하는 요청들을 서비스하고 있다면, 그리고, 요청이 최적으로 실행되도록 하기 위하여 데이터베이스 시스템으로의 접속 수가 제한되어야 한다면, 풀의 사이즈는 요청의 성능을 저하시킬 사이즈를 초과하지 않도록 자체로 조정되는 경향이 있을 것이다.

각 요청은 실행하는데 얼마간의 시간을 소비하고, 실행을 완료하자 마자, 요청의 쓰레드가 실행 가능 풀로 반환되고(즉, 실행 가능 래퍼 객체를 되돌려주거나 놓아줌으로써), 요청의 WQE는 그 실행 시간을 기록하도록 갱신된다. 종래 기술을 사용하여 클라이언트에 의해 요청된 내용이 반환된다(도 1에 도시되지 않음). WQE가 이력 처리를 위하여 큐에 대기하고(통계 큐(155) 참조), 이 후에 통계 계산 쓰레드가 결국 WQE를 큐에서 빼내고, 원소(160)가 가리키는 데이터를 처리한다.

본 발명의 목적을 위하여, 160에서 수행된 처리는 큐에 넣어진 WQE로부터 대기 시간 및 실행 시간을 처리하는 단계, "LRU" 트리밍 프로세스를 수행하는 단계, 및/또는 풀 목표 계산을 수행하는 단계를 포함한다. 통계 계산 쓰레드는 바람직하게는 배경 프로세스로서 실행되도록 구현되고, 바람직하게는 타이머에 의해 구동되는 방식(timer-driven manner)으로 호출된다. 바람직한 실시예에서, 시간 간격은 구성 가능하고, 시스템 성능을 저하시키지 않도록 최소 값(예를 들어, 20초)을 가진다.

바람직한 실시예에 따라, 통계 계산 쓰레드가 실행되고 있을 때, 만일 통계 큐에 항목이 있다면, 이 항목은 큐에서 빠져나와 처리된다. 발생한 타임 아웃에 따라 다른 동작이 또한 수행될 수 있다. 바람직하게는 한 번의 타임 아웃만이 통계 계산 쓰레드의 호출에 따라 처리되고, 큐(155)로부터의 통계를 먼저 처리한다. (큐에서 입력되는 통계는 분류를 갱신하고, 따라서, 분류가 적절한 시기에 실제 상태를 나타내도록 하기 위해서는 신속히 처리되어야 한다. LRU와 풀 목표 계산은 집합적인 정보에 달려 있고, 따라서, 자주 실행될 필요는 없다.)

통계 큐를 처리할 때, 통계 계산 쓰레드는 항목을 큐에서 빼내고, 이력 통계를 수정하여 현재의 실행 및 대기 시간 정보를 포함시킨다. 전술한 바와 같이, 큐에 넣어진 WQE에서 값들이 효율적인 방식으로 손쉽게 이용가능하도록, 이력 통계에 대한 참조가 보관된다. 후자의 경우에, 통계 계산 쓰레드는 먼저 큐에서 나온 항목으로부터 식별 정보(예를 들어, 요청 유형, 다른 실시예에서는 파라미터 값과 같은 추가적인 또는 상이한 정보)를 얻고, 이 식별 정보를 이전에 계산된 이력 통계를 액세스하는 분류 키로서 사용한다. 이력 통계에서 유지되는 대기 시간과 실행 데이터는 그 후 큐에서 나온 항목으로터의 정보를 반영하도록 정정되고, 만일 이 정보가 특정한 구현에서 사용된다면 표준 편차 정보가 정정될 수 있다. 바람직하게는 통계 계산 쓰레드는 이벤트에 의해 구동되고, 입력되는 통계가 수신될 때 웨이크 업(wake up)된다. 웨이크 업 이벤트는 바람직하게는 타임 아웃시에 트리거된 다. (LRU와 풀 목표 계산은 바람직하게는 관련된 타이머가 끝났을 때 무조건적으로 수행된다.)

상이한 타이머 간격이 LRU 트리밍 프로세스와 풀 목표 계산의 처리를 트리거하는데 사용될 수 있다. 만일 LRU 트리밍 프로세스가 트리거된다면, 바람직하게는 최근에 사용되지 않은 분류 데이터가 무시되고, 이 데이터에 대하여 사용된 저장 장치 리소스는 해제된다. (예를 들어, 엔드 유저가 이전에 수신된 어떤 요청 유형을 서버의 현재 작업 부하와 무관하게 만들면서, 상이한 웹 페이지로 이동하였을 수 있다. 이 경우에, 이러한 요청 유형에 대한 통계를 고려하는 것은 더 이상 유용하지 않다. 또한, 통계는 엔드 유저의 수집에 대한 집합적인 정보를 나타내고, 사용자 중 일부는 그들의 세션을 마쳤을 수도 있다. 이 경우, 수집된 데이터의 일부는 더 이상 시스템의 현재 동작 상태와 관련이 없을 수 있다.) 만일 풀 목표 계산이 트리거된다면, (전술한) 도 4의 처리가 호출된다. 전술한 상이한 유형의 처리를 위하여 별개의 쓰레드를 사용하는 것보다 복수의 목적을 위해 단일 쓰레드를 사용하는 것(160)은 오버헤드를 감소시키고, 분류 데이터와 같은 공유 리소스에 대한 경쟁을 감소시킨다.

큐에서 나온 WQE로부터 정보가 추출되고 처리된(160) 이후에, WQE는 추후의 사용을 위해 프리 리스트(165)로 반환될 수 있다. (또는, WQE에 사용된 저장 장치가 방면(free)될 수 있다. 바람직한 실시예에서는 오버헤드를 감소시키기 위하여, WQE를 재사용한다. 도 1의 처리는 수신되는 각 요청에 대하여 이러한 방식으로 반복된다.

도 5는 여기 개시된 풀 조정 프로세스의 실시예들과 함께 사용될 수 있는 상태 전이를 도시하는 상태도이다. 도 6내지 도 8에 도시된 로직과 함께 이러한 전이가 사용되어, 풀 개수와 각 풀의 사이즈를 조정할 때 변화를 분리시킬 수 있다.

도 5에 도시된 것처럼, 초기 상태, "S0"에서는 풀 개수 또는 풀 사이즈에 변화가 생기지 않는다. 그 후, 풀의 개수는 다음 상태, "S1"에서 조정된다. 마지막으로 풀 사이즈는 개별적으로 상태 "S2"에서 조정될 수 있다. 바람직하게는 한 상태에서 다른 상태로 전이하는 것은 타이머에 의해 구동되고, 시스템은 어떤 시간 주기 동안 특정한 상태로 유지되어, 상태가 실행에 미치는 영향이 기록되고 분석될 수 있도록 한다. 바람직한 실시예에서, 도 6의 로직에 도시된 것처럼(블록(620)에서 다음 상태 전이를 가능하게 하기 전에 "슬립(sleep)" 연산을 구현함), 타이머가 조정 프로세스 내에 설치된다. 다른 실시예에서는 전이가 이벤트에 의해 구동되는 방식처럼 다른 방식으로 트리거될 수 있다. (이러한 다른 방식에서 예를 들어, 상태 S2에서 상태 S0로 전이하는 것은 도 8에서 모든 풀에 대한 풀 사이즈 조정을 완료할 때 트리거될 수 있다.)

다른 실시예에서 상태 S1과 S2의 순서가 뒤바뀔 수 있다. 다른 실시예에서, 풀 개수 조정 프로세스와 풀 사이즈 조정 프로세스를 호출하는 기술은 상태 전이도에 의해 구동될 필요는 없다.

도 6 내지 도 8은 풀 사이즈 및/또는 풀의 개수를 주어진 작업 부하로 동적으로 조정하는데 사용될 수 있는 로직의 흐름도를 제공한다. 도 6은 다음 전이 상태(도 5의 상태도 참조)를 구함으로써 시작된다(블록(600)). 다음 상태가 "변화 없음"이면(블록(615)), 제어가 블록(620)으로 넘어가고, 그렇지 않으면, 블록(625)에서 처리가 계속된다.

처리가 블록(620)에 도달할 때, 도면에서 "TUNING_SETTLE_TIME"이라고 값이 조정된(configured) 간격, 즉, 시스템이 정상 상태에 도달할 수 있도록 하는데 충분한 시간량에 대하여 슬립 또는 지연이 수행된다. 블록(605)은 현재 통계를 구하고, 이들을 사용하여 기준을 설정하고, 이 후에 블록(600)으로 돌아감으로써, 다음 조정 동작이 수행된다.

제어가 블록(625)으로 넘어간다면, 다음 조정 상태가 풀의 개수를 조정할 것인지 알아보는 테스트가 이루어진다. 만일 그렇다면, 도 7에 더 상세히 도시된 바와 같이, 블록(630)에서 풀의 개수 조정 프로세스가 수행된다. 이 프로세스를 완료하면, 제어가 블록(620)으로 넘어간다.

만일 블록(625)의 테스트가 음의 결과를 갖는다면, 블록(635)이 다음 전이 상태가 풀 사이즈를 조정할 것인지 알아보는 검사를 한다. 만일 그렇다면, 블록(640)에서, 도 8에 보다 상세히 도시된 바와 같이, 풀 사이즈 조정 프로세스가 수행된다. 이 프로세스를 완료할 때, 제어가 블록(620)으로 넘어간다.

블록(635)에서의 테스트가 음의 결과를 갖는다면, 이것은 에러이다. 이 에러는 블록(610)에 도시된 것처럼, 도 6의 조정 프로세스가 TUNING_SETTLE_TIME 간격 동안 슬립(sleep)하도록 함으로써 처리될 수 있고, 그 후, 제어가 블록(600)으로 돌아간다. 다른 대안으로, 조정 프로세스가 중지될 수도 있다(그리고, 이 경우에 에러 메시지가 시스템 관리자에게 디스플레이된다).

그 후 풀 조정 프로세스가 반복적으로 수행되도록 도 6의 로직이 반복된다.

도 7의 로직은 풀의 개수가 조정되고 있을 때, 도 6의 블록(630)으로부터 호출된다. 블록(700)에서 명백한 변화가 필요한지 여부가 검사된다. 예를 들어, 분류 데이터에 별개의 항목보다 많은 풀이 있다고 가정하자. 다양한 타일의 상한선은 이 경우 복제될 수 있고, 또는, 단지 맵핑 요청 유형보다 더 많은 풀이 있을 수 있다. 이러한 유형의 에러는 잘 조정되고 적당하게 수행되는 시스템에서 일어나지 않아야 하지만, 일어날 수 있다. 일반적인 의미에서, 블록(700)이 이러한 유형의 명백한 문제들에 대한 "캐치 콜(catch call)"로 간주될 수 있다. 이렇게 해서, 이 테스트가 양의 값을 가지면, 임의의 수의 풀의 조정 계산을 수행하는 대신에, 제어가 블록(705)으로 직접 넘어갈 수 있다. 그 후 제어는 도 6의 호출 로직으로 돌아간다(시스템은 이 변화 후에 정상 상태로 안정될 시간을 가질 것이다).

만일 명백한 변화가 요구되지 않는다면, 블록(710)에서 현재 통계가 시스템의 현재의 작업 부하에 의해 실행되고 있는 요청 유형에 대하여 캡쳐된다(captured). 바람직하게는, 이것은 분류 데이터의 현재 스냅샷을 얻는 단계를 포함하는데, 여기서 실행 시간과 대기 시간 정보(그리고, 선택적으로 표준 편차 정보)가 업데이트되어 있다. 블록(715)에서 추가적인 풀이 더해진다.

블록(720)은 "SLEEP_TIME"이라고 불리는 시간 간격 동안 슬립 또는 대기 프로세스를 구현하고, 수신되는 요청에 대하여 실행 시간과 대기 시간(그리고, 선택적으로 표준 편차)에 풀의 개수의 변화가 어떻게 영향을 미쳤는지에 대한 정보를 반영하도록 분류 데이터가 업데이트될 수 있도록 한다. 이 SETTLE_TIME 값은 바람 직하게는 조정가능한 값이고, 도 6에서 사용된 TUNING_SETTLE_TIME 값과 동일하거나 상이할 수 있다. 바람직하게는, SETTLE_TIME 슬립 동안 분배 계산이 자동적으로 트리거되도록, SETTLE_TIME 값은 도 4의 분배 계산 프로세스가 슬립하는 시간 간격보다 더 길고, 이에 따라, 블록(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)에서 이 인덱스가 0 이상인지 검사한다. 만일 아니라면, 풀 사이즈 조정 연산은 모든 풀에 대하여 시도된 것이고, 제어는 도 6의 호출 로직으로 돌아간다(블록(815)).

다른 실시예에서, 각 풀의 사이즈를 조정하는 것을 시도할 필요는 없다. 예를 들어, 현재 얼마나 많은 풀이 사용 중인지에 관계 없이, 도 8의 로직을 거치는 반복 횟수를 제한하기 위하여, 반복 카운터가 사용될 수 있다. 다른 실시예에서, 풀 사이즈 조정은 가장 높은 수가 아니라, 가장 낮은 수의 풀에서 시작할 수 있다. 당업자에게는 도 8의 로직을 어떻게 변경하여 본 발명의 범위 내에 있는 다른 방법을 제공할 수 있는지가 명백할 것이다.

만일 풀 카운터 인덱스 값이, 평가될 풀이 더 많이 있다는 것을 나타낸다면, "현재 조정량"이 풀의 쓰레드의 개수를 감소시키기 위하여 음의 값으로 설정되어 있는 블록(820)에 제어가 도달한다. 바람직하게는 구성 가능한 값(도면에서 "POOL_DELTA"로 칭함)이 조정량으로서 사용될 수 있다. 이 값은 퍼센트 또는 (단지 쓰레드의 수를 1 만큼 변화시키는 것과 같이) 절대 번호(absolute number)로 표현될 수 있다. 특정한 구현에서 어떤 방식이 가장 효과가 좋은지는 쓰레드 풀의 상대적인 사이즈와 같은 인자에 달려 있을 수 있고, 어느 방식이든 본 발명의 범위 내에 있다.

도 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)에서 다시 슬립이 수행된다. 이 슬립 구간이 종료할 때, 블록(890)에서 새로운 스냅샷을 캡쳐하고, 블록(895)에서 이 스냅샷과 블록(870)에서 찍은 스냅샷을 비교한다. 새로운 통계가 더 낫다면, 시스템은 증가된 수의 쓰레드를 가지고 진행하고, 블록(805)으로 제어가 돌아와서, 조정될 풀이 더 있는지 확인하는 테스트를 한다. 그렇지 않고, 수신되는 요청의 실행 시간과 대기 시간이 풀 사이즈를 증가시킨 후에 나아지지 않았다면(즉, 블록(895)에서 음의 결과), 풀 사이즈가 복구된다(블록(700)). 슬립이 또한번 초기화되고(블록(705)), 그 이후 제어가 블록(805)으로 돌아간다.

종래 기술을 사용하여, 어떤 이유로 쓰레드 풀을 제한하는 것은 시스템 성능에 좋다고 경험적으로 결정되었다. 예를 들어, 데이터베이스 액세스를 요구하는 요청을 참조하면, 한번에 개방될 수 있는 데이터베이스 접속의 최대 수가 존재할 수 있다. 쓰레드가 제한되지 않는다면, 풀은 데이터베이스를 액세스하려고 시도하는 요청들로 클로그될 수 있다(clogged). 이 시나리오를 위하여 쓰레드 풀을 한정하는 것은 그 목적에는 맞지만, 시스템의 다른 요청들(데이터베이스 액세스를 전혀 필요로 하지 않을 수 있는 요청들)이 영향을 받는 바람직하지 못한 부작용이 있다. 여기서 개시된 자체 조정 동적 프로세스는 시스템 관리자의 개입이 없이도, 이러한 유형의 영향을 자동적으로 없앤다.

전술한 바와 같이, 본 발명은 작업 부하의 응답 시간 특성(그리고 특히, 응 답 시간의 실행 시간과 대기 시간 성분)에 기초하여, 실행 리소스의 집합에 걸쳐 작업 부하를 프로그램적으로 분배하는 유리한 기술을 제공한다. 이에 의해, 다중 쓰레드 서버의 전체적인 성능이 향상되고, 엔드 유저가 그들의 많은 요청에 대한 응답 시간이 감소되는 이익을 누릴 수 있다. 이 프로그램적인 분배는 여기서 개시된 풀 조정 기술과는 독립적으로 사용될 수 있고, 풀의 개수 및/또는 풀의 사이즈가 (적어도 일시적으로) 고정되어 유지되더라도, 성능 향상이 실현될 수 있다. 또한, 풀 조정 기술중의 하나 또는 모두가 구현될 수 있고, 성능 개선을 더 제공하는 것으로 예상될 수 있다. 개시된 기술은 다양한 수신 작업 부하 유형과 함께 유리하게 사용될 수 있다. 바람직한 실시예에서 특정한 유형의 데이터를 사용하여 수신 요청들을 분류하는 것을 참조하여 설명되었지만, 이것은 설명의 목적을 위한 것이며, 이에 한정되는 것은 아니다. 일반적으로, 메시지 큐 작업 부하는 메시지 유형 및/또는 이 메시지 내에 포함된 데이터(메시지의 처리 목적지를 포함하지만, 이에 한정되는 것은 아님, 처리 목적지란 수신 작업에 대한 첫 번째 레벨의 핸들러를 정의하며, 파라미터가 큐에 있는 메시지에 따라 다양한 추가적인 로직, 코드 경로, 및 이용되는 리소스를 구동할 수 있음)에 의하여 분류될 수 있다.

본 발명은 사업 방법으로서 제공될 수 있다. 예를 들어, 서비스가 고객에게 제공될 수 있고, 이에 의해 클라이언트/서버 네트워크 트래픽의 동작 특성이 모니터링되고, 쓰레드 풀에 대한 조정이 이 모니터링에 기초하여 프로그램적으로 이루어질 수 있다. 여기서 설명된 기술은 이 서비스를 수행하는 소프트웨어를 구현하는데 사용될 수 있다. 이 서비스는 사용에 따른 과금, 월별 과금 또는 다른 주기 적인 과금 등과 같이, 다양한 수익 모델 하에 제공될 수 있다.

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

본 발명은 실시예에 따라 흐름도 및/또는 방법의 블록도, 장치(시스템), 및 컴퓨터 프로그램 제품을 참조하여 설명되었다. 흐름도 및/또는 블록도의 각 블록 및 흐름도 및/또는 블록도의 블록의 조합은 컴퓨터 프로그램 명령어에 의해 구현될 수 있다. 이러한 컴퓨터 프로그램 명령어는 범용 컴퓨터, 특수 목적 컴퓨터, 내장 프로세서, 또는 기계를 생산하는 다른 프로그램가능한 데이터 처리 장치의 프로세서로 제공되어, (컴퓨터 또는 다른 프로그램가능한 데이터 처리 장치를 통하여 실행되는) 명령어가 흐름도 및/또는 블록도의 블록에 나타난 기능을 구현하는 수단을 생성할 수 있다.

이 컴퓨터 프로그램 명령어는 하나 이상의 컴퓨터로 판독가능한 메모리에 저장될 수 있는데, 이러한 각 메모리는 컴퓨터 또는 다른 프로그램가능한 데이터 처리 장치가 특정한 방식으로 기능을 수행하도록 지시하고, 컴퓨터로 판독가능한 메모리에 저장된 명령어는 흐름도 및/또는 블록도의 블록에 나타난 기능을 구현하는 명령어 수단을 포함하는 제조물을 생산할 수 있다.

컴퓨터 프로그램 명령어는 하나 이상의 컴퓨터 또는 다른 프로그램가능한 데이터 처리 장치로 로딩되어, 일련의 동작 단계가 컴퓨터 또는 다른 프로그램가능한 장치에서 수행되도록 하고, 이러한 각 장치에서 실행되는 명령어가 흐름도 및/또는 블록도의 블록에 나타난 기능을 구현하는 단계를 제공하는 식으로, 장치에서 컴퓨터로 구현되는 프로세스를 생성한다.

본 발명의 바람직한 실시예가 설명되었지만, 당업자가 기본 발명의 개념을 이해한다면, 추가적인 변경 및 부분적 수정을 할 수 있다. 따라서, 첨부된 청구항은 본 발명의 사상과 범위내에서 바람직한 실시예와 모든 이러한 변경 및 부분적 수정을 포함하는 것으로 해석되어야 할 것이다.

본 발명에 의하면, 실행 시간과 대기/큐 시간 추적에 기초하여 다중 쓰레드 풀로 작업을 효과적으로 분배하기 위한, 자체 조정되고 높은 쓰루풋을 가지는 메카니즘을 구축할 수 있다. 여기서 개시된 기술은 전체적인 작업 부하에 걸쳐 동적으로 균형을 이룰 수 있도록 하고, 작업 부하가 시간에 따라 특성이 변화할 수 있고 여전히 최적화된 쓰루풋과 응답 시간을 얻을 수 있도록 한다.

Claims

다중 쓰레드 서버에서 쓰레드 풀들을 동적으로 조정하는 방법에 있어서,

상기 다중 쓰레드 서버에서 동적으로 변하는 작업 부하에 대한 기준 런 타임 통계를 축적하는 단계로서, 상기 기준 런 타임 통계는 상기 동적으로 변하는 작업 부하의 첫 번째 복수의 요청을 실행하는 것에 관련되고, 상기 요청들은 복수의 쓰레드 풀에 의해 서비스되는, 상기 기준 런 타임 통계 축적 단계와,

상기 쓰레드 풀들을 프로그램적으로 변경하는 단계와,

상기 동적으로 변하는 작업 부하에 대한 새로운 런 타임 통계를 축적하는 단계로서, 상기 새로운 런 타임 통계는 상기 동적으로 변하는 작업 부하의 두 번째 복수의 요청을 실행하는 것에 관련되고, 상기 요청들은 상기 프로그램적으로 변경된 쓰레드 풀들에 의해 서비스되는, 상기 새로운 런 타임 통계 축적 단계와,

만일 상기 새로운 런 타임 통계와 상기 기준 런 타임 통계를 비교한 것이 상기 프로그램적인 변경의 결과로서 성능이 저하되었다는 것을 나타낸다면, 상기 프로그램적인 변경을 프로그램적으로 반전(reverse)시키는 단계를 포함하는 쓰레드 풀 동적 조정 방법.
제1항에 있어서, 상기 쓰레드 풀들은 물리적 쓰레드 풀을 논리적으로 체계화하여 분류한 그룹들인 쓰레드 풀 동적 조정 방법.
제1항에 있어서, 만일 상기 새로운 런 타임 통계와 상기 기준 런 타임 통계를 비교한 것이 상기 프로그램적인 변경의 결과로서 성능이 향상되지 못했다는 것을 나타낸다면, 상기 프로그램적인 변경을 프로그램적으로 반전시키는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제1항에 있어서, 상기 프로그램적으로 변경하는 단계는 상기 동적으로 변하는 작업 부하를 서비스하기 위한 추가적인 쓰레드 풀을 추가하는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제4항에 있어서, 상기 새로운 런 타임 통계를 축적하는 단계 이전에, 상기 추가된 쓰레드 풀을 고려하여 상기 동적으로 변하는 작업 부하를 상기 복수의 쓰레드 풀에 할당한 것을 프로그램적으로 재조정(rebalancing)하는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제5항에 있어서, 상기 프로그램적으로 재조정하는 단계는 상기 쓰레드 풀들에 의해 서비스될 요청들의 실행 시간에 대한 상한선을 계산하는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제4항에 있어서, 상기 프로그램적으로 반전시키는 단계는,

상기 추가된 쓰레드 풀을 프로그램적으로 제거하는 단계와,

상기 제거된 쓰레드 풀을 고려하여 상기 동적으로 변하는 작업 부하를 상기 복수의 쓰레드 풀에 할당한 것을 재조정하는 단계를 더 포함하는 것인 쓰레드 풀 동적 조정 방법.
제1항에 있어서, 상기 기준 런 타임 통계와 상기 새로운 런 타임 통계는 상기 변하는 작업 부하를 포함하는 상기 요청들을 서비스하는데 걸리는 평균 실행 시간과 평균 큐 대기 시간(queued time)인 것인 쓰레드 풀 동적 조정 방법.
제8항에 있어서, 상기 평균 실행 시간과 상기 평균 큐 대기 시간은 요청 유형 별로 유지되는 것인 쓰레드 풀 동적 조정 방법.
제8항에 있어서, 상기 평균 실행 시간과 상기 평균 큐 대기 시간은 요청 유형과 파라미터 값들 별로 유지되는 것인 쓰레드 풀 동적 조정 방법.
제8항에 있어서, 상기 평균 실행 시간과 상기 평균 큐 대기 시간은 요청 유형, 파라미터 이름들, 파라미터 값들 별로 유지되는 것인 쓰레드 풀 동적 조정 방법.
제8항에 있어서, 상기 평균 실행 시간과 상기 평균 큐 대기 시간은 메서드 이름 별로 유지되는 것인 쓰레드 풀 동적 조정 방법.
제8항에 있어서, 상기 평균 실행 시간과 상기 평균 큐 대기 시간은 메서드 이름과 파라미터 값들 별로 유지되는 것인 쓰레드 풀 동적 조정 방법.
제8항에 있어서, 상기 평균 실행 시간과 상기 평균 큐 대기 시간은 메서드 이름과 파라미터 이름들과 파라미터 값들 별로 유지되는 것인 쓰레드 풀 동적 조정 방법.
제8항에 있어서, 상기 평균 실행 시간과 상기 평균 큐 대기 시간은 URI(Uniform Resource Identifier) 이름 별로 유지되는 것인 쓰레드 풀 동적 조정 방법.
제8항에 있어서, 상기 평균 실행 시간과 상기 평균 큐 대기 시간은 URI(Uniform Resource Identifier) 이름과 파라미터 값들 별로 유지되는 것인 쓰레드 풀 동적 조정 방법.
제8항에 있어서, 상기 평균 실행 시간과 상기 평균 큐 대기 시간은 처리 목적지(processing destination) 별로 유지되는 것인 쓰레드 풀 동적 조정 방법.
제1항에 있어서, 상기 프로그램적으로 변경하는 단계는, 상기 동적으로 변하는 작업 부하를 서비스하는 상기 복수의 쓰레드 풀로부터 쓰레드 풀을 제거하는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제18항에 있어서, 상기 새로운 런 타임 통계를 축적하는 단계 이전에, 상기 제거된 쓰레드 풀을 고려하여 상기 동적으로 변하는 작업 부하를 상기 복수의 쓰레드 풀에 할당한 것을 프로그램적으로 재조정하는 단계를 더 포함하는 것인 쓰레드 풀 동적 조정 방법.
제18항에 있어서, 상기 프로그램적으로 반전시키는 단계는,

또 하나의 쓰레드 풀을 프로그램적으로 추가하는 단계와,

상기 추가된 쓰레드 풀을 고려하여, 상기 동적으로 변하는 작업 부하를 상기 복수의 쓰레드 풀에 할당한 것을 재조정하는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제1항에 있어서, 상기 프로그램적으로 변경하는 단계는, 상기 새로운 런 타임 통계를 축적하는 단계 이전에, 상기 쓰레드 풀들 중 선택된 쓰레드 풀에 할당된 쓰레드의 수를 증가시키는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제21항에 있어서, 상기 프로그램적으로 반전시키는 단계는, 상기 쓰레드 풀들 중 상기 선택된 쓰레드 풀에 할당된 쓰레드의 수를 감소시키는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제1항에 있어서, 상기 프로그램적으로 변경하는 단계는, 상기 새로운 런 타임 통계를 축적하는 단계 이전에, 상기 쓰레드 풀들 중 선택된 쓰레드 풀에 할당된 쓰레드의 수를 감소시키는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제23항에 있어서, 상기 프로그램적으로 반전시키는 단계는, 상기 쓰레드 풀들 중 상기 선택된 쓰레드 풀에 할당된 쓰레드의 수를 증가시키는 단계를 더 포함하는 쓰레드 풀 동적 조정 방법.
제1항에 있어서, 상기 기준 런 타임 통계와 상기 새로운 런 타임 통계는 상기 변하는 작업 부하를 포함하는 요청들을 서비스하는데 걸리는 평균 실행 시간, 실행 시간의 표준 편차, 평균 큐 대기 시간, 큐 대기 시간의 표준 편차인 것인 쓰레드 풀 동적 조정 방법.
제1항 내지 제25항 중 어느 한 항에 의한 방법의 각 단계를 수행하는 각 수단을 포함하는 쓰레드 풀 동적 조정 시스템.
제1항 내지 제25항 중 어느 한 항에 의한 방법의 각 단계를 수행하는 컴퓨터 프로그램이 기록된 컴퓨터로 판독가능한 기록 매체.
다중 쓰레드 서버의 쓰레드 풀들을 동적으로 조정함으로써 사업을 행하는 방법으로서,

상기 다중 쓰레드 서버에서 작업 부하의 기준 동작 특성을 프로그램적으로 축적하는 단계로서, 상기 기준 동작 특성은 동적으로 변하는 상기 작업 부하의 첫 번째 복수의 요청을 실행하는 것에 관련되고, 상기 요청들은 복수의 쓰레드 풀에 의해 서비스되는, 상기 기준 동작 특성 축적 단계와,

(1) 상기 작업 부하의 요청들을 서비스하는데 사용되는 쓰레드 풀들의 개수와, (2) 상기 쓰레드 풀들 중 특정한 쓰레드 풀에 할당된 쓰레드들의 개수 중 하나를 선택적으로 증가시키거나 감소시킴으로써, 상기 쓰레드 풀들을 프로그램적으로 변경하는 단계와,

상기 동적으로 변하는 작업 부하에 대한 새로운 동작 특성을 프로그램적으로 축적하는 단계로서, 상기 새로운 동작 특성은 상기 동적으로 변하는 작업 부하의 두 번째 복수의 요청을 실행하는 것에 관계되고, 상기 요청들은 상기 프로그램적으로 변경된 쓰레드 풀들에 의해 서비스되는, 상기 새로운 동작 특성 축적 단계와,

만일 상기 새로운 동작 특성과 상기 기준 동작 특성을 비교한 것이 상기 프로그램적인 변경의 결과로서 성능이 저하되었다는 것을 나타낸다면, 상기 프로그램적인 변경을 프로그램적으로 반전(reverse)시키는 단계와,

상기 기준 동작 특성을 프로그램적으로 축적하는 단계와, 상기 프로그램적으로 변경하는 단계와, 상기 새로운 동작 특성을 프로그램적으로 축적하는 단계와, 상기 프로그램적으로 반전시키는 단계를 수행하는데 대하여 요금을 부과하는 단계를 포함하는 사업 방법.