JP5476208B2 - リクエスト処理システム、方法及びプログラム - Google Patents

Description

この発明は、ウェブ・サーバなどのように、リクエストを順次受け付けてキューに入れ、処理するコンピュータ・システムに関し、キュー上で待機するリクエストの処理の効率化に関する。

近年、インターネット技術が隆盛するにつれて、インターネット上に配置され、クラアイント・システムからアクセス可能なウェブ・サーバが増大している。ウェブ・サーバは通常、インターネットを介して多数のクライアント・コンピュータから、処理リクエストを受け取るので、これを一度に処理することはできず、一旦キューに入れて、順次処理する。

このようにキューに入れられたリクエストを、少しでも早く合理的に処理する技法が要望されている。

特開２００３−２８３５５６号公報は、クライアントからサーバへの要求を、データ通信中継装置を介して行い、データ通信中継装置は要求の優先度付きのキューイング手段を持ち、ある優先度に応じて、要求の中継順序も入れ替える手段を持ち、これにより、サーバへの同時要求数をサーバの処理能力内に押さえもとともに、安定したサービスを提供することを開示する。

特開２００６−７２７６０号公報は、情報装置からのリクエスト情報に応じてサービスを提供するサーバの負荷を監視し、情報装置からのリクエスト情報を受信した際に、前記監視の結果、負荷が所定条件を満たしていれば該リクエスト情報を前記サーバに通知し、負荷が所定条件を満たしていなければ該リクエスト情報を保留にして当該情報装置の情報を待ち行列に加え、前記待ち行列に加えた情報装置に対し、待ち時間に応じたインセンティブの発行を通知すると共に、この情報装置とインセンティブとを対応付けて記憶し、前記監視の結果、新規リクエストが可能な場合に、所定の順で前記情報装置の情報を待ち行列から除き、当該情報装置からのリクエスト情報を前記サーバへ通知することを開示する。

特開２００７−３２９６１７号公報は、ＩＰネットワークでの呼処理サーバに関し、呼処理バッファに優先度の異なる２種類以上のキューを用意することにより、接続要求処理の実行を切断要求処理の実行よりも優先して行い、呼処理タスクが次の処理を行うために、キューからイベントを取り出す際に、キューの間で取り出し順の優先制御を行うことを開示する。この際、ルータなどのパケット転送処理と同様に、ＰＱ、あるいは、ＷＲＲなどのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する。

Oliver Rose, "THE SHORTEST PROCESSING TIME FIRST (SPTF) DISPATCH RULE AND SOME VARIANTS IN SEMICONDUCTOR MANUFACTURING, Proceedings of the 2001 Winter Simulation Conference は、キューにおいて、処理時間が短い案件を先に処理することで、全体の待ち時間が減少するという一般的な技法を開示する。

すなわち、上記特許公開公報に開示されているような技術、あるいは、ＳＰＴＦ技法を用いることによって、キュー上にあるリクエストの平均待ち時間を減らすことができる。

ところが、最近ウェブ・サーバによく使われている、Ｊａｖａ（商標）ベースのサーバにおいては、あるリクエストを処理しようとして、その処理のためのヒープ残量が十分でないと、ガベージ・コレクション（以下、ＧＣとも称する）が発生する。このＧＣが行われている間、全てのアプリケーション・スレッドが停止されてしまい、ＧＣの終了後、アプリケーション・スレッドは再開される。なお、このような、全てのアプリケーション・スレッドを一旦停止させてしまうようなＧＣの現象は、"Stop the world"と呼ばれる。

このようなガベージ・コレクションの発生を考慮に入れるとき、上記従来技術のキューイング・スキームでは、リクエストの平均待ち時間を減少させるという目的を達成することはできない。なぜなら、どの時点で、どのリクエストがＧＣを発生させるか、考慮されないからである。

なお、Ｊａｖａ（商標）のスレッド環境におけるＧＣポイントについては、Ole Agesen, "GC Points in a Threaded Environment", Sun Microsystems, Inc. Mountain View, CA, USA Technical Report: TR-98-70, 1998などに記述されている。

特開２００３−２８３５５６号公報 特開２００６−７２７６０号公報 特開２００７−３２９６１７号公報

Oliver Rose, "THE SHORTEST PROCESSING TIME FIRST (SPTF) DISPATCH RULE AND SOME VARIANTS IN SEMICONDUCTOR MANUFACTURING", Proceedings of the 2001 Winter Simulation Conference Ole Agesen, "GC Points in a Threaded Environment", Sun Microsystems, Inc. Mountain View, CA, USA Technical Report: TR-98-70, 1998

従って、この発明の目的は、ＧＣが発生しえるというシステム環境で、キュー上にあるリクエストの平均待ち時間を減少させるための処理技法を提供することにある。

上記目的は、キュー上にあるリクエストと、そのリクエストを処理した際に発生し得るＧＣの完了時間を１つの単位とし、この単位に対して、ＧＣ時間も含む処理時間が短い単位を先に処理することをシステム的に実行することにより、達成される。

キューを管理している、例えばウェブ・サーバであるコンピュータ・システムは、あるリクエストを処理する時点でのヒープの残量を把握している。一方、コンピュータ・システムは、リクエストのタイプに応じて、どれくらいのヒープ量を消費するかを事前に統計的に計算して、その値を保持している。

すると、コンピュータ・システムは、あるリクエストを処理する際に、そのリクエストの予測ヒープ消費量と、メモリにおけるヒープの残量を考慮して、ＧＣを起こすかどうか予め予測することができる。このことが、リクエストと、そのリクエストを処理した際に発生し得るＧＣの完了時間を１つの単位として扱えることの理論的根拠となる。

この際、好適には、リクエストの処理時間そのものも考慮されるが、一般的には、リクエストの処理時間よりもＧＣ時間の方が圧倒的に長いので、ＧＣ時間のみに着目して、処理時間が短い単位を先に処理するようにしてもよい。

以上のように、この発明によれば、ＧＣが発生しえるというシステム環境で、キュー上にあるリクエストと、そのリクエストを処理した際に発生し得るＧＣの完了時間を１つの単位とし、この単位に対して、ＧＣ時間も含む処理時間が短い単位を先に処理することをシステム的に実行することにより、キュー上にあるリクエストの平均待ち時間を減少させることができるという効果が得られる。

すなわち、ＧＣが早晩起こることは避けられないので、ＧＣが起きる前に可能な限り、比較的軽いリクエストが早めに処理されるという次第である。

アプリケーション・サーバに、インターネットを介して、クライアント・コンピュータが接続されることを示す図である。 クライアント・コンピュータのハードウェア構成を示す図である。 アプリケーション・サーバ・サーバのハードウェア構成を示す図である。 本発明の実施例の機能ブロック図である。 リクエストがキューに到着したときの処理のフローチャートを示す図である。 リクエストを、ヒープ消費量クラスに分ける処理のフローチャートを示す図である。 キューからリクエストを削除して処理する場合の処理のフローチャートを示す図である。 リクエストのヒープ消費量を測定する処理のフローチャートを示す図である。 ヒープ残量と、リクエストのヒープ消費量及びクラスを考慮して、リクエストの処理順序を決定する処理を説明するための図である。 ヒープ残量と、リクエストのヒープ消費量及びクラスを考慮して、リクエストの処理順序を決定する処理を説明するための図である。 ヒープ残量と、リクエストのヒープ消費量及びクラスを考慮して、リクエストの処理順序を決定する処理を説明するための図である。

以下、図面を参照して、本発明の実施例を説明する。特に断わらない限り、同一の参照番号は、図面を通して、同一の対象を指すものとする。また、以下で説明するのは、本発明の一実施形態であり、この発明を、この実施例で説明する内容に限定する意図はないことに留意されたい。

図１において、ウェブ・サーバの機能を併せ持つアプリケーション・サーバ１０２には、インターネット１０４を介して、複数のクライアント・コンピュータ１０６ａ、１０６ｂ・・・１０６ｚから、ＨＴＴＰなどのプロトコルにより、リクエストを受け取る。。図１のシステムにおいては、クライアント・コンピュータのユーザは、Ｗｅｂブラウザを通じて、インターネット１０４の回線を介して、アプリケーション・サーバ１０２に、ログインする。具体的には、所定のＵＲＬをＷｅｂブラウザに打ち込んで、所定のページを表示する。なお、Ｗｅｂブラウザではなく、所定の専用クライアント・アプリケーション・プログラムを使ってログインするようにしてもよい。

次に、図２を参照して、図１で参照番号１０６ａ、１０６ｂ・・・１０６ｚのように示されているクライアント・コンピュータのハードウェア・ブロック図について、説明する。図２において、クライアント・コンピュータは、主記憶２０６、ＣＰＵ２０４、ＩＤＥコントローラ２０８をもち、これらは、バス２０２に接続されている。バス２０２には更に、ディスプレイ・コントローラ２１４と、通信インターフェース２１８と、ＵＳＢインターフェース２２０と、オーディオ・インターフェース２２２と、キーボード・マウス・コントローラ２２８が接続されている。ＩＤＥコントローラ２０８には、ハードディスク・ドライブ（ＨＤＤ）２１０と、ＤＶＤドライブ２１２が接続されている。ＤＶＤドライブ２１２は、必要に応じて、ＣＤ−ＲＯＭやＤＶＤから、プログラムを導入するために使用する。ディスプレイ・コントローラ２１４には、好適には、ＬＣＤ画面をもつディスプレイ装置２１６が接続されている。ディスプレイ装置２１６には、Ｗｅｂブラウザを通じて、アプリケーションの画面が表示される。

ＵＳＢインターフェース２２０には、必要に応じて、拡張ハードディスクなどのデバイスを接続をすることができる。

キーボード・マウス・コントローラ２２８には、キーボード２３０と、マウス２３２が接続されている。キーボード２３０は、所定のリクエストのメッセージや、パスワードなどを打ち込むために使用される。

ＣＰＵ２０４は、例えば、３２ビット・アーキテクチャまたは６４ビット・アーキテクチャに基づく任意のものでよく、インテル社のＰｅｎｔｉｕｍ（インテル・コーポレーションの商標）４、Ｃｏｒｅ（商標）２ Ｄｕｏ、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。

ハードディスク・ドライブ２１０には、少なくとも、オペレーティング・システムと、オペレーティング・システム上で動作するＷｅｂブラウザ（図示しない）が格納されており、システムの起動時に、オペレーティング・システムは、メインメモリ２０６にロードされる。オペレーティング・システムは、Ｗｉｎｄｏｗｓ ＸＰ（マイクロソフト・コーポレーションの商標）、Ｗｉｎｄｏｗｓ Ｖｉｓｔａ（マイクロソフト・コーポレーションの商標）、Ｗｉｎｄｏｗｓ（マイクロソフト・コーポレーションの商標） ７、Ｌｉｎｕｘ（Linus Torvaldsの商標）などを使用することができる。また、Ｗｅｂブラウザは、マイクロソフト・コーポレーションのInternet Explorer、Mozilla FoundationのMizilla FireFoxなど、任意のものを使用することができる。

通信インターフェース２１８は、オペレーティング・システムが提供するＴＣＰ／ＩＰ通信機能を利用して、イーサネット（商標）・プロトコルなどにより、アプリケーション・サーバ１０２と、通信する。

図３は、アプリケーション・サーバ１０２のハードウェア構成の概要ブロック図である。図３に示すように、クライアント・コンピュータ１０６ａ、１０６ｂ・・・１０６ｚは、インターネット１０４を経由して、アプリケーション・サーバ１０２の通信インターフェース３０２に接続される。通信インターフェース３０２はさらに、バス３０４に接続され、バス３０４には、ＣＰＵ３０６、主記憶（ＲＡＭ）３０８、及びハードディスク・ドライブ（ＨＤＤ）３１０が接続されている。

図示しないが、アプリケーション・サーバ１０２にはさらに、キーボード、マウス、及びディスプレイが接続され、これらによって、アプリケーション・サーバ１０２全体の管理やメンテナンス作業を行うようにしてもよい。

アプリケーション・サーバ１０２のハードディスク・ドライブ３１０には、オペレーティング・システム、クライアント・コンピュータ１０６ａ、１０６ｂ・・・１０６ｚのログイン管理のための、ユーザＩＤとパスワードの対応テーブルが保存されている。ハードディスク・ドライブ３１０にはさらに、アプリケーション・サーバ１０２をＷｅｂサーバとして機能させるためのＡｐａｃｈｅなどのソフトウェア、及びＪａｖａ仮想環境を実現するＪａｖａ ＥＥ、及びＪａｖａ仮想環境上で動作する本発明に係る後述する処理プログラム等が保存され、アプリケーション・サーバ１０２の立ち上げ時に、主記憶３０８にロードされて、動作する。これによって、クライアント・コンピュータ１０６ａ、１０６ｂ・・・１０６ｚが、ＴＣＰ／ＩＰのプロトコルで、アプリケーション・サーバ１０２にアクセスすることが可能となる。

尚、上記アプリケーション・サーバ１０２として、インターナョナル・ビジネス・マシーンズ・コーポレーションから購入可能な、ＩＢＭ（インターナョナル・ビジネス・マシーンズ・コーポレーションの商標）Ｓｙｓｔｅｍ Ｘ、Ｓｙｓｔｅｍ ｉ、Ｓｙｓｔｅｍ ｐなどの機種のサーバを使うことができる。その際、使用可能なオペレーティング・システムは、ＡＩＸ（インターナョナル・ビジネス・マシーンズ・コーポレーションの商標）、ＵＮＩＸ（The Open Groupの商標）、Ｌｉｎｕｘ（商標）、Ｗｉｎｄｏｗｓ（商標）２００３ Ｓｅｒｖｅｒなどがある。

次に、図４の機能ブロック図を参照して、本発明の実施例の論理構成について説明する。

図４において、リクエスト受信モジュール４０２は実際上、Ｗｅｂサーバとして動作するＡｐａｃｈｅなどのソフトウェアの一部であり、ＨＴＴＰなどのプロトコルでクライアント・コンピュータ１０６ａ、１０６ｂ・・・１０６ｚから送られてきたリクエストを受信し、キュー４０４に入れる。キュー４０４は好適には、主記憶３０８上に確保されたメモリ領域であり、処理スケジューラ４０６の働きにより、リクエスト処理モジュール４０８に対して順次リクエストをキュー４０４から出したり、キュー４０４上でリクエストの順序を変更したりすることができる。

ここでリクエスト処理モジュール４０８は、実際は、さまざまな機能を実行する、Ｊａｖａで書かれたプログラムの集まりであると考えてもよい。すなわち、リクエストのタイプに応じて、異なるプログラムが呼び出される。

主記憶３０８上には、ヒープ領域４１０が確保されており、ヒープ領域４１０では、リクエスト処理モジュール４０８がリクエストを処理する度にメモリが消費される。ヒープ残量監視モジュール４１２は、ヒープの使用可能な残量を監視し、残量が不足すると、ガベージ・コレクション機能４１４を呼び出して、ヒープ領域４１０の容量を確保し直す。ここで、ガベージ・コレクション機能４１４は、"Stop the world"タイプのガベージ・コレクションであり、Ｊａｖａ仮想マシンの基本的な機能の１つである。

なお、処理スケジューラ４０６、リクエスト処理モジュール４０８及びヒープ残量監視モジュール４１２は、Ｊａｖａで書かれたプログラムであり、好適には、アプリケーション・サーバ１０２の起動時に、並列に動作するスレッドとして構成される。

ヒープ消費量データベース４１６は、リクエストのタイプ毎に、予測されるヒープの消費量を記録しておくデータベースであり、好適には、ハードディスク・ドライブ３１０に永続的に記録されるが、主記憶３０８上に格納してもよい。なお、この実施例におけるリクエストとは例えば、普通のＷｅｂページの表示、検索などの処理、あるいは、複数Ｗｅｂページのレイアウト表示などのことである。また、リクエストのタイプとは、クライアント・コンピュータから送られてくるＵＲＬにパラメータとして指定される、例えばbrowse.jsp?id=123のような文字列のことである。このような文字列は、Ｊａｖａのミドルウェアの構文解析処理によって切り出される。このようなパラメータに従い、対応するＪａｖａプログラムが呼び出される。

処理スケジューラ４０６は、ヒープ残量監視モジュール４１２及びヒープ消費量データベース４１６からの情報に基づきキュー４０４を処理して、リクエストをリクエスト処理モジュール４０８を送るが、そのより詳しい処理は、図５以下に示すフローチャートに従い、説明する。

リクエスト処理モジュール４０８の処理結果は、処理結果送信モジュール４１８を介して、リクエストしたクライアント・コンピュータに返される。処理結果送信モジュール４１８は、好適には、Ｗｅｂサーバとして動作するＡｐａｃｈｅなどのソフトウェアの一部として実装される。

図５は、リクエストＲがキュー４０４（以下、キューＱとも称する）に到着したときに、処理スケジューラ４０６によって行われる処理のフローチャートである。ステップ５０２で、リクエストＲがキューＱに入ると、処理スケジューラ４０６は、ミドルウェアの構文解析機能を利用して、リクエスト・タイプＴを解析する。

次のステップ５０４で、処理スケジューラ４０６は、データベース４１６にアクセスして、リクエスト・タイプＴの処理時の予測される平均ヒープ消費量Ｈを取得しようと試みる。ステップ５０６でＨが取得できない、すなわちまだ処理スケジューラ４０６が処理したことがないタイプであるなら、処理スケジューラ４０６は、ステップ５０８で、リクエストＲのヒープ消費量統計フラグＬをセットして、次のリクエストがキューに到来を待つステップ５０２に戻る。こうしておくと、別途の処理で、リクエストＲのヒープ消費量が計測され、そのタイプＴに対応するヒープ消費量がデータベース４１６に登録されることになる。

ステップ５０６に戻って、Ｔの処理時の平均ヒープ消費量Ｈを取得できたなら、ステップ５１０で、処理スケジューラ４０６は、平均ヒープ消費量Ｈの対応するクラスＣを計算する。次にステップ５１２では、ＨとＣをリクエストＲに関連付けて、次のリクエストがキューに到来を待つステップ５０２に戻る。

図６は、ステップ５１０の詳細の処理を示すフローチャートである。ステップ６０２で、処理スケジューラ４０６は、ステップ５０４で取得した平均ヒープ消費量Ｈが、ある閾値Ｅより大きいかどうか判断し、もしそうならステップ６０４で、平均ヒープ消費量ＨのクラスがClargeであるとセットし、そうでなければステップ６０２で、平均ヒープ消費量ＨのクラスがCsmallであるとセットする。

図７は、処理スケジューラ４０６が、キューＱからリクエストを削除して処理する処理のフローチャートである。

ステップ７０２では、処理スケジューラ４０６は、リクエスト処理モジュール４０８に問い合わせてリクエスト処理の準備が出来たかどうか判断し、もしそうなら、キューＱの先頭リクエストＲのＨとＣを取得する。この値は、そのリクエストがキューＱに入れられた段階で、図５のフローチャートの処理で取得されている。

ステップ７０４では、処理スケジューラ４０６は、キューＱの先頭リクエストＲのヒープ消費クラスＣがClargeであり、Ｈはヒープ残量Ｆより大きいかどうかを判断する。このとき、ヒープ残量Ｆは、ヒープ残量監視モジュール４１２から取得される。

ステップ７０４での判断が肯定的であるなら、ステップ７０６で、消費クラスがCsmallであるキューＱ内のリクエストを、キューＱ内で、リクエストＲの前に移動させる。これによって、その消費クラスがCsmallであるリクエストが、キューＱ内での先頭リクエストとなる。こうして次にステップ７０８に進む。

ステップ７０４での判断が否定的であるなら、処理は直ちにステップ７０８に進む。

ステップ７０８では、処理スケジューラ４０６は、キューＱから先頭のリクエストを削除し、図８のフローチャートの処理を呼び出す。そうして、ステップ７０２に戻る。

次に、図８のフローチャートを参照して、図７のステップ７０８のリクエスト削除以降の処理を、より詳細に説明する。図８において、ステップ８０２では、処理スケジューラ４０６とは別のワーカースレッド（図示しない）が、未処理命令があるかどうか判断し、もうそうなら、ステップ８０４に進み、命令はヒープ割当を行うかどうか判断する。もしそうなら、ステップ８０６に進み、リクエストのフラグＬがセットかどうか判断する。リクエストのフラグＬとは、図５のフローチャートの処理のステップ５０８で条件に従いセットされているものであり、フラグＬのセットとは、リクエストのヒープ消費量統計を計測して記録すべきことを意味する。

そこで、ステップ８０８では、ワーカースレッドは、現在の命令のヒープ割当量を、リクエストのタイプＴに関連付け、ステップ８１０での命令実行に進む。

ステップ８０４で命令がヒープ割当でない場合も、ステップ８０６でリクエストのフラグＬがセットされていない場合も、処理は直接ステップ８１０に進む。

ステップ８０２に戻って、未処理命令がないと判断されると、ステップ８１２に進み、そこで、ワーカースレッドは、リクエストのフラグＬがセットかどうか判断する。もしそうなら、ステップ８１４で、ワーカースレッドは、タイプＴに関連づいヒープ割当量を、Ｔのヒープ消費量としてデータベース４１６に保存して、ステップ７０８に戻る。リクエストのフラグＬがセットされていないなら、直ちにステップ７０８に戻る。

この実施例の処理をよりよく理解するために、全体を通しての動作を説明する。先ず、クライアント・コンピュータ１０６ａのユーザが、ディスプレイ２１６にＷｅｂブラウザを呼び出して、所定の操作ボタン（図示しない）をクリックすると、ＨＴＴＰプロトコルに従い、所定のＵＲＬと、リクエスト・タイプを示す追加のパラメータを含むリクエストが、インターネット回線を通じて、アプリケーション・サーバ１０２に送られる。この場合、リクエストは、Ｗｅｂページの一覧レイアウト表示であるとする。

送られたリクエストは、アプリケーション・サーバ１０２のリクエスト受信モジュール４０２によって受け取られ、キュー４０４に入れられる。このとき、ステップ５０２に記述されているように、ミドルウェアによる構文解析により、リクエスト・タイプを示す追加のパラメータが抽出される。

すると、処理スケジューラ４０６は、ステップ５０４で、そのリクエスト・タイプＴを以って、ヒープ消費量データベース４１６にアクセスし、リクエスト・タイプＴのヒープ消費量Ｈを取得しようと試みる。このとき、既に処理済のリクエスト・タイプＴであったとすると、ヒープ消費量Ｈが得られるので、そのＨの値で以って、図６のフローチャートの処理により、リクエストはClargeであると判定されたとする。そのリクエストを、リクエスト１とする。

同様にして、次にクライアント・コンピュータ１０６ｂから、別のリクエストがアプリケーション・サーバ１０２のリクエスト受信モジュール４０２に届いたとする。それはキュー４０４に入れられ、このとき、ステップ５０２に記述されているように、ミドルウェアによる構文解析により、リクエスト・タイプを示す追加のパラメータが抽出される。この場合のリクエストは、単純なＷｅｂページ表示であるとする。

処理スケジューラ４０６は、ステップ５０４で、そのリクエスト・タイプＴを以って、ヒープ消費量データベース４１６にアクセスし、リクエスト・タイプＴのヒープ消費量Ｈを取得しようと試みる。このとき、既に処理済のリクエスト・タイプＴであったとすると、ヒープ消費量Ｈが得られるので、そのＨの値で以って、図６のフローチャートの処理により、リクエストはCsmallであると判定されたとする。そのリクエストを、リクエスト２とする。

すると、図９に示すように、クライアント・コンピュータ１０６ａからのＷｅｂページの一覧レイアウト表示リクエストであるリクエスト１が、キュー４０４の先頭に達したとき、クライアント・コンピュータ１０６ｂからの単純なＷｅｂページ表示リクエストであるリクエスト２が、キュー４０４の先頭から二番目に位置している。

ところが、ステップ７０４で、先頭にあるリクエスト１がClargeであり且つ、そのヒープ消費量Ｈが、ヒープ残量監視モジュール４１２から取得したヒープ残量Ｆより大きいと判定されると、図９から見て取れるように、このままリクエスト１を実行すると、確実にＧＣが起こってしまう。

そこで、ステップ７０６で、処理スケジューラ４０６は、Csmallであるリクエストをキュー４０４内で先頭から探すが、たまたま次のリクエスト２がCsmallなので、リクエスト２を先頭に移動させ、ステップ７０８で、図１０に示すように、リクエスト処理モジュール４０８にリクエスト２を処理させる。すると、ヒープ残量Ｆよりも、ヒープ消費量Ｈが小さいので、とりあえずＧＣが起こるのが回避される。こうすることによって、ＧＣを起す前に処理されるリクエストの数を可能な限り増やすことができる。

リクエスト２が処理されると、図１１に示すように、リクエスト１がキュー４０４の先頭に来る。ヒープ残量Ｆは、リクエスト２の実行により、さらに減っている。するとリクエスト１のヒープ消費量Ｈは、明らかにヒープ残量Ｆより少ないので、ステップ７０６の判断で、Csmallのリクエストが検索され、次のリクエストがCsmallなので、リクエスト３が先頭に移動され、結果としてリクエスト１が二番目になる処理が行われる。

このように、Clargeのリクエストを実行するとＧＣが起こると予想される場合に、本発明によれば、Csmallのリクエストが先行して実行される。ヒープ残量Ｆが減ってくると、Csmallのリクエストを実行しても結局ＧＣが避けられない時点が来るが、本発明によれば、ＧＣが起きる前に可能な限り多数のリクエストを処理できるので、リクエスト毎の平均待ち時間は減少させることができる。

なお、ステップ５０６で、今まで処理したことがないリクエスト・タイプのリクエストであることにより、平均ヒープ消費量Ｈが得られない場合は、ステップ５０８でリクエストのヒープ消費統計フラグがセットされるものの直ちには平均ヒープ消費量Ｈは得られない。

すなわち、その平均ヒープ消費量Ｈが得られてデータベース４１６に記録されるのは、図８のフローチャートに示すように、そのリクエストが処理された後である。すると、そのようなリクエストが処理準備可能となってステップ７０４の判断に遭遇したときは、まだ、消費クラスＣも、平均ヒープ消費量Ｈも未知ということになる。そこで例えば、消費クラスＣも、平均ヒープ消費量Ｈも未知であるリクエストについては、ステップ７０４でとりあえず、クラスはClargeで、平均ヒープ消費量Ｈは、Clargeのクラス全体の平均のヒープ消費量であると想定して、処理を進めることにしてもよい。

そのリクエストが処理された後は、そのリクエスト・タイプの平均ヒープ消費量Ｈがデータベース４１６に記録されるので、次回の処理からは、そのリクエスト・タイプのリクエストに適切な消費クラスＣと、平均ヒープ消費量Ｈが割り当てられる。

なお、上記実施例では、リクエストを、タイプに応じて、Csmallと、Clargeに分けたが、特にクラス分けせず、ステップ７０４のところで、リクエストの平均ヒープ消費量Ｈと、ヒープ残量Ｆだけに基づき、ＧＣを引き起こさないと判断されるリクエストをキューで繰り上げて先に処理するようにしてもよい。

また、上記実施例は、Ｊａｖａ ＶＭでの実装に基づき説明したが、処理キューをもち、ＧＣを引き起こしえるシステムであれば、サーバ・クライアント環境であることに拘わらず、スタンド・アロン環境でも本発明は適用可能であることを理解されたい。もちろん、特定のＯＳやアプリケーションにも限定されるものではない。

１０２ アプリケーション・サーバ
１０４ インターネット
２０２ バス
２０６ 主記憶
２０４ ＣＰＵ
２０８ ＩＤＥコントローラ
２１２ ＤＶＤドライブ
２１４ ディスプレイ・コントローラ
２１８ 通信インターフェース
２２０ ＵＳＢインターフェース
２２２ オーディオ・インターフェース
２２８ キーボード・マウス・コントローラ
２１６ ディスプレイ装置
２３０ キーボード
２３２ マウス
２１０ ハードディスク・ドライブ
２０６ メインメモリ
３０２ 通信インターフェース
３０４ バス
３０６ ＣＰＵ
３１０ ハードディスク・ドライブ
３０８ 主記憶
４０２ リクエスト受信モジュール
４０４ キュー
４０６ 処理スケジューラ
４０８ リクエスト処理モジュール
４１０ ヒープ領域
４１２ ヒープ残量監視モジュール
４１４ ガベージ・コレクション機能
４１６ ヒープ消費量データベース
４１８ 処理結果送信モジュール

Claims (15)

1. 処理すべきリクエストを入れるためのキューをもち、該キューから取り出されたリクエストを処理する際のヒープ残量不足に応じてガベージ・コレクションを起しえるシステムにおいて、該リクエストを処理するためのシステムであって、
   前記キューにある処理すべきリクエストについて、予測されるヒープ消費量を取得するヒープ消費量取得手段と、
   前記キューの先頭にあるリクエストについて、前記ヒープ消費量取得手段により取得された、予測されるヒープ消費量が前記ヒープ残量よりも大きいことに応答して、前記キュー中で、予測されるヒープ消費量が前記ヒープ残量よりも小さいと期待されるリクエストを見出す手段と、
   前記見出されたリクエストを、前記キュー中で、前記キューの先頭にあるリクエストより前に移動させる手段を有する、
   リクエスト処理システム。
2. 前記ヒープ消費量取得手段は、処理済みのリクエストのタイプ毎のヒープ消費量を、リクエストのタイプによって検索可能に記録するデータベースを有する、請求項１に記載のシステム。
3. 前記キューにある処理すべきリクエストについて、取得された予測されるヒープ消費量に応じて、ヒープ消費量が相対的に大きい第１のクラスと、ヒープ消費量が相対的に小さい第２のクラスに分ける手段をさらに有し、前記リクエストを見出す手段が、該第２のクラスのリクエストを前記キュー中で探す、請求項１に記載のシステム。
4. 前記リクエストを処理するためのシステムは、インターネット上のサーバであり、前記リクエストは、クライアント・コンピュータから、インターネット経由で送られる、請求項１に記載のシステム。
5. 前記サーバは、Ｊａｖａ ＶＭで実装される、請求項４に記載のシステム。
6. 処理すべきリクエストを入れるためのキューをもち、該キューから取り出されたリクエストを処理する際のヒープ残量不足に応じてガベージ・コレクションを起しえるシステムにおいて、該リクエストを処理するための方法であって、
   前記キューにある処理すべきリクエストについて、予測されるヒープ消費量を取得するステップと、
   前記キューの先頭にあるリクエストについて、前記予測されるヒープ消費量が前記ヒープ残量よりも大きいことに応答して、前記キュー中で、予測されるヒープ消費量が前記ヒープ残量よりも小さいと期待されるリクエストを見出すステップと、
   前記見出されたリクエストを、前記キュー中で、前記キューの先頭にあるリクエストより前に移動させるステップを有する、
   リクエスト処理方法。
7. 前記ヒープ消費量取得するステップは、処理済みのリクエストのタイプ毎のヒープ消費量を、リクエストのタイプによって検索可能に記録するステップを有する、請求項６に記載の方法。
8. 前記キューにある処理すべきリクエストについて、取得された予測されるヒープ消費量に応じて、ヒープ消費量が相対的に大きい第１のクラスと、ヒープ消費量が相対的に小さい第２のクラスに分けるステップをさらに有し、前記リクエストを見出すステップが、該第２のクラスのリクエストを前記キュー中で探す、請求項６に記載の方法。
9. 前記システムは、インターネット上のサーバであり、前記リクエストは、クライアント・コンピュータから、インターネット経由で送られる、請求項６に記載の方法。
10. 前記サーバは、Ｊａｖａ ＶＭで実装される、請求項９に記載の方法。
11. 処理すべきリクエストを入れるためのキューをもち、該キューから取り出されたリクエストを処理する際のヒープ残量不足に応じてガベージ・コレクションを起しえるシステムにおいて、該リクエストを処理するためのプログラムであって、
    前記システムのコンピュータをして、
    前記キューにある処理すべきリクエストについて、予測されるヒープ消費量を取得するステップと、
    前記キューの先頭にあるリクエストについて、前記予測されるヒープ消費量が前記ヒープ残量よりも大きいことに応答して、前記キュー中で、予測されるヒープ消費量が前記ヒープ残量よりも小さいと期待されるリクエストを見出すステップと、
    前記見出されたリクエストを、前記キュー中で、前記キューの先頭にあるリクエストより前に移動させるステップを実行させる、
    リクエスト処理プログラム。
12. 前記ヒープ消費量を取得するステップは、処理済みのリクエストのタイプ毎のヒープ消費量を、リクエストのタイプによって検索可能に記録するステップを有する、請求項１１に記載のプログラム。
13. 前記キューにある処理すべきリクエストについて、取得された予測されるヒープ消費量に応じて、ヒープ消費量が相対的に大きい第１のクラスと、ヒープ消費量が相対的に小さい第２のクラスに分けるステップをさらに有し、前記リクエストを見出すステップが、該第２のクラスのリクエストを前記キュー中で探す、請求項１１に記載のプログラム。
14. 前記システムは、インターネット上のサーバであり、前記リクエストは、クライアント・コンピュータから、インターネット経由で送られる、請求項１１に記載のプログラム。
15. 前記サーバは、Ｊａｖａ ＶＭで実装される、請求項１４に記載のプログラム。

Images