JP2000029815A - スレッド・サ―バのパフォ―マンス強化方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 マルチスレッド・サーバ・アプリケーション
を実行するコンピュータのパフォーマンスを強化する技
法、システム、およびコンピュータ・プログラムを提供
する。 【解決手段】 使用可能なスレッドの数を最適化するス
ケジューリング・ヒューリスティックを規定する。この
ヒューリスティックは、着信要求のためにブロック・ス
レッドを覚醒させるのではなく、（スレッドの現在の作
業の完了時に）現在実行中のスレッドに着信要求を割り
当てるのを待つ技法を規定することによって、作業スレ
ッドのオーバースケジューリングを改善する。どのスレ
ッドも長時間待ちすぎないようにするための措置が施さ
れる。受動ソケットに２つの段階を関連づけ、それによ
って、接続が、その接続のために作業が到着したときに
のみ作業スレッドに結合されるようにする。複数の入力
源からの入力をマージし、そのマージされた入力をスケ
ジューリングに使用できるようにする、新規なタイプの
ソケットを規定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はコンピュータのパフ
ォーマンスに関し、より詳細には、マルチスレッド・サ
ーバ・アプリケーションを実行するコンピュータのパフ
ォーマンスを強化する技法、システム、およびコンピュ
ータ・プログラムを対象とする。使用可能なスレッドの
数を最適化するようにスケジューリング・ヒューリステ
ィック（heuristic）を規定する。データが送信中でな
い場合に接続にスレッドが割り当てられないように保証
するために、受動ソケットのための２段階待ち行列を規
定する。複数の入力源からの入力をマージし、マージさ
れた入力をスケジューリングに使用できるようにする、
新規なタイプのソケットを規定する。持続接続を使用す
る場合に着信要求へのスレッドの割当てを最適化する関
数を規定する。

【０００２】

【従来の技術】マルチスレッド・アプリケーションと
は、複数のスレッドによる並列実行をサポートするソフ
トウェア・プログラム、すなわち再入可能プログラムで
ある。スレッドとは、そのようなプログラム内の単一の
実行経路である。スレッドは、使用可能なスレッドにタ
イム・スライスを割り振るオペレーティング・システム
・スケジューラの制御下で、１つのプロセス内で順次に
実行される。プロセスは、実行中のプログラムの１つの
インスタンスである。オペレーティング・システムは各
並列スレッドに関する情報を維持し、この情報は、各タ
イム・スライスでスレッドがＣＰＵを共用することがで
きるようにするが、それにもかかわらず互いに区別可能
であるようにする。たとえば、スレッドごとに異なる現
行命令ポインタが維持され、レジスタの値も同様に維持
される。明確な状態情報を維持することによって、再入
可能プログラム全体の各実行経路は、別々のプログラム
が実行されているかのように独立して機能することがで
きる。オープンＩ／Ｏ（入出力）ストリームのための仮
想メモリやファイル記述子など、その他の状態情報は、
実行効率向上のためにプロセス内のすべてのスレッドに
よって共用される。ＳＭＰ（対称マルチプロセッサ）マ
シン上では、これらのスレッドのいくつかを同時に実行
することができる。再入可能プログラムは、複数の実行
経路でのこれらの共用資源を同期させる機構を含むこと
ができる。

【０００３】インターネット環境で稼働しているサーバ
上では、マルチスレッド・アプリケーションがますます
普及しつつある。インターネットは、世界中の場所か
ら、ネットワークとして相互接続された膨大なコンピュ
ータ資源の集まりである。インターネットは、毎日数百
万人の人々によって使用されている。ワールド・ワイド
・ウェブ（本明細書では「ウェブ」と呼ぶ）は、インタ
ーネットのうち、メッセージを交換するためのプロトコ
ルとしてHyperText転送プロトコル（「ＨＴＴＰ」）を
使用する部分である。（あるいは、「ＨＴＴＰＳ」プロ
トコルを使用することができ、このプロトコルはＨＴＴ
Ｐのセキュリティ強化版である。）

【０００４】インターネットのユーザは一般に、インタ
ーネット・サービス・プロバイダ（ＩＳＰ）のサービス
を介してネットワーク接続を確立することによってイン
ターネットにアクセスし、使用する。ＩＳＰは、コンピ
ュータ・ユーザが、コンピュータ・モデム（または衛星
伝送などのその他の接続機構）を使用して電話番号をダ
イヤルし、それによってＩＳＰが所有または管理する遠
隔コンピュータとの接続を確立できるようにする。その
後で、この遠隔コンピュータはユーザのコンピュータに
サービスを提供する。典型的なサービスとしては、イン
ターネットの相互接続されたコンピュータ全体でユーザ
が求める項目を検索する検索機能、検索機能を使用して
探し出された情報を表示するブラウズ機能、ユーザが他
のコンピュータ・ユーザとの間でメール・メッセージの
送受信を行うことができる電子メール機能の提供などが
ある。

【０００５】ウェブ環境で作業するユーザは、ユーザの
コンピュータ上で実行され、情報を求める要求の作成と
送信を行い、その結果を見ることができるようにするソ
フトウェアを持つ。これらの機能は、一般には「ウェブ
・ブラウザ」または「ブラウザ」と呼ばれるものとして
組み合わされている。ユーザがブラウザを使用して要求
を作成した後、その要求メッセージは処理のためにイン
ターネットに送出される。要求メッセージの宛先は、イ
ンターネットのネットワーク内の相互接続されたコンピ
ュータの１つである。そのコンピュータは、メッセージ
を受け取り、ユーザの要求を満たすデータの検索を試
み、ユーザのブラウザを使用して表示するためにそのデ
ータを形式設定し、形式設定された応答をユーザのコン
ピュータ上で実行されているブラウザ・ソフトウェアに
返す。同じコンピュータに多くのクライアントがアクセ
スすることができるようにするために、クライアントの
要求の受け取りや処理を行うコンピュータは一般にはマ
ルチスレッド・アプリケーションを実行する。これで、
このアプリケーションの同じインスタンスが複数の要求
を処理することができ、その際、別々のスレッドを使用
して１つのクライアントの要求が他のクライアントの要
求から分離される。

【０００６】これは、クライアント／サーバ・コンピュ
ーティング・モデルの一例であり、ユーザが情報を要求
するマシンはクライアントと呼ばれ、その情報を探し出
してクライアントに返すコンピュータがサーバである。
ウェブ環境では、サーバは「ウェブ・サーバ」と呼ばれ
る。クライアント／サーバ・モデルは、「三層アーキテ
クチャ」と呼ばれるものに拡張することができる。この
アーキテクチャは、ウェブ・サーバを中央層に配置し、
それに付加された層は典型的には、クライアントの要求
を処理するタスクの一部としてウェブ・サーバがアクセ
スすることができる情報のデータベースを表す。この三
層アーキテクチャは、多くのクライアント要求が単に静
的データの検索と返送を求めているだけでなく、返され
るデータを動的に作成するためにクライアントの要求を
処理するアプリケーション・プログラムを必要としてい
ることを認識している。このアーキテクチャでは、ウェ
ブ・サーバは「アプリケーション・サーバ」とも呼ばれ
ることがある。サーバがマルチスレッド・アプリケーシ
ョン・プログラムを実行する場合、サーバを「スレッド
・サーバ」または「マルチスレッド・サーバ」と呼ぶこ
ともある。

【０００７】サーバは、スレッドを処理する役割を負
う。本明細書では、作成されたが廃棄されていないスレ
ッドのセットをスレッドの「プール」と呼ぶ。プールの
ために作成されるスレッドの数は一般にはユーザ（たと
えばシステム管理者）が、サーバを初期設定するときに
構成パラメータとして指定する。一般には、このパラメ
ータは、予想最大接続負荷（すなわち着信クライアント
要求の最大数）を扱うために、サーバが多数のスレッド
を作成するように設定される。

【０００８】ＴＣＰ／ＩＰプロトコル（転送制御プロト
コル／インターネット・プロトコル）が、ネットワーク
でデータを伝送する事実上の標準方法であり、インター
ネット伝送で広く使用されている。ＴＣＰ／ＩＰは、２
つのコンピュータ間でデータを交換するために２つの
「ソケット」間の接続という概念を使用し、ソケットは
それらコンピュータのうちの一方のコンピュータを識別
するアドレスと、そのコンピュータ上の特定のプロセス
を識別するポート番号とから成る。ポート番号によって
識別されたプロセスは、そのソケットのために着信デー
タを受け取るプロセスである。ソケットは、典型的には
その接続を使用する２つのコンピュータの各コンピュー
タによって待ち行列として実施され、接続でデータを送
信するコンピュータは作成したデータを送信のために接
続待ち行列に入れ、接続でデータを受信するコンピュー
タはそのデータを処理するために着信データを待ち行列
に入れる。

【０００９】いくつかのクライアントから要求を受け取
るアプリケーションの場合、保留クライアント接続の待
ち行列を表す特別な「受動」ソケットが作成される。こ
のアプリケーションのサービスを必要とする各クライア
ントは、同じサーバ・ポート番号を使用して、この受動
ソケットへの接続を要求する（ただし、セキュア・ソケ
ット層（「ＳＳＲ」）などの保護プロトコルを使用する
通信は一般には、同じアプリケーションに、セキュリテ
ィなしの「通常の」通信とは異なるポート番号を使用す
る。）サーバは、この特別な受動ソケットから保留クラ
イアント接続を受け入れる。これによって新しいサーバ
・ソケットが作成され、次に、そのソケットが処理のた
めに使用可能なスレッドに割り当てられる。

【００１０】この環境で稼働するマルチスレッド・サー
バ・アプリケーションを実施する現行の手法にはいくつ
かの欠点があり、その結果、そのようなアプリケーショ
ンの最適パフォーマンスが満たされないことになる。数
千または数百万もの１日当たりの「ヒット」（すなわち
処理を求めるクライアント要求）を受け取ることがあ
る、ウェブ・サーバ上で稼働するアプリケーションなど
のアプリケーションが普及するにつれて、パフォーマン
スは重要な問題になる。本発明はこのようなパフォーマ
ンス上の問題に対処する。

【００１１】既存のサーバ実装では、別個の「ディスパ
ッチャ」スレッドが、所与のアプリケーションのための
受動ソケットに対する着信接続要求を受け取る待ち行列
を監視する役割を果たす。ディスパッチを行うスレッド
と、作業のディスパッチ先のスレッドとを区別するため
に、本明細書では後者を「作業スレッド」と呼ぶ。ディ
スパッチャ・スレッドは、各作業スレッドの状況を追跡
し、各着信要求を使用可能なスレッドに割り当てる。
「使用可能な」スレッドとは、実行可能であるが、現在
割り当てられている作業がないスレッドである。この状
態のスレッドを「遊休スレッド」と呼ぶこともある。遊
休スレッドに作業が割り当てられると、そのスレッドは
もはや遊休とはみなされず、その現在の作業要求が完了
するまではそれ以上の作業は割り当てられない。ＳＭＰ
マシン上では、ディスパッチャ・スレッドは、作業スレ
ッドがすべてのプロセッサを使用中にしておくのに十分
な速さでケジュールされるのを妨げるボトルネックにな
る可能性がある。

【００１２】あるいは、ディスパッチャ・スレッドを使
用せずにサーバを実施することもできる。この手法で
は、スレッドは受動ソケット待ち行列を調べて接続要求
がないかどうかを判断する役割を負う。各スレッドは処
理していた作業要求を完了すると、待ち行列で次の要求
を探す。要求が待機中である場合、スレッドはその要求
を待ち行列から取り出し、その処理を開始する。待機中
の要求がない場合、スレッドは遊休スレッドになる。そ
の後、遊休スレッドは「スリープ」することがあり、そ
の場合、システム・タイマを使用してそのスレッドを所
定期間待機させた後、「覚醒」させて作業が到着してい
ないかどうか待ち行列を再度調べさせる。これは「ポー
リング」モードと呼ばれる。ポーリング・モードに代わ
るより一般的な代替手法は、イベント・ドリブン割込み
を使用することである。この手法では、スレッドは遊休
状態になり、作業が到着すると呼び出されてスレッドに
再度アクティブになるように通知するシステム割込みを
待つ。遊休状態になることを「ブロック」と呼び、ブロ
ック状態から覚醒されること（すなわち割込みを受け取
ること）を「アンブロック」と呼ぶ。

【００１３】イベント・ドリブン割込みを使用する現行
のサーバ実装では、各作業スレッドは現行要求を完了す
ると、受動ソケット待ち行列を調べて要求が待機してい
ないかどうかを調べる。待機している要求がない場合、
スレッドはブロックする。所与の時点で任意の数のスレ
ッドをブロックすることができる。次の着信要求が到着
すると、スレッドを覚醒させるイベントが生成される。
ブロックされた各作業スレッドはこの割込みを受け取
り、したがって各ブロックはアンブロックして、待ち行
列から要求の取り出しを試みる。着信要求を受け取るこ
とができるのは最初の作業スレッドだけであり、他のス
レッドは再度待ち行列が空であるのを認めて、ブロック
状態に戻る。しかし、この割込み生成手法を変える新し
いＡＰＩ（アプリケーション・プログラミング・インタ
フェース）が開発中である。このＡＰＩを本明細書では
「アクセプト・アンド・レシーブ（accept_and_receiv
e）と呼ぶ。アクセプト・アンド・レシーブ（accept_an
d_receive）ＡＰＩによると、着信要求が到着すると、
単一のブロックスレッドに対してのみ割込みが生成され
る。

【００１４】この新しい割込み手法によって、本明細書
で扱う第１のパフォーマンス問題が生じ、これを本明細
書では「オーバースケジューリング」と呼ぶ。着信接続
の数がスレッド・プール内のスレッドの数より少ない場
合（すなわち、接続負荷がサーバの構成最大値よりも小
さい場合）、その作業負荷を処理するために使用される
プール内のスレッドが多すぎる。言い換えると、スレッ
ド・プールはオーバースケジューリングされている。こ
れによって資源の使用効率が悪くなる。

【００１５】以下の事例で、オーバースケジューリング
問題を例示する。すべてのスレッドがブロックされ、接
続要求を待っているとする。第１の要求が到着する。シ
ステム・スケジューラはこれらのブロック・スレッドの
１つを覚醒させ、着信要求をそのスレッドに割り当て
る。そのスレッドは要求の処理を開始する。次に、第２
の要求が到着し、そのため、スケジューラは第２のブロ
ック・スレッドを覚醒させ、この新しい要求をそのスレ
ッドに割り当てる。第２のスレッドはこの新しい要求の
処理を開始する。第１のスレッドは作業していた要求を
完了し、受動ソケットを調べる。受動ソケットに新しい
接続要求がないことがわかり、第１のスレッドはブロッ
クする。２つの要求について、スケジューラは２つのス
レッドを覚醒させている。

【００１６】しかし、第２の要求が到着した時点で、第
１のスレッドはその第１の要求の処理をほとんど完了し
ようとしている場合がある。その場合、第２のスレッド
を覚醒させるのではなく、第１のスレッドが完了し、受
動ソケットを調べたときに第２の要求を見つけるのを待
つ方がより効率的であろう。スケジューラが各着信要求
ごとに新しいスレッドを覚醒させた場合（すなわちスレ
ッドをオーバースケジュールした場合）、要求を処理す
るスレッドは、現行要求を完了して別の要求がないか調
べたときに着信接続待ち行列が空であることを見いだす
ことが確実である。ブロック操作とアンブロック操作の
繰り返しは、要求を処理するための全体的パス長の点で
不経済である。スレッドがブロックすると、スケジュー
ラはそのスレッドのコンテキスト情報を保管し、スレッ
ドは「実行可能」状態から「ブロック」状態に移行す
る。アンブロック操作には、割込み処理に伴うかなりの
オーバーヘッドを要する。

【００１７】オーバースケジューリング中にシステムの
パフォーマンスに及ぼす他の影響は、メモリ・ページン
グ機構によるものである。スレッドは実行されると記憶
情報を参照する。その情報は処理するためにメモリに入
っていなければならない。まだメモリに入っていない場
合はページインされる。一般に、１つのページをページ
インするための空きを作るために他のページがページア
ウトされなければならない。ページング機構は、アルゴ
リズムを使用してどのページをページアウトするかを決
定する。通例、最も長い期間使用されなかった（ＬＲ
Ｕ）ページがページアウトのために選択される。オーバ
ースケジューリングが起こると、各スレッドは実行後に
ブロックし、したがってそのページは使用されなくな
る。スレッドが部録する期間が長いほど、そのページが
ページアウトされる可能性が高くなる。その後、スレッ
ドが覚醒されると、そのページをページインし戻さなけ
ればならず、それによって別のスレッドのページがペー
ジアウトされる。これらのページング操作によって生じ
る余分な処理によって、着信要求の処理効率が低下す
る。

【００１８】さらに、空であることがわかるだけの受動
ソケットを調べる操作は無駄な操作であり、それによっ
てブロック・スレッドの効率が低下する。

【００１９】本明細書では第２のパフォーマンス問題を
「複数入力源」問題と呼ぶ。前述のように、サーバ・ア
プリケーションは１つの受動ソケットで非セキュア接続
要求を受け取り、もう一つの受動ソケットでセキュア接
続要求を受け取ることがある。これは、たとえばオンラ
イン・ショッピング・アプリケーションの場合である。
クライアント買物客は、オンライン・カタログから入手
可能な製品を表示するように要求し、最終的に注文する
いくつかの製品を選択する。情報の表示を求めるこのよ
うな要求は、セキュア接続に付随する付加的な処理オー
バーヘッドを生じさせないように、通常は非セキュア接
続で送信される。買物客は注文を行うときに、クレジッ
ト・カードによる支払いを選択し、自分のクレジット・
カード情報を電子的に発信することがある。買物客の情
報を保護するために、買物客のトランザクションのこの
部分はセキュア接続で送信される。一般には、販売業者
はショッピング・トランザクションの全シーケンスに同
じサーバ・アプリケーションを使用する。したがって、
アプリケーションは、２つの受動ソケットから非セキュ
ア接続要求とセキュア接続要求の両方を受け入れること
ができなければならない。

【００２０】ウェブ・サーバが複数のホスト名をホスト
しており、各ホスト名がそれ自体のＩＰアドレスを有す
る場合、各ホスト名に１対の受動ソケットが使用され
る。したがって、所与のアプリケーションが多くの受動
ソケットに到着する接続を受け入れる必要がある場合が
ある。このようなソケットのセットを本明細書では「複
数入力源」と呼ぶ。

【００２１】ソケット待ち行列管理の前述のディスパッ
チャ・スレッド手法では、各受動ソケットに１つのディ
スパッチャ（または「アクセプタ」）スレッドが割り振
られる。着信接続要求が到着すると、これらのディスパ
ッチャはスレッド・プールから使用可能な作業スレッド
を見つけ、そのスレッドに着信要求を割り当てる役割を
果たす。ディスパッチャ・スレッドの数が増えるにつれ
て、作業スレッドの共用プールの管理をめぐるそれらの
スレッド間の衝突も増える。

【００２２】ディスパッチャ・スレッドを使用せず、着
信待ち行列を調べる役割が作業スレッドにある場合、ス
レッド・プールは受動ソケット待ち行列のセット全体で
静的に区分化されることになる。特定の時点での作業負
荷と、それに対応する受動ソケット間での要求の分配は
予測不能なため、この静的区分化は最適状態を下回る可
能性がきわめて高くなる。１つの待ち行列のスレッド
は、その作業負荷を処理するには少な過ぎ、別の待ち行
列は多過ぎる場合がある。使用可能なスレッドが少なす
ぎる場合、着信要求は待ち行列上で待たなければなら
ず、その間に使用可能なシステム能力が遊休状態のまま
になる。着信要求には通常、応答を待っている人間がい
るため、応答を処理する際のこのタイプの遅延は、最大
限回避しなければならない。使用可能なスレッドが多す
ぎる場合、オーバースケジューリングについて前述した
非効率が生じる。受動ソケット間での作業の現在の分配
に基づいて作業スレッドのプールを分割するより動的な
区分化は、受動ソケット上の接続待ち行列内項目数がサ
ーバ・アプリケーションには入手できないために、サー
バ・アプリケーションによって行うことはできない。

【００２３】第３のパフォーマンス問題を、本明細書で
は「持続接続スケジューリング」と呼ぶ。持続接続機能
は、ＨＴＴＰの１．１版で導入され、クライアントとサ
ーバの間の要求（およびそれに対応する応答）のストリ
ームに単一の接続を使用できるようにする。持続接続
は、一連の要求の処理に付随するオーバーヘッドの量を
少なくし、それによって普通なら個別要求ごとに必要に
なるＴＣＰ接続のセットアップとティアダウンのコスト
をなくし、１回のセットアップと１回のティアダウンを
使用することを意図したものである。結果は、クライア
ントのもとで生成された各要求が新しい接続を生み出
し、それはその要求の持続時間の間だけ持続した。接続
をセットアップするのにメッセージの交換が必要であ
り、それを閉じるのにもう一度交換が必要だった。多く
のウェブ・ベースのアプリケーションは、ユーザに対し
てきわめて複雑な情報ページを表示し、各ページでネッ
トワークを介していくつかの別々の要求を送信する必要
がある場合がある。たとえば、ページ上の各グラフィッ
ク画像ごとに１つの要求を送信し、静的テキストのため
に別の要求、動的生成テキストのためにさらに他の要求
が送信される場合がある。したがって、単一のウェブ・
ページの表示に、持続接続を使用すれば相当量の処理オ
ーバーヘッドが節減される。すなわち、２つのコンピュ
ータ間で使用するために１つの接続を設定した後は、ク
ライアントは、サーバがそれらの要求の各要求を受け取
ったという肯定応答を待つために停止せずに、その接続
を介して任意の数の要求を送信することができる。これ
を要求の送信の「ストリーム」モードと呼ぶ。サーバは
ストリームのすべての要求に順に応答する必要がある。
クライアントまたはサーバは、プロトコル・エラーを生
じさせることなく、任意の要求境界で接続を終了するこ
とができる。

【００２４】実際には、ユーザが異なるウェブ・サイト
に移動する（異なるサーバ・ソケット・アドレスと、そ
れに応じて新しい接続が必要になる）まで、ブラウザ内
のクライアント・ソフトウェアがこの持続接続を開いた
ままに維持する。開いた持続接続で最後の要求が送信さ
れてからユーザが新しいサイトに移動するまでの間にあ
る程度の時間が経過することがある。既存の接続のソケ
ットには、この時間中、着信データがまったくなくな
る。サーバ・アプリケーションは、ソケットがこの特定
の状態（すなわち、クライアントはデータの送信を終了
しているが、接続はまだ開いている状態）であるかどう
か、またはクライアントが次の要求をまだ生成していな
いだけなのかどうかを知ることができない。したがっ
て、このタイプの接続の次の要求の読取りに関してサー
バ側に不確定性が存在する。待ち行列にデータがある可
能性もあり、データがまもなく着信するか、またはデー
タがしばらくの間着信しない可能性もある。しかも、こ
れらのデータ・パケットのいずれかに、その接続で進行
中の作業を求めるクライアント要求や、ソケットを閉じ
る要求が入っている可能性もある。

【００２５】データが間もなく着信する場合は、その作
業スレッドとの接続を結合した状態に維持し、作業スレ
ッドが一時的に遊休状態になるようにするのが最も効率
的である。しかし、データが着信するまで長い遅延時間
がある場合は、作業スレッドをその接続から結合解除
し、その作業スレッドを別の要求に割り当てた方がより
効率的である。その後、その結合解除された接続を求め
る次の要求が着信した場合、その処理を続けるためにス
レッド（元々結合されていたスレッドとは異なるスレッ
ドである可能性が最も高い）を割り当てる。どの接続が
所与の要求間での遅延が長くなるか、そのような遅延が
いつ発生するか、または遅延がどれだけ長く続くかを前
もって知る方法がない。作業スレッドのプールを、新し
い接続を受け入れるスレッドと、遅延後に再アクティブ
化する接続を処理するスレッドとを区分化する試みは、
複数入力源問題に関して前述したのと同様の問題を生じ
させる。すなわち、いずれかの区分に割り当てられるス
レッドが多すぎたり少なすぎたりすることによって、非
効率になる。

【００２６】したがって、マルチスレッド・サーバ・ア
プリケーションの現行の実施システムにおけるこれらの
非効率問題を克服する技法が必要である。本提案の技法
は、使用可能スレッドの数を最適化するスケジューリン
グ・ヒューリスティックと、受動ソケットのための２段
階待ち行列と、複数の入力源からの入力をマージし、そ
のマージされた入力をスケジューリングに使用できるよ
うにする新しいタイプのソケットと、持続接続を使用す
る場合に着信要求へのスレッドの割当てを最適化する関
数とを規定する。

【００２７】

【発明が解決しようとする課題】本発明の目的は、マル
チスレッド・サーバのパフォーマンスを強化する技法を
提供することである。

【００２８】本発明の他の目的は、作業スレッドに対す
る要求のスケジューリングを最適化することによって上
記のパフォーマンス強化を実現する技法を提供すること
である。

【００２９】本発明の他の目的は、使用可能スレッドの
数を最適化するスケジューリング・ヒューリスティック
を規定することによって、上記の最適化を実現すること
である。

【００３０】本発明の他の目的は、複数の入力源からの
入力をマージする新しいタイプのソケットを規定し、そ
のマージされた入力をスケジューリングに使用できるよ
うにすることによって上記の最適化を実現することであ
る。

【００３１】本発明の他の目的は、持続接続を使用する
場合に着信要求へのスレッドの割当てを最適化する関数
を規定することによって、上記の最適化を実現すること
である。

【００３２】本発明のその他の目的および利点は、一部
は以下の説明、一部は図面に記載され、その説明を読め
ば明らかになるであろうし、本発明の実施によってわか
るであろう。

【００３３】

【課題を解決するための手段】上記の目的を達成するた
めと、本明細書で概説する本発明の目的により、本発明
は、ネットワークへの接続を有するコンピューティング
環境において使用し、マルチスレッド・アプリケーショ
ンのパフォーマンスを強化するシステム、方法、および
ソフトウェア・プロセスを実施するコンピュータ可読コ
ードであって、接続を求める複数のクライアント要求
と、複数の作業スレッドと、前記複数のクライアント要
求を受け取るサブプロセスと、前記作業スレッドのオー
バースケジューリングを改善するスケジューリング・ヒ
ューリスティックを実施するサブプロセスとを含むシス
テム、方法、およびコンピュータ可読コードを提供す
る。さらに、前記作業スレッドの第１のグループはアク
ティブ・スレッドであり、前記第１のグループは、前記
複数の作業スレッドのうちの変更可能な作業スレッドか
ら成り、変更可能な数の前記変更可能スレッドを有し、
前記変更可能な数は少なくとも１であり、スケジューリ
ング・ヒューリスティックを実施する前記サブプロセス
は、前記第１のグループにおける前記変更可能な数を、
前記複数のクライアント要求のうちの１つまたは複数の
クライアント要求から成る現行作業負荷に照らしてバラ
ンスをとるサブプロセスをさらに含む。バランスをとる
前記サブプロセスは、平均遅延と、最大遅延の使用も含
むことができる。前記平均遅延と前記最大遅延は構成パ
ラメータであることが好ましい。作業スレッドの前記第
１のグループに加えて、ブロック・スレッドであり、後
入れ先出し待ち行列に格納される前記作業スレッドの第
２のグループも存在することができる（前記第２のグル
ープは、前記複数の作業スレッドのうち前記第１のグル
ープに入っていない作業スレッドから成る）。さらに、
本発明は、マルチスレッド・アプリケーションのパフォ
ーマンスを強化するシステム、方法、およびコンピュー
タ可読コードであって、各前記接続が受け入れられる場
合に保留接続待ち行列から接続を第１の待ち行列に移動
させるサブプロセスと、前記接続のための最初のデータ
・パケットが着信すると前記第１の待ち行列から各前記
接続を第２の待ち行列に移動させるサブプロセスと、前
記第２の待ち行列上の各前記接続に作業スレッドを割り
当てるサブプロセスとを含む、システム、方法、および
コンピュータ可読コードを提供する。さらに、本発明
は、マルチスレッド・アプリのパフォーマンスを強化す
るシステム、方法、およびコンピュータ可読コードであ
って、複数の入力源から入力を受け取るサブプロセス
と、受け取った前記入力をスケジューリングのために単
一の待ち行列上にマージするサブプロセスとを含む、シ
ステム、方法、およびコンピュータ可読コードを提供す
る。これは、各前記接続が受け入れられる場合、保留接
続待ち行列から接続を第１の待ち行列に移動させるサブ
プロセスと、前記接続のための最初のデータ・パケット
が着信すると各前記接続を前記第１の待ち行列から前記
単一の待ち行列に移動させるサブプロセスと、前記単一
の待ち行列上の各前記接続に作業スレッドを割り当てる
サブプロセスとをさらに含むことが好ましい。スケジュ
ーリングする前記サブプロセスは、複数の作業スレッド
のうちの変更可能な作業スレッドから成り、少なくとも
１である変更可能な数の前記変更可能作業スレッドを有
するアクティブ作業スレッドのグループと、前記単一待
ち行列上に格納された前記クライアント要求から成る現
行作業負荷に照らして前記アクティブ・グループ内の前
記変更可能数のバランスをとるスケジューリング・ヒュ
ーリスティックを実施するサブプロセスとをさらに含む
ことが好ましい。さらに、本発明は、マルチスレッド・
アプリケーションのパフォーマンスを強化するシステ
ム、方法、およびコンピュータ可読コードであって、複
数の持続接続と、複数の作業スレッドと、前記持続接続
のうちの選択された持続接続を前記作業スレッドのうち
の選択された作業スレッドに結合するサブプロセスであ
って、その実行の結果として結合された接続ができるサ
ブプロセスと、前記結合された接続のうちの選択された
接続を結合解除するサブプロセスであって、その実行の
結果として作業スレッドが結合解除されるサブプロセス
とを含む、システム、方法、およびコンピュータ可読コ
ードを提供する。結合する前記サブプロセスは、２段階
待ち行列の使用をさらに含み、結合解除する前記サブプ
ロセスは前記２段階待ち行列の使用をさらに含むことが
好ましい。前記２段階待ち行列を使用して結合する前記
サブプロセスは、前記接続のために最初のデータ・パケ
ットが着信すると各前記持続接続を前記第１の段階に移
動させるサブプロセスと、前記接続のためにデータを受
け取ると各前記持続接続を前記第２の段階から前記第１
の段階に移動させるサブプロセスと、前記第１の段階か
ら前記持続接続をスケジューリングするサブプロセスと
をさらに含み、前記２段階待ち行列を使用して結合解除
する前記サブプロセスは、選択された前記結合接続が遊
休状態になると、前記結合された接続のうちの選択され
た接続を前記第１の段階から前記第２の段階に移動させ
るサブプロセスと、最大遊休期間を超えるとそれに応答
して、前記第２の段階内の前記持続接続のうちの選択さ
れた持続接続を閉じるサブプロセスと、結合解除された
前記作業スレッドを前記結合サブプロセスに使用するこ
とができるようにするサブプロセスとをさらに含む。結
合解除する前記サブプロセスは、最大遊休接続数を超え
るとそれに応答して、前記第２の段階内の前記持続接続
のうちのさらに選択された持続接続を閉じるサブプロセ
スをさらに含むことが好ましい。

【００３４】

【発明の実施の形態】図１に、本発明を実施することが
できる代表的なワークステーション・ハードウェア環境
を示す。図１の環境は、関連する周辺装置を含むパーソ
ナル・コンピュータなどの代表的なコンピュータまたは
インテリジェント・ワークステーション１０を含む。あ
るいは、ワークステーション１０は、ネットワーク環境
におけるサーバとすることもできる。ワークステーショ
ン１０は、マイクロプロセッサ１２と、周知の技法によ
りマイクロプロセッサ１２とワークステーション１０の
構成要素とを接続し、それらの間の通信を可能にするバ
ス１４とを含む。ワークステーション１０は、典型的に
は、バス１４を介してマイクロプロセッサ１２を、キー
ボード１８、マウス２０、またはタッチ・センシティブ
画面、ディジタイズ入力パッドなどの任意のユーザ・イ
ンタフェース装置とすることができるその他のインタフ
ェース装置２２など、１つまたは複数のインタフェース
装置と接続するユーザ・インタフェース・アダプタ１６
を含む。バス１４は、ディスプレイ・アダプタ２６を介
してＬＣＤ画面またはモニタなどの表示装置２４もマイ
クロプロセッサ１２に接続する。また、バス１４はマイ
クロプロセッサ１２を、メモリ２８およびハード・ドラ
イブ、ディスケット・ドライブ、テープ・ドライブなど
の長期記憶域３０にも接続する。

【００３５】ワークステーション１０は、通信チャネル
３２を介して他のコンピュータまたはコンピュータのネ
ットワークと通信する。ワークステーション１０は、ロ
ーカル・エリア・ネットワーク（ＬＡＮ）やワイド・エ
リア・ネットワーク内などの他のコンピュータと関連づ
けることができ、あるいはワークステーション１０は、
他のコンピュータなどとのクライアント／サーバ構成に
おけるクライアントとすることもできる。これらのすべ
ての構成と、適切な通信ハードウェアおよびソフトウェ
アは、当技術分野で周知である。

【００３６】図２に、本発明を実施することができるデ
ータ処理ネットワーク４０を示す。データ処理ネットワ
ーク４０は、ＬＡＮ４２および４４を含む複数の個別ネ
ットワークを含み、各ネットワークは複数の個別のワー
クステーション１０を含む。あるいは、当業者ならわか
るように、ＬＡＮはホスト・プロセッサに結合された複
数のインテリジェント・ワークステーションを含むこと
もできる。

【００３７】図２を参照すると、データ処理ネットワー
ク４０は、好ましくは通信リンク４８を使用してＬＡＮ
４４に結合することができるメインフレーム・コンピュ
ータ４６などの、複数のメインフレーム・コンピュータ
またはサーバも含むことができる。メインフレーム・コ
ンピュータ４６は、ＩＢＭが販売するエンタープライズ
・システム・アーキテクチャ／３７０（Enterprise Sys
tems Architecture/370）またはエンタープライズ・シ
ステム・アーキテクチャ／３９０（EnterpriseSystem A
rchitecture/390）コンピュータ、または他の任意のタ
イプのメインフレーム・コンピュータを使用して実施す
ることができる。応用分野によっては、アプリケーショ
ン・システム／４００（Application System/400）（Ａ
Ｓ／４００とも呼ぶ）などの中規模コンピュータも使用
可能である。「エンタープライズ・システム・アーキテ
クチャ／３７０（Enterprise System Architecture/37
0）」はＩＢＭの商標である。「エンタープライズ・シ
ステム・アーキテクチャ／３９０（Enterprise System
Architecture/390）」、「アプリケーション・システム
／４００(Application System/400）」、および「ＡＳ
／４００」はＩＢＭの登録商標である。

【００３８】メインフレーム・コンピュータ４６は、Ｌ
ＡＮ４４の遠隔記憶域として機能する記憶装置５０にも
結合することができる。同様に、ＬＡＮ４４は、通信リ
ンク５２に結合することができ、サブシステム制御装置
／通信コントローラ５４および通信リンク５６を介して
ゲートウェイ・サーバ５８に結合することができる。ゲ
ートウェイ・サーバ５８は、ＬＡＮ４２をＬＡＮ４４と
リンクさせる役割を果たす個別コンピュータまたはイン
テリジェント・ワークステーションであることが好まし
い。

【００３９】当業者なら、メインフレーム・コンピュー
タ４６はＬＡＮ４４から地理的に遠距離に配置すること
ができ、同様にＬＡＮ４４はＬＡＮ４２から遠距離に配
置することができることがわかるであろう。たとえば、
ＬＡＮ４２を米国カリフォルニア州に配置し、ＬＡＮ４
４をテキサス州に配置し、メインフレーム・コンピュー
タ４６をニューヨークに配置することができる。

【００４０】本発明を実施するソフトウェア・プログラ
ミング・コードは、典型的には、クライアント／サーバ
環境または三層環境におけるサーバ４６などのサーバに
インストールされ、サーバ４６はワークステーション１
０などのコンピュータを有するユーザから送られる要求
を処理する。このコードは、典型的にはサーバ・メモリ
２８内で実施され、バス１４を使用してマイクロプロセ
ッサ１２にアクセスすることができる。あるいは、この
コードは、ＣＤ−ＲＯＭドライブやハード・ドライブな
どの何らかのタイプの長期記憶媒体３０からアクセスす
ることもできる。このソフトウェア・プログラミング・
コードは、ディスケット、ハード・ドライブ、ＣＤ−Ｒ
ＯＭなど、データ処理システムと共に使用される様々な
周知の媒体のいずれの媒体上でも実施可能である。コー
ドは、そのような媒体で配布したり、他のコンピュータ
・システムで使用するために、１つのコンピュータ・シ
ステムのメモリまたは記憶域から何らかのタイプのネッ
トワークを介して他のコンピュータ・システムに配布し
たりすることができる。ソフトウェア・プログラミング
・コードをメモリ、物理媒体で実施したり、ソフトウェ
ア・コードをネットワークを介して配布する技法および
方法は周知であり、本明細書では詳述しない。

【００４１】ウェブ環境におけるサーバは典型的には表
示装置２４を備えない場合があるが、本発明の好ましい
実施形態は、本発明のスケジューリング最適化のために
必要なパラメータを（たとえばシステム管理者が）構成
することができるようにするために、表示装置２４を使
用する。

【００４２】本発明の好ましい実施形態について、図３
から図１０を参照しながら以下に説明する。

【００４３】好ましい実施形態では、本発明はコンピュ
ータ・ソフトウェア・プログラムとして実施される。こ
のプログラムは、クライアントがサーバに対してデータ
を求める要求を送信した場合に使用され、ネットワーク
のサーバ側で行われる処理の部分を含む。本発明は、複
数のスレッドを使用してアプリケーション処理を行うサ
ーバと共に機能する。典型的には、このプログラムはイ
ンターネット環境で使用され、サーバはウェブ・サーバ
であり、要求はＨＴＴＰ（またはＨＴＴＰＳ）を使用し
て形式設定される。あるいは、ユーザのコンピュータが
その構成要素である企業イントラネット（すなわちユー
ザの会社内部で所有または管理されるネットワーク）に
接続を行うこともでき、その場合、この企業イントラネ
ットはインターネットと同様にしてサービスを提供す
る。本明細書では、特に明記のない限り、ユーザの要求
に関連づけられた処理について説明する場合の「インタ
ーネット」という用語の使用にはイントラネットで行わ
れる処理も含まれる。好ましい実施形態のプログラム・
コードは、Smalltalkなどのオブジェクト指向プログラ
ミング言語におけるオブジェクトとして、または「Ｃ」
などの従来の手続き型プログラミング言語の関数または
サブルーチンとして実施することができる。

【００４４】図３から図５に、前述のオーバースケジュ
ーリング問題を改善する第１の好ましい実施形態に関係
する論理が記載されたフローチャートを示す。

【００４５】図３は、要求を処理する接続があるかどう
かを判断するために作業スレッドによって実行される論
理を示す。このプロセスはステップ１００から始まり、
この論理に入る前にこのスレッドがすでの要求を処理し
ていたかどうかを問い合わせる。回答が否定の場合、制
御はステップ１１５に移る。肯定の場合、ステップ１０
５および１１０を実行することによってこのスレッドに
関する統計情報を収集する。ステップ１０５で、現在実
行中のスレッドの数のカウンタを減分する。（このカウ
ンタは、サーバが初期設定された場合、ゼロに初期設定
されていることになり、図４の説明で「Ｉ」と呼ぶ。）
ステップ１１０で、（スレッドが直前の接続を処理する
ために割り振られたときにステップ１３０で事前に記録
された開始時刻を使用して）スレッドが実行されていた
時間の長さを計算し、平均値を更新する（これについて
は図４を参照しながら詳述する）。次に制御はステップ
１１５に渡される。

【００４６】ステップ１１５で、この作業スレッドによ
って処理可能になっている接続があるかどうかを判断す
る検査が行われる。この好ましい実施形態によると、接
続でデータが着信するまでは作業スレッドには接続が割
り当てられない。クライアントによっては、接続を要求
するが、その後でデータ要求を送信する前にその接続を
閉じる場合もある。クライアントがデータを送信してい
ることがわかるまで作業スレッドへの接続の割当てを遅
らせることによって、作業スレッドのこのよううな非生
産的な使用が回避される。まだデータを受信していない
受け入れられた接続をデータを受信している接続から区
別するために、２段階待ち行列を規定する。接続（すな
わち接続のための待ち行列要素）は受け入れられると
（さらにクライアントがその接続に肯定応答すると）第
１段階に移り、データが着信するまで第１段階にとどま
る。この第１段階を「受け入れられた接続待ち行列」と
も呼ぶ。データ・パケットが着信すると、その接続は第
２段階に移る。この第２段階を「実行可能待ち行列」と
も呼ぶ。作業スレッドは、第２段階に達した接続にのみ
割り当てられる。第１段階は先入れ先出し（ＦＩＦＯ）
待ち行列として実施することが好ましい。しかし、接続
のためにデータが着信すると待ち行列から接続が除去さ
れ、厳密にはＦＩＦＯ方式ではないため、第１段階に要
素を記憶するために他の構造（リンク・リストなど）も
使用可能である。第２段階は、接続が待ち行列に着信し
た順序で待ち行列から出されるように、ＦＩＦＯ待ち行
列として実施されることが好ましい。この手法によっ
て、個別の接続が処理のためにスケジュールされる前
に、待機している他の接続と比較して過度に長い時間待
たない可能性が高くなる。待ち行列要素に状態変数を関
連づけて各接続の状況を示すなど、本発明の進歩的概念
から逸脱することなく、この処理を実施するために２段
階待ち行列に加えて他機構も使用可能であることは当業
者には明らかであろう。

【００４７】ステップ１１５での検査の応答が否定の場
合（すなわち作業スレッドに割り当てられるのを待って
いる接続がない場合）、制御はステップ１２０に移り、
作業スレッドはブロック状態になる。その後、この作業
スレッドに関する図３のプロセスは終了する。作業スレ
ッドは、図４のステップ２１０または図５のステップ２
７０に関して後述する論理に従ってアンブロックされる
ことになる。

【００４８】この第１の好ましい実施形態では、ブロッ
ク作業スレッドは待ち行列内に保持され、これを「ブロ
ック・スレッド待ち行列」とも呼ぶ。この待ち行列は後
入れ先出し（ＬＩＦＯ）待ち行列として実施されること
が好ましい。ページング機構が新しいページをメモリに
入れるときにページを置き換えるために最長時間未（Ｌ
ＲＵ）使用方式を使用することを前提とすれば、ブロッ
クスレッドをＬＩＦＯ待ち行列に入れることによって、
スレッドがアンブロックされたときにスレッドのページ
がメモリ内に残っている可能性がより高くなる。

【００４９】ステップ１１５の検査で接続可能状態があ
る場合、制御はステップ１２５に進む。次にこの接続は
作業スレッドに割り当てられる。この接続のデータ要求
を含むソケット構造が、実行可能待ち行列から取り出さ
れ、スレッドに渡される。

【００５０】ステップ１３０で、このスレッドがこの接
続の処理を開始した時刻として現在時刻が記録され、ス
テップ１３５で実行スレッドのカウンタが増分される。
これは、実行統計情報の収集を、後でスケジューリング
・ヒューリスティックで使用することができるようにす
るために行われる。その後、図３のプロセスは終了す
る。

【００５１】作業レッドが受動ソケットでアクセプト・
アンド・レシーブ（accept_and_receive）ＡＰＩを実行
するとき、図３の処理を呼び出すのはこのＡＰＩ呼出し
の実行である。しかし、図３はこのＡＰＩとの併用には
限定されず、その論理は他の方法で（たとえば、同様の
受入れ接続機能の関数呼出しを実行して）呼び出すこと
もできる。

【００５２】図３によって作業スレッドに割り当てられ
た接続は、本発明の一部を形成しない技法に従って処理
される。処理が完了すると、（たとえばサーバが停止し
ていない限り）スレッドは図３のプロセスを使用して再
び別の接続を要求することができる。

【００５３】図４に、受動ソケットに到着した着信パケ
ットを処理するためにネットワークＩ／Ｏ割込みハンド
ラなどのプロセスによって実行される論理を示す。

【００５４】このプロセスはステップ１５０から始ま
り、着信パケットを受け取る。ステップ１５５で、この
パケットが新規接続の要求であるかどうかを検査する。
新規接続要求の場合、制御はステップ１６０に移り、そ
うでない場合は制御はステップ１８０に移る。

【００５５】ステップ１６０で、当技術分野で周知の技
法を使用して新しいソケットが作成され、その結果、新
しいソケット・データ構造が作成される。ステップ１６
５で、この接続の項目が受動ソケットの「保留接続」待
ち行列に入れられる。

【００５６】ステップ１７０で、この受動ソケット上の
接続を自動的に受け入れるかどうかを検査する。この情
報は、構成パラメータを使用して示すことができる。着
信接続要求を自動的に受け入れることによって、作業ス
レッドへの要求のスケジューリングをデータが着信する
まで遅らせることができる。この検査の応答が否定の場
合、この実施形態の２段階待ち行列は使用されない。こ
れによって、既存の実施システムとの互換性をもたせる
ことができ、既存の実施システムは本発明の他の機構を
実施することができる。接続は保留接続待ち行列に残
る。検査の応答が肯定の場合は、ステップ１７５でクラ
イアントに肯定応答が送信される。次に制御はステップ
１５０に返り、次の着信パケットを待つ。

【００５７】ステップ１８０で、着信パケットが接続の
確認であったかどうかを問い合わせる。そうであった場
合には、ステップ１８５で接続は「受入れ」としてマー
クされる。この好ましい実施形態の２段階待ち行列を使
用することにより、これは、この接続の項目を「保留接
続」待ち行列から２段階のうちの最初の段階である「受
入れ接続」待ち行列に移動することを含む。次に制御は
ステップ１５０に移り、次の着信パケットを待つ。

【００５８】着信パケットが接続要求または接続確認で
なかった場合、制御はステップ１９０に移る。参照しや
すいように、図４ではパケットはデータ・パケットであ
るものと仮定している。他のパケット・タイプは、図４
の実行フローには関係がなく、したがって対象としな
い。当業者には、本発明の進歩的概念から逸脱すること
なく、これらのパケットに追加の論理を付加することが
できることが明らかであろう。ステップ１９０で、この
データ・パケットは適切なソケットの到着待ち行列に入
れられる。ステップ１９５で、これがこの接続の最初の
着信データ・パケットであるかどうかを判断する検査が
行われる。最初の着信パケットでない場合、（その接続
はすでに作業スレッドに割り当てられているため）割込
みハンドラはこのパケットをそれ以上処理せず、制御は
ステップ１５０に返る。

【００５９】ステップ２００で、受け入れられた接続の
最初のデータ・パケットが到着している。したがって、
この接続は作業スレッドにスケジューリングするために
使用可能にすることができる。この好ましい実施形態の
２段階待ち行列を使用すると、ステップ２００の処理
は、接続を「受入れ接続」待ち行列（段階１）から「実
行可能」待ち行列（段階２）に移動させるステップを含
む。

【００６０】ステップ２０５で、本発明によって規定さ
れた新規なスケジューリング・ヒューリスティックを使
用して、この接続を処理するために待機スレッドをアン
ブロックするか、それとも現在実行中のスレッドが完了
するのを待つ（すなわち、接続を当面、実行待ち行列に
入れたままにしておく）かを判断する。このヒューリス
ティックの結果、ブロック・スレッドをアンブロックす
べきであることが示された場合、（ステップ２０５から
の「覚醒」分岐をたどることによって）制御はステップ
２１０に移る。そうでない場合は、この接続を処理する
ために待機スレッドをまだアンブロックする必要がない
かまたはアンブロックすることが望ましくないため、割
込みハンドラはこの時点ではそれ以上の処理を行わず、
（ステップ２０５から「待機」分岐をたどることによっ
て）制御はステップ１５０に返る。

【００６１】ステップ２０５で実行されるスケジューリ
ング・ヒューリスティックは、以下の数式によって定義
される。 Ｒ＝（Ｃ＊Ｔ＊Ｄ）−（Ｔ／２）

【００６２】このスケジューリング・ヒューリスティッ
クの目的は、現行着信作業負荷に照らして作業スレッド
の数のバランスをとることである。オーバースケジュー
リングが起こらない場合に最適な結果が得られる。その
ためには、着信実行可能待ち行列で小さなバックログを
保持する必要がある（すなわち、待ち行列にいくつかの
接続を残しておくことができるようにし、ただちに作業
スレッドを覚醒させることによって割り当てられないよ
うにする）。しかし、ある程度の短い受容可能な遅延期
間を超えて接続を待ち行列に残しておいてはならない。
その遅延期間の終わりに使用可能な作業スレッドがない
場合、受容可能な遅延を超えないようにブロック作業ス
レッドを覚醒させる。この遅延の長さは、平均受容可能
遅延と最大受容可能遅延の２つの部分からなることが好
ましい。任意選択により、これらの遅延要素を、ユーザ
がその値を入力することができる構成パラメータとす
る。ユーザが構成パラメータの値を入力する方式は、当
業者には周知であり、本明細書では詳述しない。典型的
には、サーバの初期設定中に構成メニューを表示し、こ
れらのパラメータをそのメニューに含める。

【００６３】上記の式で、Ｒは２段階待ち行列の段階２
での実行可能接続の目標数を表し、「待ち行列内項目
数」または「待ち行列バックログ」とも呼ぶ。ステップ
２０５で検査を行ったときに接続数がＲより大きいか等
しい場合、現行パラメータにより、すでに待機している
接続が多すぎるため、ステップ２１０に制御を移すこと
によって待機スレッドがアンブロックされる。待ち行列
内項目数がＲより小さい場合、接続はすべて待ち行列に
残り、実行中のスレッドが完了するのを待つ。すべての
接続が待ち行列に残っているため、処理はステップ１５
０に移る。

【００６４】スケジューリング・ヒューリスティックの
変数Ｃは、１つの作業スレッドが完了することができる
毎秒の平均接続数を表す。この変数の値は、スレッドの
実行データを収集することによって計算することができ
る。実行データ収集は、図３に関して前述した処理に従
って行うことができる。サーバ・アプリケーションがあ
る程度の期間実行するまでは、代表データは存在しな
い。したがって、Ｃの値はゼロに初期設定され、それに
よってＲ＝０になり、その結果、制御はステップ２０５
からステップ２１０（待機スレッドのアンブロック）に
移ることになる。

【００６５】変数Ｔは現在実行中のスレッドの数を表
す。したがって、１秒間に完了する要求の数は（Ｃ＊
Ｔ）である。たとえば、スレッドが毎秒平均８個の要求
を完了することができ、現在実行中のスレッドが１０個
ある場合、これらのスレッドは毎秒平均（８＊１０）＝
８０個の要求を完了することができる。

【００６６】変数Ｄは、要求が待ち行列上で待機する平
均受容可能遅延時間を表す。遅延時間Ｄ中に新規接続が
スレッド・プールに吸収される（すなわち接続が作業ス
レッドに割り当てられる）平均レートは、（Ｃ＊Ｔ＊
Ｄ）である。たとえば、平均受容可能遅延時間が０．２
秒の場合、（上記の例の数値を使用すると）この遅延期
間中にこのスレッド数によって１６個の要求を吸収する
ことができ、１秒間に８０個の要求を完了することがで
きる場合、０．２秒間に（８＊１０＊０．２）＝１６個
の要求を完了することができる。

【００６７】所与の時点で、平均して実行中のスレッド
の半分が現行要求を完了し、他の要求の処理を開始す
る。このスケジューリング・ヒューリスティックは、こ
れを項（Ｔ／２）によって反映させる。この値は（Ｃ＊
Ｔ＊Ｄ）から引かれる。これは、新しい要求を開始した
ばかりのスレッドは、実際には、（１／（Ｃ／２））秒
の平均完了期間内に新しい要求を引き受けるために対応
することができず、（１／Ｃ）秒に対応可能になるため
である。上述の例を続けると、差し引く値は（１０／
２）＝５であり、それによってＲの最終結果は（１６−
５）＝１１になる。

【００６８】言い換えると、この例のパラメータと合致
するシステムは、実行中のスレッドの完了を待ち、それ
らのスレッドが対応可能になったときにそれらのＴ＝１
０個のスレッドに新規要求を割り当てることによって、
Ｄ＝０．２秒当たり最高（Ｃ＊Ｔ＊Ｄ）−（Ｔ／２）＝
１１個の新規要求を処理することができ、要求は平均Ｄ
＝０．２秒より長く待ち行列上で待機する必要はない。
期間Ｄ＝０．２秒中に１１を超える新規要求が到着した
場合、システムの容量を超え、所与の要求の遅延がＤを
超えないように保証するために待機スレッドをアンブロ
ックしなければならない。

【００６９】この実施形態では、２段階待ち行列からの
接続のスケジューリングを決定するために使用する新規
なスケジューリング・ヒューリスティックについて説明
したが、別法として、このスケジューリング・ヒューリ
スティックはそのような待ち行列がなくても、本発明の
進歩的概念から逸脱することなく使用することができ
る。すなわち、図３で説明したように統計情報が収集さ
れることを条件として、このヒューリスティックは、受
け入れられたがまだデータを受信していない接続をスケ
ジュールするために既存の受動ソケットと共に使用する
こともできる。この手法で、この第１の好ましい実施形
態の多くの（ただしすべてではない）利点が実現され
る。いくつかの接続が作業スレッドにスケジュールされ
たが、結果的に、クライアントがその接続でデータを送
信しないうちに閉じられるだけになる可能性が残る。し
かし、オーバースケジューリング問題は改善される。

【００７０】同様に、この好ましい実施形態で規定した
２段階待ち行列は、この新規なスケジューリング・ヒュ
ーリスティックを使用しなくても使用することができる
ので有利である。そのような状況では、第２段階にある
接続のために任意のスケジューリング手法を使用するこ
とができる。これには、作業スレッドをその都度アンブ
ロックしなければならない場合であっても各接続を第２
段階に達したらただちにスケジューリングする手法も含
まれる。この手法の結果、スレッドのある程度のオーバ
ースケジューリングは生じるが、このオーバースケジュ
ーリングは処理可能になったデータのある接続に限られ
る。

【００７１】ステップ２１０で、待機スレッドがアンブ
ロックされる。このスレッドは、ステップ２１５で段階
２の「実行可能」待ち行列の先頭にある要求を処理する
ために割り当てられる。次に制御はステップ１５０に返
る。スレッドがアンブロックされ、要求に割り当てられ
る方式は、当業者に周知であり、本発明の一部を形成し
ない。たとえば、「WAIT（待機）」を発行することによ
って（図３のステップ１２０で）スレッドがブロックし
た場合、そのスレッドは「POST（ポスト）」または「NO
TIFY（通知）」事象を発行することによってアンブロッ
クすることができる。アクセプト・アンド・レシーブ
（accept_and_receive）ＡＰＩを使用してWAITを発生さ
せた場合、このPOSTによって単一のスレッドがアンブロ
ックされる。アクセプト・アンド・レシーブ（accept_a
nd_receive）以外のＡＰＩを使用した場合、POSTコマン
ドの発行によって、前述のように待機中のすべてのスレ
ッドがアンブロックされる。

【００７２】図５に、作業スレッドにスケジュールされ
るまでの待機時間が長くなり過ぎる接続がないように保
証するために、遅延モニタによって実行することができ
る論理を示す。この論理は周期的に実行され、タイマを
使用して呼び出される。

【００７３】このプロセスはステップ２５０から開始さ
れ、「最大遅延」タイマに達していないかどうかが検査
される。これはステップ２５０で反復ループとして図示
されているが、この検査が途切れなく行われることは当
業者には明らかであろう。典型的には、「最大遅延」期
間のタイマ・プロセスがスケジュールされ、それによっ
てタイマは刻時を開始する。最大遅延期間が経過する
と、このタイマ・プロセスについて割込みが生成され、
ステップ２５５からステップ２７５までの論理が処理可
能になる。あるいは、この検査は最大遅延時間より高い
頻度または低い頻度で実行することもでき、その場合、
ステップ２５０での検査は異なる時間間隔を反映するこ
とになる。

【００７４】ステップ２５５で、段階２の「実行可能」
待ち行列が空かどうかを調べる検査が行われる。空の場
合、待機時間が長すぎる接続はなく、したがって制御は
ステップ２５０に返り、次のタイマの満了を待つ。空で
ない場合、ステップ２６０でブロック・スレッド待ち行
列が空かどうかを調べる検査を行う。この検査の応答が
肯定の場合、それ以上使用可能なスレッドはなく、した
がって実行可能待ち行列の項目は検査されない。制御は
ステップ２５０に返る。ステップ２６０の応答が否定の
場合、待ち行列上の接続に待機時間が長すぎる接続がな
いか調べる。ステップ２６５からステップ２７５まで
は、この検査を実行する反復ループを表す。ステップ２
６５で、待ち行列上の最も古い要求（待ち行列先頭ポイ
ンタによって指し示された接続）が最大許容時間を超え
て待機していないかどうか調べられる。超えている場
合、ステップ２７０で待機スレッドがアンブロックさ
れ、ステップ２７５でそのスレッドに接続が割り当てら
れる。その後、ステップ２６５に制御が返ることによっ
て、次に古い接続が検査される。実行可能待ち行列がＦ
ＩＦＯ待ち行列を使用して実施されており、ステップ２
６５での検査が否定の場合、残りの待ち行列化接続のい
ずれも最大遅延を超えておらず、制御はステップ２５０
に返る。（ＦＩＦＯ待ち行列を使用していない場合、待
ち行列の終わりに達するまで、ステップ２６５から２７
５を繰り返すことによって実行可能待ち行列上の各項目
を検査する必要がある。）

【００７５】図６に、前述の複数入力源問題を改善する
第２の好ましい実施形態に関わる論理が記載されたフロ
ーチャートを示す。

【００７６】第２の好ましい実施形態は、コレクタ・ソ
ケットと呼ぶ新規なタイプのソケットの規定に基づく。
複数の受動ソケットからの入力がコレクタ・ソケット上
にマージされ、それによって、そこから接続をスレッド
にスケジュールする単一の入力源が得られる。コレクタ
・ソケットは、第１の好ましい実施形態で説明した２段
階待ち行列の第２段階の「実行可能」待ち行列を有する
ものとして実施され、第１段階の「受入れ接続」待ち行
列は複数の受動ソケットに関連づけられたままである。
接続は受け入れられると受動ソケットの受入れ接続待ち
行列に入れられ、各接続の最初のデータ・パケットが到
着するとコレクタ・ソケットの実行可能待ち行列に移さ
れる。

【００７７】図７に、コレクタ・ソケットを使用するた
めに必要な変更との比較のために、第１の好ましい実施
形態の２段階待ち行列の概念図を示す。図７には受動ソ
ケット５００が図示されている。このような受動ソケッ
トが多数存在することができ、各受動ソケットは、
（１）接続がまだ保留中である間ソケット構造が保持さ
れる保留接続待ち行列５０２と、（２）接続が受け入れ
られた後、その接続の最初のデータ・パケットが到着す
る前にソケット構造が保持される受入れ接続待ち行列５
０４と、（３）少なくとも１つのデータ・パケットが到
着した後、接続が作業スレッドにスケジュールされる前
にソケット構造が保持される実行可能接続待ち行列５０
６とを有する。各受動ソケットには、ブロック・スレッ
ド待ち行列５１０が関連づけられ、それを使用して接続
が前述の技法に従ってスレッドにスケジュールされる。

【００７８】これと対比して、図８に、コレクタ・ソケ
ットを使用した場合に受動ソケットがどのように異なる
かを図示する。図８には３個の受動ソケット５３０、５
４０、５５０が図示され、そのデータが１つのコレクタ
・ソケット５６０にマージされている（ただし、マージ
される数は３個には限定されない）。各受動ソケット５
３０、５４０、５５０は今度は、（１）保留接続待ち行
列５３２、５４２、５５２と、（２）受入れ接続待ち行
列５３４、５４４、５５４の２つの待ち行列から成る。
実行可能待ち行列５６２はコレクタ・ソケット５６０に
付随している。さらに、各受動ソケット５００ごとにブ
ロック・スレッド待ち行列５１０を備えるのではなく、
単一のコレクタ・ソケット５６０に単一のブロック・ス
レッド待ち行列５７０がある。図８に示すように、受入
れ接続待ち行列５３４、５４４、５５４から接続が移動
するとき、それらの接続はコレクタ・ソケット５６０の
実行可能待ち行列５６２に移動される。

【００７９】コレクタ・ソケットの使用を可能にするに
は追加のＡＰＩが必要である。このＡＰＩの目的は、ど
の受動ソケットがコレクタ・ソケットにマージされるか
を示すことである。したがって、このＡＰＩ呼出しは、
収集する受動ソケットのリストを備える。この情報は、
好ましくは、構成パラメータを使用して伝えられ、シス
テム管理者などのユーザに対して受動ソケット識別子を
指定するように求める。この情報を提供するための他の
方法も、本発明の進歩的概念から逸脱することなく使用
可能である。その後、これらの識別子は、第２の好まし
い実施形態に提供される。ユーザから構成パラメータを
入手し、実行プログラムに提供する方法は、当業者には
明らかであろう。したがって、これについては詳述しな
い。

【００８０】コレクタＡＰＩは、サーバが動作を開始す
るときに発行されることが好ましい。しかし、クライア
ントがサーバに要求の送信を開始してからコレクタ・ソ
ケットが確立されるまでの間に、ある程度の遅延が存在
する可能性がある。図６に、この状況を改善するために
使用可能であって、受動ソケットの実行可能待ち行列に
すでに移動されている接続がないか見つけるために収集
される受動ソケットを検査する論理を示す。これらの接
続は、コレクタ・ソケットの実行可能待ち行列に移され
る。図６の論理は、サーバがすでに実行を開始している
後でコレクタＡＰＩを呼び出す場合にも使用することが
できる。

【００８１】ステップ４００で、ＡＰＩ呼出しの受信に
応答してコレクタ・ソケットが作成される。実行可能待
ち行列は空の待ち行列に初期設定される。コレクタ・ソ
ケットとこのソケットを使用するスレッドの実行に関す
る統計情報の保持を開始するために、（前述の）スケジ
ューリング・ヒューリスティックのために保持される統
計情報が初期設定される。コレクタ・ソケットのため
に、このソケットからの接続を処理するために使用され
るスレッドのためのブロック・スレッドの待ち行列が作
成される。

【００８２】ステップ４１０で、指標やループ・カウン
タなどの指示機構を使用して、ＡＰＩ呼出し時に提供さ
れるリストから最初の受動ソケット識別子を指示する。
リスト内の項目に指標付けする技法は当技術分野で周知
であり、詳述しない。

【００８３】ステップ４２０で、現在指示されている受
動ソケットを、コレクタ・ソケットを指すように修正す
る。これによって、後で受動ソケットでデータを受け取
った接続が、データ・パケットをコレクタ・ソケットに
転送させることができるようになる。

【００８４】ステップ４３０で、受動ソケットの実行可
能待ち行列を検査して、この接続がすでに実行可能待ち
行列に移されているかどうかを調べる。前述のように、
受け入れられた接続の最初のデータ・パケットは、コレ
クタ・ソケットが作成される前に到着している可能性が
あり、ステップ４３０で、そのような接続をコレクタ・
ソケットの実行可能待ち行列に移動させることができる
ようにする。待ち行列から項目を取り出す技法と、待ち
行列に項目を入れる技法は、当技術分野で周知である。

【００８５】ステップ４４０で、ポインタがリスト内の
最後の要素を指しているかどうかを調べることによっ
て、コレクタＡＰＩで識別されているすべての受動ソケ
ットが処理されたかどうかを検査する。この検査の応答
が肯定の場合、図６の処理は終了する。否定の場合は、
ステップ４５０で、次の受動ソケットを指すようにポイ
ンタを増分し、制御はステップ４２０に返る。

【００８６】作業スレッドがコレクタ・ソケットの実行
可能待ち行列から作業を受け取る処理論理は、受動ソケ
ットの実行可能待ち行列から作業を受け取るスレッドに
関して図３に示したプロセスと同じである。しかし、前
述の図３の説明とは異なる以下の相違点がある。（１）
保持される統計情報はコレクタ・ソケットに関して保持
され、（２）ブロック作業スレッドの待ち行列は、コレ
クタ・ソケットに付随する待ち行列であり、（３）検査
される実行可能待ち行列はコレクタ・ソケットの実行可
能待ち行列であり、（４）作業スレッドはコレクタ・ソ
ケットに対してアクセプト・アンド・レシーブ（accept
_and_receive）ＡＰＩを実行する。

【００８７】この好ましい実施形態で受動ソケットでの
着信パケットの受け取りを扱う処理論理は、図４に示す
ものと類似している。ただし、若干の変更が必要であ
る。ステップ１９５で、コレクタ・ソケットにマージさ
れる受動ソケットのために到着する最初のデータ・パケ
ットを検出した後（すなわちステップ１９５の「Yes」
分岐）、接続は受動ソケットの実行可能待ち行列ではな
くコレクタ・ソケットの実行可能待ち行列に移動され
る。ステップ２０５でスケジューリング・ヒューリステ
ィックに使用される統計は、コレクタ・ソケットの統計
である。ステップ２１０で覚醒されるスレッドは、コレ
クタ・ソケットに付随するブロック・スレッド待ち行列
内のスレッドである。

【００８８】コレクタ・ソケットの実行可能接続待ち行
列を監視して、スケジュールされるまでに待機する時間
が長くなり過ぎる接続がないように保証する処理論理
は、図５に示す論理と同じである。しかし、前述の図５
の説明とは異なる以下のような相違点がある。（１）監
視される実行可能接続待ち行列はコレクタ・ソケットの
実行可能待ち行列であり、（２）検査されるブロック・
スレッド待ち行列はコレクタ・ソケットに付随する待ち
行列であり、（３）ステップ２７０で覚醒されるスレッ
ドは、コレクタ・ソケットに付随するブロック・スレッ
ド待ち行列内のスレッドである。

【００８９】（図３を参照しながら前述したように）受
け入れられた接続が受動ソケットからコレクタ・ソケッ
トに移されるときに、それらの接続と共に、その接続が
どの受動ソケットに到着したかを示す情報を渡す必要が
ある。これは、異なる入力源からの入力に異なる処理が
必要な場合があるためである。たとえば、１つの受動ソ
ケットにセキュア接続要求が到着した場合、作業スレッ
ドは、非セキュア接続要求が到着した場合には不要な特
別なセキュリティ関係の処理を必要とする。その接続が
ＳＳＬ使用可能受動ソケットに到着した場合、この特別
な処理にはハンドシェーク・プロトコルが含まれる。こ
の特別な処理は本発明の一部を形成しない。本発明の進
歩的概念から逸脱することなく、接続の入力源を示す情
報を渡すためにいくつかの方法が使用可能である。たと
えば、当技術分野で周知のように、接続には様々なタイ
プの情報を入れるために割り振られた記憶域がある。こ
のデータ域に、着信ソケットの識別子を記憶するための
パラメータを付加することができる。各作業スレッド
は、このデータ域を調べて入力源関係の処理が必要かど
うかを判断する論理を含む。これによって、プール内の
任意のスレッドが、複数の受動ソケットのうちのいずれ
かのソケットに到着する接続を処理することができる。
したがって、静的区分化を使用して受動ソケットに作業
スレッドを割り振る必要がなくなる。この実施形態は、
コレクタ・ソケットの実行待ち行列にマージされた入力
源を有することによって、様々な入力源へのプールの動
的区分化を実現する。

【００９０】コレクタ・ソケットの実行可能待ち行列か
ら要求をスケジュールするための、第１の好ましい実施
形態で定義されたスケジューリング・ヒューリスティッ
クの使用は、この第２の実施形態では任意選択である。
しかし、その使用によって、コレクタ・ソケット上の接
続負荷が使用可能スレッドの数に満たない場合に生じる
オーバースケジューリング問題を回避することができ
る。

【００９１】図９から図１０に、持続接続問題のある前
述のスレッド割当てを改善する第３の実施形態に関与す
る論理が記載されたフローチャートを示す。

【００９２】第３の好ましい実施形態は、第２の好まし
い実施形態により規定されたコレクタ・ソケットの使用
を必要とする。持続接続を使用する場合により効率的な
処理を可能にする、コレクタ・ソケットを処理するため
の改善点を規定する。図８に示す実行可能待ち行列に加
えて、コレクタ・ソケットは「遊休接続」待ち行列も有
する。本明細書で「ギブバック（giveback）」ＡＰＩと
呼ぶ、（後述の）追加のＡＰＩを定義する。

【００９３】作業スレッドがコレクタ・ソケットの実行
可能待ち行列から作業を受け取るための処理論理は、第
２の好ましい実施形態に関して前述したプロセス（図３
を参照）と同じである。作業スレッドは、コレクタ・ソ
ケットの実行可能待ち行列上にある接続のみに割り当て
られる。

【００９４】この第３の好ましい実施形態の受動ソケッ
トで着信パケットの受領を処理する処理論理は、第２の
好ましい実施形態に関して前述したもの（図４を参照）
と類似している。しかし、若干の変更を要する。ステッ
プ１５５で着信接続要求を検出した後、ステップ１６０
で作成される新しいソケットは、この実施形態では２つ
の追加のデータ値の初期設定を必要とする。第１に、ソ
ケット状況を「実行不能」、すなわち当該接続は現在ス
ケジュールすることができないことを示すように設定し
なければならない。第２に、アプリケーション・コンテ
キストを、当該接続にまだコンテキストが関連づけられ
ていないことを示すヌル値に設定しなければならない。
その他の変更は、接続のデータが到着したときに実行さ
れる処理に関するものである。ステップ１９５でそれが
最初に受け取ったデータ・パケットであるかどうかを調
べる検査を行う代わりに、ソケットが「実行可能」と
「実行不能」のどちらにマークされているかを問い合わ
せる検査を行う。状況がすでに「実行可能」に設定され
ていた場合、制御はステップ１５０に返る。そうでない
場合（すなわち状況が「実行不能」だった場合）、制御
はステップ２００に進む。現在ステップ２００に示され
ている処理の代わりに、新しい処理は、（１）ソケット
を「実行可能」としてマークするステップと、（２）ソ
ケットを現行待ち行列（受動ソケットの受入れ待ち行列
またはコレクタ・ソケットの遊休待ち行列である）か
ら、コレクタ・ソケットの実行可能待ち行列に移動する
ステップとを含む。

【００９５】コレクタ・ソケットの実行可能接続待ち行
列を監視して、スケジューリングされるまでの待機時間
が長すぎる接続がないようにする処理論理は、図５に示
すものと同じである。第２の好ましい実施形態に関して
説明した図５との相違は、この第３の好ましい実施形態
にも当てはまる。

【００９６】図６を参照しながら第２の好ましい実施形
態に関して説明したようにコレクタ・ソケットを作成す
るとき、１つの追加の変更が必要である。今度は、ステ
ップ４００でコレクタ・ソケットをセットアップすると
きに空の遊休接続待ち行列を作成しなければならない。

【００９７】図９に、アプリケーションによる新しいギ
ブバック（giveback）ＡＰＩの発行に応答して呼び出さ
れる論理を示す。このＡＰＩ呼出しによって、作業スレ
ッドに割り当てられていた（したがってすでにデータを
受信していた）ソケットが、そのスレッドから結合解除
され、そのスレッドを他の接続に割り当てることが可能
になる。このＡＰＩは、持続接続が着信データ要求間で
遅延（何らかの所定のしきい値を超える）に遭うと呼び
出される。

【００９８】ステップ６００で、この接続のための未読
のデータがあるかどうかを問い合わせる。ギブバック
（giveback）ＡＰＩが処理中だったときにデータが着信
している可能性がある。この条件が真の場合、制御はス
テップ６５０に移る。そうでない場合、ステップ６１０
で接続を遊休待ち行列に移動するプロセスが続けられ
る。

【００９９】ステップ６１０で、このソケットを「実行
不能」としてマークし、ソケットの項目を遊休接続待ち
行列に入れる。遊休接続数のカウンタが増分される。ソ
ケットが遊休待ち行列に入れられるとき、このＡＰＩの
入力パラメータである、この接続に関連づけられたアプ
リケーション・コンテキスト値がソケットと共に格納さ
れる。これによって、ソケットは後でデータが到着した
ときに同じソケットを使用して処理を再開できるように
なる。

【０１００】ステップ６２０で、遊休接続カウンタの現
行値が最大値（構成パラメータまたは静的値として設定
することができる）と比較される。この検査の応答が肯
定の場合、遊休状態の接続が多すぎ、ステップ６３０に
制御を移すことによって最も古い接続が除去される。最
大値を超えていない場合、図９の処理は終了する。

【０１０１】ステップ６３０で、遊休接続待ち行列上の
最も古い接続を除去しなければならない。好ましくは、
遊休接続待ち行列はＦＩＦＯ待ち行列であり、したがっ
てステップ６３０は待ち行列の先頭を指すステップを含
む。この接続は閉じられ、使用していた資源は解放され
る。ステップ６４０で、「Expired（期限切れ）」であ
ることを示すようにソケットにマークを付け遊休待ち行
列から外すことによって、このプロセスが開始される。
遊休接続のカウントが減分され、ステップ６５０で、こ
のソケットは実行可能待ち行列い移動される。実行可能
待ち行列から接続が作業スレッドにスケジュールされる
と、その作業スレッドによってクローズ・プロセスは完
了される。ステップ６６０からステップ６８０で、第１
の好ましい実施形態に関して説明したスケジューリング
・ヒューリスティックが実行され、それによって、接続
はスレッドをアンブロックすることによってこの時点で
スケジュールされるか、または使用中のスレッドが使用
可能になり、（図３の修正したプロセスを使用して）コ
レクタ・ソケットの実行可能待ち行列を調べの時点でス
ケジューリングされるのを待つ。ステップ６６０で、ス
レッドがスケジュールされるのを待つことが示された場
合、またはステップ６８０でアンブロック・スレッドへ
の接続の割当てが終了した場合、図９の処理は完了す
る。

【０１０２】このギブバック（giveback）ＡＰＩの使用
によってコレクタ・ソケットの遊休接続待ち行列に入れ
られた接続は、以下のいずれか１つの条件が満たされる
までそこにとどまる。すなわち、（１）さらにデータが
到着するか、（２）クライアントから接続クローズ要求
を受け取るか、（３）接続が最大時間を超えて遊休状態
のままになっているか、または（４）遊休接続のカウン
トが高くなり過ぎるという条件である。条件１の場合、
接続を遊休待ち行列上に保持することによって、最初の
データ要求の受領によってスケジューリングされる接続
について通常行われる初期設定ステップを踏まずに、接
続を後続の作業スレッドに割り当てることができる。こ
の第３の実施形態に関して前述した図４の修正された論
理によって、この追加のデータの到着が検出され、接続
の再スケジュールが処理される。条件４は、図９のステ
ップ６２０〜６８０に関して前述したプロセスである。
以下で、条件２および３について詳述する。

【０１０３】クライアントが接続を閉じることを要求す
る条件２の場合、接続を遊休接続待ち行列からコレクタ
・ソケットの実行可能待ち行列に移動しなければならな
い。これは、接続が遊休状態を続けている間、その接続
のためのアプリケーション・コンテキストが保持されて
おり、この時点でそれを作業スレッドによって打ち切る
必要があるためである。接続は図４のステップ２００の
修正された論理を使用して実行可能待ち行列に移動され
る。

【０１０４】接続が遊休状態になっている時間が長すぎ
る条件３の場合、図１０の処理が使用される。実行可能
待ち行列に入っている時間が長すぎる接続がないか検査
する第１および第２の実施形態で使用した遅延モニタ
を、前述のようにこの第３の実施形態でも実行する。し
かし、図１０に示す、遊休接続待ち行列を検査する追加
の監視手続きも使用する。

【０１０５】図１０の処理は何らかの所定の間隔で呼び
出され、この間隔は構成パラメータとすることができ
る。この呼出しを行うためにタイマを使用することもで
きる。ステップ７００で、遊休待ち行列から最も古い遊
休ソケットを入手する。前述のように、好ましくは、遊
休接続待ち行列はＦＩＦＯ待ち行列であり、したがって
ステップ７００は待ち行列の先頭を指すステップを含
む。ステップ７１０で、当該接続が遊休状態のままであ
る時間が長すぎないかどうかを検査する。ギブバック
（giveback）ＡＰＩにタイムアウト・パラメータを組み
込むことによって、各接続は定義されたそれ自体の最大
遊休期間を有することができる。このパラメータ値は、
接続の項目と共に遊休待ち行列に格納される。あるい
は、たとえば構成時に値を指定することによって、各接
続に同じ最大遊休時間を使用することもできる。

【０１０６】接続がまだ最大遊休時間に達していない場
合、制御はステップ７２０に進む。したがって、接続は
遊休待ち行列にとどまることができる。ステップ７２０
で、これが遊休接続待ち行列上の最後の接続かどうかを
問い合わせる。最後の接続の場合、それ以上検査する接
続はなく、したがって図１０のプロセスは終了する。最
後の接続でない場合、ステップ７３０で、待ち行列内の
次の接続を指示し、制御はステップ７１０に返ってその
接続を検査する。

【０１０７】検査している接続が最大遊休時間を超えて
遊休状態であった場合、制御はステップ７４０に進む。
送るべきデータがないときに当該接続のための関連コン
テキストを開いたままにしておくと、システム資源が効
率的に使用されないため、接続は閉じられ、資源が解放
される。ステップ７４０で、ソケットを「Expired（期
限切れ）」を示すようにマークし、遊休待ち行列から除
去することによって、このプロセスが開始される。遊休
接続のカウントが減分され、ステップ７５０でソケット
が実行可能待ち行列に移される。接続がスケジュールさ
れると、作業スレッドがこのクローズ・プロセスを完了
させる。ステップ７６０から７８０で、第１の好ましい
実施形態で説明したスケジューリング・ヒューリスティ
ックが実行され、それによって接続はスレッドをアンブ
ロックすることによってこの時点でスケジュールされる
か、または使用中のスレッドが使用可能になり、（図３
の修正したプロセスを使用して）コレクタ・ソケットの
実行可能待ち行列を検査する時点でスケジュールされる
のを待つ。ステップ７６０で、スレッドがスケジュール
されるのを待つことが示された場合、またはステップ７
８０でアンブロック・スレッドへの接続の割当てが終了
した場合、制御はステップ７２０に返り、遊休待ち行列
になお接続があるかどうかを調べる。

【０１０８】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１０９】（１）ネットワークへの接続を有するコン
ピューティング環境において、前記環境内のコンピュー
タ・システムによって読取り可能で、マルチスレッド・
アプリケーションのパフォーマンスを強化するコンピュ
ータ可読コードであって、接続を求める複数のクライア
ント要求と、複数の作業スレッドと、前記複数のクライ
アント要求を受け取るサブプロセスと、前記作業スレッ
ドのオーバースケジューリングを改善するスケジューリ
ング・ヒューリスティックを実施するサブプロセスとを
含むコンピュータ可読コード。 （２）前記作業スレッドの第１のグループがアクティブ
・スレッドであり、前記第１のグループが前記複数の作
業スレッドのうちの変更可能な作業スレッドから成り、
変更可能な数の前記変更可能な作業スレッドを有し、前
記変更可能な数が少なくとも１であり、スケジューリン
グ・ヒューリスティックを実施する前記サブプロセス
が、前記複数のクライアント要求のうちの１つまたは複
数のクライアント要求から成る現行作業負荷に照らして
前記第１のグループ内の前記変更可能な数のバランスを
とるサブプロセスをさらに含む、上記（１）に記載のマ
ルチスレッド・アプリのパフォーマンスを強化するコン
ピュータ可読コード。 （３）バランスをとる前記サブプロセスが平均遅延の使
用をさらに含む、上記（２）に記載のマルチスレッド・
アプリケーションのパフォーマンスを強化するコンピュ
ータ可読コード。 （４）バランスをとる前記サブプロセスが最大遅延の使
用をさらに含む、上記（３）に記載のマルチスレッド・
アプリケーションのパフォーマンスを強化するコンピュ
ータ可読コード。 （５）前記平均遅延および前記最大遅延が構成パラメー
タである、上記（４）に記載のマルチスレッド・アプリ
ケーションのパフォーマンスを強化するコンピュータ可
読コード。 （６）前記作業スレッドの第２のグループがブロック・
スレッドであり、前記第２のグループが前記複数の作業
スレッドのうちの前記第１のグループに入っていない作
業スレッドから成り、前記ブロック・スレッドが後入れ
先出し待ち行列に格納される、上記（２）に記載のマル
チスレッド・アプリケーションのパフォーマンスを強化
するコンピュータ可読コード。 （７）ネットワークへの接続を有するコンピューティン
グ環境において、前記環境内のコンピュータ・システム
によって読取り可能で、マルチスレッド・アプリケーシ
ョンのパフォーマンスを強化するコンピュータ可読コー
ドであって、各前記接続が受け入れられると、接続を保
留接続待ち行列から第１の待ち行列に移動させるサブプ
ロセスと、前記接続の最初のデータ・パケットが到着す
ると、前記接続を前記第１の待ち行列から第２の待ち行
列に移動させるサブプロセスと、前記第２の待ち行列上
の各前記接続に作業スレッドを割り当てるサブプロセス
とを含むコンピュータ可読コード。 （８）ネットワークへの接続を有するコンピューティン
グ環境において、前記環境内のコンピュータ・システム
によって読取り可能で、マルチスレッド・アプリケーシ
ョンのパフォーマンスを強化するコンピュータ可読コー
ドであって、複数の発生源から入力を受け取るサブプロ
セスと、前記受け取った入力をスケジューリングのため
に単一の待ち行列にマージするサブプロセスとを含むコ
ンピュータ可読コード。 （９）各前記接続が受け入れられると、接続を保留接続
待ち行列から第１の待ち行列に移動させるサブプロセス
と、前記接続の最初のデータ・パケットが到着すると、
前記接続を前記第１の待ち行列から前記単一の待ち行列
に移動させるサブプロセスと、前記単一の待ち行列上の
各前記接続に作業スレッドを割り当てるサブプロセスと
をさらに含む、上記（８）に記載のマルチスレッド・ア
プリケーションのパフォーマンスを強化するコンピュー
タ可読コード。 （１０）スケジューリングする前記サブプロセスが、複
数の作業スレッドのうちの変更可能な作業スレッドから
成り、変更可能な数の前記変更可能な作業スレッドを有
し、前記変更可能な数が少なくとも１であるアクティブ
作業スレッドのグループと、前記単一の待ち行列に格納
された前記クライアント要求から成る現行作業負荷に照
らして前記アクティブ・グループ内の前記変更可能な数
のバランスをとるスケジューリング・ヒューリスティッ
クを実施するサブプロセスとをさらに含む、上記（９）
に記載のマルチスレッド・アプリケーションのパフォー
マンスを強化するコンピュータ可読コード。 （１１）ネットワークへの接続を有するコンピューティ
ング環境において、前記環境内のコンピュータ・システ
ムによって読取り可能で、マルチスレッド・アプリケー
ションのパフォーマンスを強化するコンピュータ可読コ
ードであって、複数の持続接続と、複数の作業スレッド
と、前記持続接続のうちの選択された持続接続を前記作
業スレッドのうちの選択された作業スレッドに結合する
サブプロセスであって、その実行の結果として結合接続
が生じるサブプロセスと、前記結合接続のうちの選択さ
れた結合接続を結合解除するサブプロセスであって、そ
の実行の結果として結合解除された作業スレッドが生じ
るサブプロセスとを含むコンピュータ可読コード。 （１２）結合する前記サブプロセスが２段階待ち行列を
使用するステップをさらに含み、結合解除する前記サブ
プロセスが前記２段階待ち行列を使用するステップをさ
らに含む、上記（１１）に記載のマルチスレッド・アプ
リケーションのパフォーマンスを強化するコンピュータ
可読コード。 （１３）前記２段階待ち行列を使用して結合する前記サ
ブプロセスが、前記接続の最初のデータ・パケットが到
着すると、各前記持続接続を前記第１の段階に移動させ
るサブプロセスと、前記接続のデータを受け取ると各前
記持続接続を前記第２の段階から前記第１の段階に移動
させるサブプロセスと、前記第１の段階から前記持続接
続をスケジュールするサブプロセスとをさらに含み、前
記２段階待ち行列を使用して結合解除する前記サブプロ
セスが、前記選択された結合接続が遊休状態になると、
前記結合接続のうちの選択された結合接続を前記第１の
段階から前記第２の段階に移動させるサブプロセスと、
最大遊休期間を超えるとそれに応答して、前記第２の段
階にある前記持続接続のうちの選択された持続接続を閉
じるサブプロセスと、前記結合解除された作業スレッド
を、結合する前記サブプロセスに使用可能にするサブプ
ロセスとをさらに含む、上記（１２）に記載のマルチス
レッド・アプリケーションのパフォーマンスを強化する
コンピュータ可読コード。 （１４）結合解除する前記サブプロセスが、最大遊休接
続数を超えるとそれに応答して、前記第２段階にある前
記持続接続のうちのさらに選択された持続接続を閉じる
サブプロセスをさらに含む、上記（１３）に記載のマル
チスレッド・アプリケーションのパフォーマンスを強化
するコンピュータ可読コード。 （１５）ネットワークへの接続を有するコンピューティ
ング環境においてマルチスレッド・アプリケーションの
パフォーマンスを強化するシステムであって、接続を求
める複数のクライアント要求と、複数の作業スレッド
と、前記複数のクライアント要求を受け取る手段と、前
記作業スレッドのオーバースケジューリングを改善する
スケジューリング・ヒューリスティックを実施する手段
とを含むシステム。 （１６）前記作業スレッドの第１のグループがアクティ
ブ・スレッドであり、前記第１のグループが前記複数の
作業スレッドのうちの変更可能な作業スレッドから成
り、変更可能な数の前記変更可能な作業スレッドを有
し、前記変更可能な数が少なくとも１であり、スケジュ
ーリング・ヒューリスティックを実施する前記手段が、
前記複数のクライアント要求のうちの１つまたは複数の
クライアント要求から成る現行作業負荷に照らして前記
第１のグループ内の前記変更可能な数のバランスをとる
手段をさらに含む、上記（１５）に記載のマルチスレッ
ド・アプリケーションのパフォーマンスを強化するシス
テム。 （１７）バランスをとる前記手段が平均遅延の使用をさ
らに含む、上記（１６）に記載のマルチスレッド・アプ
リケーションのパフォーマンスを強化するシステム。 （１８）バランスをとる前記手段が最大遅延の使用をさ
らに含む、上記（１７）に記載のマルチスレッド・アプ
リケーションのパフォーマンスを強化するシステム。 （１９）前記平均遅延および前記最大遅延が構成パラメ
ータである、上記（１８）に記載のマルチスレッド・ア
プリケーションのパフォーマンスを強化するシステム。 （２０）前記作業スレッドの第２のグループがブロック
・スレッドであり、前記第２のグループが前記複数の作
業スレッドのうちの前記第１のグループに入っていない
作業スレッドから成り、前記ブロック・スレッドが後入
れ先出し待ち行列に格納される、上記（１６）に記のマ
ルチスレッド・アプリケーションのパフォーマンスを強
化するシステム。 （２１）ネットワークへの接続を有するコンピューティ
ング環境においてマルチスレッド・アプリケーションの
パフォーマンスを強化するシステムであって、各前記接
続が受け入れられると、接続を保留接続待ち行列から第
１の待ち行列に移動させる手段と、前記接続の最初のデ
ータ・パケットが到着すると、前記接続を前記第１の待
ち行列から第２の待ち行列に移動させる手段と、前記第
２の待ち行列上の各前記接続に作業スレッドを割り当て
る手段とを含むシステム。 （２２）ネットワークへの接続を有するコンピューティ
ング環境においてマルチスレッド・アプリケーションの
パフォーマンスを強化するシステムであって、複数の発
生源から入力を受け取る手段と、前記受け取った入力を
スケジューリングのために単一の待ち行列にマージする
手段とを含むシステム。 （２３）各前記接続が受け入れられると、接続を保留接
続待ち行列から第１の待ち行列に移動させる手段と、前
記接続の最初のデータ・パケットが到着すると、前記各
接続を前記第１の待ち行列から前記単一の待ち行列に移
動させる手段と、前記単一の待ち行列上の各前記接続に
作業スレッドを割り当てる手段とをさらに含む、上記
（２２）に記載のマルチスレッド・アプリケーションの
パフォーマンスを強化するシステム。 （２４）スケジューリングする前記手段が、複数の作業
スレッドのうちの変更可能な作業スレッドから成り、変
更可能な数の前記変更可能な作業スレッドを有し、前記
変更可能な数が少なくとも１であるアクティブ作業スレ
ッドのグループと、前記単一の待ち行列に格納された前
記クライアント要求から成る現行作業負荷に照らして前
記アクティブ・グループ内の前記変更可能な数のバラン
スをとるスケジューリング・ヒューリスティックを実施
する手段とをさらに含む、上記（２３）に記載のマルチ
スレッド・アプリケーションのパフォーマンスを強化す
るシステム。 （２５）ネットワークへの接続を有するコンピューティ
ング環境においてマルチスレッド・アプリケーションの
パフォーマンスを強化するシステムであって、複数の持
続接続と、複数の作業スレッドと、前記持続接続のうち
の選択された持続接続を前記作業スレッドのうちの選択
された作業スレッドに結合する手段であって、結合の実
行の結果として結合接続が生じる手段と、前記結合接続
のうちの選択された結合接続を結合解除する手段であっ
て、結合解除の実行の結果として結合解除された作業ス
レッドが生じる手段とを含むシステム。 （２６）結合する前記手段が２段階待ち行列を使用する
ステップをさらに含み、結合解除する前記手段が前記２
段階待ち行列を使用するステップをさらに含む、上記
（２５）に記載のマルチスレッド・アプリケーションの
パフォーマンスを強化するシステム。 （２７）前記２段階待ち行列を使用して結合する前記手
段が、前記接続の最初のデータ・パケットが到着する
と、各前記持続接続を前記第１の段階に移動させる手段
と、前記接続のデータを受け取ると各前記持続接続を前
記第２の段階から前記第１の段階に移動させる手段と、
前記第１の段階から前記持続接続をスケジュールする手
段とをさらに含み、前記２段階待ち行列を使用して結合
解除する前記手段が、前記選択された結合接続が遊休状
態になると、前記結合接続のうちの選択された結合接続
を前記第１の段階から前記第２の段階に移動させる手段
と、最大遊休期間を超えるとそれに応答して、前記第２
の段階にある前記持続接続のうちの選択された持続接続
を閉じる手段と、前記結合解除された作業スレッドを、
結合する前記手段に使用可能にする手段とをさらに含
む、上記（２６）に記載のマルチスレッド・アプリケー
ションのパフォーマンスを強化するシステム。 （２８）結合解除する前記手段が、最大遊休接続数を超
えるとそれに応答して、前記第２段階にある前記持続接
続のうちのさらに選択された持続接続を閉じる手段をさ
らに含む、上記（２７）に記載のマルチスレッド・アプ
リケーションのパフォーマンスを強化するシステム。 （２９）ネットワークへの接続を有するコンピューティ
ング環境においてマルチスレッド・アプリケーションの
パフォーマンスを強化する方法であって、接続を求める
複数のクライアント要求を受け取るステップと、前記複
数のクライアント要求への複数の作業スレッドのオーバ
ースケジューリングを改善するスケジューリング・ヒュ
ーリスティックを実施するステップとを含む方法。 （３０）前記作業スレッドの第１のグループがアクティ
ブ・スレッドであり、前記第１のグループが前記複数の
作業スレッドのうちの変更可能な作業スレッドから成
り、変更可能な数の前記変更可能な作業スレッドを有
し、前記変更可能な数が少なくとも１であり、スケジュ
ーリング・ヒューリスティックを実施する前記ステップ
が、前記複数のクライアント要求のうちの１つまたは複
数のクライアント要求から成る現行作業負荷に照らして
前記第１のグループ内の前記変更可能な数のバランスを
とるステップをさらに含む、上記（２９）に記載のマル
チスレッド・アプリケーションのパフォーマンスを強化
する方法。 （３１）バランスをとる前記ステップが平均遅延の使用
をさらに含む、上記（３０）に記載のマルチスレッド・
アプリケーションのパフォーマンスを強化する方法。 （３２）バランスをとる前記ステップが最大遅延の使用
をさらに含む、上記（３１）に記載のマルチスレッド・
アプリケーションのパフォーマンスを強化する方法。 （３３）前記平均遅延および前記最大遅延が構成パラメ
ータである、上記（３２）に記載のマルチスレッド・ア
プリケーションのパフォーマンスを強化する方法。 （３４）前記作業スレッドの第２のグループがブロック
・スレッドであり、前記第２のグループが前記複数の作
業スレッドのうちの前記第１のグループに入っていない
作業スレッドから成り、前記ブロック・スレッドが後入
れ先出し待ち行列に格納される、上記（３０）に記載の
マルチスレッド・アプリケーションのパフォーマンスを
強化する方法。 （３５）ネットワークへの接続を有するコンピューティ
ング環境においてマルチスレッド・アプリケーションの
パフォーマンスを強化する方法であって、各前記接続が
受け入れられると、接続を保留接続待ち行列から第１の
待ち行列に移動させるステップと、前記接続の最初のデ
ータ・パケットが到着すると、前記接続を前記第１の待
ち行列から第２の待ち行列に移動させるステップと、前
記第２の待ち行列上の各前記接続に作業スレッドを割り
当てるステップとを含む方法。 （３６）ネットワークへの接続を有するコンピューティ
ング環境においてマルチスレッド・アプリケーションの
パフォーマンスを強化する方法であって、複数の発生源
から入力を受け取るステップと、前記受け取った入力を
スケジューリングのために単一の待ち行列にマージする
ステップとを含む方法。 （３７）各前記接続が受け入れられると、接続を保留接
続待ち行列から第１の待ち行列に移動させるステップ
と、前記接続の最初のデータ・パケットが到着すると、
前記接続を前記第１の待ち行列から前記単一の待ち行列
に移動させるステップと、前記単一の待ち行列上の各前
記接続に作業スレッドを割り当てるステップとをさらに
含む、上記（３６）に記載のマルチスレッド・アプリケ
ーションのパフォーマンスを強化する方法。 （３８）複数の作業スレッドのうちの変更可能な作業ス
レッドから成り、変更可能な数の前記変更可能な作業ス
レッドを有し、前記変更可能な数が少なくとも１である
アクティブ作業スレッドのグループをさらに含み、前記
スケジューリング・ステップが、前記単一の待ち行列に
格納された前記クライアント要求から成る現行作業負荷
に照らして前記アクティブ・グループ内の前記変更可能
な数のバランスをとるスケジューリング・ヒューリステ
ィックを実施するステップとをさらに含む、上記（３
７）に記載のマルチスレッド・アプリケーションのパフ
ォーマンスを強化する方法。 （３９）ネットワークへの接続を有するコンピューティ
ング環境においてマルチスレッド・アプリケーションの
パフォーマンスを強化する方法であって、複数の持続接
続のうちの選択された持続接続を複数の作業スレッドの
うちの選択された作業スレッドに結合するステップであ
って、結合ステップの実行の結果として結合接続が生じ
るステップと、前記結合接続のうちの選択された結合接
続を結合解除する手段であって、結合解除ステップの実
行の結果として結合解除された作業スレッドが生じるス
テップとを含む方法。 （４０）前記結合ステップが２段階待ち行列を使用する
ステップをさらに含み、前記結合解除ステップが前記２
段階待ち行列を使用するステップをさらに含む、上記
（３９）に記載のマルチスレッド・アプリケーションの
パフォーマンスを強化する方法。 （４１）前記２段階待ち行列を使用して結合する前記ス
テップが、前記持続接続の最初のデータ・パケットが到
着すると、各前記持続接続を前記第１の段階に移動させ
るステップと、前記持続接続のデータを受け取ると各前
記持続接続を前記第２の段階から前記第１の段階に移動
させるステップと、前記第１の段階から前記持続接続を
スケジュールするステップとをさらに含み、前記２段階
待ち行列を使用して結合解除する前記ステップが、前記
選択された結合接続が遊休状態になると、前記結合接続
のうちの選択された結合接続を前記第１の段階から前記
第２の段階に移動させるステップと、最大遊休期間を超
えるとそれに応答して、前記第２の段階にある前記持続
接続のうちの選択された持続接続を閉じるステップと、
前記結合解除された作業スレッドを、結合する前記ステ
ップに使用可能にするステップとをさらに含む、上記
（４０）に記載のマルチスレッド・アプリケーションの
パフォーマンスを強化する方法。 （４２）前記結合解除ステップが、最大遊休接続数を超
えるとそれに応答して、前記第２段階にある前記持続接
続のうちのさらに選択された持続接続を閉じるステップ
をさらに含む、上記（４１）に記載のマルチスレッド・
アプリケーションのパフォーマンスを強化する方法。

【図面の簡単な説明】

【図１】本発明を実施することができるコンピュータ・
ワークステーション環境を示すブロック図である。

【図２】本発明を実施することができるネットワーク・
コンピューティング環境を示す図である。

【図３】オーバースケジューリング問題を改善する本発
明に関係する論理を記載したフローチャートである。

【図４】オーバースケジューリング問題を改善する本発
明に関係する論理を記載したフローチャートである。

【図５】オーバースケジューリング問題を改善する本発
明に関係する論理を記載したフローチャートである。

【図６】マージされた入力をスケジューリングに使用可
能にあうるために、複数の入力源からの入力をマージす
る場合の、本発明に関係する論理を記載したフローチャ
ートである。

【図７】本発明によって使用される多段階待ち行列を示
す概念図である。

【図８】本発明によって使用される多段階待ち行列を示
す概念図である。

【図９】持続接続を使用する場合に、着信要求へのスレ
ッドの割当てを最適化する本発明に関係する論理を記載
したフローチャートである。

【図１０】持続接続を使用する場合に、着信要求へのス
レッドの割当てを最適化する本発明に関係する論理を記
載したフローチャートである。

【符号の説明】

１０ ワークステーション １２ マイクロプロセッサ １４ バス １６ ユーザ・インタフェース・アダプタ １８ キーボード ２０ マウス ２４ 表示装置 ２６ ディスプレイ・アダプタ ２８ サーバ・メモリ ３０ 長期記憶域 ４０ データ処理ネットワーク ４４ ローカル・エリア・ネットワーク ４６ メインフレーム・コンピュータ（サーバ） ４８ 通信リンク

Claims (42)

【特許請求の範囲】
1. 【請求項１】ネットワークへの接続を有するコンピュー
   ティング環境において、前記環境内のコンピュータ・シ
   ステムによって読取り可能で、マルチスレッド・アプリ
   ケーションのパフォーマンスを強化するコンピュータ可
   読コードであって、 接続を求める複数のクライアント要求と、 複数の作業スレッドと、 前記複数のクライアント要求を受け取るサブプロセス
   と、 前記作業スレッドのオーバースケジューリングを改善す
   るスケジューリング・ヒューリスティックを実施するサ
   ブプロセスとを含むコンピュータ可読コード。
2. 【請求項２】前記作業スレッドの第１のグループがアク
   ティブ・スレッドであり、前記第１のグループが前記複
   数の作業スレッドのうちの変更可能な作業スレッドから
   成り、変更可能な数の前記変更可能な作業スレッドを有
   し、前記変更可能な数が少なくとも１であり、 スケジューリング・ヒューリスティックを実施する前記
   サブプロセスが、前記複数のクライアント要求のうちの
   １つまたは複数のクライアント要求から成る現行作業負
   荷に照らして前記第１のグループ内の前記変更可能な数
   のバランスをとるサブプロセスをさらに含む、請求項１
   に記載のマルチスレッド・アプリのパフォーマンスを強
   化するコンピュータ可読コード。
3. 【請求項３】バランスをとる前記サブプロセスが平均遅
   延の使用をさらに含む、請求項２に記載のマルチスレッ
   ド・アプリケーションのパフォーマンスを強化するコン
   ピュータ可読コード。
4. 【請求項４】バランスをとる前記サブプロセスが最大遅
   延の使用をさらに含む、請求項３に記載のマルチスレッ
   ド・アプリケーションのパフォーマンスを強化するコン
   ピュータ可読コード。
5. 【請求項５】前記平均遅延および前記最大遅延が構成パ
   ラメータである、請求項４に記載のマルチスレッド・ア
   プリケーションのパフォーマンスを強化するコンピュー
   タ可読コード。
6. 【請求項６】前記作業スレッドの第２のグループがブロ
   ック・スレッドであり、前記第２のグループが前記複数
   の作業スレッドのうちの前記第１のグループに入ってい
   ない作業スレッドから成り、 前記ブロック・スレッドが後入れ先出し待ち行列に格納
   される、請求項２に記載のマルチスレッド・アプリケー
   ションのパフォーマンスを強化するコンピュータ可読コ
   ード。
7. 【請求項７】ネットワークへの接続を有するコンピュー
   ティング環境において、前記環境内のコンピュータ・シ
   ステムによって読取り可能で、マルチスレッド・アプリ
   ケーションのパフォーマンスを強化するコンピュータ可
   読コードであって、 各前記接続が受け入れられると、接続を保留接続待ち行
   列から第１の待ち行列に移動させるサブプロセスと、 前記接続の最初のデータ・パケットが到着すると、前記
   接続を前記第１の待ち行列から第２の待ち行列に移動さ
   せるサブプロセスと、 前記第２の待ち行列上の各前記接続に作業スレッドを割
   り当てるサブプロセスとを含むコンピュータ可読コー
   ド。
8. 【請求項８】ネットワークへの接続を有するコンピュー
   ティング環境において、前記環境内のコンピュータ・シ
   ステムによって読取り可能で、マルチスレッド・アプリ
   ケーションのパフォーマンスを強化するコンピュータ可
   読コードであって、 複数の発生源から入力を受け取るサブプロセスと、 前記受け取った入力をスケジューリングのために単一の
   待ち行列にマージするサブプロセスとを含むコンピュー
   タ可読コード。
9. 【請求項９】各前記接続が受け入れられると、接続を保
   留接続待ち行列から第１の待ち行列に移動させるサブプ
   ロセスと、 前記接続の最初のデータ・パケットが到着すると、前記
   接続を前記第１の待ち行列から前記単一の待ち行列に移
   動させるサブプロセスと、 前記単一の待ち行列上の各前記接続に作業スレッドを割
   り当てるサブプロセスとをさらに含む、請求項８に記載
   のマルチスレッド・アプリケーションのパフォーマンス
   を強化するコンピュータ可読コード。
10. 【請求項１０】スケジューリングする前記サブプロセス
    が、 複数の作業スレッドのうちの変更可能な作業スレッドか
    ら成り、変更可能な数の前記変更可能な作業スレッドを
    有し、前記変更可能な数が少なくとも１であるアクティ
    ブ作業スレッドのグループと、 前記単一の待ち行列に格納された前記クライアント要求
    から成る現行作業負荷に照らして前記アクティブ・グル
    ープ内の前記変更可能な数のバランスをとるスケジュー
    リング・ヒューリスティックを実施するサブプロセスと
    をさらに含む、請求項９に記載のマルチスレッド・アプ
    リケーションのパフォーマンスを強化するコンピュータ
    可読コード。
11. 【請求項１１】ネットワークへの接続を有するコンピュ
    ーティング環境において、前記環境内のコンピュータ・
    システムによって読取り可能で、マルチスレッド・アプ
    リケーションのパフォーマンスを強化するコンピュータ
    可読コードであって、 複数の持続接続と、 複数の作業スレッドと、 前記持続接続のうちの選択された持続接続を前記作業ス
    レッドのうちの選択された作業スレッドに結合するサブ
    プロセスであって、その実行の結果として結合接続が生
    じるサブプロセスと、 前記結合接続のうちの選択された結合接続を結合解除す
    るサブプロセスであって、その実行の結果として結合解
    除された作業スレッドが生じるサブプロセスとを含むコ
    ンピュータ可読コード。
12. 【請求項１２】結合する前記サブプロセスが２段階待ち
    行列を使用するステップをさらに含み、 結合解除する前記サブプロセスが前記２段階待ち行列を
    使用するステップをさらに含む、請求項１１に記載のマ
    ルチスレッド・アプリケーションのパフォーマンスを強
    化するコンピュータ可読コード。
13. 【請求項１３】前記２段階待ち行列を使用して結合する
    前記サブプロセスが、 前記接続の最初のデータ・パケットが到着すると、各前
    記持続接続を前記第１の段階に移動させるサブプロセス
    と、 前記接続のデータを受け取ると各前記持続接続を前記第
    ２の段階から前記第１の段階に移動させるサブプロセス
    と、 前記第１の段階から前記持続接続をスケジュールするサ
    ブプロセスとをさらに含み、 前記２段階待ち行列を使用して結合解除する前記サブプ
    ロセスが、 前記選択された結合接続が遊休状態になると、前記結合
    接続のうちの選択された結合接続を前記第１の段階から
    前記第２の段階に移動させるサブプロセスと、 最大遊休期間を超えるとそれに応答して、前記第２の段
    階にある前記持続接続のうちの選択された持続接続を閉
    じるサブプロセスと、 前記結合解除された作業スレッドを、結合する前記サブ
    プロセスに使用可能にするサブプロセスとをさらに含
    む、請求項１２に記載のマルチスレッド・アプリケーシ
    ョンのパフォーマンスを強化するコンピュータ可読コー
    ド。
14. 【請求項１４】結合解除する前記サブプロセスが、 最大遊休接続数を超えるとそれに応答して、前記第２段
    階にある前記持続接続のうちのさらに選択された持続接
    続を閉じるサブプロセスをさらに含む、請求項１３に記
    載のマルチスレッド・アプリケーションのパフォーマン
    スを強化するコンピュータ可読コード。
15. 【請求項１５】ネットワークへの接続を有するコンピュ
    ーティング環境においてマルチスレッド・アプリケーシ
    ョンのパフォーマンスを強化するシステムであって、 接続を求める複数のクライアント要求と、 複数の作業スレッドと、 前記複数のクライアント要求を受け取る手段と、 前記作業スレッドのオーバースケジューリングを改善す
    るスケジューリング・ヒューリスティックを実施する手
    段とを含むシステム。
16. 【請求項１６】前記作業スレッドの第１のグループがア
    クティブ・スレッドであり、前記第１のグループが前記
    複数の作業スレッドのうちの変更可能な作業スレッドか
    ら成り、変更可能な数の前記変更可能な作業スレッドを
    有し、前記変更可能な数が少なくとも１であり、 スケジューリング・ヒューリスティックを実施する前記
    手段が、前記複数のクライアント要求のうちの１つまた
    は複数のクライアント要求から成る現行作業負荷に照ら
    して前記第１のグループ内の前記変更可能な数のバラン
    スをとる手段をさらに含む、請求項１５に記載のマルチ
    スレッド・アプリケーションのパフォーマンスを強化す
    るシステム。
17. 【請求項１７】バランスをとる前記手段が平均遅延の使
    用をさらに含む、請求項１６に記載のマルチスレッド・
    アプリケーションのパフォーマンスを強化するシステ
    ム。
18. 【請求項１８】バランスをとる前記手段が最大遅延の使
    用をさらに含む、請求項１７に記載のマルチスレッド・
    アプリケーションのパフォーマンスを強化するシステ
    ム。
19. 【請求項１９】前記平均遅延および前記最大遅延が構成
    パラメータである、請求項１８に記載のマルチスレッド
    ・アプリケーションのパフォーマンスを強化するシステ
    ム。
20. 【請求項２０】前記作業スレッドの第２のグループがブ
    ロック・スレッドであり、前記第２のグループが前記複
    数の作業スレッドのうちの前記第１のグループに入って
    いない作業スレッドから成り、 前記ブロック・スレッドが後入れ先出し待ち行列に格納
    される、請求項１６に記のマルチスレッド・アプリケー
    ションのパフォーマンスを強化するシステム。
21. 【請求項２１】ネットワークへの接続を有するコンピュ
    ーティング環境においてマルチスレッド・アプリケーシ
    ョンのパフォーマンスを強化するシステムであって、 各前記接続が受け入れられると、接続を保留接続待ち行
    列から第１の待ち行列に移動させる手段と、 前記接続の最初のデータ・パケットが到着すると、前記
    接続を前記第１の待ち行列から第２の待ち行列に移動さ
    せる手段と、 前記第２の待ち行列上の各前記接続に作業スレッドを割
    り当てる手段とを含むシステム。
22. 【請求項２２】ネットワークへの接続を有するコンピュ
    ーティング環境においてマルチスレッド・アプリケーシ
    ョンのパフォーマンスを強化するシステムであって、 複数の発生源から入力を受け取る手段と、 前記受け取った入力をスケジューリングのために単一の
    待ち行列にマージする手段とを含むシステム。
23. 【請求項２３】各前記接続が受け入れられると、接続を
    保留接続待ち行列から第１の待ち行列に移動させる手段
    と、 前記接続の最初のデータ・パケットが到着すると、前記
    各接続を前記第１の待ち行列から前記単一の待ち行列に
    移動させる手段と、 前記単一の待ち行列上の各前記接続に作業スレッドを割
    り当てる手段とをさらに含む、請求項２２に記載のマル
    チスレッド・アプリケーションのパフォーマンスを強化
    するシステム。
24. 【請求項２４】スケジューリングする前記手段が、 複数の作業スレッドのうちの変更可能な作業スレッドか
    ら成り、変更可能な数の前記変更可能な作業スレッドを
    有し、前記変更可能な数が少なくとも１であるアクティ
    ブ作業スレッドのグループと、 前記単一の待ち行列に格納された前記クライアント要求
    から成る現行作業負荷に照らして前記アクティブ・グル
    ープ内の前記変更可能な数のバランスをとるスケジュー
    リング・ヒューリスティックを実施する手段とをさらに
    含む、請求項２３に記載のマルチスレッド・アプリケー
    ションのパフォーマンスを強化するシステム。
25. 【請求項２５】ネットワークへの接続を有するコンピュ
    ーティング環境においてマルチスレッド・アプリケーシ
    ョンのパフォーマンスを強化するシステムであって、 複数の持続接続と、 複数の作業スレッドと、 前記持続接続のうちの選択された持続接続を前記作業ス
    レッドのうちの選択された作業スレッドに結合する手段
    であって、結合の実行の結果として結合接続が生じる手
    段と、 前記結合接続のうちの選択された結合接続を結合解除す
    る手段であって、結合解除の実行の結果として結合解除
    された作業スレッドが生じる手段とを含むシステム。
26. 【請求項２６】結合する前記手段が２段階待ち行列を使
    用するステップをさらに含み、 結合解除する前記手段が前記２段階待ち行列を使用する
    ステップをさらに含む、請求項２５に記載のマルチスレ
    ッド・アプリケーションのパフォーマンスを強化するシ
    ステム。
27. 【請求項２７】前記２段階待ち行列を使用して結合する
    前記手段が、 前記接続の最初のデータ・パケットが到着すると、各前
    記持続接続を前記第１の段階に移動させる手段と、 前記接続のデータを受け取ると各前記持続接続を前記第
    ２の段階から前記第１の段階に移動させる手段と、 前記第１の段階から前記持続接続をスケジュールする手
    段とをさらに含み、 前記２段階待ち行列を使用して結合解除する前記手段
    が、 前記選択された結合接続が遊休状態になると、前記結合
    接続のうちの選択された結合接続を前記第１の段階から
    前記第２の段階に移動させる手段と、 最大遊休期間を超えるとそれに応答して、前記第２の段
    階にある前記持続接続のうちの選択された持続接続を閉
    じる手段と、 前記結合解除された作業スレッドを、結合する前記手段
    に使用可能にする手段とをさらに含む、請求項２６に記
    載のマルチスレッド・アプリケーションのパフォーマン
    スを強化するシステム。
28. 【請求項２８】結合解除する前記手段が、 最大遊休接続数を超えるとそれに応答して、前記第２段
    階にある前記持続接続のうちのさらに選択された持続接
    続を閉じる手段をさらに含む、請求項２７に記載のマル
    チスレッド・アプリケーションのパフォーマンスを強化
    するシステム。
29. 【請求項２９】ネットワークへの接続を有するコンピュ
    ーティング環境においてマルチスレッド・アプリケーシ
    ョンのパフォーマンスを強化する方法であって、 接続を求める複数のクライアント要求を受け取るステッ
    プと、 前記複数のクライアント要求への複数の作業スレッドの
    オーバースケジューリングを改善するスケジューリング
    ・ヒューリスティックを実施するステップとを含む方
    法。
30. 【請求項３０】前記作業スレッドの第１のグループがア
    クティブ・スレッドであり、前記第１のグループが前記
    複数の作業スレッドのうちの変更可能な作業スレッドか
    ら成り、変更可能な数の前記変更可能な作業スレッドを
    有し、前記変更可能な数が少なくとも１であり、 スケジューリング・ヒューリスティックを実施する前記
    ステップが、前記複数のクライアント要求のうちの１つ
    または複数のクライアント要求から成る現行作業負荷に
    照らして前記第１のグループ内の前記変更可能な数のバ
    ランスをとるステップをさらに含む、請求項２９に記載
    のマルチスレッド・アプリケーションのパフォーマンス
    を強化する方法。
31. 【請求項３１】バランスをとる前記ステップが平均遅延
    の使用をさらに含む、請求項３０に記載のマルチスレッ
    ド・アプリケーションのパフォーマンスを強化する方
    法。
32. 【請求項３２】バランスをとる前記ステップが最大遅延
    の使用をさらに含む、請求項３１に記載のマルチスレッ
    ド・アプリケーションのパフォーマンスを強化する方
    法。
33. 【請求項３３】前記平均遅延および前記最大遅延が構成
    パラメータである、請求項３２に記載のマルチスレッド
    ・アプリケーションのパフォーマンスを強化する方法。
34. 【請求項３４】前記作業スレッドの第２のグループがブ
    ロック・スレッドであり、前記第２のグループが前記複
    数の作業スレッドのうちの前記第１のグループに入って
    いない作業スレッドから成り、 前記ブロック・スレッドが後入れ先出し待ち行列に格納
    される、請求項３０に記載のマルチスレッド・アプリケ
    ーションのパフォーマンスを強化する方法。
35. 【請求項３５】ネットワークへの接続を有するコンピュ
    ーティング環境においてマルチスレッド・アプリケーシ
    ョンのパフォーマンスを強化する方法であって、 各前記接続が受け入れられると、接続を保留接続待ち行
    列から第１の待ち行列に移動させるステップと、 前記接続の最初のデータ・パケットが到着すると、前記
    接続を前記第１の待ち行列から第２の待ち行列に移動さ
    せるステップと、 前記第２の待ち行列上の各前記接続に作業スレッドを割
    り当てるステップとを含む方法。
36. 【請求項３６】ネットワークへの接続を有するコンピュ
    ーティング環境においてマルチスレッド・アプリケーシ
    ョンのパフォーマンスを強化する方法であって、 複数の発生源から入力を受け取るステップと、 前記受け取った入力をスケジューリングのために単一の
    待ち行列にマージするステップとを含む方法。
37. 【請求項３７】各前記接続が受け入れられると、接続を
    保留接続待ち行列から第１の待ち行列に移動させるステ
    ップと、 前記接続の最初のデータ・パケットが到着すると、前記
    接続を前記第１の待ち行列から前記単一の待ち行列に移
    動させるステップと、 前記単一の待ち行列上の各前記接続に作業スレッドを割
    り当てるステップとをさらに含む、請求項３６に記載の
    マルチスレッド・アプリケーションのパフォーマンスを
    強化する方法。
38. 【請求項３８】複数の作業スレッドのうちの変更可能な
    作業スレッドから成り、変更可能な数の前記変更可能な
    作業スレッドを有し、前記変更可能な数が少なくとも１
    であるアクティブ作業スレッドのグループをさらに含
    み、 前記スケジューリング・ステップが、 前記単一の待ち行列に格納された前記クライアント要求
    から成る現行作業負荷に照らして前記アクティブ・グル
    ープ内の前記変更可能な数のバランスをとるスケジュー
    リング・ヒューリスティックを実施するステップとをさ
    らに含む、請求項３７に記載のマルチスレッド・アプリ
    ケーションのパフォーマンスを強化する方法。
39. 【請求項３９】ネットワークへの接続を有するコンピュ
    ーティング環境においてマルチスレッド・アプリケーシ
    ョンのパフォーマンスを強化する方法であって、 複数の持続接続のうちの選択された持続接続を複数の作
    業スレッドのうちの選択された作業スレッドに結合する
    ステップであって、結合ステップの実行の結果として結
    合接続が生じるステップと、 前記結合接続のうちの選択された結合接続を結合解除す
    る手段であって、結合解除ステップの実行の結果として
    結合解除された作業スレッドが生じるステップとを含む
    方法。
40. 【請求項４０】前記結合ステップが２段階待ち行列を使
    用するステップをさらに含み、 前記結合解除ステップが前記２段階待ち行列を使用する
    ステップをさらに含む、請求項３９に記載のマルチスレ
    ッド・アプリケーションのパフォーマンスを強化する方
    法。
41. 【請求項４１】前記２段階待ち行列を使用して結合する
    前記ステップが、 前記持続接続の最初のデータ・パケットが到着すると、
    各前記持続接続を前記第１の段階に移動させるステップ
    と、 前記持続接続のデータを受け取ると各前記持続接続を前
    記第２の段階から前記第１の段階に移動させるステップ
    と、 前記第１の段階から前記持続接続をスケジュールするス
    テップとをさらに含み、 前記２段階待ち行列を使用して結合解除する前記ステッ
    プが、 前記選択された結合接続が遊休状態になると、前記結合
    接続のうちの選択された結合接続を前記第１の段階から
    前記第２の段階に移動させるステップと、 最大遊休期間を超えるとそれに応答して、前記第２の段
    階にある前記持続接続のうちの選択された持続接続を閉
    じるステップと、 前記結合解除された作業スレッドを、結合する前記ステ
    ップに使用可能にするステップとをさらに含む、請求項
    ４０に記載のマルチスレッド・アプリケーションのパフ
    ォーマンスを強化する方法。
42. 【請求項４２】前記結合解除ステップが、 最大遊休接続数を超えるとそれに応答して、前記第２段
    階にある前記持続接続のうちのさらに選択された持続接
    続を閉じるステップをさらに含む、請求項４１に記載の
    マルチスレッド・アプリケーションのパフォーマンスを
    強化する方法。