JP3555846B2 - スレッド・サーバのパフォーマンス強化方法および装置 - Google Patents
スレッド・サーバのパフォーマンス強化方法および装置 Download PDFInfo
- Publication number
- JP3555846B2 JP3555846B2 JP14109999A JP14109999A JP3555846B2 JP 3555846 B2 JP3555846 B2 JP 3555846B2 JP 14109999 A JP14109999 A JP 14109999A JP 14109999 A JP14109999 A JP 14109999A JP 3555846 B2 JP3555846 B2 JP 3555846B2
- Authority
- JP
- Japan
- Prior art keywords
- connection
- queue
- connections
- thread
- threads
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Computer And Data Communications (AREA)
- Multi Processors (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はコンピュータのパフォーマンスに関し、より詳細には、マルチスレッド・サーバ・アプリケーションを実行するコンピュータのパフォーマンスを強化する技法、システム、およびコンピュータ・プログラムを対象とする。使用可能なスレッドの数を最適化するようにスケジューリング・ヒューリスティック（ｈｅｕｒｉｓｔｉｃ）を規定する。データが送信中でない場合に接続にスレッドが割り当てられないように保証するために、受動ソケットのための２段階待ち行列を規定する。複数の入力源からの入力をマージし、マージされた入力をスケジューリングに使用できるようにする、新規なタイプのソケットを規定する。持続接続を使用する場合に着信要求へのスレッドの割当てを最適化する関数を規定する。
【０００２】
【従来の技術】
マルチスレッド・アプリケーションとは、複数のスレッドによる並列実行をサポートするソフトウェア・プログラム、すなわち再入可能プログラムである。スレッドとは、そのようなプログラム内の単一の実行経路である。スレッドは、使用可能なスレッドにタイム・スライスを割り振るオペレーティング・システム・スケジューラの制御下で、１つのプロセス内で順次に実行される。プロセスは、実行中のプログラムの１つのインスタンスである。オペレーティング・システムは各並列スレッドに関する情報を維持し、この情報は、各タイム・スライスでスレッドがＣＰＵを共用することができるようにするが、それにもかかわらず互いに区別可能であるようにする。たとえば、スレッドごとに異なる現行命令ポインタが維持され、レジスタの値も同様に維持される。明確な状態情報を維持することによって、再入可能プログラム全体の各実行経路は、別々のプログラムが実行されているかのように独立して機能することができる。オープンＩ／Ｏ（入出力）ストリームのための仮想メモリやファイル記述子など、その他の状態情報は、実行効率向上のためにプロセス内のすべてのスレッドによって共用される。ＳＭＰ（対称マルチプロセッサ）マシン上では、これらのスレッドのいくつかを同時に実行することができる。再入可能プログラムは、複数の実行経路でのこれらの共用資源を同期させる機構を含むことができる。
【０００３】
インターネット環境で稼働しているサーバ上では、マルチスレッド・アプリケーションがますます普及しつつある。インターネットは、世界中の場所から、ネットワークとして相互接続された膨大なコンピュータ資源の集まりである。インターネットは、毎日数百万人の人々によって使用されている。ワールド・ワイド・ウェブ（本明細書では「ウェブ」と呼ぶ）は、インターネットのうち、メッセージを交換するためのプロトコルとしてＨｙｐｅｒＴｅｘｔ転送プロトコル（「ＨＴＴＰ」）を使用する部分である。（あるいは、「ＨＴＴＰＳ」プロトコルを使用することができ、このプロトコルはＨＴＴＰのセキュリティ強化版である。）
【０００４】
インターネットのユーザは一般に、インターネット・サービス・プロバイダ（ＩＳＰ）のサービスを介してネットワーク接続を確立することによってインターネットにアクセスし、使用する。ＩＳＰは、コンピュータ・ユーザが、コンピュータ・モデム（または衛星伝送などのその他の接続機構）を使用して電話番号をダイヤルし、それによってＩＳＰが所有または管理する遠隔コンピュータとの接続を確立できるようにする。その後で、この遠隔コンピュータはユーザのコンピュータにサービスを提供する。典型的なサービスとしては、インターネットの相互接続されたコンピュータ全体でユーザが求める項目を検索する検索機能、検索機能を使用して探し出された情報を表示するブラウズ機能、ユーザが他のコンピュータ・ユーザとの間でメール・メッセージの送受信を行うことができる電子メール機能の提供などがある。
【０００５】
ウェブ環境で作業するユーザは、ユーザのコンピュータ上で実行され、情報を求める要求の作成と送信を行い、その結果を見ることができるようにするソフトウェアを持つ。これらの機能は、一般には「ウェブ・ブラウザ」または「ブラウザ」と呼ばれるものとして組み合わされている。ユーザがブラウザを使用して要求を作成した後、その要求メッセージは処理のためにインターネットに送出される。要求メッセージの宛先は、インターネットのネットワーク内の相互接続されたコンピュータの１つである。そのコンピュータは、メッセージを受け取り、ユーザの要求を満たすデータの検索を試み、ユーザのブラウザを使用して表示するためにそのデータを形式設定し、形式設定された応答をユーザのコンピュータ上で実行されているブラウザ・ソフトウェアに返す。同じコンピュータに多くのクライアントがアクセスすることができるようにするために、クライアントの要求の受け取りや処理を行うコンピュータは一般にはマルチスレッド・アプリケーションを実行する。これで、このアプリケーションの同じインスタンスが複数の要求を処理することができ、その際、別々のスレッドを使用して１つのクライアントの要求が他のクライアントの要求から分離される。
【０００６】
これは、クライアント／サーバ・コンピューティング・モデルの一例であり、ユーザが情報を要求するマシンはクライアントと呼ばれ、その情報を探し出してクライアントに返すコンピュータがサーバである。ウェブ環境では、サーバは「ウェブ・サーバ」と呼ばれる。クライアント／サーバ・モデルは、「三層アーキテクチャ」と呼ばれるものに拡張することができる。このアーキテクチャは、ウェブ・サーバを中央層に配置し、それに付加された層は典型的には、クライアントの要求を処理するタスクの一部としてウェブ・サーバがアクセスすることができる情報のデータベースを表す。この三層アーキテクチャは、多くのクライアント要求が単に静的データの検索と返送を求めているだけでなく、返されるデータを動的に作成するためにクライアントの要求を処理するアプリケーション・プログラムを必要としていることを認識している。このアーキテクチャでは、ウェブ・サーバは「アプリケーション・サーバ」とも呼ばれることがある。サーバがマルチスレッド・アプリケーション・プログラムを実行する場合、サーバを「スレッド・サーバ」または「マルチスレッド・サーバ」と呼ぶこともある。
【０００７】
サーバは、スレッドを処理する役割を負う。本明細書では、作成されたが廃棄されていないスレッドのセットをスレッドの「プール」と呼ぶ。プールのために作成されるスレッドの数は一般にはユーザ（たとえばシステム管理者）が、サーバを初期設定するときに構成パラメータとして指定する。一般には、このパラメータは、予想最大接続負荷（すなわち着信クライアント要求の最大数）を扱うために、サーバが多数のスレッドを作成するように設定される。
【０００８】
ＴＣＰ／ＩＰプロトコル（転送制御プロトコル／インターネット・プロトコル）が、ネットワークでデータを伝送する事実上の標準方法であり、インターネット伝送で広く使用されている。ＴＣＰ／ＩＰは、２つのコンピュータ間でデータを交換するために２つの「ソケット」間の接続という概念を使用し、ソケットはそれらコンピュータのうちの一方のコンピュータを識別するアドレスと、そのコンピュータ上の特定のプロセスを識別するポート番号とから成る。ポート番号によって識別されたプロセスは、そのソケットのために着信データを受け取るプロセスである。ソケットは、典型的にはその接続を使用する２つのコンピュータの各コンピュータによって待ち行列として実施され、接続でデータを送信するコンピュータは作成したデータを送信のために接続待ち行列に入れ、接続でデータを受信するコンピュータはそのデータを処理するために着信データを待ち行列に入れる。
【０００９】
いくつかのクライアントから要求を受け取るアプリケーションの場合、保留クライアント接続の待ち行列を表す特別な「受動」ソケットが作成される。このアプリケーションのサービスを必要とする各クライアントは、同じサーバ・ポート番号を使用して、この受動ソケットへの接続を要求する（ただし、セキュア・ソケット層（「ＳＳＲ」）などの保護プロトコルを使用する通信は一般には、同じアプリケーションに、セキュリティなしの「通常の」通信とは異なるポート番号を使用する。）サーバは、この特別な受動ソケットから保留クライアント接続を受け入れる。これによって新しいサーバ・ソケットが作成され、次に、そのソケットが処理のために使用可能なスレッドに割り当てられる。
【００１０】
この環境で稼働するマルチスレッド・サーバ・アプリケーションを実施する現行の手法にはいくつかの欠点があり、その結果、そのようなアプリケーションの最適パフォーマンスが満たされないことになる。数千または数百万もの１日当たりの「ヒット」（すなわち処理を求めるクライアント要求）を受け取ることがある、ウェブ・サーバ上で稼働するアプリケーションなどのアプリケーションが普及するにつれて、パフォーマンスは重要な問題になる。本発明はこのようなパフォーマンス上の問題に対処する。
【００１１】
既存のサーバ実装では、別個の「ディスパッチャ」スレッドが、所与のアプリケーションのための受動ソケットに対する着信接続要求を受け取る待ち行列を監視する役割を果たす。ディスパッチを行うスレッドと、作業のディスパッチ先のスレッドとを区別するために、本明細書では後者を「作業スレッド」と呼ぶ。ディスパッチャ・スレッドは、各作業スレッドの状況を追跡し、各着信要求を使用可能なスレッドに割り当てる。「使用可能な」スレッドとは、実行可能であるが、現在割り当てられている作業がないスレッドである。この状態のスレッドを「遊休スレッド」と呼ぶこともある。遊休スレッドに作業が割り当てられると、そのスレッドはもはや遊休とはみなされず、その現在の作業要求が完了するまではそれ以上の作業は割り当てられない。ＳＭＰマシン上では、ディスパッチャ・スレッドは、作業スレッドがすべてのプロセッサを使用中にしておくのに十分な速さでスケジュールされるのを妨げるボトルネックになる可能性がある。
【００１２】
あるいは、ディスパッチャ・スレッドを使用せずにサーバを実施することもできる。この手法では、スレッドは受動ソケット待ち行列を調べて接続要求がないかどうかを判断する役割を負う。各スレッドは処理していた作業要求を完了すると、待ち行列で次の要求を探す。要求が待機中である場合、スレッドはその要求を待ち行列から取り出し、その処理を開始する。待機中の要求がない場合、スレッドは遊休スレッドになる。その後、遊休スレッドは「スリープ」することがあり、その場合、システム・タイマを使用してそのスレッドを所定期間待機させた後、「覚醒」させて作業が到着していないかどうか待ち行列を再度調べさせる。これは「ポーリング」モードと呼ばれる。ポーリング・モードに代わるより一般的な代替手法は、イベント・ドリブン割込みを使用することである。この手法では、スレッドは遊休状態になり、作業が到着すると呼び出されてスレッドに再度アクティブになるように通知するシステム割込みを待つ。遊休状態になることを「ブロック」と呼び、ブロック状態から覚醒されること（すなわち割込みを受け取ること）を「アンブロック」と呼ぶ。
【００１３】
イベント・ドリブン割込みを使用する現行のサーバ実装では、各作業スレッドは現行要求を完了すると、受動ソケット待ち行列を調べて要求が待機していないかどうかを調べる。待機している要求がない場合、スレッドはブロックする。所与の時点で任意の数のスレッドをブロックすることができる。次の着信要求が到着すると、スレッドを覚醒させるイベントが生成される。ブロックされた各作業スレッドはこの割込みを受け取り、したがって各ブロックはアンブロックして、待ち行列から要求の取り出しを試みる。着信要求を受け取ることができるのは最初の作業スレッドだけであり、他のスレッドは再度待ち行列が空であるのを認めて、ブロック状態に戻る。しかし、この割込み生成手法を変える新しいＡＰＩ（アプリケーション・プログラミング・インタフェース）が開発中である。このＡＰＩを本明細書では「アクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）と呼ぶ。アクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）ＡＰＩによると、着信要求が到着すると、単一のブロックスレッドに対してのみ割込みが生成される。
【００１４】
この新しい割込み手法によって、本明細書で扱う第１のパフォーマンス問題が生じ、これを本明細書では「オーバースケジューリング」と呼ぶ。着信接続の数がスレッド・プール内のスレッドの数より少ない場合（すなわち、接続負荷がサーバの構成最大値よりも小さい場合）、その作業負荷を処理するために使用されるプール内のスレッドが多すぎる。言い換えると、スレッド・プールはオーバースケジューリングされている。これによって資源の使用効率が悪くなる。
【００１５】
以下の事例で、オーバースケジューリング問題を例示する。すべてのスレッドがブロックされ、接続要求を待っているとする。第１の要求が到着する。システム・スケジューラはこれらのブロック・スレッドの１つを覚醒させ、着信要求をそのスレッドに割り当てる。そのスレッドは要求の処理を開始する。次に、第２の要求が到着し、そのため、スケジューラは第２のブロック・スレッドを覚醒させ、この新しい要求をそのスレッドに割り当てる。第２のスレッドはこの新しい要求の処理を開始する。第１のスレッドは作業していた要求を完了し、受動ソケットを調べる。受動ソケットに新しい接続要求がないことがわかり、第１のスレッドはブロックする。２つの要求について、スケジューラは２つのスレッドを覚醒させている。
【００１６】
しかし、第２の要求が到着した時点で、第１のスレッドはその第１の要求の処理をほとんど完了しようとしている場合がある。その場合、第２のスレッドを覚醒させるのではなく、第１のスレッドが完了し、受動ソケットを調べたときに第２の要求を見つけるのを待つ方がより効率的であろう。スケジューラが各着信要求ごとに新しいスレッドを覚醒させた場合（すなわちスレッドをオーバースケジュールした場合）、要求を処理するスレッドは、その現行要求を完了して別の要求がないか調べたときに着信接続待ち行列が空であることを見いだすことが確実である。ブロック操作とアンブロック操作の繰り返しは、要求を処理するための全体的パス長の点で不経済である。スレッドがブロックすると、スケジューラはそのスレッドのコンテキスト情報を保管し、スレッドは「実行可能」状態から「ブロック」状態に移行する。アンブロック操作には、割込み処理に伴うかなりのオーバーヘッドを要する。
【００１７】
オーバースケジューリング中にシステムのパフォーマンスに及ぼす他の影響は、メモリ・ページング機構によるものである。スレッドは実行されると記憶情報を参照する。その情報は処理するためにメモリに入っていなければならない。まだメモリに入っていない場合はページインされる。一般に、１つのページをページインするための空きを作るために他のページがページアウトされなければならない。ページング機構は、アルゴリズムを使用してどのページをページアウトするかを決定する。通例、最も長い期間使用されなかった（ＬＲＵ）ページがページアウトのために選択される。オーバースケジューリングが起こると、各スレッドは実行後にブロックし、したがってそのページは使用されなくなる。スレッドがブロックする期間が長いほど、そのページがページアウトされる可能性が高くなる。その後、スレッドが覚醒されると、そのページをページインし戻さなければならず、それによって別のスレッドのページがページアウトされる。これらのページング操作によって生じる余分な処理によって、着信要求の処理効率が低下する。
【００１８】
さらに、空であることがわかるだけの受動ソケットを調べる操作は無駄な操作であり、それによってブロック・スレッドの効率が低下する。
【００１９】
本明細書では第２のパフォーマンス問題を「複数入力源」問題と呼ぶ。前述のように、サーバ・アプリケーションは１つの受動ソケットで非セキュア接続要求を受け取り、もう一つの受動ソケットでセキュア接続要求を受け取ることがある。これは、たとえばオンライン・ショッピング・アプリケーションの場合である。クライアント買物客は、オンライン・カタログから入手可能な製品を表示するように要求し、最終的に注文するいくつかの製品を選択する。情報の表示を求めるこのような要求は、セキュア接続に付随する付加的な処理オーバーヘッドを生じさせないように、通常は非セキュア接続で送信される。買物客は注文を行うときに、クレジット・カードによる支払いを選択し、自分のクレジット・カード情報を電子的に発信することがある。買物客の情報を保護するために、買物客のトランザクションのこの部分はセキュア接続で送信される。一般には、販売業者はショッピング・トランザクションの全シーケンスに同じサーバ・アプリケーションを使用する。したがって、アプリケーションは、２つの受動ソケットから非セキュア接続要求とセキュア接続要求の両方を受け入れることができなければならない。
【００２０】
ウェブ・サーバが複数のホスト名をホストしており、各ホスト名がそれ自体のＩＰアドレスを有する場合、各ホスト名に１対の受動ソケットが使用される。したがって、所与のアプリケーションが多くの受動ソケットに到着する接続を受け入れる必要がある場合がある。このようなソケットのセットを本明細書では「複数入力源」と呼ぶ。
【００２１】
ソケット待ち行列管理の前述のディスパッチャ・スレッド手法では、各受動ソケットに１つのディスパッチャ（または「アクセプタ」）スレッドが割り振られる。着信接続要求が到着すると、これらのディスパッチャはスレッド・プールから使用可能な作業スレッドを見つけ、そのスレッドに着信要求を割り当てる役割を果たす。ディスパッチャ・スレッドの数が増えるにつれて、作業スレッドの共用プールの管理をめぐるそれらのスレッド間の衝突も増える。
【００２２】
ディスパッチャ・スレッドを使用せず、着信待ち行列を調べる役割が作業スレッドにある場合、スレッド・プールは受動ソケット待ち行列のセット全体で静的に区分化されることになる。特定の時点での作業負荷と、それに対応する受動ソケット間での要求の分配は予測不能なため、この静的区分化は最適状態を下回る可能性がきわめて高くなる。１つの待ち行列のスレッドは、その作業負荷を処理するには少な過ぎ、別の待ち行列は多過ぎる場合がある。使用可能なスレッドが少なすぎる場合、着信要求は待ち行列上で待たなければならず、その間に使用可能なシステム能力が遊休状態のままになる。着信要求には通常、応答を待っている人間がいるため、応答を処理する際のこのタイプの遅延は、最大限回避しなければならない。使用可能なスレッドが多すぎる場合、オーバースケジューリングについて前述した非効率が生じる。受動ソケット間での作業の現在の分配に基づいて作業スレッドのプールを分割するより動的な区分化は、受動ソケット上の接続待ち行列内項目数がサーバ・アプリケーションには入手できないために、サーバ・アプリケーションによって行うことはできない。
【００２３】
第３のパフォーマンス問題を、本明細書では「持続接続スケジューリング」と呼ぶ。持続接続機能は、ＨＴＴＰの１．１版で導入され、クライアントとサーバの間の要求（およびそれに対応する応答）のストリームに単一の接続を使用できるようにする。持続接続は、一連の要求の処理に付随するオーバーヘッドの量を少なくし、それによって普通なら個別要求ごとに必要になるＴＣＰ接続のセットアップとティアダウンのコストをなくし、１回のセットアップと１回のティアダウンを使用することを意図したものである。結果は、クライアントのもとで生成された各要求が新しい接続を生み出し、それはその要求の持続時間の間だけ持続した。接続をセットアップするのにメッセージの交換が必要であり、それを閉じるのにもう一度交換が必要だった。多くのウェブ・ベースのアプリケーションは、ユーザに対してきわめて複雑な情報ページを表示し、各ページでネットワークを介していくつかの別々の要求を送信する必要がある場合がある。たとえば、ページ上の各グラフィック画像ごとに１つの要求を送信し、静的テキストのために別の要求、動的生成テキストのためにさらに他の要求が送信される場合がある。したがって、単一のウェブ・ページの表示に、持続接続を使用すれば相当量の処理オーバーヘッドが節減される。すなわち、２つのコンピュータ間で使用するために１つの接続を設定した後は、クライアントは、サーバがそれらの要求の各要求を受け取ったという肯定応答を待つために停止せずに、その接続を介して任意の数の要求を送信することができる。これを要求の送信の「ストリーム」モードと呼ぶ。サーバはストリームのすべての要求に順に応答する必要がある。クライアントまたはサーバは、プロトコル・エラーを生じさせることなく、任意の要求境界で接続を終了することができる。
【００２４】
実際には、ユーザが異なるウェブ・サイトに移動する（異なるサーバ・ソケット・アドレスと、それに応じて新しい接続が必要になる）まで、ブラウザ内のクライアント・ソフトウェアがこの持続接続を開いたままに維持する。開いた持続接続で最後の要求が送信されてからユーザが新しいサイトに移動するまでの間にある程度の時間が経過することがある。既存の接続のソケットには、この時間中、着信データがまったくなくなる。サーバ・アプリケーションは、ソケットがこの特定の状態（すなわち、クライアントはデータの送信を終了しているが、接続はまだ開いている状態）であるかどうか、またはクライアントが次の要求をまだ生成していないだけなのかどうかを知ることができない。したがって、このタイプの接続の次の要求の読取りに関してサーバ側に不確定性が存在する。待ち行列にデータがある可能性もあり、データがまもなく着信するか、またはデータがしばらくの間着信しない可能性もある。しかも、これらのデータ・パケットのいずれかに、その接続で進行中の作業を求めるクライアント要求や、ソケットを閉じる要求が入っている可能性もある。
【００２５】
データが間もなく着信する場合は、その作業スレッドとの接続を結合した状態に維持し、作業スレッドが一時的に遊休状態になるようにするのが最も効率的である。しかし、データが着信するまで長い遅延時間がある場合は、作業スレッドをその接続から結合解除し、その作業スレッドを別の要求に割り当てた方がより効率的である。その後、その結合解除された接続を求める次の要求が着信した場合、その処理を続けるためにスレッド（元々結合されていたスレッドとは異なるスレッドである可能性が最も高い）を割り当てる。どの接続が所与の要求間での遅延が長くなるか、そのような遅延がいつ発生するか、または遅延がどれだけ長く続くかを前もって知る方法がない。作業スレッドのプールを、新しい接続を受け入れるスレッドと、遅延後に再アクティブ化する接続を処理するスレッドとを区分化する試みは、複数入力源問題に関して前述したのと同様の問題を生じさせる。すなわち、いずれかの区分に割り当てられるスレッドが多すぎたり少なすぎたりすることによって、非効率になる。
【００２６】
したがって、マルチスレッド・サーバ・アプリケーションの現行の実施システムにおけるこれらの非効率問題を克服する技法が必要である。本提案の技法は、使用可能スレッドの数を最適化するスケジューリング・ヒューリスティックと、受動ソケットのための２段階待ち行列と、複数の入力源からの入力をマージし、そのマージされた入力をスケジューリングに使用できるようにする新しいタイプのソケットと、持続接続を使用する場合に着信要求へのスレッドの割当てを最適化する関数とを規定する。
【００２７】
【発明が解決しようとする課題】
本発明の目的は、マルチスレッド・サーバのパフォーマンスを強化する技法を提供することである。
【００２８】
本発明の他の目的は、作業スレッドに対する要求のスケジューリングを最適化することによって上記のパフォーマンス強化を実現する技法を提供することである。
【００２９】
本発明の他の目的は、使用可能スレッドの数を最適化するスケジューリング・ヒューリスティックを規定することによって、上記の最適化を実現することである。
【００３０】
本発明の他の目的は、複数の入力源からの入力をマージする新しいタイプのソケットを規定し、そのマージされた入力をスケジューリングに使用できるようにすることによって上記の最適化を実現することである。
【００３１】
本発明の他の目的は、持続接続を使用する場合に着信要求へのスレッドの割当てを最適化する関数を規定することによって、上記の最適化を実現することである。
【００３２】
本発明のその他の目的および利点は、一部は以下の説明、一部は図面に記載され、その説明を読めば明らかになるであろうし、本発明の実施によってわかるであろう。
【００３３】
【課題を解決するための手段】
上記の目的を達成するためと、本明細書で概説する本発明の目的により、本発明は、ネットワークへの接続を有するコンピューティング環境において使用し、マルチスレッド・アプリケーションのパフォーマンスを強化するシステム、方法、およびソフトウェア・プロセスを実施するコンピュータ可読コードであって、接続を求める複数のクライアント要求と、複数の作業スレッドと、前記複数のクライアント要求を受け取るサブプロセスと、前記作業スレッドのオーバースケジューリングを改善するスケジューリング・ヒューリスティックを実施するサブプロセスとを含むシステム、方法、およびコンピュータ可読コードを提供する。さらに、前記作業スレッドの第１のグループはアクティブ・スレッドであり、前記第１のグループは、前記複数の作業スレッドのうちの変更可能な作業スレッドから成り、変更可能な数の前記変更可能スレッドを有し、前記変更可能な数は少なくとも１であり、スケジューリング・ヒューリスティックを実施する前記サブプロセスは、前記第１のグループにおける前記変更可能な数を、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らしてバランスをとるサブプロセスをさらに含む。バランスをとる前記サブプロセスは、平均遅延と、最大遅延の使用も含むことができる。前記平均遅延と前記最大遅延は構成パラメータであることが好ましい。作業スレッドの前記第１のグループに加えて、ブロック・スレッドであり、後入れ先出し待ち行列に格納される前記作業スレッドの第２のグループも存在することができる（前記第２のグループは、前記複数の作業スレッドのうち前記第１のグループに入っていない作業スレッドから成る）。さらに、本発明は、マルチスレッド・アプリケーションのパフォーマンスを強化するシステム、方法、およびコンピュータ可読コードであって、各前記接続が受け入れられる場合に保留接続待ち行列から接続を第１の待ち行列に移動させるサブプロセスと、前記接続のための最初のデータ・パケットが着信すると前記第１の待ち行列から各前記接続を第２の待ち行列に移動させるサブプロセスと、前記第２の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとを含む、システム、方法、およびコンピュータ可読コードを提供する。さらに、本発明は、マルチスレッド・アプリのパフォーマンスを強化するシステム、方法、およびコンピュータ可読コードであって、複数の入力源から入力を受け取るサブプロセスと、受け取った前記入力をスケジューリングのために単一の待ち行列上にマージするサブプロセスとを含む、システム、方法、およびコンピュータ可読コードを提供する。これは、各前記接続が受け入れられる場合、保留接続待ち行列から接続を第１の待ち行列に移動させるサブプロセスと、前記接続のための最初のデータ・パケットが着信すると各前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるサブプロセスと、前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとをさらに含むことが好ましい。スケジューリングする前記サブプロセスは、複数の作業スレッドのうちの変更可能な作業スレッドから成り、少なくとも１である変更可能な数の前記変更可能作業スレッドを有するアクティブ作業スレッドのグループと、前記単一待ち行列上に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ・グループ内の前記変更可能数のバランスをとるスケジューリング・ヒューリスティックを実施するサブプロセスとをさらに含むことが好ましい。さらに、本発明は、マルチスレッド・アプリケーションのパフォーマンスを強化するシステム、方法、およびコンピュータ可読コードであって、複数の持続接続と、複数の作業スレッドと、前記持続接続のうちの選択された持続接続を前記作業スレッドのうちの選択された作業スレッドに結合するサブプロセスであって、その実行の結果として結合された接続ができるサブプロセスと、前記結合された接続のうちの選択された接続を結合解除するサブプロセスであって、その実行の結果として作業スレッドが結合解除されるサブプロセスとを含む、システム、方法、およびコンピュータ可読コードを提供する。結合する前記サブプロセスは、２段階待ち行列の使用をさらに含み、結合解除する前記サブプロセスは前記２段階待ち行列の使用をさらに含むことが好ましい。前記２段階待ち行列を使用して結合する前記サブプロセスは、前記接続のために最初のデータ・パケットが着信すると各前記持続接続を前記第１の段階に移動させるサブプロセスと、前記接続のためにデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させるサブプロセスと、前記第１の段階から前記持続接続をスケジューリングするサブプロセスとをさらに含み、前記２段階待ち行列を使用して結合解除する前記サブプロセスは、選択された前記結合接続が遊休状態になると、前記結合された接続のうちの選択された接続を前記第１の段階から前記第２の段階に移動させるサブプロセスと、最大遊休期間を超えるとそれに応答して、前記第２の段階内の前記持続接続のうちの選択された持続接続を閉じるサブプロセスと、結合解除された前記作業スレッドを前記結合サブプロセスに使用することができるようにするサブプロセスとをさらに含む。結合解除する前記サブプロセスは、最大遊休接続数を超えるとそれに応答して、前記第２の段階内の前記持続接続のうちのさらに選択された持続接続を閉じるサブプロセスをさらに含むことが好ましい。
【００３４】
【発明の実施の形態】
図１に、本発明を実施することができる代表的なワークステーション・ハードウェア環境を示す。図１の環境は、関連する周辺装置を含むパーソナル・コンピュータなどの代表的なコンピュータまたはインテリジェント・ワークステーション１０を含む。あるいは、ワークステーション１０は、ネットワーク環境におけるサーバとすることもできる。ワークステーション１０は、マイクロプロセッサ１２と、周知の技法によりマイクロプロセッサ１２とワークステーション１０の構成要素とを接続し、それらの間の通信を可能にするバス１４とを含む。ワークステーション１０は、典型的には、バス１４を介してマイクロプロセッサ１２を、キーボード１８、マウス２０、またはタッチ・センシティブ画面、ディジタイズ入力パッドなどの任意のユーザ・インタフェース装置とすることができるその他のインタフェース装置２２など、１つまたは複数のインタフェース装置と接続するユーザ・インタフェース・アダプタ１６を含む。バス１４は、ディスプレイ・アダプタ２６を介してＬＣＤ画面またはモニタなどの表示装置２４もマイクロプロセッサ１２に接続する。また、バス１４はマイクロプロセッサ１２を、メモリ２８およびハード・ドライブ、ディスケット・ドライブ、テープ・ドライブなどの長期記憶域３０にも接続する。
【００３５】
ワークステーション１０は、通信チャネル３２を介して他のコンピュータまたはコンピュータのネットワークと通信する。ワークステーション１０は、ローカル・エリア・ネットワーク（ＬＡＮ）やワイド・エリア・ネットワーク内などの他のコンピュータと関連づけることができ、あるいはワークステーション１０は、他のコンピュータなどとのクライアント／サーバ構成におけるクライアントとすることもできる。これらのすべての構成と、適切な通信ハードウェアおよびソフトウェアは、当技術分野で周知である。
【００３６】
図２に、本発明を実施することができるデータ処理ネットワーク４０を示す。データ処理ネットワーク４０は、ＬＡＮ４２および４４を含む複数の個別ネットワークを含み、各ネットワークは複数の個別のワークステーション１０を含む。あるいは、当業者ならわかるように、ＬＡＮはホスト・プロセッサに結合された複数のインテリジェント・ワークステーションを含むこともできる。
【００３７】
図２を参照すると、データ処理ネットワーク４０は、好ましくは通信リンク４８を使用してＬＡＮ４４に結合することができるメインフレーム・コンピュータ４６などの、複数のメインフレーム・コンピュータまたはサーバも含むことができる。メインフレーム・コンピュータ４６は、ＩＢＭが販売するエンタープライズ・システム・アーキテクチャ／３７０（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍｓ Ａｒｃｈｉｔｅｃｔｕｒｅ／３７０）またはエンタープライズ・システム・アーキテクチャ／３９０（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ／３９０）コンピュータ、または他の任意のタイプのメインフレーム・コンピュータを使用して実施することができる。応用分野によっては、アプリケーション・システム／４００（Ａｐｐｌｉｃａｔｉｏｎ Ｓｙｓｔｅｍ／４００）（ＡＳ／４００とも呼ぶ）などの中規模コンピュータも使用可能である。「エンタープライズ・システム・アーキテクチャ／３７０（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ／３７０）」はＩＢＭの商標である。「エンタープライズ・システム・アーキテクチャ／３９０（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ／３９０）」、「アプリケーション・システム／４００（Ａｐｐｌｉｃａｔｉｏｎ Ｓｙｓｔｅｍ／４００）」、および「ＡＳ／４００」はＩＢＭの登録商標である。
【００３８】
メインフレーム・コンピュータ４６は、ＬＡＮ４４の遠隔記憶域として機能する記憶装置５０にも結合することができる。同様に、ＬＡＮ４４は、通信リンク５２に結合することができ、サブシステム制御装置／通信コントローラ５４および通信リンク５６を介してゲートウェイ・サーバ５８に結合することができる。ゲートウェイ・サーバ５８は、ＬＡＮ４２をＬＡＮ４４とリンクさせる役割を果たす個別コンピュータまたはインテリジェント・ワークステーションであることが好ましい。
【００３９】
当業者なら、メインフレーム・コンピュータ４６はＬＡＮ４４から地理的に遠距離に配置することができ、同様にＬＡＮ４４はＬＡＮ４２から遠距離に配置することができることがわかるであろう。たとえば、ＬＡＮ４２を米国カリフォルニア州に配置し、ＬＡＮ４４をテキサス州に配置し、メインフレーム・コンピュータ４６をニューヨークに配置することができる。
【００４０】
本発明を実施するソフトウェア・プログラミング・コードは、典型的には、クライアント／サーバ環境または三層環境におけるサーバ４６などのサーバにインストールされ、サーバ４６はワークステーション１０などのコンピュータを有するユーザから送られる要求を処理する。このコードは、典型的にはサーバ・メモリ２８内で実施され、バス１４を使用してマイクロプロセッサ１２にアクセスすることができる。あるいは、このコードは、ＣＤ−ＲＯＭドライブやハード・ドライブなどの何らかのタイプの長期記憶媒体３０からアクセスすることもできる。このソフトウェア・プログラミング・コードは、ディスケット、ハード・ドライブ、ＣＤ−ＲＯＭなど、データ処理システムと共に使用される様々な周知の媒体のいずれの媒体上でも実施可能である。コードは、そのような媒体で配布したり、他のコンピュータ・システムで使用するために、１つのコンピュータ・システムのメモリまたは記憶域から何らかのタイプのネットワークを介して他のコンピュータ・システムに配布したりすることができる。ソフトウェア・プログラミング・コードをメモリ、物理媒体で実施したり、ソフトウェア・コードをネットワークを介して配布する技法および方法は周知であり、本明細書では詳述しない。
【００４１】
ウェブ環境におけるサーバは典型的には表示装置２４を備えない場合があるが、本発明の好ましい実施形態は、本発明のスケジューリング最適化のために必要なパラメータを（たとえばシステム管理者が）構成することができるようにするために、表示装置２４を使用する。
【００４２】
本発明の好ましい実施形態について、図３から図１０を参照しながら以下に説明する。
【００４３】
好ましい実施形態では、本発明はコンピュータ・ソフトウェア・プログラムとして実施される。このプログラムは、クライアントがサーバに対してデータを求める要求を送信した場合に使用され、ネットワークのサーバ側で行われる処理の部分を含む。本発明は、複数のスレッドを使用してアプリケーション処理を行うサーバと共に機能する。典型的には、このプログラムはインターネット環境で使用され、サーバはウェブ・サーバであり、要求はＨＴＴＰ（またはＨＴＴＰＳ）を使用して形式設定される。あるいは、ユーザのコンピュータがその構成要素である企業イントラネット（すなわちユーザの会社内部で所有または管理されるネットワーク）に接続を行うこともでき、その場合、この企業イントラネットはインターネットと同様にしてサービスを提供する。本明細書では、特に明記のない限り、ユーザの要求に関連づけられた処理について説明する場合の「インターネット」という用語の使用にはイントラネットで行われる処理も含まれる。好ましい実施形態のプログラム・コードは、Ｓｍａｌｌｔａｌｋなどのオブジェクト指向プログラミング言語におけるオブジェクトとして、または「Ｃ」などの従来の手続き型プログラミング言語の関数またはサブルーチンとして実施することができる。
【００４４】
図３から図５に、前述のオーバースケジューリング問題を改善する第１の好ましい実施形態に関係する論理が記載されたフローチャートを示す。
【００４５】
図３は、要求を処理する接続があるかどうかを判断するために作業スレッドによって実行される論理を示す。このプロセスはステップ１００から始まり、この論理に入る前にこのスレッドがすでに要求を処理していたかどうかを問い合わせる。回答が否定の場合、制御はステップ１１５に移る。肯定の場合、ステップ１０５および１１０を実行することによってこのスレッドに関する統計情報を収集する。ステップ１０５で、現在実行中のスレッドの数のカウンタを減分する。（このカウンタは、サーバが初期設定された場合、ゼロに初期設定されていることになり、図４の説明で「Ｉ」と呼ぶ。）ステップ１１０で、（スレッドが直前の接続を処理するために割り振られたときにステップ１３０で事前に記録された開始時刻を使用して）スレッドが実行されていた時間の長さを計算し、平均値を更新する（これについては図４を参照しながら詳述する）。次に制御はステップ１１５に渡される。
【００４６】
ステップ１１５で、この作業スレッドによって処理可能になっている接続があるかどうかを判断する検査が行われる。この好ましい実施形態によると、接続でデータが着信するまでは作業スレッドには接続が割り当てられない。クライアントによっては、接続を要求するが、その後でデータ要求を送信する前にその接続を閉じる場合もある。クライアントがデータを送信していることがわかるまで作業スレッドへの接続の割当てを遅らせることによって、作業スレッドのこのような非生産的な使用が回避される。まだデータを受信していない受け入れられた接続を、データを受信している接続から区別するために、２段階待ち行列を規定する。接続（すなわち接続のための待ち行列要素）は受け入れられると（さらにクライアントがその接続に肯定応答すると）第１段階に移り、データが着信するまで第１段階にとどまる。この第１段階を「受け入れられた接続待ち行列」とも呼ぶ。データ・パケットが着信すると、その接続は第２段階に移る。この第２段階を「実行可能待ち行列」とも呼ぶ。作業スレッドは、第２段階に達した接続にのみ割り当てられる。第１段階は先入れ先出し（ＦＩＦＯ）待ち行列として実施することが好ましい。しかし、接続のためにデータが着信すると待ち行列から接続が除去され、厳密にはＦＩＦＯ方式ではないため、第１段階に要素を記憶するために他の構造（リンク・リストなど）も使用可能である。第２段階は、接続が待ち行列に着信した順序で待ち行列から出されるように、ＦＩＦＯ待ち行列として実施されることが好ましい。この手法によって、個別の接続が処理のためにスケジュールされる前に、待機している他の接続と比較して過度に長い時間待たない可能性が高くなる。待ち行列要素に状態変数を関連づけて各接続の状況を示すなど、本発明の進歩的概念から逸脱することなく、この処理を実施するために２段階待ち行列に加えて他機構も使用可能であることは当業者には明らかであろう。
【００４７】
ステップ１１５での検査の応答が否定の場合（すなわち作業スレッドに割り当てられるのを待っている接続がない場合）、制御はステップ１２０に移り、作業スレッドはブロック状態になる。その後、この作業スレッドに関する図３のプロセスは終了する。作業スレッドは、図４のステップ２１０または図５のステップ２７０に関して後述する論理に従ってアンブロックされることになる。
【００４８】
この第１の好ましい実施形態では、ブロック作業スレッドは待ち行列内に保持され、これを「ブロック・スレッド待ち行列」とも呼ぶ。この待ち行列は後入れ先出し（ＬＩＦＯ）待ち行列として実施されることが好ましい。ページング機構が新しいページをメモリに入れるときにページを置き換えるために最長時間未（ＬＲＵ）使用方式を使用することを前提とすれば、ブロックスレッドをＬＩＦＯ待ち行列に入れることによって、スレッドがアンブロックされたときにスレッドのページがメモリ内に残っている可能性がより高くなる。
【００４９】
ステップ１１５の検査で接続可能状態がある場合、制御はステップ１２５に進む。次にこの接続は作業スレッドに割り当てられる。この接続のデータ要求を含むソケット構造が、実行可能待ち行列から取り出され、スレッドに渡される。
【００５０】
ステップ１３０で、このスレッドがこの接続の処理を開始した時刻として現在時刻が記録され、ステップ１３５で実行スレッドのカウンタが増分される。これは、実行統計情報の収集を、後でスケジューリング・ヒューリスティックで使用することができるようにするために行われる。その後、図３のプロセスは終了する。
【００５１】
作業スレッドが受動ソケットでアクセプト・アンド・レシーブ（accept_and_receive）ＡＰＩを実行するとき、図３の処理を呼び出すのはこのＡＰＩ呼出しの実行である。しかし、図３はこのＡＰＩとの併用には限定されず、その論理は他の方法で（たとえば、同様の受入れ接続機能の関数呼出しを実行して）呼び出すこともできる。
【００５２】
図３によって作業スレッドに割り当てられた接続は、本発明の一部を形成しない技法に従って処理される。処理が完了すると、（たとえばサーバが停止していない限り）スレッドは図３のプロセスを使用して再び別の接続を要求することができる。
【００５３】
図４に、受動ソケットに到着した着信パケットを処理するためにネットワークＩ／Ｏ割込みハンドラなどのプロセスによって実行される論理を示す。
【００５４】
このプロセスはステップ１５０から始まり、着信パケットを受け取る。ステップ１５５で、このパケットが新規接続の要求であるかどうかを検査する。新規接続要求の場合、制御はステップ１６０に移り、そうでない場合は制御はステップ１８０に移る。
【００５５】
ステップ１６０で、当技術分野で周知の技法を使用して新しいソケットが作成され、その結果、新しいソケット・データ構造が作成される。ステップ１６５で、この接続の項目が受動ソケットの「保留接続」待ち行列に入れられる。
【００５６】
ステップ１７０で、この受動ソケット上の接続を自動的に受け入れるかどうかを検査する。この情報は、構成パラメータを使用して示すことができる。着信接続要求を自動的に受け入れることによって、作業スレッドへの要求のスケジューリングをデータが着信するまで遅らせることができる。この検査の応答が否定の場合、この実施形態の２段階待ち行列は使用されない。これによって、既存の実施システムとの互換性をもたせることができ、既存の実施システムは本発明の他の機構を実施することができる。接続は保留接続待ち行列に残る。検査の応答が肯定の場合は、ステップ１７５でクライアントに肯定応答が送信される。次に制御はステップ１５０に返り、次の着信パケットを待つ。
【００５７】
ステップ１８０で、着信パケットが接続の確認であったかどうかを問い合わせる。そうであった場合には、ステップ１８５で接続は「受入れ」としてマークされる。この好ましい実施形態の２段階待ち行列を使用することにより、これは、この接続の項目を「保留接続」待ち行列から２段階のうちの最初の段階である「受入れ接続」待ち行列に移動することを含む。次に制御はステップ１５０に移り、次の着信パケットを待つ。
【００５８】
着信パケットが接続要求または接続確認でなかった場合、制御はステップ１９０に移る。参照しやすいように、図４ではパケットはデータ・パケットであるものと仮定している。他のパケット・タイプは、図４の実行フローには関係がなく、したがって対象としない。当業者には、本発明の進歩的概念から逸脱することなく、これらのパケットに追加の論理を付加することができることが明らかであろう。ステップ１９０で、このデータ・パケットは適切なソケットの到着待ち行列に入れられる。ステップ１９５で、これがこの接続の最初の着信データ・パケットであるかどうかを判断する検査が行われる。最初の着信パケットでない場合、（その接続はすでに作業スレッドに割り当てられているため）割込みハンドラはこのパケットをそれ以上処理せず、制御はステップ１５０に返る。
【００５９】
ステップ２００で、受け入れられた接続の最初のデータ・パケットが到着している。したがって、この接続は作業スレッドにスケジューリングするために使用可能にすることができる。この好ましい実施形態の２段階待ち行列を使用すると、ステップ２００の処理は、接続を「受け入れられた接続」待ち行列（段階１）から「実行可能」待ち行列（段階２）に移動させるステップを含む。
【００６０】
ステップ２０５で、本発明によって規定された新規なスケジューリング・ヒューリスティックを使用して、この接続を処理するために待機スレッドをアンブロックするか、それとも現在実行中のスレッドが完了するのを待つ（すなわち、接続を当面、実行待ち行列に入れたままにしておく）かを判断する。このヒューリスティックの結果、ブロック・スレッドをアンブロックすべきであることが示された場合、（ステップ２０５からの「覚醒」分岐をたどることによって）制御はステップ２１０に移る。そうでない場合は、この接続を処理するために待機スレッドをまだアンブロックする必要がないかまたはアンブロックすることが望ましくないため、割込みハンドラはこの時点ではそれ以上の処理を行わず、（ステップ２０５から「待機」分岐をたどることによって）制御はステップ１５０に返る。
【００６１】
ステップ２０５で実行されるスケジューリング・ヒューリスティックは、以下の数式によって定義される。
Ｒ＝（Ｃ＊Ｔ＊Ｄ）−（Ｔ／２）
【００６２】
このスケジューリング・ヒューリスティックの目的は、現行着信作業負荷に照らして作業スレッドの数のバランスをとることである。オーバースケジューリングが起こらない場合に最適な結果が得られる。そのためには、着信実行可能待ち行列で小さなバックログを保持する必要がある（すなわち、待ち行列にいくつかの接続を残しておくことができるようにし、ただちに作業スレッドを覚醒させることによって割り当てられないようにする）。しかし、ある程度の短い受容可能な遅延期間を超えて接続を待ち行列に残しておいてはならない。その遅延期間の終わりに使用可能な作業スレッドがない場合、受容可能な遅延を超えないようにブロック作業スレッドを覚醒させる。この遅延の長さは、平均受容可能遅延と最大受容可能遅延の２つの部分からなることが好ましい。任意選択により、これらの遅延要素を、ユーザがその値を入力することができる構成パラメータとする。ユーザが構成パラメータの値を入力する方式は、当業者には周知であり、本明細書では詳述しない。典型的には、サーバの初期設定中に構成メニューを表示し、これらのパラメータをそのメニューに含める。
【００６３】
上記の式で、Ｒは２段階待ち行列の段階２での実行可能接続の目標数を表し、「待ち行列内項目数」または「待ち行列バックログ」とも呼ぶ。ステップ２０５で検査を行ったときに接続数がＲより大きいか等しい場合、現行パラメータにより、すでに待機している接続が多すぎるため、ステップ２１０に制御を移すことによって待機スレッドがアンブロックされる。待ち行列内項目数がＲより小さい場合、接続はすべて待ち行列に残り、実行中のスレッドが完了するのを待つ。すべての接続が待ち行列に残っているため、処理はステップ１５０に移る。
【００６４】
スケジューリング・ヒューリスティックの変数Ｃは、１つの作業スレッドが完了することができる毎秒の平均接続数を表す。この変数の値は、スレッドの実行データを収集することによって計算することができる。実行データ収集は、図３に関して前述した処理に従って行うことができる。サーバ・アプリケーションがある程度の期間実行するまでは、代表データは存在しない。したがって、Ｃの値はゼロに初期設定され、それによってＲ＝０になり、その結果、制御はステップ２０５からステップ２１０（待機スレッドのアンブロック）に移ることになる。
【００６５】
変数Ｔは現在実行中のスレッドの数を表す。したがって、１秒間に完了する要求の数は（Ｃ＊Ｔ）である。たとえば、スレッドが毎秒平均８個の要求を完了することができ、現在実行中のスレッドが１０個ある場合、これらのスレッドは毎秒平均（８＊１０）＝８０個の要求を完了することができる。
【００６６】
変数Ｄは、要求が待ち行列上で待機する平均受容可能遅延時間を表す。遅延時間Ｄ中に新規接続がスレッド・プールに吸収される（すなわち接続が作業スレッドに割り当てられる）平均レートは、（Ｃ＊Ｔ＊Ｄ）である。たとえば、平均受容可能遅延時間が０．２秒の場合、（上記の例の数値を使用すると）この遅延期間中にこのスレッド数によって１６個の要求を吸収することができ、１秒間に８０個の要求を完了することができる場合、０．２秒間に（８＊１０＊０．２）＝１６個の要求を完了することができる。
【００６７】
所与の時点で、平均して実行中のスレッドの半分が現行要求を完了し、他の要求の処理を開始する。このスケジューリング・ヒューリスティックは、これを項（Ｔ／２）によって反映させる。この値は（Ｃ＊Ｔ＊Ｄ）から引かれる。これは、新しい要求を開始したばかりのスレッドは、実際には、（１／（Ｃ／２））秒の平均完了期間内に新しい要求を引き受けるために対応することができず、（１／Ｃ）秒に対応可能になるためである。上述の例を続けると、差し引く値は（１０／２）＝５であり、それによってＲの最終結果は（１６−５）＝１１になる。
【００６８】
言い換えると、この例のパラメータと合致するシステムは、実行中のスレッドの完了を待ち、それらのスレッドが対応可能になったときにそれらのＴ＝１０個のスレッドに新規要求を割り当てることによって、Ｄ＝０．２秒当たり最高（Ｃ＊Ｔ＊Ｄ）−（Ｔ／２）＝１１個の新規要求を処理することができ、要求は平均Ｄ＝０．２秒より長く待ち行列上で待機する必要はない。期間Ｄ＝０．２秒中に１１を超える新規要求が到着した場合、システムの容量を超え、所与の要求の遅延がＤを超えないように保証するために待機スレッドをアンブロックしなければならない。
【００６９】
この実施形態では、２段階待ち行列からの接続のスケジューリングを決定するために使用する新規なスケジューリング・ヒューリスティックについて説明したが、別法として、このスケジューリング・ヒューリスティックはそのような待ち行列がなくても、本発明の進歩的概念から逸脱することなく使用することができる。すなわち、図３で説明したように統計情報が収集されることを条件として、このヒューリスティックは、受け入れられたがまだデータを受信していない接続をスケジュールするために既存の受動ソケットと共に使用することもできる。この手法で、この第１の好ましい実施形態の多くの（ただしすべてではない）利点が実現される。いくつかの接続が作業スレッドにスケジュールされたが、結果的に、クライアントがその接続でデータを送信しないうちに閉じられるだけになる可能性が残る。しかし、オーバースケジューリング問題は改善される。
【００７０】
同様に、この好ましい実施形態で規定した２段階待ち行列は、この新規なスケジューリング・ヒューリスティックを使用しなくても使用することができるので有利である。そのような状況では、第２段階にある接続のために任意のスケジューリング手法を使用することができる。これには、作業スレッドをその都度アンブロックしなければならない場合であっても各接続を第２段階に達したらただちにスケジューリングする手法も含まれる。この手法の結果、スレッドのある程度のオーバースケジューリングは生じるが、このオーバースケジューリングは処理可能になったデータのある接続に限られる。
【００７１】
ステップ２１０で、待機スレッドがアンブロックされる。このスレッドは、ステップ２１５で段階２の「実行可能」待ち行列の先頭にある要求を処理するために割り当てられる。次に制御はステップ１５０に返る。スレッドがアンブロックされ、要求に割り当てられる方式は、当業者に周知であり、本発明の一部を形成しない。たとえば、「ＷＡＩＴ（待機）」を発行することによって（図３のステップ１２０で）スレッドがブロックした場合、そのスレッドは「ＰＯＳＴ（ポスト）」または「ＮＯＴＩＦＹ（通知）」事象を発行することによってアンブロックすることができる。アクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）ＡＰＩを使用してＷＡＩＴを発生させた場合、このＰＯＳＴによって単一のスレッドがアンブロックされる。アクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）以外のＡＰＩを使用した場合、ＰＯＳＴコマンドの発行によって、前述のように待機中のすべてのスレッドがアンブロックされる。
【００７２】
図５に、作業スレッドにスケジュールされるまでの待機時間が長くなり過ぎる接続がないように保証するために、遅延モニタによって実行することができる論理を示す。この論理は周期的に実行され、タイマを使用して呼び出される。
【００７３】
このプロセスはステップ２５０から開始され、「最大遅延」タイマに達していないかどうかが検査される。これはステップ２５０で反復ループとして図示されているが、この検査が途切れなく行われないことは当業者には明らかであろう。典型的には、「最大遅延」期間のタイマ・プロセスがスケジュールされ、それによってタイマは刻時を開始する。最大遅延期間が経過すると、このタイマ・プロセスについて割込みが生成され、ステップ２５５からステップ２７５までの論理が処理可能になる。あるいは、この検査は最大遅延時間より高い頻度または低い頻度で実行することもでき、その場合、ステップ２５０での検査は異なる時間間隔を反映することになる。
【００７４】
ステップ２５５で、段階２の「実行可能」待ち行列が空かどうかを調べる検査が行われる。空の場合、待機時間が長すぎる接続はなく、したがって制御はステップ２５０に返り、次のタイマの満了を待つ。空でない場合、ステップ２６０でブロック・スレッド待ち行列が空かどうかを調べる検査を行う。この検査の応答が肯定の場合、それ以上使用可能なスレッドはなく、したがって実行可能待ち行列の項目は検査されない。制御はステップ２５０に返る。ステップ２６０の応答が否定の場合、待ち行列上の接続に待機時間が長すぎる接続がないか調べる。ステップ２６５からステップ２７５までは、この検査を実行する反復ループを表す。ステップ２６５で、待ち行列上の最も古い要求（待ち行列先頭ポインタによって指し示された接続）が最大許容時間を超えて待機していないかどうか調べられる。超えている場合、ステップ２７０で待機スレッドがアンブロックされ、ステップ２７５でそのスレッドに接続が割り当てられる。その後、ステップ２６５に制御が返ることによって、次に古い接続が検査される。実行可能待ち行列がＦＩＦＯ待ち行列を使用して実施されており、ステップ２６５での検査が否定の場合、残りの待ち行列化接続のいずれも最大遅延を超えておらず、制御はステップ２５０に返る。（ＦＩＦＯ待ち行列を使用していない場合、待ち行列の終わりに達するまで、ステップ２６５から２７５を繰り返すことによって実行可能待ち行列上の各項目を検査する必要がある。）
【００７５】
図６に、前述の複数入力源問題を改善する第２の好ましい実施形態に関わる論理が記載されたフローチャートを示す。
【００７６】
第２の好ましい実施形態は、コレクタ・ソケットと呼ぶ新規なタイプのソケットの規定に基づく。複数の受動ソケットからの入力がコレクタ・ソケット上にマージされ、それによって、そこから接続をスレッドにスケジュールする単一の入力源が得られる。コレクタ・ソケットは、第１の好ましい実施形態で説明した２段階待ち行列の第２段階の「実行可能」待ち行列を有するものとして実施され、第１段階の「受入れ接続」待ち行列は複数の受動ソケットに関連づけられたままである。接続は受け入れられると受動ソケットの受入れ接続待ち行列に入れられ、各接続の最初のデータ・パケットが到着するとコレクタ・ソケットの実行可能待ち行列に移される。
【００７７】
図７に、コレクタ・ソケットを使用するために必要な変更との比較のために、第１の好ましい実施形態の２段階待ち行列の概念図を示す。図７には受動ソケット５００が図示されている。このような受動ソケットが多数存在することができ、各受動ソケットは、（１）接続がまだ保留中である間ソケット構造が保持される保留接続待ち行列５０２と、（２）接続が受け入れられた後、その接続の最初のデータ・パケットが到着する前にソケット構造が保持される受入れ接続待ち行列５０４と、（３）少なくとも１つのデータ・パケットが到着した後、接続が作業スレッドにスケジュールされる前にソケット構造が保持される実行可能接続待ち行列５０６とを有する。各受動ソケットには、ブロック・スレッド待ち行列５１０が関連づけられ、それを使用して接続が前述の技法に従ってスレッドにスケジュールされる。
【００７８】
これと対比して、図８に、コレクタ・ソケットを使用した場合に受動ソケットがどのように異なるかを図示する。図８には３個の受動ソケット５３０、５４０、５５０が図示され、そのデータが１つのコレクタ・ソケット５６０にマージされている（ただし、マージされる数は３個には限定されない）。各受動ソケット５３０、５４０、５５０は今度は、（１）保留接続待ち行列５３２、５４２、５５２と、（２）受入れ接続待ち行列５３４、５４４、５５４の２つの待ち行列から成る。実行可能待ち行列５６２はコレクタ・ソケット５６０に付随している。さらに、各受動ソケット５００ごとにブロック・スレッド待ち行列５１０を備えるのではなく、単一のコレクタ・ソケット５６０に単一のブロック・スレッド待ち行列５７０がある。図８に示すように、受入れ接続待ち行列５３４、５４４、５５４から接続が移動するとき、それらの接続はコレクタ・ソケット５６０の実行可能待ち行列５６２に移動される。
【００７９】
コレクタ・ソケットの使用を可能にするには追加のＡＰＩが必要である。このＡＰＩの目的は、どの受動ソケットがコレクタ・ソケットにマージされるかを示すことである。したがって、このＡＰＩ呼出しは、収集する受動ソケットのリストを備える。この情報は、好ましくは、構成パラメータを使用して伝えられ、システム管理者などのユーザに対して受動ソケット識別子を指定するように求める。この情報を提供するための他の方法も、本発明の進歩的概念から逸脱することなく使用可能である。その後、これらの識別子は、第２の好ましい実施形態に提供される。ユーザから構成パラメータを入手し、実行プログラムに提供する方法は、当業者には明らかであろう。したがって、これについては詳述しない。
【００８０】
コレクタＡＰＩは、サーバが動作を開始するときに発行されることが好ましい。しかし、クライアントがサーバに要求の送信を開始してからコレクタ・ソケットが確立されるまでの間に、ある程度の遅延が存在する可能性がある。図６に、この状況を改善するために使用可能であって、受動ソケットの実行可能待ち行列にすでに移動されている接続がないか見つけるために収集される受動ソケットを検査する論理を示す。これらの接続は、コレクタ・ソケットの実行可能待ち行列に移される。図６の論理は、サーバがすでに実行を開始している後でコレクタＡＰＩを呼び出す場合にも使用することができる。
【００８１】
ステップ４００で、ＡＰＩ呼出しの受信に応答してコレクタ・ソケットが作成される。実行可能待ち行列は空の待ち行列に初期設定される。コレクタ・ソケットとこのソケットを使用するスレッドの実行に関する統計情報の保持を開始するために、（前述の）スケジューリング・ヒューリスティックのために保持される統計情報が初期設定される。コレクタ・ソケットのために、このソケットからの接続を処理するために使用されるスレッドのためのブロック・スレッドの待ち行列が作成される。
【００８２】
ステップ４１０で、指標やループ・カウンタなどの指示機構を使用して、ＡＰＩ呼出し時に提供されるリストから最初の受動ソケット識別子を指示する。リスト内の項目に指標付けする技法は当技術分野で周知であり、詳述しない。
【００８３】
ステップ４２０で、現在指示されている受動ソケットを、コレクタ・ソケットを指すように修正する。これによって、後で受動ソケットでデータを受け取った接続が、データ・パケットをコレクタ・ソケットに転送させることができるようになる。
【００８４】
ステップ４３０で、受動ソケットの実行可能待ち行列を検査して、この接続がすでに実行可能待ち行列に移されているかどうかを調べる。前述のように、受け入れられた接続の最初のデータ・パケットは、コレクタ・ソケットが作成される前に到着している可能性があり、ステップ４３０で、そのような接続をコレクタ・ソケットの実行可能待ち行列に移動させることができるようにする。待ち行列から項目を取り出す技法と、待ち行列に項目を入れる技法は、当技術分野で周知である。
【００８５】
ステップ４４０で、ポインタがリスト内の最後の要素を指しているかどうかを調べることによって、コレクタＡＰＩで識別されているすべての受動ソケットが処理されたかどうかを検査する。この検査の応答が肯定の場合、図６の処理は終了する。否定の場合は、ステップ４５０で、次の受動ソケットを指すようにポインタを増分し、制御はステップ４２０に返る。
【００８６】
作業スレッドがコレクタ・ソケットの実行可能待ち行列から作業を受け取る処理論理は、受動ソケットの実行可能待ち行列から作業を受け取るスレッドに関して図３に示したプロセスと同じである。しかし、前述の図３の説明とは異なる以下の相違点がある。（１）保持される統計情報はコレクタ・ソケットに関して保持され、（２）ブロック作業スレッドの待ち行列は、コレクタ・ソケットに付随する待ち行列であり、（３）検査される実行可能待ち行列はコレクタ・ソケットの実行可能待ち行列であり、（４）作業スレッドはコレクタ・ソケットに対してアクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）ＡＰＩを実行する。
【００８７】
この好ましい実施形態で受動ソケットでの着信パケットの受け取りを扱う処理論理は、図４に示すものと類似している。ただし、若干の変更が必要である。ステップ１９５で、コレクタ・ソケットにマージされる受動ソケットのために到着する最初のデータ・パケットを検出した後（すなわちステップ１９５の「Ｙｅｓ」分岐）、接続は受動ソケットの実行可能待ち行列ではなくコレクタ・ソケットの実行可能待ち行列に移動される。ステップ２０５でスケジューリング・ヒューリスティックに使用される統計は、コレクタ・ソケットの統計である。ステップ２１０で覚醒されるスレッドは、コレクタ・ソケットに付随するブロック・スレッド待ち行列内のスレッドである。
【００８８】
コレクタ・ソケットの実行可能接続待ち行列を監視して、スケジュールされるまでに待機する時間が長くなり過ぎる接続がないように保証する処理論理は、図５に示す論理と同じである。しかし、前述の図５の説明とは異なる以下のような相違点がある。（１）監視される実行可能接続待ち行列はコレクタ・ソケットの実行可能待ち行列であり、（２）検査されるブロック・スレッド待ち行列はコレクタ・ソケットに付随する待ち行列であり、（３）ステップ２７０で覚醒されるスレッドは、コレクタ・ソケットに付随するブロック・スレッド待ち行列内のスレッドである。
【００８９】
（図３を参照しながら前述したように）受け入れられた接続が受動ソケットからコレクタ・ソケットに移されるときに、それらの接続と共に、その接続がどの受動ソケットに到着したかを示す情報を渡す必要がある。これは、異なる入力源からの入力に異なる処理が必要な場合があるためである。たとえば、１つの受動ソケットにセキュア接続要求が到着した場合、作業スレッドは、非セキュア接続要求が到着した場合には不要な特別なセキュリティ関係の処理を必要とする。その接続がＳＳＬ使用可能受動ソケットに到着した場合、この特別な処理にはハンドシェーク・プロトコルが含まれる。この特別な処理は本発明の一部を形成しない。本発明の進歩的概念から逸脱することなく、接続の入力源を示す情報を渡すためにいくつかの方法が使用可能である。たとえば、当技術分野で周知のように、接続には様々なタイプの情報を入れるために割り振られた記憶域がある。このデータ域に、着信ソケットの識別子を記憶するためのパラメータを付加することができる。各作業スレッドは、このデータ域を調べて入力源関係の処理が必要かどうかを判断する論理を含む。これによって、プール内の任意のスレッドが、複数の受動ソケットのうちのいずれかのソケットに到着する接続を処理することができる。したがって、静的区分化を使用して受動ソケットに作業スレッドを割り振る必要がなくなる。この実施形態は、コレクタ・ソケットの実行待ち行列にマージされた入力源を有することによって、様々な入力源へのプールの動的区分化を実現する。
【００９０】
コレクタ・ソケットの実行可能待ち行列から要求をスケジュールするための、第１の好ましい実施形態で定義されたスケジューリング・ヒューリスティックの使用は、この第２の実施形態では任意選択である。しかし、その使用によって、コレクタ・ソケット上の接続負荷が使用可能スレッドの数に満たない場合に生じるオーバースケジューリング問題を回避することができる。
【００９１】
図９から図１０に、持続接続問題のある前述のスレッド割当てを改善する第３の実施形態に関与する論理が記載されたフローチャートを示す。
【００９２】
第３の好ましい実施形態は、第２の好ましい実施形態により規定されたコレクタ・ソケットの使用を必要とする。持続接続を使用する場合により効率的な処理を可能にする、コレクタ・ソケットを処理するための改善点を規定する。図８に示す実行可能待ち行列に加えて、コレクタ・ソケットは「遊休接続」待ち行列も有する。本明細書で「ギブバック（ｇｉｖｅｂａｃｋ）」ＡＰＩと呼ぶ、（後述の）追加のＡＰＩを定義する。
【００９３】
作業スレッドがコレクタ・ソケットの実行可能待ち行列から作業を受け取るための処理論理は、第２の好ましい実施形態に関して前述したプロセス（図３を参照）と同じである。作業スレッドは、コレクタ・ソケットの実行可能待ち行列上にある接続のみに割り当てられる。
【００９４】
この第３の好ましい実施形態の受動ソケットで着信パケットの受領を処理する処理論理は、第２の好ましい実施形態に関して前述したもの（図４を参照）と類似している。しかし、若干の変更を要する。ステップ１５５で着信接続要求を検出した後、ステップ１６０で作成される新しいソケットは、この実施形態では２つの追加のデータ値の初期設定を必要とする。第１に、ソケット状況を「実行不能」、すなわち当該接続は現在スケジュールすることができないことを示すように設定しなければならない。第２に、アプリケーション・コンテキストを、当該接続にまだコンテキストが関連づけられていないことを示すヌル値に設定しなければならない。その他の変更は、接続のデータが到着したときに実行される処理に関するものである。ステップ１９５でそれが最初に受け取ったデータ・パケットであるかどうかを調べる検査を行う代わりに、ソケットが「実行可能」と「実行不能」のどちらにマークされているかを問い合わせる検査を行う。状況がすでに「実行可能」に設定されていた場合、制御はステップ１５０に返る。そうでない場合（すなわち状況が「実行不能」だった場合）、制御はステップ２００に進む。現在ステップ２００に示されている処理の代わりに、新しい処理は、（１）ソケットを「実行可能」としてマークするステップと、（２）ソケットを現行待ち行列（受動ソケットの受入れ待ち行列またはコレクタ・ソケットの遊休待ち行列である）から、コレクタ・ソケットの実行可能待ち行列に移動するステップとを含む。
【００９５】
コレクタ・ソケットの実行可能接続待ち行列を監視して、スケジューリングされるまでの待機時間が長すぎる接続がないようにする処理論理は、図５に示すものと同じである。第２の好ましい実施形態に関して説明した図５との相違は、この第３の好ましい実施形態にも当てはまる。
【００９６】
図６を参照しながら第２の好ましい実施形態に関して説明したようにコレクタ・ソケットを作成するとき、１つの追加の変更が必要である。今度は、ステップ４００でコレクタ・ソケットをセットアップするときに空の遊休接続待ち行列を作成しなければならない。
【００９７】
図９に、アプリケーションによる新しいギブバック（ｇｉｖｅｂａｃｋ）ＡＰＩの発行に応答して呼び出される論理を示す。このＡＰＩ呼出しによって、作業スレッドに割り当てられていた（したがってすでにデータを受信していた）ソケットが、そのスレッドから結合解除され、そのスレッドを他の接続に割り当てることが可能になる。このＡＰＩは、持続接続が着信データ要求間で遅延（何らかの所定のしきい値を超える）に遭うと呼び出される。
【００９８】
ステップ６００で、この接続のための未読のデータがあるかどうかを問い合わせる。ギブバック（ｇｉｖｅｂａｃｋ）ＡＰＩが処理中だったときにデータが着信している可能性がある。この条件が真の場合、制御はステップ６５０に移る。そうでない場合、ステップ６１０で接続を遊休待ち行列に移動するプロセスが続けられる。
【００９９】
ステップ６１０で、このソケットを「実行不能」としてマークし、ソケットの項目を遊休接続待ち行列に入れる。遊休接続数のカウンタが増分される。ソケットが遊休待ち行列に入れられるとき、このＡＰＩの入力パラメータである、この接続に関連づけられたアプリケーション・コンテキスト値がソケットと共に格納される。これによって、アプリケーションは後でデータが到着したときに同じソケットを使用して処理を再開できるようになる。
【０１００】
ステップ６２０で、遊休接続カウンタの現行値が最大値（構成パラメータまたは静的値として設定することができる）と比較される。この検査の応答が肯定の場合、遊休状態の接続が多すぎ、ステップ６３０に制御を移すことによって最も古い接続が除去される。最大値を超えていない場合、図９の処理は終了する。
【０１０１】
ステップ６３０で、遊休接続待ち行列上の最も古い接続を除去しなければならない。好ましくは、遊休接続待ち行列はＦＩＦＯ待ち行列であり、したがってステップ６３０は待ち行列の先頭を指すステップを含む。この接続は閉じられ、使用していた資源は解放される。ステップ６４０で、「Expired（期限切れ）」であることを示すようにソケットにマークを付け遊休待ち行列から外すことによって、このプロセスが開始される。遊休接続のカウントが減分され、ステップ６５０で、このソケットは実行可能待ち行列に移動される。実行可能待ち行列から接続が作業スレッドにスケジュールされると、その作業スレッドによってクローズ・プロセスは完了される。ステップ６６０からステップ６８０で、第１の好ましい実施形態に関して説明したスケジューリング・ヒューリスティックが実行され、それによって、接続はスレッドをアンブロックすることによってこの時点でスケジュールされるか、または使用中のスレッドが使用可能になり、（図３の修正したプロセスを使用して）コレクタ・ソケットの実行可能待ち行列を調べの時点でスケジューリングされるのを待つ。ステップ６６０で、スレッドがスケジュールされるのを待つことが示された場合、またはステップ６８０でアンブロック・スレッドへの接続の割当てが終了した場合、図９の処理は完了する。
【０１０２】
このギブバック（ｇｉｖｅｂａｃｋ）ＡＰＩの使用によってコレクタ・ソケットの遊休接続待ち行列に入れられた接続は、以下のいずれか１つの条件が満たされるまでそこにとどまる。すなわち、（１）さらにデータが到着するか、（２）クライアントから接続クローズ要求を受け取るか、（３）接続が最大時間を超えて遊休状態のままになっているか、または（４）遊休接続のカウントが高くなり過ぎるという条件である。条件１の場合、接続を遊休待ち行列上に保持することによって、最初のデータ要求の受領によってスケジューリングされる接続について通常行われる初期設定ステップを踏まずに、接続を後続の作業スレッドに割り当てることができる。この第３の実施形態に関して前述した図４の修正された論理によって、この追加のデータの到着が検出され、接続の再スケジュールが処理される。条件４は、図９のステップ６２０〜６８０に関して前述したプロセスである。以下で、条件２および３について詳述する。
【０１０３】
クライアントが接続を閉じることを要求する条件２の場合、接続を遊休接続待ち行列からコレクタ・ソケットの実行可能待ち行列に移動しなければならない。これは、接続が遊休状態を続けている間、その接続のためのアプリケーション・コンテキストが保持されており、この時点でそれを作業スレッドによって打ち切る必要があるためである。接続は図４のステップ２００の修正された論理を使用して実行可能待ち行列に移動される。
【０１０４】
接続が遊休状態になっている時間が長すぎる条件３の場合、図１０の処理が使用される。実行可能待ち行列に入っている時間が長すぎる接続がないか検査する第１および第２の実施形態で使用した遅延モニタを、前述のようにこの第３の実施形態でも実行する。しかし、図１０に示す、遊休接続待ち行列を検査する追加の監視手続きも使用する。
【０１０５】
図１０の処理は何らかの所定の間隔で呼び出され、この間隔は構成パラメータとすることができる。この呼出しを行うためにタイマを使用することもできる。ステップ７００で、遊休待ち行列から最も古い遊休ソケットを入手する。前述のように、好ましくは、遊休接続待ち行列はＦＩＦＯ待ち行列であり、したがってステップ７００は待ち行列の先頭を指すステップを含む。ステップ７１０で、当該接続が遊休状態のままである時間が長すぎないかどうかを検査する。ギブバック（ｇｉｖｅｂａｃｋ）ＡＰＩにタイムアウト・パラメータを組み込むことによって、各接続は定義されたそれ自体の最大遊休期間を有することができる。このパラメータ値は、接続の項目と共に遊休待ち行列に格納される。あるいは、たとえば構成時に値を指定することによって、各接続に同じ最大遊休時間を使用することもできる。
【０１０６】
接続がまだ最大遊休時間に達していない場合、制御はステップ７２０に進む。したがって、接続は遊休待ち行列にとどまることができる。ステップ７２０で、これが遊休接続待ち行列上の最後の接続かどうかを問い合わせる。最後の接続の場合、それ以上検査する接続はなく、したがって図１０のプロセスは終了する。最後の接続でない場合、ステップ７３０で、待ち行列内の次の接続を指示し、制御はステップ７１０に返ってその接続を検査する。
【０１０７】
検査している接続が最大遊休時間を超えて遊休状態であった場合、制御はステップ７４０に進む。送るべきデータがないときに当該接続のためのアプリケーション・コンテキストを開いたままにしておくと、システム資源が効率的に使用されないため、接続は閉じられ、資源が解放される。ステップ７４０で、ソケットを「Expired（期限切れ）」を示すようにマークし、遊休待ち行列から除去することによって、このプロセスが開始される。遊休接続のカウントが減分され、ステップ７５０でソケットが実行可能待ち行列に移される。接続がスケジュールされると、作業スレッドがこのクローズ・プロセスを完了させる。ステップ７６０から７８０で、第１の好ましい実施形態で説明したスケジューリング・ヒューリスティックが実行され、それによって接続はスレッドをアンブロックすることによってこの時点でスケジュールされるか、または使用中のスレッドが使用可能になり、（図３の修正したプロセスを使用して）コレクタ・ソケットの実行可能待ち行列を検査する時点でスケジュールされるのを待つ。ステップ７６０で、スレッドがスケジュールされるのを待つことが示された場合、またはステップ７８０でアンブロック・スレッドへの接続の割当てが終了した場合、制御はステップ７２０に返り、遊休待ち行列になお接続があるかどうかを調べる。
【０１０８】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１０９】
（１） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
接続を求める複数のクライアント要求と、
複数の作業スレッドと、
前記複数のクライアント要求を受け取るサブプロセスと、
スケジューラが前記クライアント要求の各々に新しい作業スレッドを覚醒させることを緩和するために、スケジューリング・ヒューリスティックを実施するサブプロセスであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するサブプロセスと
を含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（２） 前記作業スレッドの第１のグループがアクティブ・スレッドであり、前記第１のグループが、前記複数の作業スレッドのうちの変更可能な作業スレッドから成りかつ変更可能な数の前記変更可能な作業スレッドを有し、前記変更可能な数が少なくとも１であり、
前記スケジューリング・ヒューリスティックを実施する前記サブプロセスが、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らして前記第１のグループ内の前記変更可能な数のバランスをとるサブプロセスをさらに含む、請求項１に記載のマルチスレッド・アプリのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（３） バランスをとる前記サブプロセスが平均遅延の使用をさらに含む、（２）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（４） バランスをとる前記サブプロセスが最大遅延の使用をさらに含む、（３）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（５） 前記平均遅延および前記最大遅延が構成パラメータである、（４）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（６） 前記作業スレッドの第２のグループがブロック・スレッドであり、前記第２のグループが前記複数の作業スレッドのうちの前記第１のグループに入っていない作業スレッドから成り、
前記ブロック・スレッドが後入れ先出し待ち行列に格納される、（２）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（７） 前記スケジューリング・ヒューリスティックが使用可能な作業スレッドの数を最適化する、（１〜６のいずれか１項）に記載のマルチスレッド・アプリのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（８） ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるサブプロセスと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から第２の待ち行列に移動させるサブプロセスと、
前記第２の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスと
を含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（９） ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
複数の発生源から入力を受け取るサブプロセスと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするサブプロセスと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるサブプロセスと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるサブプロセスと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとをさらに含む、
コンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１０） ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
複数の発生源から入力を受け取るサブプロセスと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするサブプロセスと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるサブプロセスと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるサブプロセスと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとをさらに含み、
スケジューリングのためにマージする前記サブプロセスが、
複数の作業スレッドのうちの変更可能な作業スレッドから成り且つ前記変更可能な作業スレッドの変更可能な数を有するアクティブ作業スレッドのグループであって、前記変更可能な数が少なくとも１である、前記アクティブ作業スレッドのグループを含み、
前記単一の待ち行列に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ作業スレッドのグループ内の前記変更可能な数のバランスをとるためにスケジューリング・ヒューリスティックを実施するサブプロセスであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するサブプロセスと
をさらに含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１１） ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
複数の持続接続と、
複数の作業スレッドと、
前記持続接続のうちの選択された持続接続を前記作業スレッドのうちの選択された作業スレッドに結合するサブプロセスであって、その実行の結果として結合接続が生じるサブプロセスと、
前記結合接続のうちの選択された結合接続を結合解除するサブプロセスであって、その実行の結果として結合解除された作業スレッドが生じるサブプロセスと
を含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１２） 結合する前記サブプロセスが２段階待ち行列を使用するステップをさらに含み、
結合解除する前記サブプロセスが前記２段階待ち行列を使用するステップをさらに含む、（１１）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１３） 前記２段階待ち行列を使用して結合する前記サブプロセスが、
前記接続の最初のデータ・パケットが到着すると、各前記持続接続を前記第２の段階に移動させるサブプロセスと、
前記接続のデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させるサブプロセスと、
前記第１の段階から前記持続接続をスケジュールするサブプロセスと
をさらに含み、
前記２段階待ち行列を使用して結合解除する前記サブプロセスが、
前記選択された結合接続が遊休状態になると、前記結合接続のうちの選択された結合接続を前記第１の段階から前記第２の段階に移動させるサブプロセスと、
最大遊休期間を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちの選択された持続接続を閉じるサブプロセスと、
前記結合解除された作業スレッドを、結合する前記サブプロセスに使用可能にするサブプロセスと
をさらに含む、（１２）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１４） 結合解除する前記サブプロセスが、
最大遊休接続数を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちのさらに選択された持続接続を閉じるサブプロセスをさらに含む、（１３）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１５） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
接続を求める複数のクライアント要求と、
複数の作業スレッドと、
スケジューラと、
前記複数のクライアント要求を受け取る手段と、
前記スケジューラが前記クライアント要求の各々に新しい作業スレッドを覚醒させることを緩和すために、スケジューリング・ヒューリスティックを実施する手段であって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施する手段と
を含むシステム。
（１６） 前記作業スレッドの第１のグループがアクティブ・スレッドであり、前記第１のグループが前記複数の作業スレッドのうちの変更可能な作業スレッドから成りかつ変更可能な数の前記変更可能な作業スレッドを有し、前記変更可能な数が少なくとも１であり、
前記スケジューリング・ヒューリスティックを実施する前記手段が、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らして前記第１のグループ内の前記変更可能な数のバランスをとる手段をさらに含む、（１５）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（１７） バランスをとる前記手段が平均遅延の使用をさらに含む、（１６）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（１８） バランスをとる前記手段が最大遅延の使用をさらに含む、（１７）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（１９） 前記平均遅延および前記最大遅延が構成パラメータである、（１８）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２０） 前記作業スレッドの第２のグループがブロック・スレッドであり、前記第２のグループが前記複数の作業スレッドのうちの前記第１のグループに入っていない作業スレッドから成り、
前記ブロック・スレッドが後入れ先出し待ち行列に格納される、（１６）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２１） 前記スケジューリング・ヒューリスティックが使用可能な作業スレッドの数を最適化する、（１５〜２０のいずれか１項）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２２） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させる手段と、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から第２の待ち行列に移動させる手段と、
前記第２の待ち行列上の各前記接続に作業スレッドを割り当てる手段と
を含むシステム。
（２３） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
複数の発生源から入力を受け取る手段と、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージする手段と
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させる手段と、
前記接続の最初のデータ・パケットが到着すると、前記各接続を前記第１の待ち行列から前記単一の待ち行列に移動させる手段と、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てる手段と
をさらに含む、システム。
（２４） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
複数の発生源から入力を受け取る手段と、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージする手段と
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させる手段と、
前記接続の最初のデータ・パケットが到着すると、前記各接続を前記第１の待ち行列から前記単一の待ち行列に移動させる手段と、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てる手段と
をさらに含み、
スケジューリングのためにマージする前記手段が、
複数の作業スレッドのうちの変更可能な作業スレッドから成り且つ前記変更可能な作業スレッドの変更可能な数を有するアクティブ作業スレッドのグループであって、前記変更可能な数が少なくとも１である、前記アクティブ作業スレッドのグループを含み、
前記単一の待ち行列に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ作業スレッドのグループ内の前記変更可能な数のバランスをとるためにスケジューリング・ヒューリスティックを実施する手段であって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施する手段と
をさらに含む、システム。
（２５） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
複数の持続接続と、
複数の作業スレッドと、
前記持続接続のうちの選択された持続接続を前記作業スレッドのうちの選択された作業スレッドに結合する手段であって、結合の実行の結果として結合接続が生じる手段と、
前記結合接続のうちの選択された結合接続を結合解除する手段であって、結合解除の実行の結果として結合解除された作業スレッドが生じる手段と
を含むシステム。
（２６） 結合する前記手段が２段階待ち行列を使用する手段をさらに含み、
結合解除する前記手段が前記２段階待ち行列を使用する手段をさらに含む、（２５）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２７） 前記２段階待ち行列を使用して結合する前記手段が、
前記接続の最初のデータ・パケットが到着すると、各前記持続接続を前記第２の段階に移動させる手段と、
前記接続のデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させる手段と、
前記第１の段階から前記持続接続をスケジュールする手段と
をさらに含み、
前記２段階待ち行列を使用して結合解除する前記手段が、
前記選択された結合接続が遊休状態になると、前記結合接続のうちの選択された結合接続を前記第１の段階から前記第２の段階に移動させる手段と、
最大遊休期間を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちの選択された持続接続を閉じる手段と、
前記結合解除された作業スレッドを、結合する前記手段に使用可能にする手段と
をさらに含む、（２６）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２８） 結合解除する前記手段が、
最大遊休接続数を超えるとそれに応答して、前記第２段階にある前記持続接続のうちのさらに選択された持続接続を閉じる手段をさらに含む、（２７）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２９） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
接続を求める複数のクライアント要求を受け取るステップと、
スケジューラが前記クライアント要求の各々に新しい作業スレッドを覚醒させることを緩和するためにスケジューリング・ヒューリスティックを実施するステップであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するステップと
を含む方法。
（３０） 前記作業スレッドの第１のグループがアクティブ・スレッドであり、前記第１のグループが、前記複数の作業スレッドのうちの変更可能な作業スレッドから成りかつ変更可能な数の前記変更可能な作業スレッドを有し、前記変更可能な数が少なくとも１であり、
前記スケジューリング・ヒューリスティックを実施する前記ステップが、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らして前記第１のグループ内の前記変更可能な数のバランスをとるステップをさらに含む、（２９）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３１） バランスをとる前記ステップが平均遅延の使用をさらに含む、（３０）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３２） バランスをとる前記ステップが最大遅延の使用をさらに含む、（３１）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３３） 前記平均遅延および前記最大遅延が構成パラメータである、（３２）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３４） 前記作業スレッドの第２のグループがブロック・スレッドであり、前記第２のグループが前記複数の作業スレッドのうちの前記第１のグループに入っていない作業スレッドから成り、
前記ブロック・スレッドが後入れ先出し待ち行列に格納される、（３０）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３５） 前記スケジューリング・ヒューリスティックが使用可能な作業スレッドの数を最適化する、（２９〜３４のいずれか１項）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３６） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるステップと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から第２の待ち行列に移動させるステップと、
前記第２の待ち行列上の各前記接続に作業スレッドを割り当てるステップと
を含む方法。
（３７） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
複数の発生源から入力を受け取るステップと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするステップと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるステップと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるステップと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるステップと
をさらに含む方法。
（３８） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
複数の発生源から入力を受け取るステップと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするステップと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるステップと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるステップと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるステップと
をさらに含み、
複数の作業スレッドのうちの変更可能な作業スレッドから成り、前記変更可能な作業スレッドの変更可能な数を有し、前記変更可能な数が少なくとも１であるアクティブ作業スレッドのグループをさらに含み、
スケジューリングのために前記マージするステップが、
前記単一の待ち行列に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ・グループ内の前記変更可能な数のバランスをとるためにスケジューリング・ヒューリスティックを実施するステップであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するステップと
をさらに含む、方法。
（３９） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
複数の持続接続のうちの選択された持続接続を複数の作業スレッドのうちの選択された作業スレッドに結合するステップであって、結合ステップの実行の結果として結合接続が生じるステップと、
前記結合接続のうちの選択された結合接続を結合解除する手段であって、結合解除ステップの実行の結果として結合解除された作業スレッドが生じるステップと
を含む方法。
（４０） 前記結合ステップが２段階待ち行列を使用するステップをさらに含み、
前記結合解除ステップが前記２段階待ち行列を使用するステップをさらに含む、（３９）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（４１） 前記２段階待ち行列を使用して結合する前記ステップが、
前記持続接続の最初のデータ・パケットが到着すると、各前記持続接続を前記第２の段階に移動させるステップと、
前記持続接続のデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させるステップと、
前記第１の段階から前記持続接続をスケジュールするステップと
をさらに含み、
前記２段階待ち行列を使用して結合解除する前記ステップが、
前記選択された結合接続が遊休状態になると、前記結合接続のうちの選択された結合接続を前記第１の段階から前記第２の段階に移動させるステップと、
最大遊休期間を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちの選択された持続接続を閉じるステップと、
前記結合解除された作業スレッドを、結合する前記ステップに使用可能にするステップと
をさらに含む、（４０）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（４２） 結合解除する前記ステップが、
最大遊休接続数を超えるとそれに応答して、前記第２段階にある前記持続接続のうちのさらに選択された持続接続を閉じるステップをさらに含む、（４１）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
【図面の簡単な説明】
【図１】本発明を実施することができるコンピュータ・ワークステーション環境を示すブロック図である。
【図２】本発明を実施することができるネットワーク・コンピューティング環境を示す図である。
【図３】オーバースケジューリング問題を改善する本発明に関係する論理を記載したフローチャートである。
【図４】オーバースケジューリング問題を改善する本発明に関係する論理を記載したフローチャートである。
【図５】オーバースケジューリング問題を改善する本発明に関係する論理を記載したフローチャートである。
【図６】マージされた入力をスケジューリングに使用可能にあうるために、複数の入力源からの入力をマージする場合の、本発明に関係する論理を記載したフローチャートである。
【図７】本発明によって使用される多段階待ち行列を示す概念図である。
【図８】本発明によって使用される多段階待ち行列を示す概念図である。
【図９】持続接続を使用する場合に、着信要求へのスレッドの割当てを最適化する本発明に関係する論理を記載したフローチャートである。
【図１０】持続接続を使用する場合に、着信要求へのスレッドの割当てを最適化する本発明に関係する論理を記載したフローチャートである。
【符号の説明】
１０ ワークステーション
１２ マイクロプロセッサ
１４ バス
１６ ユーザ・インタフェース・アダプタ
１８ キーボード
２０ マウス
２４ 表示装置
２６ ディスプレイ・アダプタ
２８ サーバ・メモリ
３０ 長期記憶域
４０ データ処理ネットワーク
４４ ローカル・エリア・ネットワーク
４６ メインフレーム・コンピュータ（サーバ）
４８ 通信リンク
【発明の属する技術分野】
本発明はコンピュータのパフォーマンスに関し、より詳細には、マルチスレッド・サーバ・アプリケーションを実行するコンピュータのパフォーマンスを強化する技法、システム、およびコンピュータ・プログラムを対象とする。使用可能なスレッドの数を最適化するようにスケジューリング・ヒューリスティック（ｈｅｕｒｉｓｔｉｃ）を規定する。データが送信中でない場合に接続にスレッドが割り当てられないように保証するために、受動ソケットのための２段階待ち行列を規定する。複数の入力源からの入力をマージし、マージされた入力をスケジューリングに使用できるようにする、新規なタイプのソケットを規定する。持続接続を使用する場合に着信要求へのスレッドの割当てを最適化する関数を規定する。
【０００２】
【従来の技術】
マルチスレッド・アプリケーションとは、複数のスレッドによる並列実行をサポートするソフトウェア・プログラム、すなわち再入可能プログラムである。スレッドとは、そのようなプログラム内の単一の実行経路である。スレッドは、使用可能なスレッドにタイム・スライスを割り振るオペレーティング・システム・スケジューラの制御下で、１つのプロセス内で順次に実行される。プロセスは、実行中のプログラムの１つのインスタンスである。オペレーティング・システムは各並列スレッドに関する情報を維持し、この情報は、各タイム・スライスでスレッドがＣＰＵを共用することができるようにするが、それにもかかわらず互いに区別可能であるようにする。たとえば、スレッドごとに異なる現行命令ポインタが維持され、レジスタの値も同様に維持される。明確な状態情報を維持することによって、再入可能プログラム全体の各実行経路は、別々のプログラムが実行されているかのように独立して機能することができる。オープンＩ／Ｏ（入出力）ストリームのための仮想メモリやファイル記述子など、その他の状態情報は、実行効率向上のためにプロセス内のすべてのスレッドによって共用される。ＳＭＰ（対称マルチプロセッサ）マシン上では、これらのスレッドのいくつかを同時に実行することができる。再入可能プログラムは、複数の実行経路でのこれらの共用資源を同期させる機構を含むことができる。
【０００３】
インターネット環境で稼働しているサーバ上では、マルチスレッド・アプリケーションがますます普及しつつある。インターネットは、世界中の場所から、ネットワークとして相互接続された膨大なコンピュータ資源の集まりである。インターネットは、毎日数百万人の人々によって使用されている。ワールド・ワイド・ウェブ（本明細書では「ウェブ」と呼ぶ）は、インターネットのうち、メッセージを交換するためのプロトコルとしてＨｙｐｅｒＴｅｘｔ転送プロトコル（「ＨＴＴＰ」）を使用する部分である。（あるいは、「ＨＴＴＰＳ」プロトコルを使用することができ、このプロトコルはＨＴＴＰのセキュリティ強化版である。）
【０００４】
インターネットのユーザは一般に、インターネット・サービス・プロバイダ（ＩＳＰ）のサービスを介してネットワーク接続を確立することによってインターネットにアクセスし、使用する。ＩＳＰは、コンピュータ・ユーザが、コンピュータ・モデム（または衛星伝送などのその他の接続機構）を使用して電話番号をダイヤルし、それによってＩＳＰが所有または管理する遠隔コンピュータとの接続を確立できるようにする。その後で、この遠隔コンピュータはユーザのコンピュータにサービスを提供する。典型的なサービスとしては、インターネットの相互接続されたコンピュータ全体でユーザが求める項目を検索する検索機能、検索機能を使用して探し出された情報を表示するブラウズ機能、ユーザが他のコンピュータ・ユーザとの間でメール・メッセージの送受信を行うことができる電子メール機能の提供などがある。
【０００５】
ウェブ環境で作業するユーザは、ユーザのコンピュータ上で実行され、情報を求める要求の作成と送信を行い、その結果を見ることができるようにするソフトウェアを持つ。これらの機能は、一般には「ウェブ・ブラウザ」または「ブラウザ」と呼ばれるものとして組み合わされている。ユーザがブラウザを使用して要求を作成した後、その要求メッセージは処理のためにインターネットに送出される。要求メッセージの宛先は、インターネットのネットワーク内の相互接続されたコンピュータの１つである。そのコンピュータは、メッセージを受け取り、ユーザの要求を満たすデータの検索を試み、ユーザのブラウザを使用して表示するためにそのデータを形式設定し、形式設定された応答をユーザのコンピュータ上で実行されているブラウザ・ソフトウェアに返す。同じコンピュータに多くのクライアントがアクセスすることができるようにするために、クライアントの要求の受け取りや処理を行うコンピュータは一般にはマルチスレッド・アプリケーションを実行する。これで、このアプリケーションの同じインスタンスが複数の要求を処理することができ、その際、別々のスレッドを使用して１つのクライアントの要求が他のクライアントの要求から分離される。
【０００６】
これは、クライアント／サーバ・コンピューティング・モデルの一例であり、ユーザが情報を要求するマシンはクライアントと呼ばれ、その情報を探し出してクライアントに返すコンピュータがサーバである。ウェブ環境では、サーバは「ウェブ・サーバ」と呼ばれる。クライアント／サーバ・モデルは、「三層アーキテクチャ」と呼ばれるものに拡張することができる。このアーキテクチャは、ウェブ・サーバを中央層に配置し、それに付加された層は典型的には、クライアントの要求を処理するタスクの一部としてウェブ・サーバがアクセスすることができる情報のデータベースを表す。この三層アーキテクチャは、多くのクライアント要求が単に静的データの検索と返送を求めているだけでなく、返されるデータを動的に作成するためにクライアントの要求を処理するアプリケーション・プログラムを必要としていることを認識している。このアーキテクチャでは、ウェブ・サーバは「アプリケーション・サーバ」とも呼ばれることがある。サーバがマルチスレッド・アプリケーション・プログラムを実行する場合、サーバを「スレッド・サーバ」または「マルチスレッド・サーバ」と呼ぶこともある。
【０００７】
サーバは、スレッドを処理する役割を負う。本明細書では、作成されたが廃棄されていないスレッドのセットをスレッドの「プール」と呼ぶ。プールのために作成されるスレッドの数は一般にはユーザ（たとえばシステム管理者）が、サーバを初期設定するときに構成パラメータとして指定する。一般には、このパラメータは、予想最大接続負荷（すなわち着信クライアント要求の最大数）を扱うために、サーバが多数のスレッドを作成するように設定される。
【０００８】
ＴＣＰ／ＩＰプロトコル（転送制御プロトコル／インターネット・プロトコル）が、ネットワークでデータを伝送する事実上の標準方法であり、インターネット伝送で広く使用されている。ＴＣＰ／ＩＰは、２つのコンピュータ間でデータを交換するために２つの「ソケット」間の接続という概念を使用し、ソケットはそれらコンピュータのうちの一方のコンピュータを識別するアドレスと、そのコンピュータ上の特定のプロセスを識別するポート番号とから成る。ポート番号によって識別されたプロセスは、そのソケットのために着信データを受け取るプロセスである。ソケットは、典型的にはその接続を使用する２つのコンピュータの各コンピュータによって待ち行列として実施され、接続でデータを送信するコンピュータは作成したデータを送信のために接続待ち行列に入れ、接続でデータを受信するコンピュータはそのデータを処理するために着信データを待ち行列に入れる。
【０００９】
いくつかのクライアントから要求を受け取るアプリケーションの場合、保留クライアント接続の待ち行列を表す特別な「受動」ソケットが作成される。このアプリケーションのサービスを必要とする各クライアントは、同じサーバ・ポート番号を使用して、この受動ソケットへの接続を要求する（ただし、セキュア・ソケット層（「ＳＳＲ」）などの保護プロトコルを使用する通信は一般には、同じアプリケーションに、セキュリティなしの「通常の」通信とは異なるポート番号を使用する。）サーバは、この特別な受動ソケットから保留クライアント接続を受け入れる。これによって新しいサーバ・ソケットが作成され、次に、そのソケットが処理のために使用可能なスレッドに割り当てられる。
【００１０】
この環境で稼働するマルチスレッド・サーバ・アプリケーションを実施する現行の手法にはいくつかの欠点があり、その結果、そのようなアプリケーションの最適パフォーマンスが満たされないことになる。数千または数百万もの１日当たりの「ヒット」（すなわち処理を求めるクライアント要求）を受け取ることがある、ウェブ・サーバ上で稼働するアプリケーションなどのアプリケーションが普及するにつれて、パフォーマンスは重要な問題になる。本発明はこのようなパフォーマンス上の問題に対処する。
【００１１】
既存のサーバ実装では、別個の「ディスパッチャ」スレッドが、所与のアプリケーションのための受動ソケットに対する着信接続要求を受け取る待ち行列を監視する役割を果たす。ディスパッチを行うスレッドと、作業のディスパッチ先のスレッドとを区別するために、本明細書では後者を「作業スレッド」と呼ぶ。ディスパッチャ・スレッドは、各作業スレッドの状況を追跡し、各着信要求を使用可能なスレッドに割り当てる。「使用可能な」スレッドとは、実行可能であるが、現在割り当てられている作業がないスレッドである。この状態のスレッドを「遊休スレッド」と呼ぶこともある。遊休スレッドに作業が割り当てられると、そのスレッドはもはや遊休とはみなされず、その現在の作業要求が完了するまではそれ以上の作業は割り当てられない。ＳＭＰマシン上では、ディスパッチャ・スレッドは、作業スレッドがすべてのプロセッサを使用中にしておくのに十分な速さでスケジュールされるのを妨げるボトルネックになる可能性がある。
【００１２】
あるいは、ディスパッチャ・スレッドを使用せずにサーバを実施することもできる。この手法では、スレッドは受動ソケット待ち行列を調べて接続要求がないかどうかを判断する役割を負う。各スレッドは処理していた作業要求を完了すると、待ち行列で次の要求を探す。要求が待機中である場合、スレッドはその要求を待ち行列から取り出し、その処理を開始する。待機中の要求がない場合、スレッドは遊休スレッドになる。その後、遊休スレッドは「スリープ」することがあり、その場合、システム・タイマを使用してそのスレッドを所定期間待機させた後、「覚醒」させて作業が到着していないかどうか待ち行列を再度調べさせる。これは「ポーリング」モードと呼ばれる。ポーリング・モードに代わるより一般的な代替手法は、イベント・ドリブン割込みを使用することである。この手法では、スレッドは遊休状態になり、作業が到着すると呼び出されてスレッドに再度アクティブになるように通知するシステム割込みを待つ。遊休状態になることを「ブロック」と呼び、ブロック状態から覚醒されること（すなわち割込みを受け取ること）を「アンブロック」と呼ぶ。
【００１３】
イベント・ドリブン割込みを使用する現行のサーバ実装では、各作業スレッドは現行要求を完了すると、受動ソケット待ち行列を調べて要求が待機していないかどうかを調べる。待機している要求がない場合、スレッドはブロックする。所与の時点で任意の数のスレッドをブロックすることができる。次の着信要求が到着すると、スレッドを覚醒させるイベントが生成される。ブロックされた各作業スレッドはこの割込みを受け取り、したがって各ブロックはアンブロックして、待ち行列から要求の取り出しを試みる。着信要求を受け取ることができるのは最初の作業スレッドだけであり、他のスレッドは再度待ち行列が空であるのを認めて、ブロック状態に戻る。しかし、この割込み生成手法を変える新しいＡＰＩ（アプリケーション・プログラミング・インタフェース）が開発中である。このＡＰＩを本明細書では「アクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）と呼ぶ。アクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）ＡＰＩによると、着信要求が到着すると、単一のブロックスレッドに対してのみ割込みが生成される。
【００１４】
この新しい割込み手法によって、本明細書で扱う第１のパフォーマンス問題が生じ、これを本明細書では「オーバースケジューリング」と呼ぶ。着信接続の数がスレッド・プール内のスレッドの数より少ない場合（すなわち、接続負荷がサーバの構成最大値よりも小さい場合）、その作業負荷を処理するために使用されるプール内のスレッドが多すぎる。言い換えると、スレッド・プールはオーバースケジューリングされている。これによって資源の使用効率が悪くなる。
【００１５】
以下の事例で、オーバースケジューリング問題を例示する。すべてのスレッドがブロックされ、接続要求を待っているとする。第１の要求が到着する。システム・スケジューラはこれらのブロック・スレッドの１つを覚醒させ、着信要求をそのスレッドに割り当てる。そのスレッドは要求の処理を開始する。次に、第２の要求が到着し、そのため、スケジューラは第２のブロック・スレッドを覚醒させ、この新しい要求をそのスレッドに割り当てる。第２のスレッドはこの新しい要求の処理を開始する。第１のスレッドは作業していた要求を完了し、受動ソケットを調べる。受動ソケットに新しい接続要求がないことがわかり、第１のスレッドはブロックする。２つの要求について、スケジューラは２つのスレッドを覚醒させている。
【００１６】
しかし、第２の要求が到着した時点で、第１のスレッドはその第１の要求の処理をほとんど完了しようとしている場合がある。その場合、第２のスレッドを覚醒させるのではなく、第１のスレッドが完了し、受動ソケットを調べたときに第２の要求を見つけるのを待つ方がより効率的であろう。スケジューラが各着信要求ごとに新しいスレッドを覚醒させた場合（すなわちスレッドをオーバースケジュールした場合）、要求を処理するスレッドは、その現行要求を完了して別の要求がないか調べたときに着信接続待ち行列が空であることを見いだすことが確実である。ブロック操作とアンブロック操作の繰り返しは、要求を処理するための全体的パス長の点で不経済である。スレッドがブロックすると、スケジューラはそのスレッドのコンテキスト情報を保管し、スレッドは「実行可能」状態から「ブロック」状態に移行する。アンブロック操作には、割込み処理に伴うかなりのオーバーヘッドを要する。
【００１７】
オーバースケジューリング中にシステムのパフォーマンスに及ぼす他の影響は、メモリ・ページング機構によるものである。スレッドは実行されると記憶情報を参照する。その情報は処理するためにメモリに入っていなければならない。まだメモリに入っていない場合はページインされる。一般に、１つのページをページインするための空きを作るために他のページがページアウトされなければならない。ページング機構は、アルゴリズムを使用してどのページをページアウトするかを決定する。通例、最も長い期間使用されなかった（ＬＲＵ）ページがページアウトのために選択される。オーバースケジューリングが起こると、各スレッドは実行後にブロックし、したがってそのページは使用されなくなる。スレッドがブロックする期間が長いほど、そのページがページアウトされる可能性が高くなる。その後、スレッドが覚醒されると、そのページをページインし戻さなければならず、それによって別のスレッドのページがページアウトされる。これらのページング操作によって生じる余分な処理によって、着信要求の処理効率が低下する。
【００１８】
さらに、空であることがわかるだけの受動ソケットを調べる操作は無駄な操作であり、それによってブロック・スレッドの効率が低下する。
【００１９】
本明細書では第２のパフォーマンス問題を「複数入力源」問題と呼ぶ。前述のように、サーバ・アプリケーションは１つの受動ソケットで非セキュア接続要求を受け取り、もう一つの受動ソケットでセキュア接続要求を受け取ることがある。これは、たとえばオンライン・ショッピング・アプリケーションの場合である。クライアント買物客は、オンライン・カタログから入手可能な製品を表示するように要求し、最終的に注文するいくつかの製品を選択する。情報の表示を求めるこのような要求は、セキュア接続に付随する付加的な処理オーバーヘッドを生じさせないように、通常は非セキュア接続で送信される。買物客は注文を行うときに、クレジット・カードによる支払いを選択し、自分のクレジット・カード情報を電子的に発信することがある。買物客の情報を保護するために、買物客のトランザクションのこの部分はセキュア接続で送信される。一般には、販売業者はショッピング・トランザクションの全シーケンスに同じサーバ・アプリケーションを使用する。したがって、アプリケーションは、２つの受動ソケットから非セキュア接続要求とセキュア接続要求の両方を受け入れることができなければならない。
【００２０】
ウェブ・サーバが複数のホスト名をホストしており、各ホスト名がそれ自体のＩＰアドレスを有する場合、各ホスト名に１対の受動ソケットが使用される。したがって、所与のアプリケーションが多くの受動ソケットに到着する接続を受け入れる必要がある場合がある。このようなソケットのセットを本明細書では「複数入力源」と呼ぶ。
【００２１】
ソケット待ち行列管理の前述のディスパッチャ・スレッド手法では、各受動ソケットに１つのディスパッチャ（または「アクセプタ」）スレッドが割り振られる。着信接続要求が到着すると、これらのディスパッチャはスレッド・プールから使用可能な作業スレッドを見つけ、そのスレッドに着信要求を割り当てる役割を果たす。ディスパッチャ・スレッドの数が増えるにつれて、作業スレッドの共用プールの管理をめぐるそれらのスレッド間の衝突も増える。
【００２２】
ディスパッチャ・スレッドを使用せず、着信待ち行列を調べる役割が作業スレッドにある場合、スレッド・プールは受動ソケット待ち行列のセット全体で静的に区分化されることになる。特定の時点での作業負荷と、それに対応する受動ソケット間での要求の分配は予測不能なため、この静的区分化は最適状態を下回る可能性がきわめて高くなる。１つの待ち行列のスレッドは、その作業負荷を処理するには少な過ぎ、別の待ち行列は多過ぎる場合がある。使用可能なスレッドが少なすぎる場合、着信要求は待ち行列上で待たなければならず、その間に使用可能なシステム能力が遊休状態のままになる。着信要求には通常、応答を待っている人間がいるため、応答を処理する際のこのタイプの遅延は、最大限回避しなければならない。使用可能なスレッドが多すぎる場合、オーバースケジューリングについて前述した非効率が生じる。受動ソケット間での作業の現在の分配に基づいて作業スレッドのプールを分割するより動的な区分化は、受動ソケット上の接続待ち行列内項目数がサーバ・アプリケーションには入手できないために、サーバ・アプリケーションによって行うことはできない。
【００２３】
第３のパフォーマンス問題を、本明細書では「持続接続スケジューリング」と呼ぶ。持続接続機能は、ＨＴＴＰの１．１版で導入され、クライアントとサーバの間の要求（およびそれに対応する応答）のストリームに単一の接続を使用できるようにする。持続接続は、一連の要求の処理に付随するオーバーヘッドの量を少なくし、それによって普通なら個別要求ごとに必要になるＴＣＰ接続のセットアップとティアダウンのコストをなくし、１回のセットアップと１回のティアダウンを使用することを意図したものである。結果は、クライアントのもとで生成された各要求が新しい接続を生み出し、それはその要求の持続時間の間だけ持続した。接続をセットアップするのにメッセージの交換が必要であり、それを閉じるのにもう一度交換が必要だった。多くのウェブ・ベースのアプリケーションは、ユーザに対してきわめて複雑な情報ページを表示し、各ページでネットワークを介していくつかの別々の要求を送信する必要がある場合がある。たとえば、ページ上の各グラフィック画像ごとに１つの要求を送信し、静的テキストのために別の要求、動的生成テキストのためにさらに他の要求が送信される場合がある。したがって、単一のウェブ・ページの表示に、持続接続を使用すれば相当量の処理オーバーヘッドが節減される。すなわち、２つのコンピュータ間で使用するために１つの接続を設定した後は、クライアントは、サーバがそれらの要求の各要求を受け取ったという肯定応答を待つために停止せずに、その接続を介して任意の数の要求を送信することができる。これを要求の送信の「ストリーム」モードと呼ぶ。サーバはストリームのすべての要求に順に応答する必要がある。クライアントまたはサーバは、プロトコル・エラーを生じさせることなく、任意の要求境界で接続を終了することができる。
【００２４】
実際には、ユーザが異なるウェブ・サイトに移動する（異なるサーバ・ソケット・アドレスと、それに応じて新しい接続が必要になる）まで、ブラウザ内のクライアント・ソフトウェアがこの持続接続を開いたままに維持する。開いた持続接続で最後の要求が送信されてからユーザが新しいサイトに移動するまでの間にある程度の時間が経過することがある。既存の接続のソケットには、この時間中、着信データがまったくなくなる。サーバ・アプリケーションは、ソケットがこの特定の状態（すなわち、クライアントはデータの送信を終了しているが、接続はまだ開いている状態）であるかどうか、またはクライアントが次の要求をまだ生成していないだけなのかどうかを知ることができない。したがって、このタイプの接続の次の要求の読取りに関してサーバ側に不確定性が存在する。待ち行列にデータがある可能性もあり、データがまもなく着信するか、またはデータがしばらくの間着信しない可能性もある。しかも、これらのデータ・パケットのいずれかに、その接続で進行中の作業を求めるクライアント要求や、ソケットを閉じる要求が入っている可能性もある。
【００２５】
データが間もなく着信する場合は、その作業スレッドとの接続を結合した状態に維持し、作業スレッドが一時的に遊休状態になるようにするのが最も効率的である。しかし、データが着信するまで長い遅延時間がある場合は、作業スレッドをその接続から結合解除し、その作業スレッドを別の要求に割り当てた方がより効率的である。その後、その結合解除された接続を求める次の要求が着信した場合、その処理を続けるためにスレッド（元々結合されていたスレッドとは異なるスレッドである可能性が最も高い）を割り当てる。どの接続が所与の要求間での遅延が長くなるか、そのような遅延がいつ発生するか、または遅延がどれだけ長く続くかを前もって知る方法がない。作業スレッドのプールを、新しい接続を受け入れるスレッドと、遅延後に再アクティブ化する接続を処理するスレッドとを区分化する試みは、複数入力源問題に関して前述したのと同様の問題を生じさせる。すなわち、いずれかの区分に割り当てられるスレッドが多すぎたり少なすぎたりすることによって、非効率になる。
【００２６】
したがって、マルチスレッド・サーバ・アプリケーションの現行の実施システムにおけるこれらの非効率問題を克服する技法が必要である。本提案の技法は、使用可能スレッドの数を最適化するスケジューリング・ヒューリスティックと、受動ソケットのための２段階待ち行列と、複数の入力源からの入力をマージし、そのマージされた入力をスケジューリングに使用できるようにする新しいタイプのソケットと、持続接続を使用する場合に着信要求へのスレッドの割当てを最適化する関数とを規定する。
【００２７】
【発明が解決しようとする課題】
本発明の目的は、マルチスレッド・サーバのパフォーマンスを強化する技法を提供することである。
【００２８】
本発明の他の目的は、作業スレッドに対する要求のスケジューリングを最適化することによって上記のパフォーマンス強化を実現する技法を提供することである。
【００２９】
本発明の他の目的は、使用可能スレッドの数を最適化するスケジューリング・ヒューリスティックを規定することによって、上記の最適化を実現することである。
【００３０】
本発明の他の目的は、複数の入力源からの入力をマージする新しいタイプのソケットを規定し、そのマージされた入力をスケジューリングに使用できるようにすることによって上記の最適化を実現することである。
【００３１】
本発明の他の目的は、持続接続を使用する場合に着信要求へのスレッドの割当てを最適化する関数を規定することによって、上記の最適化を実現することである。
【００３２】
本発明のその他の目的および利点は、一部は以下の説明、一部は図面に記載され、その説明を読めば明らかになるであろうし、本発明の実施によってわかるであろう。
【００３３】
【課題を解決するための手段】
上記の目的を達成するためと、本明細書で概説する本発明の目的により、本発明は、ネットワークへの接続を有するコンピューティング環境において使用し、マルチスレッド・アプリケーションのパフォーマンスを強化するシステム、方法、およびソフトウェア・プロセスを実施するコンピュータ可読コードであって、接続を求める複数のクライアント要求と、複数の作業スレッドと、前記複数のクライアント要求を受け取るサブプロセスと、前記作業スレッドのオーバースケジューリングを改善するスケジューリング・ヒューリスティックを実施するサブプロセスとを含むシステム、方法、およびコンピュータ可読コードを提供する。さらに、前記作業スレッドの第１のグループはアクティブ・スレッドであり、前記第１のグループは、前記複数の作業スレッドのうちの変更可能な作業スレッドから成り、変更可能な数の前記変更可能スレッドを有し、前記変更可能な数は少なくとも１であり、スケジューリング・ヒューリスティックを実施する前記サブプロセスは、前記第１のグループにおける前記変更可能な数を、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らしてバランスをとるサブプロセスをさらに含む。バランスをとる前記サブプロセスは、平均遅延と、最大遅延の使用も含むことができる。前記平均遅延と前記最大遅延は構成パラメータであることが好ましい。作業スレッドの前記第１のグループに加えて、ブロック・スレッドであり、後入れ先出し待ち行列に格納される前記作業スレッドの第２のグループも存在することができる（前記第２のグループは、前記複数の作業スレッドのうち前記第１のグループに入っていない作業スレッドから成る）。さらに、本発明は、マルチスレッド・アプリケーションのパフォーマンスを強化するシステム、方法、およびコンピュータ可読コードであって、各前記接続が受け入れられる場合に保留接続待ち行列から接続を第１の待ち行列に移動させるサブプロセスと、前記接続のための最初のデータ・パケットが着信すると前記第１の待ち行列から各前記接続を第２の待ち行列に移動させるサブプロセスと、前記第２の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとを含む、システム、方法、およびコンピュータ可読コードを提供する。さらに、本発明は、マルチスレッド・アプリのパフォーマンスを強化するシステム、方法、およびコンピュータ可読コードであって、複数の入力源から入力を受け取るサブプロセスと、受け取った前記入力をスケジューリングのために単一の待ち行列上にマージするサブプロセスとを含む、システム、方法、およびコンピュータ可読コードを提供する。これは、各前記接続が受け入れられる場合、保留接続待ち行列から接続を第１の待ち行列に移動させるサブプロセスと、前記接続のための最初のデータ・パケットが着信すると各前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるサブプロセスと、前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとをさらに含むことが好ましい。スケジューリングする前記サブプロセスは、複数の作業スレッドのうちの変更可能な作業スレッドから成り、少なくとも１である変更可能な数の前記変更可能作業スレッドを有するアクティブ作業スレッドのグループと、前記単一待ち行列上に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ・グループ内の前記変更可能数のバランスをとるスケジューリング・ヒューリスティックを実施するサブプロセスとをさらに含むことが好ましい。さらに、本発明は、マルチスレッド・アプリケーションのパフォーマンスを強化するシステム、方法、およびコンピュータ可読コードであって、複数の持続接続と、複数の作業スレッドと、前記持続接続のうちの選択された持続接続を前記作業スレッドのうちの選択された作業スレッドに結合するサブプロセスであって、その実行の結果として結合された接続ができるサブプロセスと、前記結合された接続のうちの選択された接続を結合解除するサブプロセスであって、その実行の結果として作業スレッドが結合解除されるサブプロセスとを含む、システム、方法、およびコンピュータ可読コードを提供する。結合する前記サブプロセスは、２段階待ち行列の使用をさらに含み、結合解除する前記サブプロセスは前記２段階待ち行列の使用をさらに含むことが好ましい。前記２段階待ち行列を使用して結合する前記サブプロセスは、前記接続のために最初のデータ・パケットが着信すると各前記持続接続を前記第１の段階に移動させるサブプロセスと、前記接続のためにデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させるサブプロセスと、前記第１の段階から前記持続接続をスケジューリングするサブプロセスとをさらに含み、前記２段階待ち行列を使用して結合解除する前記サブプロセスは、選択された前記結合接続が遊休状態になると、前記結合された接続のうちの選択された接続を前記第１の段階から前記第２の段階に移動させるサブプロセスと、最大遊休期間を超えるとそれに応答して、前記第２の段階内の前記持続接続のうちの選択された持続接続を閉じるサブプロセスと、結合解除された前記作業スレッドを前記結合サブプロセスに使用することができるようにするサブプロセスとをさらに含む。結合解除する前記サブプロセスは、最大遊休接続数を超えるとそれに応答して、前記第２の段階内の前記持続接続のうちのさらに選択された持続接続を閉じるサブプロセスをさらに含むことが好ましい。
【００３４】
【発明の実施の形態】
図１に、本発明を実施することができる代表的なワークステーション・ハードウェア環境を示す。図１の環境は、関連する周辺装置を含むパーソナル・コンピュータなどの代表的なコンピュータまたはインテリジェント・ワークステーション１０を含む。あるいは、ワークステーション１０は、ネットワーク環境におけるサーバとすることもできる。ワークステーション１０は、マイクロプロセッサ１２と、周知の技法によりマイクロプロセッサ１２とワークステーション１０の構成要素とを接続し、それらの間の通信を可能にするバス１４とを含む。ワークステーション１０は、典型的には、バス１４を介してマイクロプロセッサ１２を、キーボード１８、マウス２０、またはタッチ・センシティブ画面、ディジタイズ入力パッドなどの任意のユーザ・インタフェース装置とすることができるその他のインタフェース装置２２など、１つまたは複数のインタフェース装置と接続するユーザ・インタフェース・アダプタ１６を含む。バス１４は、ディスプレイ・アダプタ２６を介してＬＣＤ画面またはモニタなどの表示装置２４もマイクロプロセッサ１２に接続する。また、バス１４はマイクロプロセッサ１２を、メモリ２８およびハード・ドライブ、ディスケット・ドライブ、テープ・ドライブなどの長期記憶域３０にも接続する。
【００３５】
ワークステーション１０は、通信チャネル３２を介して他のコンピュータまたはコンピュータのネットワークと通信する。ワークステーション１０は、ローカル・エリア・ネットワーク（ＬＡＮ）やワイド・エリア・ネットワーク内などの他のコンピュータと関連づけることができ、あるいはワークステーション１０は、他のコンピュータなどとのクライアント／サーバ構成におけるクライアントとすることもできる。これらのすべての構成と、適切な通信ハードウェアおよびソフトウェアは、当技術分野で周知である。
【００３６】
図２に、本発明を実施することができるデータ処理ネットワーク４０を示す。データ処理ネットワーク４０は、ＬＡＮ４２および４４を含む複数の個別ネットワークを含み、各ネットワークは複数の個別のワークステーション１０を含む。あるいは、当業者ならわかるように、ＬＡＮはホスト・プロセッサに結合された複数のインテリジェント・ワークステーションを含むこともできる。
【００３７】
図２を参照すると、データ処理ネットワーク４０は、好ましくは通信リンク４８を使用してＬＡＮ４４に結合することができるメインフレーム・コンピュータ４６などの、複数のメインフレーム・コンピュータまたはサーバも含むことができる。メインフレーム・コンピュータ４６は、ＩＢＭが販売するエンタープライズ・システム・アーキテクチャ／３７０（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍｓ Ａｒｃｈｉｔｅｃｔｕｒｅ／３７０）またはエンタープライズ・システム・アーキテクチャ／３９０（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ／３９０）コンピュータ、または他の任意のタイプのメインフレーム・コンピュータを使用して実施することができる。応用分野によっては、アプリケーション・システム／４００（Ａｐｐｌｉｃａｔｉｏｎ Ｓｙｓｔｅｍ／４００）（ＡＳ／４００とも呼ぶ）などの中規模コンピュータも使用可能である。「エンタープライズ・システム・アーキテクチャ／３７０（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ／３７０）」はＩＢＭの商標である。「エンタープライズ・システム・アーキテクチャ／３９０（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ／３９０）」、「アプリケーション・システム／４００（Ａｐｐｌｉｃａｔｉｏｎ Ｓｙｓｔｅｍ／４００）」、および「ＡＳ／４００」はＩＢＭの登録商標である。
【００３８】
メインフレーム・コンピュータ４６は、ＬＡＮ４４の遠隔記憶域として機能する記憶装置５０にも結合することができる。同様に、ＬＡＮ４４は、通信リンク５２に結合することができ、サブシステム制御装置／通信コントローラ５４および通信リンク５６を介してゲートウェイ・サーバ５８に結合することができる。ゲートウェイ・サーバ５８は、ＬＡＮ４２をＬＡＮ４４とリンクさせる役割を果たす個別コンピュータまたはインテリジェント・ワークステーションであることが好ましい。
【００３９】
当業者なら、メインフレーム・コンピュータ４６はＬＡＮ４４から地理的に遠距離に配置することができ、同様にＬＡＮ４４はＬＡＮ４２から遠距離に配置することができることがわかるであろう。たとえば、ＬＡＮ４２を米国カリフォルニア州に配置し、ＬＡＮ４４をテキサス州に配置し、メインフレーム・コンピュータ４６をニューヨークに配置することができる。
【００４０】
本発明を実施するソフトウェア・プログラミング・コードは、典型的には、クライアント／サーバ環境または三層環境におけるサーバ４６などのサーバにインストールされ、サーバ４６はワークステーション１０などのコンピュータを有するユーザから送られる要求を処理する。このコードは、典型的にはサーバ・メモリ２８内で実施され、バス１４を使用してマイクロプロセッサ１２にアクセスすることができる。あるいは、このコードは、ＣＤ−ＲＯＭドライブやハード・ドライブなどの何らかのタイプの長期記憶媒体３０からアクセスすることもできる。このソフトウェア・プログラミング・コードは、ディスケット、ハード・ドライブ、ＣＤ−ＲＯＭなど、データ処理システムと共に使用される様々な周知の媒体のいずれの媒体上でも実施可能である。コードは、そのような媒体で配布したり、他のコンピュータ・システムで使用するために、１つのコンピュータ・システムのメモリまたは記憶域から何らかのタイプのネットワークを介して他のコンピュータ・システムに配布したりすることができる。ソフトウェア・プログラミング・コードをメモリ、物理媒体で実施したり、ソフトウェア・コードをネットワークを介して配布する技法および方法は周知であり、本明細書では詳述しない。
【００４１】
ウェブ環境におけるサーバは典型的には表示装置２４を備えない場合があるが、本発明の好ましい実施形態は、本発明のスケジューリング最適化のために必要なパラメータを（たとえばシステム管理者が）構成することができるようにするために、表示装置２４を使用する。
【００４２】
本発明の好ましい実施形態について、図３から図１０を参照しながら以下に説明する。
【００４３】
好ましい実施形態では、本発明はコンピュータ・ソフトウェア・プログラムとして実施される。このプログラムは、クライアントがサーバに対してデータを求める要求を送信した場合に使用され、ネットワークのサーバ側で行われる処理の部分を含む。本発明は、複数のスレッドを使用してアプリケーション処理を行うサーバと共に機能する。典型的には、このプログラムはインターネット環境で使用され、サーバはウェブ・サーバであり、要求はＨＴＴＰ（またはＨＴＴＰＳ）を使用して形式設定される。あるいは、ユーザのコンピュータがその構成要素である企業イントラネット（すなわちユーザの会社内部で所有または管理されるネットワーク）に接続を行うこともでき、その場合、この企業イントラネットはインターネットと同様にしてサービスを提供する。本明細書では、特に明記のない限り、ユーザの要求に関連づけられた処理について説明する場合の「インターネット」という用語の使用にはイントラネットで行われる処理も含まれる。好ましい実施形態のプログラム・コードは、Ｓｍａｌｌｔａｌｋなどのオブジェクト指向プログラミング言語におけるオブジェクトとして、または「Ｃ」などの従来の手続き型プログラミング言語の関数またはサブルーチンとして実施することができる。
【００４４】
図３から図５に、前述のオーバースケジューリング問題を改善する第１の好ましい実施形態に関係する論理が記載されたフローチャートを示す。
【００４５】
図３は、要求を処理する接続があるかどうかを判断するために作業スレッドによって実行される論理を示す。このプロセスはステップ１００から始まり、この論理に入る前にこのスレッドがすでに要求を処理していたかどうかを問い合わせる。回答が否定の場合、制御はステップ１１５に移る。肯定の場合、ステップ１０５および１１０を実行することによってこのスレッドに関する統計情報を収集する。ステップ１０５で、現在実行中のスレッドの数のカウンタを減分する。（このカウンタは、サーバが初期設定された場合、ゼロに初期設定されていることになり、図４の説明で「Ｉ」と呼ぶ。）ステップ１１０で、（スレッドが直前の接続を処理するために割り振られたときにステップ１３０で事前に記録された開始時刻を使用して）スレッドが実行されていた時間の長さを計算し、平均値を更新する（これについては図４を参照しながら詳述する）。次に制御はステップ１１５に渡される。
【００４６】
ステップ１１５で、この作業スレッドによって処理可能になっている接続があるかどうかを判断する検査が行われる。この好ましい実施形態によると、接続でデータが着信するまでは作業スレッドには接続が割り当てられない。クライアントによっては、接続を要求するが、その後でデータ要求を送信する前にその接続を閉じる場合もある。クライアントがデータを送信していることがわかるまで作業スレッドへの接続の割当てを遅らせることによって、作業スレッドのこのような非生産的な使用が回避される。まだデータを受信していない受け入れられた接続を、データを受信している接続から区別するために、２段階待ち行列を規定する。接続（すなわち接続のための待ち行列要素）は受け入れられると（さらにクライアントがその接続に肯定応答すると）第１段階に移り、データが着信するまで第１段階にとどまる。この第１段階を「受け入れられた接続待ち行列」とも呼ぶ。データ・パケットが着信すると、その接続は第２段階に移る。この第２段階を「実行可能待ち行列」とも呼ぶ。作業スレッドは、第２段階に達した接続にのみ割り当てられる。第１段階は先入れ先出し（ＦＩＦＯ）待ち行列として実施することが好ましい。しかし、接続のためにデータが着信すると待ち行列から接続が除去され、厳密にはＦＩＦＯ方式ではないため、第１段階に要素を記憶するために他の構造（リンク・リストなど）も使用可能である。第２段階は、接続が待ち行列に着信した順序で待ち行列から出されるように、ＦＩＦＯ待ち行列として実施されることが好ましい。この手法によって、個別の接続が処理のためにスケジュールされる前に、待機している他の接続と比較して過度に長い時間待たない可能性が高くなる。待ち行列要素に状態変数を関連づけて各接続の状況を示すなど、本発明の進歩的概念から逸脱することなく、この処理を実施するために２段階待ち行列に加えて他機構も使用可能であることは当業者には明らかであろう。
【００４７】
ステップ１１５での検査の応答が否定の場合（すなわち作業スレッドに割り当てられるのを待っている接続がない場合）、制御はステップ１２０に移り、作業スレッドはブロック状態になる。その後、この作業スレッドに関する図３のプロセスは終了する。作業スレッドは、図４のステップ２１０または図５のステップ２７０に関して後述する論理に従ってアンブロックされることになる。
【００４８】
この第１の好ましい実施形態では、ブロック作業スレッドは待ち行列内に保持され、これを「ブロック・スレッド待ち行列」とも呼ぶ。この待ち行列は後入れ先出し（ＬＩＦＯ）待ち行列として実施されることが好ましい。ページング機構が新しいページをメモリに入れるときにページを置き換えるために最長時間未（ＬＲＵ）使用方式を使用することを前提とすれば、ブロックスレッドをＬＩＦＯ待ち行列に入れることによって、スレッドがアンブロックされたときにスレッドのページがメモリ内に残っている可能性がより高くなる。
【００４９】
ステップ１１５の検査で接続可能状態がある場合、制御はステップ１２５に進む。次にこの接続は作業スレッドに割り当てられる。この接続のデータ要求を含むソケット構造が、実行可能待ち行列から取り出され、スレッドに渡される。
【００５０】
ステップ１３０で、このスレッドがこの接続の処理を開始した時刻として現在時刻が記録され、ステップ１３５で実行スレッドのカウンタが増分される。これは、実行統計情報の収集を、後でスケジューリング・ヒューリスティックで使用することができるようにするために行われる。その後、図３のプロセスは終了する。
【００５１】
作業スレッドが受動ソケットでアクセプト・アンド・レシーブ（accept_and_receive）ＡＰＩを実行するとき、図３の処理を呼び出すのはこのＡＰＩ呼出しの実行である。しかし、図３はこのＡＰＩとの併用には限定されず、その論理は他の方法で（たとえば、同様の受入れ接続機能の関数呼出しを実行して）呼び出すこともできる。
【００５２】
図３によって作業スレッドに割り当てられた接続は、本発明の一部を形成しない技法に従って処理される。処理が完了すると、（たとえばサーバが停止していない限り）スレッドは図３のプロセスを使用して再び別の接続を要求することができる。
【００５３】
図４に、受動ソケットに到着した着信パケットを処理するためにネットワークＩ／Ｏ割込みハンドラなどのプロセスによって実行される論理を示す。
【００５４】
このプロセスはステップ１５０から始まり、着信パケットを受け取る。ステップ１５５で、このパケットが新規接続の要求であるかどうかを検査する。新規接続要求の場合、制御はステップ１６０に移り、そうでない場合は制御はステップ１８０に移る。
【００５５】
ステップ１６０で、当技術分野で周知の技法を使用して新しいソケットが作成され、その結果、新しいソケット・データ構造が作成される。ステップ１６５で、この接続の項目が受動ソケットの「保留接続」待ち行列に入れられる。
【００５６】
ステップ１７０で、この受動ソケット上の接続を自動的に受け入れるかどうかを検査する。この情報は、構成パラメータを使用して示すことができる。着信接続要求を自動的に受け入れることによって、作業スレッドへの要求のスケジューリングをデータが着信するまで遅らせることができる。この検査の応答が否定の場合、この実施形態の２段階待ち行列は使用されない。これによって、既存の実施システムとの互換性をもたせることができ、既存の実施システムは本発明の他の機構を実施することができる。接続は保留接続待ち行列に残る。検査の応答が肯定の場合は、ステップ１７５でクライアントに肯定応答が送信される。次に制御はステップ１５０に返り、次の着信パケットを待つ。
【００５７】
ステップ１８０で、着信パケットが接続の確認であったかどうかを問い合わせる。そうであった場合には、ステップ１８５で接続は「受入れ」としてマークされる。この好ましい実施形態の２段階待ち行列を使用することにより、これは、この接続の項目を「保留接続」待ち行列から２段階のうちの最初の段階である「受入れ接続」待ち行列に移動することを含む。次に制御はステップ１５０に移り、次の着信パケットを待つ。
【００５８】
着信パケットが接続要求または接続確認でなかった場合、制御はステップ１９０に移る。参照しやすいように、図４ではパケットはデータ・パケットであるものと仮定している。他のパケット・タイプは、図４の実行フローには関係がなく、したがって対象としない。当業者には、本発明の進歩的概念から逸脱することなく、これらのパケットに追加の論理を付加することができることが明らかであろう。ステップ１９０で、このデータ・パケットは適切なソケットの到着待ち行列に入れられる。ステップ１９５で、これがこの接続の最初の着信データ・パケットであるかどうかを判断する検査が行われる。最初の着信パケットでない場合、（その接続はすでに作業スレッドに割り当てられているため）割込みハンドラはこのパケットをそれ以上処理せず、制御はステップ１５０に返る。
【００５９】
ステップ２００で、受け入れられた接続の最初のデータ・パケットが到着している。したがって、この接続は作業スレッドにスケジューリングするために使用可能にすることができる。この好ましい実施形態の２段階待ち行列を使用すると、ステップ２００の処理は、接続を「受け入れられた接続」待ち行列（段階１）から「実行可能」待ち行列（段階２）に移動させるステップを含む。
【００６０】
ステップ２０５で、本発明によって規定された新規なスケジューリング・ヒューリスティックを使用して、この接続を処理するために待機スレッドをアンブロックするか、それとも現在実行中のスレッドが完了するのを待つ（すなわち、接続を当面、実行待ち行列に入れたままにしておく）かを判断する。このヒューリスティックの結果、ブロック・スレッドをアンブロックすべきであることが示された場合、（ステップ２０５からの「覚醒」分岐をたどることによって）制御はステップ２１０に移る。そうでない場合は、この接続を処理するために待機スレッドをまだアンブロックする必要がないかまたはアンブロックすることが望ましくないため、割込みハンドラはこの時点ではそれ以上の処理を行わず、（ステップ２０５から「待機」分岐をたどることによって）制御はステップ１５０に返る。
【００６１】
ステップ２０５で実行されるスケジューリング・ヒューリスティックは、以下の数式によって定義される。
Ｒ＝（Ｃ＊Ｔ＊Ｄ）−（Ｔ／２）
【００６２】
このスケジューリング・ヒューリスティックの目的は、現行着信作業負荷に照らして作業スレッドの数のバランスをとることである。オーバースケジューリングが起こらない場合に最適な結果が得られる。そのためには、着信実行可能待ち行列で小さなバックログを保持する必要がある（すなわち、待ち行列にいくつかの接続を残しておくことができるようにし、ただちに作業スレッドを覚醒させることによって割り当てられないようにする）。しかし、ある程度の短い受容可能な遅延期間を超えて接続を待ち行列に残しておいてはならない。その遅延期間の終わりに使用可能な作業スレッドがない場合、受容可能な遅延を超えないようにブロック作業スレッドを覚醒させる。この遅延の長さは、平均受容可能遅延と最大受容可能遅延の２つの部分からなることが好ましい。任意選択により、これらの遅延要素を、ユーザがその値を入力することができる構成パラメータとする。ユーザが構成パラメータの値を入力する方式は、当業者には周知であり、本明細書では詳述しない。典型的には、サーバの初期設定中に構成メニューを表示し、これらのパラメータをそのメニューに含める。
【００６３】
上記の式で、Ｒは２段階待ち行列の段階２での実行可能接続の目標数を表し、「待ち行列内項目数」または「待ち行列バックログ」とも呼ぶ。ステップ２０５で検査を行ったときに接続数がＲより大きいか等しい場合、現行パラメータにより、すでに待機している接続が多すぎるため、ステップ２１０に制御を移すことによって待機スレッドがアンブロックされる。待ち行列内項目数がＲより小さい場合、接続はすべて待ち行列に残り、実行中のスレッドが完了するのを待つ。すべての接続が待ち行列に残っているため、処理はステップ１５０に移る。
【００６４】
スケジューリング・ヒューリスティックの変数Ｃは、１つの作業スレッドが完了することができる毎秒の平均接続数を表す。この変数の値は、スレッドの実行データを収集することによって計算することができる。実行データ収集は、図３に関して前述した処理に従って行うことができる。サーバ・アプリケーションがある程度の期間実行するまでは、代表データは存在しない。したがって、Ｃの値はゼロに初期設定され、それによってＲ＝０になり、その結果、制御はステップ２０５からステップ２１０（待機スレッドのアンブロック）に移ることになる。
【００６５】
変数Ｔは現在実行中のスレッドの数を表す。したがって、１秒間に完了する要求の数は（Ｃ＊Ｔ）である。たとえば、スレッドが毎秒平均８個の要求を完了することができ、現在実行中のスレッドが１０個ある場合、これらのスレッドは毎秒平均（８＊１０）＝８０個の要求を完了することができる。
【００６６】
変数Ｄは、要求が待ち行列上で待機する平均受容可能遅延時間を表す。遅延時間Ｄ中に新規接続がスレッド・プールに吸収される（すなわち接続が作業スレッドに割り当てられる）平均レートは、（Ｃ＊Ｔ＊Ｄ）である。たとえば、平均受容可能遅延時間が０．２秒の場合、（上記の例の数値を使用すると）この遅延期間中にこのスレッド数によって１６個の要求を吸収することができ、１秒間に８０個の要求を完了することができる場合、０．２秒間に（８＊１０＊０．２）＝１６個の要求を完了することができる。
【００６７】
所与の時点で、平均して実行中のスレッドの半分が現行要求を完了し、他の要求の処理を開始する。このスケジューリング・ヒューリスティックは、これを項（Ｔ／２）によって反映させる。この値は（Ｃ＊Ｔ＊Ｄ）から引かれる。これは、新しい要求を開始したばかりのスレッドは、実際には、（１／（Ｃ／２））秒の平均完了期間内に新しい要求を引き受けるために対応することができず、（１／Ｃ）秒に対応可能になるためである。上述の例を続けると、差し引く値は（１０／２）＝５であり、それによってＲの最終結果は（１６−５）＝１１になる。
【００６８】
言い換えると、この例のパラメータと合致するシステムは、実行中のスレッドの完了を待ち、それらのスレッドが対応可能になったときにそれらのＴ＝１０個のスレッドに新規要求を割り当てることによって、Ｄ＝０．２秒当たり最高（Ｃ＊Ｔ＊Ｄ）−（Ｔ／２）＝１１個の新規要求を処理することができ、要求は平均Ｄ＝０．２秒より長く待ち行列上で待機する必要はない。期間Ｄ＝０．２秒中に１１を超える新規要求が到着した場合、システムの容量を超え、所与の要求の遅延がＤを超えないように保証するために待機スレッドをアンブロックしなければならない。
【００６９】
この実施形態では、２段階待ち行列からの接続のスケジューリングを決定するために使用する新規なスケジューリング・ヒューリスティックについて説明したが、別法として、このスケジューリング・ヒューリスティックはそのような待ち行列がなくても、本発明の進歩的概念から逸脱することなく使用することができる。すなわち、図３で説明したように統計情報が収集されることを条件として、このヒューリスティックは、受け入れられたがまだデータを受信していない接続をスケジュールするために既存の受動ソケットと共に使用することもできる。この手法で、この第１の好ましい実施形態の多くの（ただしすべてではない）利点が実現される。いくつかの接続が作業スレッドにスケジュールされたが、結果的に、クライアントがその接続でデータを送信しないうちに閉じられるだけになる可能性が残る。しかし、オーバースケジューリング問題は改善される。
【００７０】
同様に、この好ましい実施形態で規定した２段階待ち行列は、この新規なスケジューリング・ヒューリスティックを使用しなくても使用することができるので有利である。そのような状況では、第２段階にある接続のために任意のスケジューリング手法を使用することができる。これには、作業スレッドをその都度アンブロックしなければならない場合であっても各接続を第２段階に達したらただちにスケジューリングする手法も含まれる。この手法の結果、スレッドのある程度のオーバースケジューリングは生じるが、このオーバースケジューリングは処理可能になったデータのある接続に限られる。
【００７１】
ステップ２１０で、待機スレッドがアンブロックされる。このスレッドは、ステップ２１５で段階２の「実行可能」待ち行列の先頭にある要求を処理するために割り当てられる。次に制御はステップ１５０に返る。スレッドがアンブロックされ、要求に割り当てられる方式は、当業者に周知であり、本発明の一部を形成しない。たとえば、「ＷＡＩＴ（待機）」を発行することによって（図３のステップ１２０で）スレッドがブロックした場合、そのスレッドは「ＰＯＳＴ（ポスト）」または「ＮＯＴＩＦＹ（通知）」事象を発行することによってアンブロックすることができる。アクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）ＡＰＩを使用してＷＡＩＴを発生させた場合、このＰＯＳＴによって単一のスレッドがアンブロックされる。アクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）以外のＡＰＩを使用した場合、ＰＯＳＴコマンドの発行によって、前述のように待機中のすべてのスレッドがアンブロックされる。
【００７２】
図５に、作業スレッドにスケジュールされるまでの待機時間が長くなり過ぎる接続がないように保証するために、遅延モニタによって実行することができる論理を示す。この論理は周期的に実行され、タイマを使用して呼び出される。
【００７３】
このプロセスはステップ２５０から開始され、「最大遅延」タイマに達していないかどうかが検査される。これはステップ２５０で反復ループとして図示されているが、この検査が途切れなく行われないことは当業者には明らかであろう。典型的には、「最大遅延」期間のタイマ・プロセスがスケジュールされ、それによってタイマは刻時を開始する。最大遅延期間が経過すると、このタイマ・プロセスについて割込みが生成され、ステップ２５５からステップ２７５までの論理が処理可能になる。あるいは、この検査は最大遅延時間より高い頻度または低い頻度で実行することもでき、その場合、ステップ２５０での検査は異なる時間間隔を反映することになる。
【００７４】
ステップ２５５で、段階２の「実行可能」待ち行列が空かどうかを調べる検査が行われる。空の場合、待機時間が長すぎる接続はなく、したがって制御はステップ２５０に返り、次のタイマの満了を待つ。空でない場合、ステップ２６０でブロック・スレッド待ち行列が空かどうかを調べる検査を行う。この検査の応答が肯定の場合、それ以上使用可能なスレッドはなく、したがって実行可能待ち行列の項目は検査されない。制御はステップ２５０に返る。ステップ２６０の応答が否定の場合、待ち行列上の接続に待機時間が長すぎる接続がないか調べる。ステップ２６５からステップ２７５までは、この検査を実行する反復ループを表す。ステップ２６５で、待ち行列上の最も古い要求（待ち行列先頭ポインタによって指し示された接続）が最大許容時間を超えて待機していないかどうか調べられる。超えている場合、ステップ２７０で待機スレッドがアンブロックされ、ステップ２７５でそのスレッドに接続が割り当てられる。その後、ステップ２６５に制御が返ることによって、次に古い接続が検査される。実行可能待ち行列がＦＩＦＯ待ち行列を使用して実施されており、ステップ２６５での検査が否定の場合、残りの待ち行列化接続のいずれも最大遅延を超えておらず、制御はステップ２５０に返る。（ＦＩＦＯ待ち行列を使用していない場合、待ち行列の終わりに達するまで、ステップ２６５から２７５を繰り返すことによって実行可能待ち行列上の各項目を検査する必要がある。）
【００７５】
図６に、前述の複数入力源問題を改善する第２の好ましい実施形態に関わる論理が記載されたフローチャートを示す。
【００７６】
第２の好ましい実施形態は、コレクタ・ソケットと呼ぶ新規なタイプのソケットの規定に基づく。複数の受動ソケットからの入力がコレクタ・ソケット上にマージされ、それによって、そこから接続をスレッドにスケジュールする単一の入力源が得られる。コレクタ・ソケットは、第１の好ましい実施形態で説明した２段階待ち行列の第２段階の「実行可能」待ち行列を有するものとして実施され、第１段階の「受入れ接続」待ち行列は複数の受動ソケットに関連づけられたままである。接続は受け入れられると受動ソケットの受入れ接続待ち行列に入れられ、各接続の最初のデータ・パケットが到着するとコレクタ・ソケットの実行可能待ち行列に移される。
【００７７】
図７に、コレクタ・ソケットを使用するために必要な変更との比較のために、第１の好ましい実施形態の２段階待ち行列の概念図を示す。図７には受動ソケット５００が図示されている。このような受動ソケットが多数存在することができ、各受動ソケットは、（１）接続がまだ保留中である間ソケット構造が保持される保留接続待ち行列５０２と、（２）接続が受け入れられた後、その接続の最初のデータ・パケットが到着する前にソケット構造が保持される受入れ接続待ち行列５０４と、（３）少なくとも１つのデータ・パケットが到着した後、接続が作業スレッドにスケジュールされる前にソケット構造が保持される実行可能接続待ち行列５０６とを有する。各受動ソケットには、ブロック・スレッド待ち行列５１０が関連づけられ、それを使用して接続が前述の技法に従ってスレッドにスケジュールされる。
【００７８】
これと対比して、図８に、コレクタ・ソケットを使用した場合に受動ソケットがどのように異なるかを図示する。図８には３個の受動ソケット５３０、５４０、５５０が図示され、そのデータが１つのコレクタ・ソケット５６０にマージされている（ただし、マージされる数は３個には限定されない）。各受動ソケット５３０、５４０、５５０は今度は、（１）保留接続待ち行列５３２、５４２、５５２と、（２）受入れ接続待ち行列５３４、５４４、５５４の２つの待ち行列から成る。実行可能待ち行列５６２はコレクタ・ソケット５６０に付随している。さらに、各受動ソケット５００ごとにブロック・スレッド待ち行列５１０を備えるのではなく、単一のコレクタ・ソケット５６０に単一のブロック・スレッド待ち行列５７０がある。図８に示すように、受入れ接続待ち行列５３４、５４４、５５４から接続が移動するとき、それらの接続はコレクタ・ソケット５６０の実行可能待ち行列５６２に移動される。
【００７９】
コレクタ・ソケットの使用を可能にするには追加のＡＰＩが必要である。このＡＰＩの目的は、どの受動ソケットがコレクタ・ソケットにマージされるかを示すことである。したがって、このＡＰＩ呼出しは、収集する受動ソケットのリストを備える。この情報は、好ましくは、構成パラメータを使用して伝えられ、システム管理者などのユーザに対して受動ソケット識別子を指定するように求める。この情報を提供するための他の方法も、本発明の進歩的概念から逸脱することなく使用可能である。その後、これらの識別子は、第２の好ましい実施形態に提供される。ユーザから構成パラメータを入手し、実行プログラムに提供する方法は、当業者には明らかであろう。したがって、これについては詳述しない。
【００８０】
コレクタＡＰＩは、サーバが動作を開始するときに発行されることが好ましい。しかし、クライアントがサーバに要求の送信を開始してからコレクタ・ソケットが確立されるまでの間に、ある程度の遅延が存在する可能性がある。図６に、この状況を改善するために使用可能であって、受動ソケットの実行可能待ち行列にすでに移動されている接続がないか見つけるために収集される受動ソケットを検査する論理を示す。これらの接続は、コレクタ・ソケットの実行可能待ち行列に移される。図６の論理は、サーバがすでに実行を開始している後でコレクタＡＰＩを呼び出す場合にも使用することができる。
【００８１】
ステップ４００で、ＡＰＩ呼出しの受信に応答してコレクタ・ソケットが作成される。実行可能待ち行列は空の待ち行列に初期設定される。コレクタ・ソケットとこのソケットを使用するスレッドの実行に関する統計情報の保持を開始するために、（前述の）スケジューリング・ヒューリスティックのために保持される統計情報が初期設定される。コレクタ・ソケットのために、このソケットからの接続を処理するために使用されるスレッドのためのブロック・スレッドの待ち行列が作成される。
【００８２】
ステップ４１０で、指標やループ・カウンタなどの指示機構を使用して、ＡＰＩ呼出し時に提供されるリストから最初の受動ソケット識別子を指示する。リスト内の項目に指標付けする技法は当技術分野で周知であり、詳述しない。
【００８３】
ステップ４２０で、現在指示されている受動ソケットを、コレクタ・ソケットを指すように修正する。これによって、後で受動ソケットでデータを受け取った接続が、データ・パケットをコレクタ・ソケットに転送させることができるようになる。
【００８４】
ステップ４３０で、受動ソケットの実行可能待ち行列を検査して、この接続がすでに実行可能待ち行列に移されているかどうかを調べる。前述のように、受け入れられた接続の最初のデータ・パケットは、コレクタ・ソケットが作成される前に到着している可能性があり、ステップ４３０で、そのような接続をコレクタ・ソケットの実行可能待ち行列に移動させることができるようにする。待ち行列から項目を取り出す技法と、待ち行列に項目を入れる技法は、当技術分野で周知である。
【００８５】
ステップ４４０で、ポインタがリスト内の最後の要素を指しているかどうかを調べることによって、コレクタＡＰＩで識別されているすべての受動ソケットが処理されたかどうかを検査する。この検査の応答が肯定の場合、図６の処理は終了する。否定の場合は、ステップ４５０で、次の受動ソケットを指すようにポインタを増分し、制御はステップ４２０に返る。
【００８６】
作業スレッドがコレクタ・ソケットの実行可能待ち行列から作業を受け取る処理論理は、受動ソケットの実行可能待ち行列から作業を受け取るスレッドに関して図３に示したプロセスと同じである。しかし、前述の図３の説明とは異なる以下の相違点がある。（１）保持される統計情報はコレクタ・ソケットに関して保持され、（２）ブロック作業スレッドの待ち行列は、コレクタ・ソケットに付随する待ち行列であり、（３）検査される実行可能待ち行列はコレクタ・ソケットの実行可能待ち行列であり、（４）作業スレッドはコレクタ・ソケットに対してアクセプト・アンド・レシーブ（ａｃｃｅｐｔ＿ａｎｄ＿ｒｅｃｅｉｖｅ）ＡＰＩを実行する。
【００８７】
この好ましい実施形態で受動ソケットでの着信パケットの受け取りを扱う処理論理は、図４に示すものと類似している。ただし、若干の変更が必要である。ステップ１９５で、コレクタ・ソケットにマージされる受動ソケットのために到着する最初のデータ・パケットを検出した後（すなわちステップ１９５の「Ｙｅｓ」分岐）、接続は受動ソケットの実行可能待ち行列ではなくコレクタ・ソケットの実行可能待ち行列に移動される。ステップ２０５でスケジューリング・ヒューリスティックに使用される統計は、コレクタ・ソケットの統計である。ステップ２１０で覚醒されるスレッドは、コレクタ・ソケットに付随するブロック・スレッド待ち行列内のスレッドである。
【００８８】
コレクタ・ソケットの実行可能接続待ち行列を監視して、スケジュールされるまでに待機する時間が長くなり過ぎる接続がないように保証する処理論理は、図５に示す論理と同じである。しかし、前述の図５の説明とは異なる以下のような相違点がある。（１）監視される実行可能接続待ち行列はコレクタ・ソケットの実行可能待ち行列であり、（２）検査されるブロック・スレッド待ち行列はコレクタ・ソケットに付随する待ち行列であり、（３）ステップ２７０で覚醒されるスレッドは、コレクタ・ソケットに付随するブロック・スレッド待ち行列内のスレッドである。
【００８９】
（図３を参照しながら前述したように）受け入れられた接続が受動ソケットからコレクタ・ソケットに移されるときに、それらの接続と共に、その接続がどの受動ソケットに到着したかを示す情報を渡す必要がある。これは、異なる入力源からの入力に異なる処理が必要な場合があるためである。たとえば、１つの受動ソケットにセキュア接続要求が到着した場合、作業スレッドは、非セキュア接続要求が到着した場合には不要な特別なセキュリティ関係の処理を必要とする。その接続がＳＳＬ使用可能受動ソケットに到着した場合、この特別な処理にはハンドシェーク・プロトコルが含まれる。この特別な処理は本発明の一部を形成しない。本発明の進歩的概念から逸脱することなく、接続の入力源を示す情報を渡すためにいくつかの方法が使用可能である。たとえば、当技術分野で周知のように、接続には様々なタイプの情報を入れるために割り振られた記憶域がある。このデータ域に、着信ソケットの識別子を記憶するためのパラメータを付加することができる。各作業スレッドは、このデータ域を調べて入力源関係の処理が必要かどうかを判断する論理を含む。これによって、プール内の任意のスレッドが、複数の受動ソケットのうちのいずれかのソケットに到着する接続を処理することができる。したがって、静的区分化を使用して受動ソケットに作業スレッドを割り振る必要がなくなる。この実施形態は、コレクタ・ソケットの実行待ち行列にマージされた入力源を有することによって、様々な入力源へのプールの動的区分化を実現する。
【００９０】
コレクタ・ソケットの実行可能待ち行列から要求をスケジュールするための、第１の好ましい実施形態で定義されたスケジューリング・ヒューリスティックの使用は、この第２の実施形態では任意選択である。しかし、その使用によって、コレクタ・ソケット上の接続負荷が使用可能スレッドの数に満たない場合に生じるオーバースケジューリング問題を回避することができる。
【００９１】
図９から図１０に、持続接続問題のある前述のスレッド割当てを改善する第３の実施形態に関与する論理が記載されたフローチャートを示す。
【００９２】
第３の好ましい実施形態は、第２の好ましい実施形態により規定されたコレクタ・ソケットの使用を必要とする。持続接続を使用する場合により効率的な処理を可能にする、コレクタ・ソケットを処理するための改善点を規定する。図８に示す実行可能待ち行列に加えて、コレクタ・ソケットは「遊休接続」待ち行列も有する。本明細書で「ギブバック（ｇｉｖｅｂａｃｋ）」ＡＰＩと呼ぶ、（後述の）追加のＡＰＩを定義する。
【００９３】
作業スレッドがコレクタ・ソケットの実行可能待ち行列から作業を受け取るための処理論理は、第２の好ましい実施形態に関して前述したプロセス（図３を参照）と同じである。作業スレッドは、コレクタ・ソケットの実行可能待ち行列上にある接続のみに割り当てられる。
【００９４】
この第３の好ましい実施形態の受動ソケットで着信パケットの受領を処理する処理論理は、第２の好ましい実施形態に関して前述したもの（図４を参照）と類似している。しかし、若干の変更を要する。ステップ１５５で着信接続要求を検出した後、ステップ１６０で作成される新しいソケットは、この実施形態では２つの追加のデータ値の初期設定を必要とする。第１に、ソケット状況を「実行不能」、すなわち当該接続は現在スケジュールすることができないことを示すように設定しなければならない。第２に、アプリケーション・コンテキストを、当該接続にまだコンテキストが関連づけられていないことを示すヌル値に設定しなければならない。その他の変更は、接続のデータが到着したときに実行される処理に関するものである。ステップ１９５でそれが最初に受け取ったデータ・パケットであるかどうかを調べる検査を行う代わりに、ソケットが「実行可能」と「実行不能」のどちらにマークされているかを問い合わせる検査を行う。状況がすでに「実行可能」に設定されていた場合、制御はステップ１５０に返る。そうでない場合（すなわち状況が「実行不能」だった場合）、制御はステップ２００に進む。現在ステップ２００に示されている処理の代わりに、新しい処理は、（１）ソケットを「実行可能」としてマークするステップと、（２）ソケットを現行待ち行列（受動ソケットの受入れ待ち行列またはコレクタ・ソケットの遊休待ち行列である）から、コレクタ・ソケットの実行可能待ち行列に移動するステップとを含む。
【００９５】
コレクタ・ソケットの実行可能接続待ち行列を監視して、スケジューリングされるまでの待機時間が長すぎる接続がないようにする処理論理は、図５に示すものと同じである。第２の好ましい実施形態に関して説明した図５との相違は、この第３の好ましい実施形態にも当てはまる。
【００９６】
図６を参照しながら第２の好ましい実施形態に関して説明したようにコレクタ・ソケットを作成するとき、１つの追加の変更が必要である。今度は、ステップ４００でコレクタ・ソケットをセットアップするときに空の遊休接続待ち行列を作成しなければならない。
【００９７】
図９に、アプリケーションによる新しいギブバック（ｇｉｖｅｂａｃｋ）ＡＰＩの発行に応答して呼び出される論理を示す。このＡＰＩ呼出しによって、作業スレッドに割り当てられていた（したがってすでにデータを受信していた）ソケットが、そのスレッドから結合解除され、そのスレッドを他の接続に割り当てることが可能になる。このＡＰＩは、持続接続が着信データ要求間で遅延（何らかの所定のしきい値を超える）に遭うと呼び出される。
【００９８】
ステップ６００で、この接続のための未読のデータがあるかどうかを問い合わせる。ギブバック（ｇｉｖｅｂａｃｋ）ＡＰＩが処理中だったときにデータが着信している可能性がある。この条件が真の場合、制御はステップ６５０に移る。そうでない場合、ステップ６１０で接続を遊休待ち行列に移動するプロセスが続けられる。
【００９９】
ステップ６１０で、このソケットを「実行不能」としてマークし、ソケットの項目を遊休接続待ち行列に入れる。遊休接続数のカウンタが増分される。ソケットが遊休待ち行列に入れられるとき、このＡＰＩの入力パラメータである、この接続に関連づけられたアプリケーション・コンテキスト値がソケットと共に格納される。これによって、アプリケーションは後でデータが到着したときに同じソケットを使用して処理を再開できるようになる。
【０１００】
ステップ６２０で、遊休接続カウンタの現行値が最大値（構成パラメータまたは静的値として設定することができる）と比較される。この検査の応答が肯定の場合、遊休状態の接続が多すぎ、ステップ６３０に制御を移すことによって最も古い接続が除去される。最大値を超えていない場合、図９の処理は終了する。
【０１０１】
ステップ６３０で、遊休接続待ち行列上の最も古い接続を除去しなければならない。好ましくは、遊休接続待ち行列はＦＩＦＯ待ち行列であり、したがってステップ６３０は待ち行列の先頭を指すステップを含む。この接続は閉じられ、使用していた資源は解放される。ステップ６４０で、「Expired（期限切れ）」であることを示すようにソケットにマークを付け遊休待ち行列から外すことによって、このプロセスが開始される。遊休接続のカウントが減分され、ステップ６５０で、このソケットは実行可能待ち行列に移動される。実行可能待ち行列から接続が作業スレッドにスケジュールされると、その作業スレッドによってクローズ・プロセスは完了される。ステップ６６０からステップ６８０で、第１の好ましい実施形態に関して説明したスケジューリング・ヒューリスティックが実行され、それによって、接続はスレッドをアンブロックすることによってこの時点でスケジュールされるか、または使用中のスレッドが使用可能になり、（図３の修正したプロセスを使用して）コレクタ・ソケットの実行可能待ち行列を調べの時点でスケジューリングされるのを待つ。ステップ６６０で、スレッドがスケジュールされるのを待つことが示された場合、またはステップ６８０でアンブロック・スレッドへの接続の割当てが終了した場合、図９の処理は完了する。
【０１０２】
このギブバック（ｇｉｖｅｂａｃｋ）ＡＰＩの使用によってコレクタ・ソケットの遊休接続待ち行列に入れられた接続は、以下のいずれか１つの条件が満たされるまでそこにとどまる。すなわち、（１）さらにデータが到着するか、（２）クライアントから接続クローズ要求を受け取るか、（３）接続が最大時間を超えて遊休状態のままになっているか、または（４）遊休接続のカウントが高くなり過ぎるという条件である。条件１の場合、接続を遊休待ち行列上に保持することによって、最初のデータ要求の受領によってスケジューリングされる接続について通常行われる初期設定ステップを踏まずに、接続を後続の作業スレッドに割り当てることができる。この第３の実施形態に関して前述した図４の修正された論理によって、この追加のデータの到着が検出され、接続の再スケジュールが処理される。条件４は、図９のステップ６２０〜６８０に関して前述したプロセスである。以下で、条件２および３について詳述する。
【０１０３】
クライアントが接続を閉じることを要求する条件２の場合、接続を遊休接続待ち行列からコレクタ・ソケットの実行可能待ち行列に移動しなければならない。これは、接続が遊休状態を続けている間、その接続のためのアプリケーション・コンテキストが保持されており、この時点でそれを作業スレッドによって打ち切る必要があるためである。接続は図４のステップ２００の修正された論理を使用して実行可能待ち行列に移動される。
【０１０４】
接続が遊休状態になっている時間が長すぎる条件３の場合、図１０の処理が使用される。実行可能待ち行列に入っている時間が長すぎる接続がないか検査する第１および第２の実施形態で使用した遅延モニタを、前述のようにこの第３の実施形態でも実行する。しかし、図１０に示す、遊休接続待ち行列を検査する追加の監視手続きも使用する。
【０１０５】
図１０の処理は何らかの所定の間隔で呼び出され、この間隔は構成パラメータとすることができる。この呼出しを行うためにタイマを使用することもできる。ステップ７００で、遊休待ち行列から最も古い遊休ソケットを入手する。前述のように、好ましくは、遊休接続待ち行列はＦＩＦＯ待ち行列であり、したがってステップ７００は待ち行列の先頭を指すステップを含む。ステップ７１０で、当該接続が遊休状態のままである時間が長すぎないかどうかを検査する。ギブバック（ｇｉｖｅｂａｃｋ）ＡＰＩにタイムアウト・パラメータを組み込むことによって、各接続は定義されたそれ自体の最大遊休期間を有することができる。このパラメータ値は、接続の項目と共に遊休待ち行列に格納される。あるいは、たとえば構成時に値を指定することによって、各接続に同じ最大遊休時間を使用することもできる。
【０１０６】
接続がまだ最大遊休時間に達していない場合、制御はステップ７２０に進む。したがって、接続は遊休待ち行列にとどまることができる。ステップ７２０で、これが遊休接続待ち行列上の最後の接続かどうかを問い合わせる。最後の接続の場合、それ以上検査する接続はなく、したがって図１０のプロセスは終了する。最後の接続でない場合、ステップ７３０で、待ち行列内の次の接続を指示し、制御はステップ７１０に返ってその接続を検査する。
【０１０７】
検査している接続が最大遊休時間を超えて遊休状態であった場合、制御はステップ７４０に進む。送るべきデータがないときに当該接続のためのアプリケーション・コンテキストを開いたままにしておくと、システム資源が効率的に使用されないため、接続は閉じられ、資源が解放される。ステップ７４０で、ソケットを「Expired（期限切れ）」を示すようにマークし、遊休待ち行列から除去することによって、このプロセスが開始される。遊休接続のカウントが減分され、ステップ７５０でソケットが実行可能待ち行列に移される。接続がスケジュールされると、作業スレッドがこのクローズ・プロセスを完了させる。ステップ７６０から７８０で、第１の好ましい実施形態で説明したスケジューリング・ヒューリスティックが実行され、それによって接続はスレッドをアンブロックすることによってこの時点でスケジュールされるか、または使用中のスレッドが使用可能になり、（図３の修正したプロセスを使用して）コレクタ・ソケットの実行可能待ち行列を検査する時点でスケジュールされるのを待つ。ステップ７６０で、スレッドがスケジュールされるのを待つことが示された場合、またはステップ７８０でアンブロック・スレッドへの接続の割当てが終了した場合、制御はステップ７２０に返り、遊休待ち行列になお接続があるかどうかを調べる。
【０１０８】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１０９】
（１） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
接続を求める複数のクライアント要求と、
複数の作業スレッドと、
前記複数のクライアント要求を受け取るサブプロセスと、
スケジューラが前記クライアント要求の各々に新しい作業スレッドを覚醒させることを緩和するために、スケジューリング・ヒューリスティックを実施するサブプロセスであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するサブプロセスと
を含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（２） 前記作業スレッドの第１のグループがアクティブ・スレッドであり、前記第１のグループが、前記複数の作業スレッドのうちの変更可能な作業スレッドから成りかつ変更可能な数の前記変更可能な作業スレッドを有し、前記変更可能な数が少なくとも１であり、
前記スケジューリング・ヒューリスティックを実施する前記サブプロセスが、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らして前記第１のグループ内の前記変更可能な数のバランスをとるサブプロセスをさらに含む、請求項１に記載のマルチスレッド・アプリのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（３） バランスをとる前記サブプロセスが平均遅延の使用をさらに含む、（２）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（４） バランスをとる前記サブプロセスが最大遅延の使用をさらに含む、（３）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（５） 前記平均遅延および前記最大遅延が構成パラメータである、（４）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（６） 前記作業スレッドの第２のグループがブロック・スレッドであり、前記第２のグループが前記複数の作業スレッドのうちの前記第１のグループに入っていない作業スレッドから成り、
前記ブロック・スレッドが後入れ先出し待ち行列に格納される、（２）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（７） 前記スケジューリング・ヒューリスティックが使用可能な作業スレッドの数を最適化する、（１〜６のいずれか１項）に記載のマルチスレッド・アプリのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（８） ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるサブプロセスと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から第２の待ち行列に移動させるサブプロセスと、
前記第２の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスと
を含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（９） ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
複数の発生源から入力を受け取るサブプロセスと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするサブプロセスと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるサブプロセスと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるサブプロセスと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとをさらに含む、
コンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１０） ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
複数の発生源から入力を受け取るサブプロセスと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするサブプロセスと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるサブプロセスと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるサブプロセスと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとをさらに含み、
スケジューリングのためにマージする前記サブプロセスが、
複数の作業スレッドのうちの変更可能な作業スレッドから成り且つ前記変更可能な作業スレッドの変更可能な数を有するアクティブ作業スレッドのグループであって、前記変更可能な数が少なくとも１である、前記アクティブ作業スレッドのグループを含み、
前記単一の待ち行列に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ作業スレッドのグループ内の前記変更可能な数のバランスをとるためにスケジューリング・ヒューリスティックを実施するサブプロセスであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するサブプロセスと
をさらに含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１１） ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
複数の持続接続と、
複数の作業スレッドと、
前記持続接続のうちの選択された持続接続を前記作業スレッドのうちの選択された作業スレッドに結合するサブプロセスであって、その実行の結果として結合接続が生じるサブプロセスと、
前記結合接続のうちの選択された結合接続を結合解除するサブプロセスであって、その実行の結果として結合解除された作業スレッドが生じるサブプロセスと
を含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１２） 結合する前記サブプロセスが２段階待ち行列を使用するステップをさらに含み、
結合解除する前記サブプロセスが前記２段階待ち行列を使用するステップをさらに含む、（１１）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１３） 前記２段階待ち行列を使用して結合する前記サブプロセスが、
前記接続の最初のデータ・パケットが到着すると、各前記持続接続を前記第２の段階に移動させるサブプロセスと、
前記接続のデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させるサブプロセスと、
前記第１の段階から前記持続接続をスケジュールするサブプロセスと
をさらに含み、
前記２段階待ち行列を使用して結合解除する前記サブプロセスが、
前記選択された結合接続が遊休状態になると、前記結合接続のうちの選択された結合接続を前記第１の段階から前記第２の段階に移動させるサブプロセスと、
最大遊休期間を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちの選択された持続接続を閉じるサブプロセスと、
前記結合解除された作業スレッドを、結合する前記サブプロセスに使用可能にするサブプロセスと
をさらに含む、（１２）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１４） 結合解除する前記サブプロセスが、
最大遊休接続数を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちのさらに選択された持続接続を閉じるサブプロセスをさらに含む、（１３）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
（１５） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
接続を求める複数のクライアント要求と、
複数の作業スレッドと、
スケジューラと、
前記複数のクライアント要求を受け取る手段と、
前記スケジューラが前記クライアント要求の各々に新しい作業スレッドを覚醒させることを緩和すために、スケジューリング・ヒューリスティックを実施する手段であって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施する手段と
を含むシステム。
（１６） 前記作業スレッドの第１のグループがアクティブ・スレッドであり、前記第１のグループが前記複数の作業スレッドのうちの変更可能な作業スレッドから成りかつ変更可能な数の前記変更可能な作業スレッドを有し、前記変更可能な数が少なくとも１であり、
前記スケジューリング・ヒューリスティックを実施する前記手段が、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らして前記第１のグループ内の前記変更可能な数のバランスをとる手段をさらに含む、（１５）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（１７） バランスをとる前記手段が平均遅延の使用をさらに含む、（１６）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（１８） バランスをとる前記手段が最大遅延の使用をさらに含む、（１７）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（１９） 前記平均遅延および前記最大遅延が構成パラメータである、（１８）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２０） 前記作業スレッドの第２のグループがブロック・スレッドであり、前記第２のグループが前記複数の作業スレッドのうちの前記第１のグループに入っていない作業スレッドから成り、
前記ブロック・スレッドが後入れ先出し待ち行列に格納される、（１６）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２１） 前記スケジューリング・ヒューリスティックが使用可能な作業スレッドの数を最適化する、（１５〜２０のいずれか１項）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２２） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させる手段と、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から第２の待ち行列に移動させる手段と、
前記第２の待ち行列上の各前記接続に作業スレッドを割り当てる手段と
を含むシステム。
（２３） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
複数の発生源から入力を受け取る手段と、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージする手段と
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させる手段と、
前記接続の最初のデータ・パケットが到着すると、前記各接続を前記第１の待ち行列から前記単一の待ち行列に移動させる手段と、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てる手段と
をさらに含む、システム。
（２４） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
複数の発生源から入力を受け取る手段と、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージする手段と
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させる手段と、
前記接続の最初のデータ・パケットが到着すると、前記各接続を前記第１の待ち行列から前記単一の待ち行列に移動させる手段と、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てる手段と
をさらに含み、
スケジューリングのためにマージする前記手段が、
複数の作業スレッドのうちの変更可能な作業スレッドから成り且つ前記変更可能な作業スレッドの変更可能な数を有するアクティブ作業スレッドのグループであって、前記変更可能な数が少なくとも１である、前記アクティブ作業スレッドのグループを含み、
前記単一の待ち行列に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ作業スレッドのグループ内の前記変更可能な数のバランスをとるためにスケジューリング・ヒューリスティックを実施する手段であって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施する手段と
をさらに含む、システム。
（２５） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
複数の持続接続と、
複数の作業スレッドと、
前記持続接続のうちの選択された持続接続を前記作業スレッドのうちの選択された作業スレッドに結合する手段であって、結合の実行の結果として結合接続が生じる手段と、
前記結合接続のうちの選択された結合接続を結合解除する手段であって、結合解除の実行の結果として結合解除された作業スレッドが生じる手段と
を含むシステム。
（２６） 結合する前記手段が２段階待ち行列を使用する手段をさらに含み、
結合解除する前記手段が前記２段階待ち行列を使用する手段をさらに含む、（２５）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２７） 前記２段階待ち行列を使用して結合する前記手段が、
前記接続の最初のデータ・パケットが到着すると、各前記持続接続を前記第２の段階に移動させる手段と、
前記接続のデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させる手段と、
前記第１の段階から前記持続接続をスケジュールする手段と
をさらに含み、
前記２段階待ち行列を使用して結合解除する前記手段が、
前記選択された結合接続が遊休状態になると、前記結合接続のうちの選択された結合接続を前記第１の段階から前記第２の段階に移動させる手段と、
最大遊休期間を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちの選択された持続接続を閉じる手段と、
前記結合解除された作業スレッドを、結合する前記手段に使用可能にする手段と
をさらに含む、（２６）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２８） 結合解除する前記手段が、
最大遊休接続数を超えるとそれに応答して、前記第２段階にある前記持続接続のうちのさらに選択された持続接続を閉じる手段をさらに含む、（２７）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
（２９） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
接続を求める複数のクライアント要求を受け取るステップと、
スケジューラが前記クライアント要求の各々に新しい作業スレッドを覚醒させることを緩和するためにスケジューリング・ヒューリスティックを実施するステップであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するステップと
を含む方法。
（３０） 前記作業スレッドの第１のグループがアクティブ・スレッドであり、前記第１のグループが、前記複数の作業スレッドのうちの変更可能な作業スレッドから成りかつ変更可能な数の前記変更可能な作業スレッドを有し、前記変更可能な数が少なくとも１であり、
前記スケジューリング・ヒューリスティックを実施する前記ステップが、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らして前記第１のグループ内の前記変更可能な数のバランスをとるステップをさらに含む、（２９）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３１） バランスをとる前記ステップが平均遅延の使用をさらに含む、（３０）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３２） バランスをとる前記ステップが最大遅延の使用をさらに含む、（３１）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３３） 前記平均遅延および前記最大遅延が構成パラメータである、（３２）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３４） 前記作業スレッドの第２のグループがブロック・スレッドであり、前記第２のグループが前記複数の作業スレッドのうちの前記第１のグループに入っていない作業スレッドから成り、
前記ブロック・スレッドが後入れ先出し待ち行列に格納される、（３０）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３５） 前記スケジューリング・ヒューリスティックが使用可能な作業スレッドの数を最適化する、（２９〜３４のいずれか１項）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（３６） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるステップと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から第２の待ち行列に移動させるステップと、
前記第２の待ち行列上の各前記接続に作業スレッドを割り当てるステップと
を含む方法。
（３７） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
複数の発生源から入力を受け取るステップと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするステップと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるステップと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるステップと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるステップと
をさらに含む方法。
（３８） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
複数の発生源から入力を受け取るステップと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするステップと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるステップと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるステップと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるステップと
をさらに含み、
複数の作業スレッドのうちの変更可能な作業スレッドから成り、前記変更可能な作業スレッドの変更可能な数を有し、前記変更可能な数が少なくとも１であるアクティブ作業スレッドのグループをさらに含み、
スケジューリングのために前記マージするステップが、
前記単一の待ち行列に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ・グループ内の前記変更可能な数のバランスをとるためにスケジューリング・ヒューリスティックを実施するステップであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するステップと
をさらに含む、方法。
（３９） ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
複数の持続接続のうちの選択された持続接続を複数の作業スレッドのうちの選択された作業スレッドに結合するステップであって、結合ステップの実行の結果として結合接続が生じるステップと、
前記結合接続のうちの選択された結合接続を結合解除する手段であって、結合解除ステップの実行の結果として結合解除された作業スレッドが生じるステップと
を含む方法。
（４０） 前記結合ステップが２段階待ち行列を使用するステップをさらに含み、
前記結合解除ステップが前記２段階待ち行列を使用するステップをさらに含む、（３９）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（４１） 前記２段階待ち行列を使用して結合する前記ステップが、
前記持続接続の最初のデータ・パケットが到着すると、各前記持続接続を前記第２の段階に移動させるステップと、
前記持続接続のデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させるステップと、
前記第１の段階から前記持続接続をスケジュールするステップと
をさらに含み、
前記２段階待ち行列を使用して結合解除する前記ステップが、
前記選択された結合接続が遊休状態になると、前記結合接続のうちの選択された結合接続を前記第１の段階から前記第２の段階に移動させるステップと、
最大遊休期間を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちの選択された持続接続を閉じるステップと、
前記結合解除された作業スレッドを、結合する前記ステップに使用可能にするステップと
をさらに含む、（４０）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
（４２） 結合解除する前記ステップが、
最大遊休接続数を超えるとそれに応答して、前記第２段階にある前記持続接続のうちのさらに選択された持続接続を閉じるステップをさらに含む、（４１）に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
【図面の簡単な説明】
【図１】本発明を実施することができるコンピュータ・ワークステーション環境を示すブロック図である。
【図２】本発明を実施することができるネットワーク・コンピューティング環境を示す図である。
【図３】オーバースケジューリング問題を改善する本発明に関係する論理を記載したフローチャートである。
【図４】オーバースケジューリング問題を改善する本発明に関係する論理を記載したフローチャートである。
【図５】オーバースケジューリング問題を改善する本発明に関係する論理を記載したフローチャートである。
【図６】マージされた入力をスケジューリングに使用可能にあうるために、複数の入力源からの入力をマージする場合の、本発明に関係する論理を記載したフローチャートである。
【図７】本発明によって使用される多段階待ち行列を示す概念図である。
【図８】本発明によって使用される多段階待ち行列を示す概念図である。
【図９】持続接続を使用する場合に、着信要求へのスレッドの割当てを最適化する本発明に関係する論理を記載したフローチャートである。
【図１０】持続接続を使用する場合に、着信要求へのスレッドの割当てを最適化する本発明に関係する論理を記載したフローチャートである。
【符号の説明】
１０ ワークステーション
１２ マイクロプロセッサ
１４ バス
１６ ユーザ・インタフェース・アダプタ
１８ キーボード
２０ マウス
２４ 表示装置
２６ ディスプレイ・アダプタ
２８ サーバ・メモリ
３０ 長期記憶域
４０ データ処理ネットワーク
４４ ローカル・エリア・ネットワーク
４６ メインフレーム・コンピュータ（サーバ）
４８ 通信リンク
Claims (42)
- ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
接続を求める複数のクライアント要求と、
複数の作業スレッドと、
前記複数のクライアント要求を受け取るサブプロセスと、
スケジューラが前記クライアント要求の各々に新しい作業スレッドを覚醒させることを緩和するために、スケジューリング・ヒューリスティックを実施するサブプロセスであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するサブプロセスと
を含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。 - 前記作業スレッドの第１のグループがアクティブ・スレッドであり、前記第１のグループが、前記複数の作業スレッドのうちの変更可能な作業スレッドから成りかつ変更可能な数の前記変更可能な作業スレッドを有し、前記変更可能な数が少なくとも１であり、
前記スケジューリング・ヒューリスティックを実施する前記サブプロセスが、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らして前記第１のグループ内の前記変更可能な数のバランスをとるサブプロセスをさらに含む、請求項１に記載のマルチスレッド・アプリのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。 - バランスをとる前記サブプロセスが平均遅延の使用をさらに含む、請求項２に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
- バランスをとる前記サブプロセスが最大遅延の使用をさらに含む、請求項３に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
- 前記平均遅延および前記最大遅延が構成パラメータである、請求項４に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
- 前記作業スレッドの第２のグループがブロック・スレッドであり、前記第２のグループが前記複数の作業スレッドのうちの前記第１のグループに入っていない作業スレッドから成り、
前記ブロック・スレッドが後入れ先出し待ち行列に格納される、請求項２に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。 - 前記スケジューリング・ヒューリスティックが使用可能な作業スレッドの数を最適化する、請求項１〜６のいずれか１項に記載のマルチスレッド・アプリのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。
- ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるサブプロセスと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から第２の待ち行列に移動させるサブプロセスと、
前記第２の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスと
を含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。 - ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
複数の発生源から入力を受け取るサブプロセスと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするサブプロセスと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるサブプロセスと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるサブプロセスと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとをさらに含む、
コンピュータ可読コードを記録したコンピュータ可読記録媒体。 - ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
複数の発生源から入力を受け取るサブプロセスと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするサブプロセスと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるサブプロセスと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるサブプロセスと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるサブプロセスとをさらに含み、
スケジューリングのためにマージする前記サブプロセスが、
複数の作業スレッドのうちの変更可能な作業スレッドから成り且つ前記変更可能な作業スレッドの変更可能な数を有するアクティブ作業スレッドのグループであって、前記変更可能な数が少なくとも１である、前記アクティブ作業スレッドのグループを含み、
前記単一の待ち行列に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ作業スレッドのグループ内の前記変更可能な数のバランスをとるためにスケジューリング・ヒューリスティックを実施するサブプロセスであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するサブプロセスと
をさらに含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。 - ネットワークへの接続を有するコンピューティング環境において、マルチスレッド・アプリケーションのパフォーマンスを強化するための、前記環境内のコンピュータ・システムによって読取り可能なコンピュータ可読コードを記録したコンピュータ可読記録媒体であって、
複数の持続接続と、
複数の作業スレッドと、
前記持続接続のうちの選択された持続接続を前記作業スレッドのうちの選択された作業スレッドに結合するサブプロセスであって、その実行の結果として結合接続が生じるサブプロセスと、
前記結合接続のうちの選択された結合接続を結合解除するサブプロセスであって、その実行の結果として結合解除された作業スレッドが生じるサブプロセスと
を含むコンピュータ可読コードを記録したコンピュータ可読記録媒体。 - 結合する前記サブプロセスが２段階待ち行列を使用するステップをさらに含み、
結合解除する前記サブプロセスが前記２段階待ち行列を使用するステップをさらに含む、請求項１１に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。 - 前記２段階待ち行列を使用して結合する前記サブプロセスが、
前記接続の最初のデータ・パケットが到着すると、各前記持続接続を前記第２の段階に移動させるサブプロセスと、
前記接続のデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させるサブプロセスと、
前記第１の段階から前記持続接続をスケジュールするサブプロセスと
をさらに含み、
前記２段階待ち行列を使用して結合解除する前記サブプロセスが、
前記選択された結合接続が遊休状態になると、前記結合接続のうちの選択された結合接続を前記第１の段階から前記第２の段階に移動させるサブプロセスと、
最大遊休期間を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちの選択された持続接続を閉じるサブプロセスと、
前記結合解除された作業スレッドを、結合する前記サブプロセスに使用可能にするサブプロセスと
をさらに含む、請求項１２に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。 - 結合解除する前記サブプロセスが、
最大遊休接続数を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちのさらに選択された持続接続を閉じるサブプロセスをさらに含む、請求項１３に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するためのコンピュータ可読コードを記録したコンピュータ可読記録媒体。 - ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
接続を求める複数のクライアント要求と、
複数の作業スレッドと、
スケジューラと、
前記複数のクライアント要求を受け取る手段と、
前記スケジューラが前記クライアント要求の各々に新しい作業スレッドを覚醒させることを緩和すために、スケジューリング・ヒューリスティックを実施する手段であって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施する手段と
を含むシステム。 - 前記作業スレッドの第１のグループがアクティブ・スレッドであり、前記第１のグループが前記複数の作業スレッドのうちの変更可能な作業スレッドから成りかつ変更可能な数の前記変更可能な作業スレッドを有し、前記変更可能な数が少なくとも１であり、
前記スケジューリング・ヒューリスティックを実施する前記手段が、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らして前記第１のグループ内の前記変更可能な数のバランスをとる手段をさらに含む、請求項１５に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。 - バランスをとる前記手段が平均遅延の使用をさらに含む、請求項１６に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
- バランスをとる前記手段が最大遅延の使用をさらに含む、請求項１７に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
- 前記平均遅延および前記最大遅延が構成パラメータである、請求項１８に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
- 前記作業スレッドの第２のグループがブロック・スレッドであり、前記第２のグループが前記複数の作業スレッドのうちの前記第１のグループに入っていない作業スレッドから成り、
前記ブロック・スレッドが後入れ先出し待ち行列に格納される、請求項１６に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。 - 前記スケジューリング・ヒューリスティックが使用可能な作業スレッドの数を最適化する、請求項１５〜２０のいずれか１項に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。
- ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させる手段と、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から第２の待ち行列に移動させる手段と、
前記第２の待ち行列上の各前記接続に作業スレッドを割り当てる手段と
を含むシステム。 - ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
複数の発生源から入力を受け取る手段と、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージする手段と
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させる手段と、
前記接続の最初のデータ・パケットが到着すると、前記各接続を前記第１の待ち行列から前記単一の待ち行列に移動させる手段と、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てる手段と
をさらに含む、システム。 - ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
複数の発生源から入力を受け取る手段と、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージする手段と
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させる手段と、
前記接続の最初のデータ・パケットが到着すると、前記各接続を前記第１の待ち行列から前記単一の待ち行列に移動させる手段と、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てる手段と
をさらに含み、
スケジューリングのためにマージする前記手段が、
複数の作業スレッドのうちの変更可能な作業スレッドから成り且つ前記変更可能な作業スレッドの変更可能な数を有するアクティブ作業スレッドのグループであって、前記変更可能な数が少なくとも１である、前記アクティブ作業スレッドのグループを含み、
前記単一の待ち行列に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ作業スレッドのグループ内の前記変更可能な数のバランスをとるためにスケジューリング・ヒューリスティックを実施する手段であって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲ より小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施する手段と
をさらに含む、システム。 - ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化するシステムであって、
複数の持続接続と、
複数の作業スレッドと、
前記持続接続のうちの選択された持続接続を前記作業スレッドのうちの選択された作業スレッドに結合する手段であって、結合の実行の結果として結合接続が生じる手段と、
前記結合接続のうちの選択された結合接続を結合解除する手段であって、結合解除の実行の結果として結合解除された作業スレッドが生じる手段と
を含むシステム。 - 結合する前記手段が２段階待ち行列を使用する手段をさらに含み、
結合解除する前記手段が前記２段階待ち行列を使用する手段をさらに含む、請求項２５に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。 - 前記２段階待ち行列を使用して結合する前記手段が、
前記接続の最初のデータ・パケットが到着すると、各前記持続接続を前記第２の段階に移動させる手段と、
前記接続のデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させる手段と、
前記第１の段階から前記持続接続をスケジュールする手段と
をさらに含み、
前記２段階待ち行列を使用して結合解除する前記手段が、
前記選択された結合接続が遊休状態になると、前記結合接続のうちの選択された結合接続を前記第１の段階から前記第２の段階に移動させる手段と、
最大遊休期間を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちの選択された持続接続を閉じる手段と、
前記結合解除された作業スレッドを、結合する前記手段に使用可能にする手段と
をさらに含む、請求項２６に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。 - 結合解除する前記手段が、
最大遊休接続数を超えるとそれに応答して、前記第２段階にある前記持続接続のうちのさらに選択された持続接続を閉じる手段をさらに含む、請求項２７に記載のマルチスレッド・アプリケーションのパフォーマンスを強化するシステム。 - ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
接続を求める複数のクライアント要求を受け取るステップと、
スケジューラが前記クライアント要求の各々に新しい作業スレッドを覚醒させることを緩和するためにスケジューリング・ヒューリスティックを実施するステップであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するステップと
を含む方法。 - 前記作業スレッドの第１のグループがアクティブ・スレッドであり、前記第１のグループが、前記複数の作業スレッドのうちの変更可能な作業スレッドから成りかつ変更可能な数の前記変更可能な作業スレッドを有し、前記変更可能な数が少なくとも１であり、
前記スケジューリング・ヒューリスティックを実施する前記ステップが、前記複数のクライアント要求のうちの１つまたは複数のクライアント要求から成る現行作業負荷に照らして前記第１のグループ内の前記変更可能な数のバランスをとるステップをさらに含む、請求項２９に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。 - バランスをとる前記ステップが平均遅延の使用をさらに含む、請求項３０に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
- バランスをとる前記ステップが最大遅延の使用をさらに含む、請求項３１に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
- 前記平均遅延および前記最大遅延が構成パラメータである、請求項３２に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
- 前記作業スレッドの第２のグループがブロック・スレッドであり、前記第２のグループが前記複数の作業スレッドのうちの前記第１のグループに入っていない作業スレッドから成り、
前記ブロック・スレッドが後入れ先出し待ち行列に格納される、請求項３０に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。 - 前記スケジューリング・ヒューリスティックが使用可能な作業スレッドの数を最適化する、請求項２９〜３４のいずれか１項に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
- ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるステップと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から第２の待ち行列に移動させるステップと、
前記第２の待ち行列上の各前記接続に作業スレッドを割り当てるステップと
を含む方法。 - ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
複数の発生源から入力を受け取るステップと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするステップと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるステップと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるステップと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるステップと
をさらに含む方法。 - ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
複数の発生源から入力を受け取るステップと、
前記受け取った入力をスケジューリングのために単一の待ち行列にマージするステップと
を含み、
各前記接続が受け入れられると、接続を保留接続待ち行列から第１の待ち行列に移動させるステップと、
前記接続の最初のデータ・パケットが到着すると、前記接続を前記第１の待ち行列から前記単一の待ち行列に移動させるステップと、
前記単一の待ち行列上の各前記接続に作業スレッドを割り当てるステップと
をさらに含み、
複数の作業スレッドのうちの変更可能な作業スレッドから成り、前記変更可能な作業スレッドの変更可能な数を有し、前記変更可能な数が少なくとも１であるアクティブ作業スレッドのグループをさらに含み、
スケジューリングのために前記マージするステップが、
前記単一の待ち行列に格納された前記クライアント要求から成る現行作業負荷に照らして前記アクティブ・グループ内の前記変更可能な数のバランスをとるためにスケジューリング・ヒューリスティックを実施するステップであって、前記スケジューリング・ヒューリスティックは、式
Ｒ＝（Ｃ×Ｔ×Ｄ）−（Ｔ／２）
（ここで、Ｒ＝待ち行列内項目数、
Ｃ＝１つの作業スレッドが完了することができる毎秒の平均接続数、
Ｔ＝現在実行中のスレッドの数、
Ｄ＝要求が待ち行列上で待機する平均受容可能遅延時間、
である）で表され、
接続数が、Ｒより大きい若しくは等しい場合に待機スレッドをアンブロックし又はＲより小さい場合に接続はすべて待ち行列に残って実行中のスレッドが完了するのを待つ、前記実施するステップと
をさらに含む、方法。 - ネットワークへの接続を有するコンピューティング環境においてマルチスレッド・アプリケーションのパフォーマンスを強化する方法であって、
複数の持続接続のうちの選択された持続接続を複数の作業スレッドのうちの選択された作業スレッドに結合するステップであって、結合ステップの実行の結果として結合接続が生じるステップと、
前記結合接続のうちの選択された結合接続を結合解除する手段であって、結合解除ステップの実行の結果として結合解除された作業スレッドが生じるステップと
を含む方法。 - 前記結合ステップが２段階待ち行列を使用するステップをさらに含み、
前記結合解除ステップが前記２段階待ち行列を使用するステップをさらに含む、請求項３９に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。 - 前記２段階待ち行列を使用して結合する前記ステップが、
前記持続接続の最初のデータ・パケットが到着すると、各前記持続接続を前記第２の段階に移動させるステップと、
前記持続接続のデータを受け取ると各前記持続接続を前記第２の段階から前記第１の段階に移動させるステップと、
前記第１の段階から前記持続接続をスケジュールするステップと
をさらに含み、
前記２段階待ち行列を使用して結合解除する前記ステップが、
前記選択された結合接続が遊休状態になると、前記結合接続のうちの選択された結合接続を前記第１の段階から前記第２の段階に移動させるステップと、
最大遊休期間を超えるとそれに応答して、前記第２の段階にある前記持続接続のうちの選択された持続接続を閉じるステップと、
前記結合解除された作業スレッドを、結合する前記ステップに使用可能にするステップと
をさらに含む、請求項４０に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。 - 結合解除する前記ステップが、
最大遊休接続数を超えるとそれに応答して、前記第２段階にある前記持続接続のうちのさらに選択された持続接続を閉じるステップをさらに含む、請求項４１に記載のマルチスレッド・アプリケーションのパフォーマンスを強化する方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/097,282 US6427161B1 (en) | 1998-06-12 | 1998-06-12 | Thread scheduling techniques for multithreaded servers |
| US09/097282 | 1998-06-12 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000029815A JP2000029815A (ja) | 2000-01-28 |
| JP3555846B2 true JP3555846B2 (ja) | 2004-08-18 |
Family
ID=22262616
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP14109999A Expired - Fee Related JP3555846B2 (ja) | 1998-06-12 | 1999-05-21 | スレッド・サーバのパフォーマンス強化方法および装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (2) | US6427161B1 (ja) |
| JP (1) | JP3555846B2 (ja) |
| KR (1) | KR100326990B1 (ja) |
Families Citing this family (131)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6353616B1 (en) * | 1998-05-21 | 2002-03-05 | Lucent Technologies Inc. | Adaptive processor schedulor and method for reservation protocol message processing |
| US6859834B1 (en) * | 1999-08-13 | 2005-02-22 | Sun Microsystems, Inc. | System and method for enabling application server request failover |
| US6754714B1 (en) * | 1999-10-05 | 2004-06-22 | Cisco Technology, Inc. | Multilink point-to-point protocol network access server channel allocation method and apparatus |
| AU2056401A (en) * | 1999-12-02 | 2001-06-12 | Senvid, Inc. | Method, system and service model for remote recording of television programs |
| US8793374B2 (en) * | 1999-12-02 | 2014-07-29 | Western Digital Technologies, Inc. | Managed peer-to-peer applications, systems and methods for distributed data access and storage |
| US7917628B2 (en) * | 1999-12-02 | 2011-03-29 | Western Digital Technologies, Inc. | Managed peer-to-peer applications, systems and methods for distributed data access and storage |
| US8688797B2 (en) * | 1999-12-02 | 2014-04-01 | Western Digital Technologies, Inc. | Managed peer-to-peer applications, systems and methods for distributed data access and storage |
| US9191443B2 (en) * | 1999-12-02 | 2015-11-17 | Western Digital Technologies, Inc. | Managed peer-to-peer applications, systems and methods for distributed data access and storage |
| US7587467B2 (en) * | 1999-12-02 | 2009-09-08 | Western Digital Technologies, Inc. | Managed peer-to-peer applications, systems and methods for distributed data access and storage |
| US7934251B2 (en) | 1999-12-02 | 2011-04-26 | Western Digital Technologies, Inc. | Managed peer-to-peer applications, systems and methods for distributed data access and storage |
| US7120692B2 (en) | 1999-12-02 | 2006-10-10 | Senvid, Inc. | Access and control system for network-enabled devices |
| US7137115B2 (en) * | 2000-01-25 | 2006-11-14 | Fujitsu Limited | Method for controlling multithreading |
| US8161182B1 (en) | 2000-01-26 | 2012-04-17 | Cisco Technology, Inc. | Managing network congestion using dynamically advertised congestion status |
| US6658449B1 (en) | 2000-02-17 | 2003-12-02 | International Business Machines Corporation | Apparatus and method for periodic load balancing in a multiple run queue system |
| US6904459B1 (en) * | 2000-03-14 | 2005-06-07 | Microsoft Corporation | Methods and systems for preventing socket flooding during denial of service attacks |
| US7069313B2 (en) * | 2000-03-14 | 2006-06-27 | Microsoft Corporation | Methods and systems for preventing socket flooding during denial of service attacks |
| US6874027B1 (en) * | 2000-04-07 | 2005-03-29 | Network Appliance, Inc. | Low-overhead threads in a high-concurrency system |
| US6941379B1 (en) * | 2000-05-23 | 2005-09-06 | International Business Machines Corporation | Congestion avoidance for threads in servers |
| US7140018B1 (en) * | 2000-06-20 | 2006-11-21 | International Business Machines Corporation | Method of using a distinct flow of computational control as a reusable abstract data object |
| WO2002013048A2 (en) * | 2000-08-03 | 2002-02-14 | Prelude Systems, Inc. | System and method for client-server communication |
| US6553406B1 (en) * | 2000-08-03 | 2003-04-22 | Prelude Systems, Inc. | Process thread system receiving request packet from server thread, initiating process thread in response to request packet, synchronizing thread process between clients-servers. |
| US7475293B1 (en) | 2000-08-04 | 2009-01-06 | Sun Microsystems, Inc. | Product check matrix |
| US7207046B1 (en) * | 2000-08-23 | 2007-04-17 | Agilent Technologies, Inc. | Method and system for providing string-over-socket scripting language access to distributed object model interfaces |
| US6807572B1 (en) * | 2000-08-31 | 2004-10-19 | Intel Corporation | Accessing network databases |
| US20020161814A1 (en) * | 2000-10-04 | 2002-10-31 | Wical Kelly J. | Batch processing system running in parallel on automated and distributed replication systems |
| US20030046394A1 (en) * | 2000-11-03 | 2003-03-06 | Steve Goddard | System and method for an application space server cluster |
| US20020055982A1 (en) * | 2000-11-03 | 2002-05-09 | The Board Of Regents Of The University Of Nebraska | Controlled server loading using L4 dispatching |
| US20020055983A1 (en) * | 2000-11-03 | 2002-05-09 | The Board Of Regents Of The University Of Nebraska | Computer server having non-client-specific persistent connections |
| US20020120716A1 (en) * | 2000-12-22 | 2002-08-29 | Balaji Raghunathan | Server frame work for a database server |
| US7415025B1 (en) | 2000-12-29 | 2008-08-19 | Cisco Technology, Inc. | Method and apparatus for clearing a large number of connections in an ATM network |
| US20020092012A1 (en) * | 2001-01-09 | 2002-07-11 | Shah Alexandre K. | Smart-caching system and method |
| US7145913B2 (en) * | 2001-02-15 | 2006-12-05 | The Board Of Trustees Of The University Of Illinois | Thread based scalable routing for an active router |
| KR100391513B1 (ko) * | 2001-05-15 | 2003-07-12 | 주식회사 넷마블 | 멀티 스레드를 이용한 네트워크의 병목현상 감소 방법 |
| US20030061257A1 (en) * | 2001-09-25 | 2003-03-27 | Javier Cardona | Multithreaded universal daemon for network data exchanges |
| US20030069917A1 (en) * | 2001-10-04 | 2003-04-10 | Miller Larry J. | Balanced client/server mechanism in a time-partitioned real-time operting system |
| US20030084164A1 (en) * | 2001-10-29 | 2003-05-01 | Mazzitelli John Joseph | Multi-threaded server accept system and method |
| JP2003143153A (ja) * | 2001-11-01 | 2003-05-16 | Nec Corp | サーバコンピュータ、そのコネクションクローズ方法及びプログラム |
| US7024481B2 (en) * | 2001-11-01 | 2006-04-04 | Microsoft Corporation | Method and framework for processing network communication protocol timers |
| US20030172128A1 (en) * | 2002-03-05 | 2003-09-11 | Intel Corporation | Dynamic asynchronous results |
| US7107596B2 (en) * | 2002-03-14 | 2006-09-12 | International Business Machines Corporation | Statistically-triggered heuristics |
| JP3828444B2 (ja) * | 2002-03-26 | 2006-10-04 | 株式会社日立製作所 | データ通信中継装置及びシステム |
| US7299264B2 (en) * | 2002-05-07 | 2007-11-20 | Hewlett-Packard Development Company, L.P. | System and method for monitoring a connection between a server and a passive client device |
| WO2003102758A1 (en) * | 2002-05-31 | 2003-12-11 | University Of Delaware | Method and apparatus for real-time multithreading |
| KR100899527B1 (ko) * | 2002-06-25 | 2009-05-27 | 주식회사 케이티 | 웹 서비스의 멀티쓰레드 운용 시스템 및 방법 |
| US7043729B2 (en) * | 2002-08-08 | 2006-05-09 | Phoenix Technologies Ltd. | Reducing interrupt latency while polling |
| AU2003259871A1 (en) * | 2002-08-16 | 2004-03-03 | Globespanvirata Incorporated | Timing ring mechanism |
| US7272820B2 (en) * | 2002-12-12 | 2007-09-18 | Extrapoles Pty Limited | Graphical development of fully executable transactional workflow applications with adaptive high-performance capacity |
| US7398518B2 (en) * | 2002-12-17 | 2008-07-08 | Intel Corporation | Method and apparatus for measuring thread wait time |
| US7249355B2 (en) * | 2002-12-18 | 2007-07-24 | Microsoft Corporation | Unified network thread management |
| US7415540B2 (en) * | 2002-12-31 | 2008-08-19 | Intel Corporation | Scheduling processing threads |
| US7237242B2 (en) * | 2002-12-31 | 2007-06-26 | International Business Machines Corporation | Dynamic thread pool tuning techniques |
| US7207043B2 (en) * | 2002-12-31 | 2007-04-17 | International Business Machines Corporation | Programmatic response-time based workload distribution techniques |
| US7298753B1 (en) * | 2003-02-10 | 2007-11-20 | Cisco Technology, Inc. | Technique for managing heavy signaling traffic that is directed to a particular signaling control unit |
| US7363626B2 (en) * | 2003-03-24 | 2008-04-22 | Sun Microsystems, Inc. | Thread level application partitioning |
| US20040190494A1 (en) * | 2003-03-26 | 2004-09-30 | Bauer Samuel M. | Systems and methods for voice quality testing in a non-real-time operating system environment |
| US7328438B2 (en) * | 2003-03-27 | 2008-02-05 | International Business Machines Corporation | Deallocation of computer data in a multithreaded computer |
| US7467390B2 (en) * | 2003-04-01 | 2008-12-16 | International Business Machines Corporation | Enhanced staged event-driven architecture |
| US7496915B2 (en) * | 2003-04-24 | 2009-02-24 | International Business Machines Corporation | Dynamic switching of multithreaded processor between single threaded and simultaneous multithreaded modes |
| US20040252709A1 (en) * | 2003-06-11 | 2004-12-16 | Fineberg Samuel A. | System having a plurality of threads being allocatable to a send or receive queue |
| US7373640B1 (en) | 2003-07-31 | 2008-05-13 | Network Appliance, Inc. | Technique for dynamically restricting thread concurrency without rewriting thread code |
| US7690003B2 (en) * | 2003-08-29 | 2010-03-30 | Fuller Jeffrey C | System and method for increasing data throughput using thread scheduling |
| WO2005050625A2 (en) * | 2003-11-14 | 2005-06-02 | Senvid, Inc. | Managed peer-to-peer applications in a secure network |
| US8578380B1 (en) * | 2003-12-17 | 2013-11-05 | Vmware, Inc. | Program concurrency control using condition variables |
| US7703101B2 (en) * | 2004-02-13 | 2010-04-20 | International Business Machines Corporation | Autonomic workload classification using predictive assertion for wait queue and thread pool selection |
| GB0407388D0 (en) | 2004-03-31 | 2004-05-05 | British Telecomm | Method and apparatus for communicating data between computer devices |
| US20050268300A1 (en) * | 2004-05-14 | 2005-12-01 | Microsoft Corporation | Distributed task scheduler for computing environments |
| US7574439B2 (en) * | 2004-05-20 | 2009-08-11 | International Business Machines Corporation | Managing a nested request |
| US7685575B1 (en) * | 2004-06-08 | 2010-03-23 | Sun Microsystems, Inc. | Method and apparatus for analyzing an application |
| US20060004977A1 (en) * | 2004-06-30 | 2006-01-05 | Joefon Jann | Autonomically tuning the virtual memory subsystem of a computer operating system |
| US7308083B2 (en) * | 2004-06-30 | 2007-12-11 | Glenayre Electronics, Inc. | Message durability and retrieval in a geographically distributed voice messaging system |
| US20060015872A1 (en) * | 2004-07-13 | 2006-01-19 | Pohl William N | Process management |
| US20060026593A1 (en) * | 2004-07-30 | 2006-02-02 | Microsoft Corporation | Categorizing, voting and rating community threads |
| US7844668B2 (en) * | 2004-07-30 | 2010-11-30 | Microsoft Corporation | Suggesting a discussion group based on indexing of the posts within that discussion group |
| BRPI0418999A (pt) * | 2004-08-12 | 2007-12-11 | Telecom Italia Spa | método de receber dados por uma pluralidade linhas, sistema para receber dados, rede de comunicação, e, produto de programa de computador |
| US20060075404A1 (en) * | 2004-10-06 | 2006-04-06 | Daniela Rosu | Method and system for scheduling user-level I/O threads |
| US20060085698A1 (en) * | 2004-10-15 | 2006-04-20 | Microsoft Corporation | Synchronization mechanism for tools that drive UI-based applications |
| US7484217B2 (en) * | 2005-02-24 | 2009-01-27 | International Business Machines Corporation | Method for automatic adjustment of time a consumer waits to access data from a queue during a waiting phase and transmission phase at the queue |
| DE102005008975A1 (de) * | 2005-02-28 | 2006-08-31 | Robert Bosch Gmbh | Verfahren und Vorrichtung zur Überwachung einer Prozessausführung |
| US7823158B2 (en) * | 2005-08-18 | 2010-10-26 | International Business Machines Corporation | Adaptive scheduling and management of work processing in a target context in resource contention |
| US7793299B2 (en) * | 2005-08-30 | 2010-09-07 | International Business Machines Corporation | System and method for scheduling tasks for execution |
| US20070121822A1 (en) * | 2005-11-01 | 2007-05-31 | Victor Carnale | Methods and apparatus to allow multiple clients to access a computer telephony interface server |
| US7962926B2 (en) * | 2006-04-05 | 2011-06-14 | International Business Machines Corporation | Method, system, and program storage device for generating a retry message when a thread in a real-time application is unavailable to process a request to utilize the real-time application |
| GB0702596D0 (en) | 2006-05-05 | 2007-03-21 | Omnifone Ltd | Big book one |
| KR101208679B1 (ko) | 2006-08-08 | 2012-12-06 | 삼성전자주식회사 | 소켓의 공유를 위한 네트워크 기기 및 그의 소켓 공유 방법 |
| CA2557343C (en) * | 2006-08-28 | 2015-09-22 | Ibm Canada Limited-Ibm Canada Limitee | Runtime code modification in a multi-threaded environment |
| US8839271B2 (en) * | 2006-10-11 | 2014-09-16 | International Business Machines Corporation | Call stack sampling to obtain information for analyzing idle states in a data processing system |
| US8356284B2 (en) * | 2006-12-28 | 2013-01-15 | International Business Machines Corporation | Threading model analysis system and method |
| US8020166B2 (en) * | 2007-01-25 | 2011-09-13 | Hewlett-Packard Development Company, L.P. | Dynamically controlling the number of busy waiters in a synchronization object |
| US8219845B2 (en) * | 2007-05-09 | 2012-07-10 | Microsoft Corporation | Timer service uses a single timer function to perform timing services for both relative and absolute timers |
| US8122449B2 (en) * | 2007-09-07 | 2012-02-21 | International Business Machines Corporation | Determining whether to retain or terminate a thread based on a minimum number of threads in a thread pool and a maximum number of threads allowed waiting on the channel |
| US20090094614A1 (en) * | 2007-10-05 | 2009-04-09 | Microsoft Corporation | Direct synchronous input |
| KR100959898B1 (ko) | 2007-12-27 | 2010-05-27 | 주식회사 케이티 | 인터넷 서비스를 위한 부하 분산형 스케줄링 구조를 가지는서비스 서버 및 그 서비스 방법 |
| US8489752B2 (en) * | 2008-05-29 | 2013-07-16 | Advanced Micro Devices, Inc. | Method and system for controlling bus access |
| US8271659B2 (en) * | 2008-09-04 | 2012-09-18 | Oracle International Corporation | Methods and systems for automatic removal and replacement of connections in a pool rendered stale by a firewall |
| JP5298974B2 (ja) * | 2009-03-10 | 2013-09-25 | 株式会社リコー | 機器管理装置、機器管理システム、機器管理方法、機器管理プログラム、及びそのプログラムを記録した記録媒体 |
| US20110010716A1 (en) * | 2009-06-12 | 2011-01-13 | Arvind Raghuraman | Domain Bounding for Symmetric Multiprocessing Systems |
| US8230078B2 (en) * | 2009-08-18 | 2012-07-24 | International Business Machines Corporation | Accept and receive enhancements |
| CN102045251B (zh) * | 2009-10-20 | 2012-08-22 | 国基电子（上海）有限公司 | 路由器及tcp端口防御方法 |
| TWI397286B (zh) * | 2009-10-28 | 2013-05-21 | Hon Hai Prec Ind Co Ltd | 路由器及tcp埠防禦方法 |
| KR101644800B1 (ko) * | 2010-01-07 | 2016-08-02 | 삼성전자주식회사 | 컴퓨팅 시스템 및 방법 |
| US8745629B2 (en) * | 2010-01-11 | 2014-06-03 | Qualcomm Incorporated | System and method of controlling power in an electronic device |
| US8756329B2 (en) | 2010-09-15 | 2014-06-17 | Oracle International Corporation | System and method for parallel multiplexing between servers in a cluster |
| US8893134B2 (en) * | 2011-04-13 | 2014-11-18 | International Business Machines Corporation | Locating bottleneck threads in multi-thread applications |
| US9086909B2 (en) * | 2011-05-17 | 2015-07-21 | Oracle International Corporation | System and method for supporting work sharing muxing in a cluster |
| US8595743B2 (en) | 2012-05-01 | 2013-11-26 | Concurix Corporation | Network aware process scheduling |
| US9417935B2 (en) | 2012-05-01 | 2016-08-16 | Microsoft Technology Licensing, Llc | Many-core process scheduling to maximize cache usage |
| US8650538B2 (en) | 2012-05-01 | 2014-02-11 | Concurix Corporation | Meta garbage collection for functional code |
| US8726255B2 (en) | 2012-05-01 | 2014-05-13 | Concurix Corporation | Recompiling with generic to specific replacement |
| US8495598B2 (en) | 2012-05-01 | 2013-07-23 | Concurix Corporation | Control flow graph operating system configuration |
| US8700838B2 (en) | 2012-06-19 | 2014-04-15 | Concurix Corporation | Allocating heaps in NUMA systems |
| US9047196B2 (en) | 2012-06-19 | 2015-06-02 | Concurix Corporation | Usage aware NUMA process scheduling |
| US8707326B2 (en) | 2012-07-17 | 2014-04-22 | Concurix Corporation | Pattern matching process scheduler in message passing environment |
| US9575813B2 (en) | 2012-07-17 | 2017-02-21 | Microsoft Technology Licensing, Llc | Pattern matching process scheduler with upstream optimization |
| US8793669B2 (en) | 2012-07-17 | 2014-07-29 | Concurix Corporation | Pattern extraction from executable code in message passing environments |
| US9043788B2 (en) | 2012-08-10 | 2015-05-26 | Concurix Corporation | Experiment manager for manycore systems |
| US9621667B2 (en) * | 2012-08-27 | 2017-04-11 | Adobe Systems Incorporated | Streaming media with a server identified at runtime |
| US8656134B2 (en) | 2012-11-08 | 2014-02-18 | Concurix Corporation | Optimized memory configuration deployed on executing code |
| US8607018B2 (en) | 2012-11-08 | 2013-12-10 | Concurix Corporation | Memory usage configuration based on observations |
| US8656135B2 (en) | 2012-11-08 | 2014-02-18 | Concurix Corporation | Optimized memory configuration deployed prior to execution |
| EP2798518B1 (en) * | 2013-02-20 | 2017-06-28 | Fastly Inc. | Enhanced thread handling in security handshaking |
| US20130227529A1 (en) | 2013-03-15 | 2013-08-29 | Concurix Corporation | Runtime Memory Settings Derived from Trace Data |
| US8739151B1 (en) * | 2013-03-15 | 2014-05-27 | Genetec Inc. | Computer system using in-service software upgrade |
| US9558035B2 (en) * | 2013-12-18 | 2017-01-31 | Oracle International Corporation | System and method for supporting adaptive busy wait in a computing environment |
| US9753780B2 (en) | 2015-07-07 | 2017-09-05 | Sybase, Inc. | Topology-aware processor scheduling |
| JP6597360B2 (ja) * | 2016-02-12 | 2019-10-30 | 富士通株式会社 | コネクション管理プログラム、コネクション管理方法、および情報処理装置 |
| US10133496B1 (en) * | 2016-06-15 | 2018-11-20 | Amazon Technologies, Inc. | Bindable state maintaining components |
| US10146593B2 (en) * | 2017-02-17 | 2018-12-04 | Sas Institute Inc. | Techniques for decentralized load balancing |
| US10802878B2 (en) * | 2017-03-31 | 2020-10-13 | Bmc Software, Inc. | Phased start and stop of resources in a mainframe environment |
| US11340955B2 (en) | 2020-01-02 | 2022-05-24 | International Business Machines Corporation | Thread pool management for multiple applications |
| US11301335B2 (en) * | 2020-03-04 | 2022-04-12 | International Business Machines Corporation | Database backup performance |
| KR102616610B1 (ko) * | 2023-06-29 | 2023-12-27 | (주)래셔널아울 | 동접 관리를 위한 소켓핸들링 및 멀티스레드 제어 장치및 방법 |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0581163A (ja) | 1991-09-19 | 1993-04-02 | Nec Corp | 情報処理システム |
| US6684261B1 (en) * | 1993-07-19 | 2004-01-27 | Object Technology Licensing Corporation | Object-oriented operating system |
| JPH07152685A (ja) | 1993-11-26 | 1995-06-16 | Hitachi Ltd | 分散編集制御方式 |
| WO1996017306A2 (en) * | 1994-11-21 | 1996-06-06 | Oracle Corporation | Media server |
| US5752031A (en) * | 1995-04-24 | 1998-05-12 | Microsoft Corporation | Queue object for controlling concurrency in a computer system |
| JPH0944366A (ja) | 1995-07-28 | 1997-02-14 | Oki Electric Ind Co Ltd | マルチスレッド・スケジューリング装置 |
| JPH09198292A (ja) | 1996-01-23 | 1997-07-31 | Nec Corp | 共用データの管理方式 |
| US5826081A (en) * | 1996-05-06 | 1998-10-20 | Sun Microsystems, Inc. | Real time thread dispatcher for multiprocessor applications |
| US6212573B1 (en) * | 1996-06-26 | 2001-04-03 | Sun Microsystems, Inc. | Mechanism for invoking and servicing multiplexed messages with low context switching overhead |
| US6298386B1 (en) * | 1996-08-14 | 2001-10-02 | Emc Corporation | Network file server having a message collector queue for connection and connectionless oriented protocols |
| GB2320112B (en) * | 1996-12-07 | 2001-07-25 | Ibm | High-availability computer server system |
| GB2320594A (en) * | 1996-12-20 | 1998-06-24 | Ibm | Dispatching client method calls to parallel execution threads within a server |
| US6173311B1 (en) * | 1997-02-13 | 2001-01-09 | Pointcast, Inc. | Apparatus, method and article of manufacture for servicing client requests on a network |
| US6021470A (en) * | 1997-03-17 | 2000-02-01 | Oracle Corporation | Method and apparatus for selective data caching implemented with noncacheable and cacheable data for improved cache performance in a computer networking system |
| US6075791A (en) * | 1997-10-28 | 2000-06-13 | Lucent Technologies Inc. | System for guaranteeing data transfer rates and delays in packet networks |
-
1998
- 1998-06-12 US US09/097,282 patent/US6427161B1/en not_active Expired - Lifetime
-
1999
- 1999-05-19 KR KR1019990018127A patent/KR100326990B1/ko not_active IP Right Cessation
- 1999-05-21 JP JP14109999A patent/JP3555846B2/ja not_active Expired - Fee Related
-
2001
- 2001-05-10 US US09/852,366 patent/US6823515B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6427161B1 (en) | 2002-07-30 |
| JP2000029815A (ja) | 2000-01-28 |
| US20010018701A1 (en) | 2001-08-30 |
| KR100326990B1 (ko) | 2002-03-04 |
| US6823515B2 (en) | 2004-11-23 |
| KR20000005691A (ko) | 2000-01-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3555846B2 (ja) | スレッド・サーバのパフォーマンス強化方法および装置 | |
| US7246167B2 (en) | Communication multiplexor using listener process to detect newly active client connections and passes to dispatcher processes for handling the connections | |
| US6988140B2 (en) | Mechanism for servicing connections by disassociating processing resources from idle connections and monitoring the idle connections for activity | |
| US5875329A (en) | Intelligent batching of distributed messages | |
| US7441241B2 (en) | Grid non-deterministic job scheduling | |
| US7051330B1 (en) | Generic application server and method of operation therefor | |
| US7137116B2 (en) | Method and system for performing a task on a computer | |
| US7873964B2 (en) | Kernel functions for inter-processor communications in high performance multi-processor systems | |
| US20040003085A1 (en) | Active application socket management | |
| US7349958B2 (en) | Method for improving performance in a computer storage system by regulating resource requests from clients | |
| JP2677744B2 (ja) | 分散メモリ式デジタル計算システム | |
| Bangs et al. | Better operating system features for faster network servers | |
| EP2618257B1 (en) | Scalable sockets | |
| Steenkiste | Analyzing communication latency using the nectar communication processor | |
| US6993764B2 (en) | Buffered coscheduling for parallel programming and enhanced fault tolerance | |
| US7539995B2 (en) | Method and apparatus for managing an event processing system | |
| US20030033345A1 (en) | Thread-based methods and systems for using the idle processing power of one or more networked computers to solve complex scientific problems | |
| JP2004046372A (ja) | 分散処理システム、リソース割当方法およびプログラムならびにリソース割当プログラムが記録された記録媒体 | |
| Evers et al. | A literature study on scheduling in distributed systems | |
| Ahuja et al. | A multi-microprocessor architecture with hardware support for communication and scheduling | |
| Sha et al. | Distributed system design using generalized rate monotonic theory | |
| Kepecs et al. | SODA: A simplified operating system for distributed applications | |
| JPH09319708A (ja) | オンライン制御プロセス代行方式 | |
| King | Optimization of machine allocation in RingLeader | |
| Wijeyeratnam | An MPI messaging layer for network processors |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20031127 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040225 Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040225 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040428 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040428 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20040428 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040507 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080521 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |