JP2007529079A - 自己調節スレッド化モデルによるアプリケーションサーバのためのシステム及び方法 - Google Patents

Abstract

【課題】自己調節スレッド化モデルによるアプリケーションサーバのためのシステム及び方法を提供する。
【解決手段】自己調節スレッド化モデルによるアプリケーションサーバのためのシステム及び方法。サーバ待ち行列は、優先順位スキームとして用いられ、受信した要求に関連するいくつかのエントリをそこに含み、これによってエントリは、単にスレッドの数だけよりも明示的な優先順位又はシェア値を有することができる。必要と考えられる場合はいつでもスレッドを生の数値データで表すか又は利用可能にされるスレッドの数に対する制約を表すための柔軟性が保持される。
【選択図】図２

Description

著作権の通知
この特許文書の開示の一部分は、著作権の保護を受ける内容を含んでいる。著作権所有者は、特許商標事務局の特許ファイル又は記録にあるような特許文書又は特許開示のファクシミリ複製を誰が行っても異論はないが、それ以外はあらゆる著作権を保持するものである。
優先権の請求
アンノ・ランゲン及びナレシュ・レバヌルにより２００４年５月２０日出願で本明細書において引用により組み込まれている「自己調節スレッド化モデルによるアプリケーションサーバのためのシステム及び方法」という名称の米国特許仮出願第６０／５７２，９３８号（代理人整理番号：ＢＥＡＳ−０１５６０ＵＳ０）。
アンノ・ランゲン及びナレシュ・レバヌルにより２００５年５月１９日出願で本明細書において引用により組み込まれている「自己調節スレッド化モデルによるアプリケーションサーバのためのシステム及び方法」という名称の米国特許出願第＿＿＿＿＿号（代理人整理番号：ＢＥＡＳ−０１５６０ＵＳ１）。

本発明は、一般的にはアプリケーションサーバ及びメッセージングシステムに関し、具体的には、自己調節スレッド化モデルによるアプリケーションサーバのためのシステム及び方法に関する。

典型的なアプリケーションサーバ又はウェブサーバ環境においては、恐らく何百又は何千の同時ユーザ（クライアント）が存在し、これらのクライアントの各々がサーバに要求を送信する可能性がある。図１は、このような環境の例を示している。最新サーバ１００は、多くのプロセッサ及びこれらのプロセッサに情報を提供する多くのスレッド１０２を有することができる。スレッドは、クライアント１０４、１０６、１０８から要求１１０、１１２、１１４を取り出し、それらを待ち行列のような方式でプロセッサに付加する。用いられるスレッドの実際の数は、サーバの性能、及び多数のユーザに対処するその機能に大きな影響を及ぼす。しかし、最適な数のスレッドを計算することは複雑な処理である。

この問題に対する１つの手法は、スレッドの数がプロセッサの数を大きく超えるように更に多くのスレッドを追加することであった。これによって要求がほぼ直ちにスレッドの中に送られることが保証されるが、これらの要求がプロセッサによって迅速に取り上げられることは保証されない。より最新の代替法は、変動する数のスレッドが内部で作動するスレッドプールを作成することである。スレッドの実際の数は、次に管理者によって微調整され、特定のランタイム環境に対して最良の性能をもたらすことができる。しかし、この処理は、管理者の技術に大きく依存し、それが非常に環境依存的かつ静的であるために、最も役に立つのは、テスト・ベンチング及びマーケティング目的のみである。現実の状況では、環境は非常に変化するので、この静的手法は満足できるものではない。

従って、必要とされるものは、サーバが作業負荷の客観的予測に基づき同時スレッドの最適数を自動的に判断して実施することを可能にするための手段である。アプリケーションサーバが位置する場所（オペレーティングシステムよりも上位）の制限のために、このスレッド制御は、オペレーティングシステム内に組み込むことはできないが、より高いレベルに存在することができるべきである。従って、アプリケーションサーバ内のスレッドの数及びこれらを送る待ち行列を制御するための手段があるべきである。

本発明の実施形態により、自己調節スレッド化モデルによるアプリケーションサーバのためのシステム及び方法が提供される。実施形態によると、サーバ待ち行列は、優先順位スキームとして用いられ、受信した要求に関連するいくつかのエントリをそこに含み、これによってエントリは、単にスレッドの数だけよりもビジネスユーザに自然で身近な明示的な優先順位を有することができる。必要と考えられる場合に生の数値データでスレッドを表し（例えば、特定数のスレッドが利用可能にされなければデッドロックすると考えられる既知の呼び出しシーケンスがある場合）、又はシステムを通じて又は作業負荷ベースで利用可能とされるスレッドの数に対する制約を表す柔軟性は、依然として保持される。

実施形態により、優先順位は、「シェア」つまり要求を受信することになるエンティティ間の比例優先順位を反映する抽象的表現として特定することができる。その総数は任意であり、恐らく１００シェアよりも多い場合があるので、シェアは、百分率のスレッド使用と同一ではないが、それらは類似している。シェアは、各エンティティに割り当てられたスレッド使用（スレッド数による）を判断するものである。システム（又は、その上で作動するアルゴリズム）は、次に、長期間にわたってスレッドの使用（スレッドタイムによる）がこれらのシェアによって分配されることになることを保証する。例えば、エンティティに割り当てられた２倍の時間又はスレッド分を使用するいかなるエンティティも、次に、相対使用割合を均衡状態に戻すようにペナルティを科せられることになる。

実施形態により、ランタイム中にアルゴリズムもまた用いられて、スレッドプールの大きさを定め、次に、スレッドをプール内に割り当てることができる。
実施形態により、優先待ち行列が維持される。各要求しているエンティティ、例えばクライアントは、待ち行列の中に入って相対シェアに従って離間した要求を出すことができる。従って、例えば、エンティティがその割り当てを超えていなければ、割り当てを使い果たしたか又はより低い時間ベースの割り当て又はシェアを有する別のエンティティに比較して、その要求は、待ち行列の比較的高位置に配置することができ、スレッドの獲得を直ちに開始することになる。

実施形態により、最大スレッド制約に対して、システムは、優先待ち行列内及び最大スレッド制約待ち行列内にも要求を保持するために別々の待ち行列を維持することができる。最大スレッド制約待ち行列が消去されると、優先待ち行列内のあらゆる同様の項目（すなわち、同じ制約に関する何か）を実行することが許されることになる。
実施形態により、スレッドプールのサイズ設定は、既存プールの１つによる増分又は減分にまで導くことができる。これは、定期的に、例えば１秒又は２秒毎に実施される。
自己調節スレッド化モデルの全体的結果は、すぐに使える性能におけるサーバの劇的改善である。スレッド特性は、特定の必要性に適するように更に調整することができる。この特徴はまた、サーバ顧客が彼らのシステムの設定により柔軟性を有することを可能にし、彼らに特定のビジネス論理又は顧客必要性の組などに対して彼らのスレッド化モデルに優先順位を付ける方法を提供する。

現在、アプリケーションサーバ顧客は、デッドロックを回避して差異化サービスをもたらすための新たなスレッドプールを定めてその大きさを設定する。これは、かなり困難な処理である。有能なソフトウエア管理者チームが、最適な性能のための設定の解明に数日を費やす場合がある。
本発明の実施形態により、自己調節サーバは、スレッドの数を動的に調整してデッドロックを回避し、並行制約による最適な処理量を達成する。これはまた、差異化サービスの目的も満たすものである。これらの目的は、応答時間ゴール、シェア、及び優先順位で表される。

実施形態により、システムは、作業負荷管理に関する要件、実行待ち行列の一掃、スレッドカウント調節、及び過負荷保護に対処する。サーバ内の多くの実行待ち行列が崩壊して、単一の優先順位ベース待ち行列になることができる。システムは、優先順位が高い作業が待ち行列でより少ない時間を費やす優先順位ベースの作業スケジューリング方式を実施する。スケジューリングは、リソース制約を考慮する。主に着目する点は、拡張可能なスケジューリングモデルを作り、管理者が作業負荷管理規則を指定することを可能にすることである。

本発明の実施形態により、自己調節スレッド化モデルによるアプリケーションサーバのためのシステム及び方法が提供される。実施形態によると、サーバ待ち行列は、優先順位スキームとして用いられ、受信した要求に関連するいくつかのエントリをそこに含み、これによってエントリは、単にスレッドの数だけよりもビジネスユーザに自然で身近な明示的な優先順位を有することができる。必要な場合に生の数値データでスレッドを表し（例えば、特定数のスレッドが利用可能にされなければデッドロックすると考えられる既知の呼び出しシーケンスがある場合）、又はシステムを通じて又は作業負荷ベースで利用可能とされるスレッドの数に対する制約を表す柔軟性は、依然として保持される。

実施形態により、優先順位は、「シェア」つまり要求を受信することになるエンティティ間の比例優先順位を反映する抽象的表現として特定することができる。その総数は任意であり、恐らく１００シェアよりも多い場合があるので、シェアは、百分率のスレッド使用と同一ではないが、それらは類似している。シェアは、各エンティティに割り当てられたスレッド使用（スレッド数による）を判断するものである。システム（又は、その上で作動するアルゴリズム）は、次に、長期間にわたってスレッドの使用（スレッドタイムによる）がこれらのシェアによって分配されることになることを保証する。例えば、エンティティに割り当てられた２倍の時間又はスレッド分を使用するいかなるエンティティも、次に、相対使用割合を均衡状態に戻すようにペナルティを科せられることになる。

実施形態により、ランタイム中にアルゴリズムもまた用いられて、スレッドプールの大きさを定め、次に、スレッドをプール内に割り当てることができる。
実施形態により、優先待ち行列が維持される。各要求しているエンティティ、例えばクライアントは、待ち行列の中に入って相対シェアに従って離間した要求を出すことができる。従って、例えば、エンティティがその割り当てを超えていなければ、割り当てを使い果たしたか又はより低い時間ベースの割り当て又はシェアを有する別のエンティティに比較して、その要求は、待ち行列の比較的高位置に配置することができ、スレッドの獲得を直ちに開始することになる。

実施形態により、最大スレッド制約に対して、システムは、優先待ち行列内及び最大スレッド制約待ち行列内にも要求を保持するために別々の待ち行列を維持することができる。最大スレッド制約待ち行列が消去されると、優先待ち行列内のあらゆる同様の項目（すなわち、同じ制約に関する何か）を実行することが許されることになる。
実施形態により、スレッドプールのサイズ設定は、既存プールの１つによる増分又は減分にまで導くことができる。これは、定期的に、例えば１秒又は２秒毎に実施される。
自己調節スレッド化モデルの全体的結果は、すぐに使える性能におけるサーバの劇的改善である。スレッド特性は、特定の必要性に適するように更に調整することができる。この特徴はまた、サーバ顧客が彼らのシステムの設定により柔軟性を有することを可能にし、彼らに特定のビジネス論理又は顧客必要性の組などに対して彼らのスレッド化モデルに優先順位を付ける方法を提供する。

図２は、本発明の実施形態により、複数のクライアントがスレッド及び優先待ち行列を用いてサーバにアクセスする環境の図を示している。図２に示すように、サーバ１２０は、多くのプロセッサ及びこれらのプロセッサに情報を提供する多くのスレッド１２２を有することができる。優先待ち行列１２４は、クライアント１０４、１０６、１０８から要求１１０、１１２、１１４を取り出し、エントリを待ち行列に入れ、エントリをその後プロセッサに付加するスレッドにエントリを送信する（１２６）前に、予め設定されたあらゆるシェア値又は制約によってエントリに優先順位を付ける。

図３は、本発明の実施形態によってスレッドを用いてサーバにアクセスする処理の流れ図を示している。図３に示すように、段階１３０において、サーバは、シェア値に従ってエンティティ間でスレッドリソースを共有するように設定される。これは、管理者がシェア値を数値的に入力するコンソール入力を通して又は何らかの他のタイプの装置を通して行うことができる。段階１３２において、サーバは、クライアントから要求を受信する。段階１３４において、要求は、シェア値によって及び各エンティティがスレッドタイムを既にどれくらい使用したかに基づいて優先待ち行列に入れられる。段階１３６において、要求が優先待ち行列から取り出され、プロセッサによって処理するためにスレッドに呈示される。

実施の詳細
作業技術者及びアプリケーション管理者は、これらの特徴の主要なユーザである。管理者は、公平なシェア及び応答時間ゴールのようなアプリケーションのスケジューリング目的を表明する。この節の関連で用いられる場合、以下の定義が用いられる。
制約作業セット−作業は、共有するリソースに基づき分類することができる。このセットにおける全ての作業の性能は、共有リソースの容量によって制約される。
エントリポイント−例には、ＲＭＩ方式記述子、ＨＴＴＰ、ＵＲＩ、ＭＤＢ、及び「ＪＣＡ １．５ ＷｏｒｋＭａｎａｇｅｒ」インスタンスが含まれる。
フェアシェア（ｆａｉｒ ｓｈａｒｅ）−スレッドを使用する権利。サービスクラスがスレッドを求めて競合すると、それらは、そのそれぞれのシェアに比例してスレッドを割り当てられることになる。この比率は、サービスクラスが競合する間の十分に長い期間の平均としてのみ実現されるものである。他にアクティブなものがなければ、全てのスレッドは、ある一定のサービスクラスに割り当てることができる。

自己調節−自動的に低レベルカーネルパラメータを設定するサーバの機能。管理者は、管理者が理解するアプリケーション要件、例えば応答時間ゴールを定義することができ、サーバは、相応にその低レベルパラメータを調節することになる。
応答時間ゴール−サーバ内のエントリポイントに到達する要求と送信されている応答との間に経過する可能性があるミリ秒の最大数に対するゴール。
サービスクラス−サービスクラスは、サーバ内の作業を分類するものである。目的は、個々の要求ではなくサービスクラスに対して表されて追跡される。システムは、それが待機状態になる前に要求のサービスクラスを判断することができるべきである。一部の有用なサービスクラスは、エントリポイント、Ｊ２ＥＥモジュール、トランザクション名、現行ユーザ、又は何らかの指定作業域に従って分類することで発生する。
スケジューリングポリシー−要求の待機継続期間をそのサービスクラス及び競合サービスクラスからの要求に基づき判断する。

作業負荷の管理
この特徴は、サーバがサービスクラス、制約、及びサーバ内で観察された負荷状況を用いて作業をスケジュールに入れる方法を説明する。サーバは、優先待ち行列で待機状態になった作業の様々なクラスに対して異なるスケジューリングポリシーを許すものである。これは、サービスクラスを提出した作業によって特定することによって可能である。この特徴は、システムに対して、優先順位が高い作業が後で到着する時でさえも、重要でない作業の前に優先順位の高い作業をスケジュールに入れさせる。競合期間中、所定のサービスクラスに情報提供するスレッドの数は、その表明した目的に依存する。制約は、デッドロック及び過負荷条件中にカーネルが作業を処理すべき方法を定める。

自動スレッドカウント調節
サーバは、最大処理量を得るためにかつ最小並行性保証を実施するためにそのスレッドカウントを自動的に調節する。「ｔｈｒｅａｄｓＩｎｃｒｅａｓｅ」又は「ｔｈｒｅａｄｓＭａｘｉｍｕｍ」のようなパラメータは、もはや必要ない。

起動時に作成される実行待ち行列の低減
従来の実施では、サブシステムは、デッドロック防止、最小スレッド保証などのような様々な理由でそれ自身の実行待ち行列を作成する。自己調節は、複数の実行待ち行列を作成してサービスクラス及び制約を用いてこれらの要件を満たす必要性を取り除くものである。

過負荷保護
過負荷保護は、重負荷の下でのサービスの低下からサーバを保護するものである。過負荷条件において、サーバは、設定可能な方法で要求を拒絶する。管理者は、後でサーバが要求を拒絶する場合がある閾値待ち行列長さを指定することができる。優先順位の低い要求のバーストは、拒絶される可能性が最も高い。彼らはまた、個々のサービスクラスに対してより具体的な閾値を指定することができる。

ＪＣＡ １．５ ＷｏｒｋＭａｎａｇｅｒ
「ＪＣＡ １．５ ＷｏｒｋＭａｎａｇｅｒ」ＡＰＩは、サーバの作業をスケジュールに入れるアダプタに対する方法を提供する。このＡＰＩは、スレッドスケジューリング機能性を公開するものである。アプリケーションは、「ＷｏｒｋＭａｎａｇｅｒ」ＡＰＩを用いて非同期的に作業を実行し、実行状態に関する通知を受信することができる。

作業負荷管理の機能説明
管理者は、以下の例に示すように、特別の目的を表明するためにスケジューリングポリシーを定めることができ、かつ制約を表すことができる。

配備記述子及びＲＭＩ記述子は、次に、「ＣｏｎｔｅｘｔＳｈｏｐｐｉｎｇ」及び「ｍｉｎＴｈｒｅａｄｓＦｏｒＰｌｕｇｉｎＭａｘＰｒｏｃｅｓｓｅｓ」のような名称を参照し、これらをエントリポイントに付加することができる。

フェアシェアは、複数のサービスクラスが競合する限り、各々によって用いられるスレッドの平均数がそのフェアシェアに比例するように、スケジューリング論理に反映される。例えば、２つのサービスクラスＡ及びＢのみがあり、それぞれ８０及び２０のフェアシェアを有する状況を考える。両方のサービスクラスが十分に要求される、つまりゼロ思考時間かつスレッドよりもクライアントが多い期間中に、Ａ又はＢを代表してスレッドが作業することになる確率は、それぞれ８０％又は２０％になる傾向があることになる。スケジューリング論理は、ＡがＢよりも遙かに長くスレッドを用いる傾向がある時でさえもこれを保証する。

応答時間ゴールは、サービスクラスを差異化することができる。システムは、個々の要求に対して応答時間ゴールを満たそうとしない。むしろそれは、観察された平均スレッド使用時間を差し引くことによってサービスクラスに対する許容待機時間を計算する。次に、それは、各サービスクラスに対する平均待機がその許容待機時間に比例するように要求をスケジュールに入れることができる。例えば、２つのサービスクラスＡ及びＢのみがあり、それぞれ応答時間ゴールが２０００ｍｓ及び５０００ｍｓであり、かつ個々の要求がスレッドを用いる時間がこれよりも遙かに短い状況を考える。両方のサービスクラスが十分に要求される、つまりゼロ思考時間かつスレッドよりもクライアントが多い期間中では、システムは、平均応答時間を２：５の比率に保つようにスケジュールに入れ、それによってそれが、表明したゴールの常分数又は公倍数になるようにすることができる。

スケジューリング実行の理解は、スケジューリングポリシーの理解に役立つものである。各サービスクラスは増分を有し、その間隔で離間した仮想時間スタンプでイベント待ち行列に要求を入力することができる。優先順位の高いものは、小さな増分によって実行される。スケジューリングポリシーは、以下のように説明することができる。

応答時間
属性「ｇｏａｌ−ｍｓ」をミリ秒で表すと、増分は、以下のようになる。
（（ｇｏａｌ−Ｔ）Ｃｒ）／Ｒ
ここで、Ｔは、平均スレッド使用時間、Ｒは到着率、Ｃｒは、フェアシェアに対して応答時間ゴールに優先順位を付ける係数である。

フェアシェア
属性をデフォルトシェアの百分率で表す。従って、デフォルトは１００である。増分は、以下のようになる。
Ｃｆ／（ＰＲＴ）
ここで、Ｐは百分率、Ｒは到着率、Ｔは、平均スレッド使用時間、Ｃｆは、応答時間ゴールよりも低くフェアシェアの優先順位を付けるフェアシェアに対する係数である。

コンテキスト
現行ユーザ又はその役割、クッキー、又は作業域フィールドのようなコンテキスト情報を指名サービスクラスにマップする複数の場合がある。

ＳｕｂｏｒｄｉｎａｔｅＳｔｅｐＲｅｓｐｏｎｓｅＴｉｍｅ
「ＰｒｉｍａｒｙＳｔｅｐＲｅｓｐｏｎｓｅＴｉｍｅ」を指名する属性「ｐｒｉｍａｒｙ」を有する。

ＰｒｉｍａｒｙＳｔｅｐＲｅｓｐｏｎｓｅＴｉｍｅ
属性「ｇｏａｌ−ｍｓ」をミリ秒で表すと、増分は、応答時間ゴールと同様に計算される。主要段階に対する下位段階の比率を用い、許容待機を得るために下位段階のその多くの平均スレッド使用を差し引く。主要段階に下位段階を加えた全ての段階に対する到着率で許容待機を割算し、応答時間係数で乗算する。

固定増分
属性「ｉｎｃｒｅｍｅｎｔ」を有する。
フェアシェア係数は、到着率及び平均スレッド使用時間の最大積の約１０００倍になるように選択される。応答時間係数は、応答時間ポリシーの平均増分がフェアシェアポリシーの平均増分の１０分の１でしかないように選択される。

制約
制約を定義してエントリポイントのセットに適用することができ、これは、本明細書で制約作業セットと呼ぶ。

ｍａｘ−ｔｈｒｅａｄｓ
制約作業セットからの要求を実行する並行スレッドの数を制限する。デフォルトは無制限である。例えば、１０の最大スレッドで定められ、３つのエントリポイントによって共有された制約を考える。スケジューリング論理は、１０を超えないスレッドが３つのエントリポイントを組合せたものからの要求を実行していることを保証する。

ｍｉｎ−ｔｈｒｅａｄｓ
デッドロックを回避するためにサーバが制約作業セットの要求に割り当てることになるスレッドの数を保証する。デフォルトはゼロである。「ｍｉｎ−ｔｈｒｅａｄｓ」値の１は、例えば、ピアから同期的に呼び出される複製更新要求に有用である。

容量
サーバは、その容量に達した時のみに要求を拒絶し始める。デフォルトはゼロである。容量は、待ち行列に入れられているか又は実行されている制約作業セットからの全ての要求を含むことに注意されたい。この制約は、主としてそれ自身のフロー制御を行うＪＭＳのようなサブシステムを意図したものである。この制約は、全体的な待ち行列閾値から独立している。

異なるスケジューリングポリシー及び制約は、以下のように相互作用する。
上記では、スケジューリングポリシーは、スケジューリングを同じポリシーを用いる他の作業に関連付けることによってフェアシェア及び応答時間に基づくことができると説明した。フェアシェア及び応答時間ポリシーの混合は、応答時間スケジューリングに好ましい顕著なバイアスでスケジュールに入れられる。
最小スレッド制約は、フェアシェアを増加させない。それは、ほぼデッドロックされたサーバに対してのみ問題になる。しかし、次に、それは、システムがそのサービスクラスが最近そのフェアシェアよりも多く得ている時でさえも最小スレッド制約作業セットからの要求をスケジュールに入れるという意味で、切り札を出すことになる。

最大スレッド制約は、必ずというわけではないが、サービスクラスがそのフェアシェアを取り出すこと又はその応答時間ゴールを満たすことを防ぐ場合があると考えられる。最大スレッド制約に達した状態で、サーバは、並行実行の数が限度よりも低くなるまでこの制約タイプの要求をスケジュールに入れないことになる。サーバは、その後にフェアシェア又は応答時間ゴールに基づき作業をスケジュールに入れることになる。

「ａｄｍｉｎ＿ｒｍｉ」及び「ａｄｍｉｎ＿ｈｔｍｌ」待ち行列要件は、最小スレッド制約及びデフォルトフェアシェアによって対処することができる。システム待ち行列要件もまた、最小スレッド制約によって満足される。マルチキャスト待ち行列要件は、最大スレッドも最小スレッドも１に等しく設定することによって満足される。これは、マルチキャスト要求を処理している、従って、順序付けを保証している唯一のスレッドが存在することを保証するものである。

機能要件
ディスパッチポリシー及び制約は、３レベル、すなわち、「ｃｏｎｆｉｇ．ｘｍｌ」で全体的に、「ｗｅｂｌｏｇｉｃ−ａｐｐｌｉｃａｔｉｏｎ．ｘｍｌ」でアプリケーション毎に、又は「ｗｅｂｌｏｇｉｃ」配備記述子の「ｗｅｂｌｏｇｉｃ−ｅｊｂ−ｊａｒ．ｘｍｌ」及び「ｗｅｂｌｏｇｉｃ．ｘｍｌ」で特定の「Ｊ２ＥＥ」モジュールに対して定義することができる。これらの名称は、対応するタグの「ｄｉｓｐａｔｃｈ−ｐｏｌｉｃｙ」、「ｍａｘ−ｔｈｒｅａｄｓ」、及び「ｍｉｎ−ｔｈｒｅａｄｓ」から用いることができる。「ｍａｘ−ｔｈｒｅａｄｓ」及び「ｍｉｎ−ｔｈｒｅａｄｓ」タグは、それぞれ「ｍａｘ−ｔｈｒｅａｄｓ−ｃｏｎｓｔｒａｉｎｔ」又は「ｍｉｎ−ｔｈｒｅａｄｓ−ｃｏｎｓｔｒａｉｎｔ」の名称、又はある一定の番号のいずれかである値をとる。「ｗｅｂｌｏｇｉｃ−ａｐｐｌｉｃａｔｉｏｎ．ｘｍｌ」においては、これらのタグは、アプリケーションを通じたデフォルトを指定する。「ｗｅｂｌｏｇｉｃ．ｘｍｌ」及び「ｗｅｂｌｏｇｉｃ−ｅｊｂ−ｊａｒ．ｘｍｌ」においては、それらは、構成要素を通じたデフォルトを最上位レベルで指定する。「ｗｅｂｌｏｇｉｃ．ｘｍｌ」においては、マッピングは、指名「ｄｉｓｐａｔｃｈ−ｐｏｌｉｃｙ」、「ｍａｘ−ｔｈｒｅａｄｓ」、又は「ｍｉｎ−ｔｈｒｅａｄｓ」が「ｕｒｉ−ｐａｔｔｅｒｎｓ」又はサーブレット名に対してマップされる「ｗｅｂ．ｘｍｌ」のフィルタマッピングとの類似が許される。「ｍａｘ−ｔｈｒｅａｄｓ−ｍａｐｐｉｎｇ」及び「ｍｉｎ−ｔｈｒｅａｄｓ−ｍａｐｐｉｎｇ」もまた数値を許容する。「ｗｅｂｌｏｇｉｃ−ｅｊｂ−ｊａｒ．ｘｍｌ」においては、「ｗｅｂｌｏｇｉｃ−ｅｎｔｅｒｐｒｉｓｅ−ｂｅａｎ」の下での既存の「ｄｉｓｐａｔｃｈ−ｐｏｌｉｃｙ」タグの値は、指名された「ｄｉｓｐａｔｃｈ−ｐｏｌｉｃｙ」とすることができる。下位互換性に対して、それはまた、「ＥｘｅｃｕｔｅＱｕｅｕｅ」を指名することができる。更に、システムはまた、「ｄｉｓｐａｔｃｈ−ｐｏｌｉｃｙ」、「ｍａｘ−ｔｈｒｅａｄｓ」、及び「ｍｉｎ−ｔｈｒｅａｄｓ」が、現在の「ｉｓｏｌａｔｉｏｎ−ｌｅｖｅｌ」タグと同様に方法のリストに対して指名された（又は、制約に対する数値を用いて無指名の）ポリシー及び制約を指定することを可能にすることができる。

以下は、「ｗｅｂｌｏｇｉｃ−ａｐｐｌｉｃａｔｉｏｎ．ｘｍｌ」からの例である。

以下は、サービスクラスを構成要素レベルで定義するＲＭＩ記述子からの例である。

「ｍａｘ−ｔｈｒｅａｄｓ」値は、番号、指名「ｍａｘ−ｔｈｒｅａｄｓ−ｃｏｎｓｔｒａｉｎｔ」、又は指名接続プール（ＪＤＢＣ又はＪＣＡ）とすることができる。リソースの大きさが動的であれば、関連する最小又は最大スレッド制約もまた動的であることになり、リソースの大きさが変わると変化する。

自動スレッドカウント調節の機能説明
優先待ち行列に情報提供するスレッドプールは、処理量を最大にするように自動的にその大きさを変化させる。管理者は、もはや「ｔｈｒｅａｄｓＩｎｃｒｅａｓｅ」及び「ｔｈｒｅａｄｓＭａｘｉｍｕｍ」のような「ＥｘｅｃｕｔｅＱｕｅｕｅＭＢｅａｎ」属性を指定する必要はない。優先待ち行列は、２秒毎に処理量をモニタし、収集されたデータを用いてスレッドカウントを変える必要があるかを判断する。例えば、過去にスレッドが多いほど処理量がよかったならば、サーバは、スレッドカウントを増加させることになる。同様に、過去に少ない数のスレッドが同じ処理量をもたらした場合は、サーバは、スレッドカウントを低減することになる。

機能要件
ユーザ入力は必要ではない。サーバは、処理量履歴及び待ち行列の大きさに全体的に基づいてスレッドカウントを判断する。

開始機能説明上に作成された実行待ち行列の低減
異なる実行待ち行列を崩壊させて単一優先待ち行列にする。過去においては、デッドロックを防ぎ（ａｄｍｉｎ＿ｒｍｉ、非ブロッキング）、作業に優先順位を付け（システム）、順序付けを達成する（マルチキャスト）ために異なる実行待ち行列を作成することが必要であった。これらの要件は、サービスクラスを待機状態の作業に関連付けることによって満足される。全ての作業は、優先待ち行列に提出することができ、スレッド使用時間は、待ち行列に存在するサービスクラスのタイプに基づいている。

機能要件
以下の表は、既存の実行待ち行列をサービスクラス及び制約にマップすることができる方法を説明している。

過負荷保護の機能説明
管理者は、サーバがその後要求を抑制し始める過負荷閾値を計算することができる。抑制は、以下のように行われる。
サーバが、最小スレッド制約セットを具備しない低次のフェアシェアから始めて要求を拒絶する。優先順位が高いサービスクラス又は最小スレッド制約を有するサービスクラスは、依然として受け入れられる。
過負荷条件が支配を続ける場合、サーバが過負荷条件から回復することができないので、優先順位の高い要求もまた拒絶されることになる。最小スレッド制約を有する要求及び管理要求は、依然として受け入れられることになる。
作業が拒絶された場合、明確なエラー応答が送信される。「５０３：サーバ使用中」エラーがＨＴＴＰに送信され、遠隔例外がＲＭＩに対して投入され、これによってクラスターは、フェイルオーバーするクライアントを知ることができると考えられる。

機能要件
待ち行列限界は、全体レベルで又は作業クラス毎に指定することができる。全体的閾値は、「ＫｅｒｎｅｌＭＢｅａｎ」属性として公開することができる。作業のクラスは、「制約」内の容量要素を用いて閾値を定義することができる。容量要素を設定する方法の例を以下に示している。

容量制約は、全体的閾値を無効にする。これは、サーバが、全体的閾値に達した時でさえ要求を受け入れ続けることになることを意味する。作業は、容量制約に達した時にのみ拒絶されることになる。これは、自身のフロー制御を実行して全体的待ち行列閾値を用いることができないサブシステムに有用である。

ＨＴＴＰ過負荷アクション
システムは、サーバがクラスター内にある場合、５０３エラーコードを送信することになる。これは、プラグインにフェイルオーバーさせることになる。サーバがクラスターに属さない場合、システムは、顧客が過負荷応答として用いられることになるエラーＪＳＰを設定することを可能にすることができる。顧客はまた、過負荷アクションとして宛先変更を指定することにより、過負荷期間中に別のサーバに要求を宛先変更することができる。

ＲＭＩ過負荷アクション
サーバがクラスター内にある場合、システムは、「ＲｅｍｏｔｅＥｘｃｅｐｔｉｏｎ」のサブクラスである「ＳｅｒｖｅｒＯｖｅｒｌｏａｄｅｄＥｘｃｅｐｔｉｏｎ」を投入する。クライアントは、これを回復可能な例外と解釈し、別のクラスターノードにフェイルオーバーすることになる。非クラスターシナリオでは、顧客は、宛先変更のために代替的なサーバを指定することができる。過負荷期間中のＲＭＩ要求は、この代替的なサーバに宛先変更されることになる。

サーバは、拒絶応答を送信するために読取スレッドを用いないことになる。応答の書込みは、遅い可能性があるＩ／Ｏを伴っている。応答を書き込むために読取スレッドを用いることは、読取スレッド全てを遮断して到着するソケット多重化を防ぐことができる。
サブシステムは、過負荷通知のためにカーネルに登録することができる。全体的待ち行列閾値が超過すると、カーネルは、その聴取者に通知することになる。この通知を使用して、作業を抑制してサブシステムレベルに戻すことができる。

機能要件
「ＷｏｒｋＭａｎａｇｅｒ」は、アプリケーションスコープ又はグローバルとすることができる。アプリケーションスコープ「ＷｏｒｋＭａｎａｇｅｒ」は、以下のような「ｗｅｂｌｏｇｉｃ−ａｐｐｌｉｃａｔｉｏｎ．ｘｍｌ」内に定義することができる。

アプリケーションから「ＷｏｒｋＭａｎａｇｅｒ」にアクセスするために、ローカル環境（ｊａｖａ：ｃｏｍｐ／ｅｎｖ）内にその名称を探すことになる。例えば、以下のようになる。

システムは、各「ＷｏｒｋＭａｎａｇｅｒ」定義に対してスレッド群を作成しない。全ての「ＷｏｒｋＭａｎａｇｅｒ」インスタンスは、デフォルト待ち行列を共有する。それらは、その「ｆａｉｒ−ｓｈａｒｅ」又は「ｒｅｓｐｏｎｓｅ−ｔｉｍｅ−ｇｏａｌ」に基づき優先順位を付けられる。

本発明は、本開示の教示に従ってプログラムされた従来の汎用又は専用デジタルコンピュータ又はマイクロプロセッサを使用して好都合に実施することができる。ソフトウエア技術の当業者には明らかなように、熟達したプログラマーは、本開示の教示に基づいて適切なソフトウエアコーディングを容易に作成することができる。
一部の実施形態では、本発明は、コンピュータプログラム製品を含み、これは、本発明の処理のいずれかを実行するようにコンピュータをプログラムするのに使用することができる命令をそこに／その上に記憶した記憶媒体（又は複数の媒体）である。記憶媒体は、以下に限定されるものではないが、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、及び光磁気ディスクを含むあらゆるタイプのディスクと、ＲＯＭと、ＲＡＭと、ＥＰＲＯＭと、ＥＥＰＲＯＭと、ＤＲＡＭと、ＶＲＡＭと、フラッシュメモリデバイスと、磁気又は光学式カードと、ナノシステム（分子メモリＩＣを含む）と、あるいは命令及び／又はデータを記憶するのに適するあらゆるタイプの媒体又はデバイスとを含むことができる。

本発明の以上の説明は、例示及び説明のために提供したものである。網羅的であること又は本発明を開示した通りの形に限定することを意図していない。実施形態は、本発明の原理及びその実用的応用を最も良く説明し、それによって当業者が様々な実施形態に関して及び考えられる特定用途に適する様々な修正を用いて本発明を理解することを可能にするように選択して説明したものである。本発明の範囲は、特許請求の範囲及びその均等物により規定されるものとする。

複数のクライアントがスレッドを用いてサーバにアクセスする環境を示す図である。 本発明の実施形態によって複数のクライアントがスレッド及び優先待ち行列を用いてサーバにアクセスする環境を示す図である。 本発明の実施形態によってスレッドを用いてサーバにアクセスする処理の流れ図である。

符号の説明

１０４、１０６、１０８ クライアント
１１０、１１２、１１４ 要求
１２０ サーバ
１２２ スレッド
１２４ 優先待ち行列

Claims (18)

1. アプリケーションサーバにおける自己調節スレッド化モデルのためのシステムであって、
   １つ又はそれ以上のプロセッサを含むサーバと、
   クライアントからの要求を受信し、それらの要求をプロセッサに通信する１つ又はそれ以上のスレッドと、
   前記スレッドの性能を最適化するために、スレッドをシェア値に従って複数の要求に割り当てるための優先待ち行列と、
   を含むことを特徴とするシステム。
2. 前記サーバは、複数のプロセッサを含むことを特徴とする請求項１に記載のシステム。
3. エントリが、比例配分された時間値に従って前記優先待ち行列に入れられることを特徴とする請求項１に記載のシステム。
4. 前記エントリは、前記時間値に比較して既に使用した計算されたスレッド使用時間に従って待ち行列に入れられることを特徴とする請求項３に記載のシステム。
5. 前記エントリは、付加的に設定された制約に従って待ち行列に入れることができることを特徴とする請求項１に記載のシステム。
6. 前記制約は、前記エントリを付加的な制約待ち行列に入れることによって判断されることを特徴とする請求項５に記載のシステム。
7. アプリケーションサーバにおける自己調節スレッド化モデルのための方法であって、
   エンティティ間でスレッドリソースを共有するようにシェア値に従ってサーバを設定する段階と、
   前記サーバにおいてクライアントから要求を受信する段階と、
   前記シェア値に従って及び各エンティティが既にスレッドタイムを使用した量に基づいて要求を優先待ち行列に入れる段階と、
   前記優先待ち行列から前記要求を取り出し、プロセッサによって処理するためにそれらを前記スレッドに呈示する段階と、
   を含むことを特徴とする方法。
8. 前記サーバは、複数のプロセッサを含むことを特徴とする請求項７に記載の方法。
9. エントリが、比例配分された時間値に従って前記優先待ち行列に入れられることを特徴とする請求項７に記載の方法。
10. 前記エントリは、前記時間値に比較して既に使用した計算されたスレッド使用時間に従って待ち行列に入れられることを特徴とする請求項９に記載の方法。
11. エントリを、付加的に設定された制約に従って待ち行列に入れることができることを特徴とする請求項７に記載の方法。
12. 前記制約は、前記エントリを付加的な制約待ち行列に入れることによって判断されることを特徴とする請求項１１に記載の方法。
13. 命令を含んだコンピュータ読み取り可能な記録媒体であって、
    前記命令は、実行された時に、
    エンティティ間でスレッドリソースを共有するようにシェア値に従ってサーバを設定する段階と、
    前記サーバにおいてクライアントから要求を受信する段階と、
    前記シェア値に従って及び各エンティティが既にスレッドタイムを使用した量に基づいて要求を優先待ち行列に入れる段階と、
    前記優先待ち行列から前記要求を取り出し、プロセッサによって処理するためにそれらを前記スレッドに呈示する段階と、
    を前記コンピュータに実行させる、
    ことを特徴とするコンピュータ読み取り可能な記録媒体。
14. 前記サーバは、複数のプロセッサを含むことを特徴とする請求項１３に記載のコンピュータ読み取り可能な記録媒体。
15. エントリが、比例配分された時間値に従って前記優先待ち行列に入れられることを特徴とする請求項１３に記載のコンピュータ読み取り可能な記録媒体。
16. 前記エントリは、前記時間値に比較して既に使用した計算されたスレッド使用時間に従って待ち行列に入れられることを特徴とする請求項１５に記載のコンピュータ読み取り可能な記録媒体。
17. エントリを、付加的に設定された制約に従って待ち行列に入れることができることを特徴とする請求項１３に記載のコンピュータ読み取り可能な記録媒体。
18. 前記制約は、前記エントリを付加的な制約待ち行列に入れることによって判断されることを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。

Images