(57)【特許請求の範囲】
【請求項１】
処理すべきリクエストを入れるためのキューをもち、該キューから取り出されたリクエストを処理する際のヒープ残量不足に応じてガベージ・コレクションを起しえるシステムにおいて、該リクエストを処理するためのシステムであって、
前記キューにある処理すべきリクエストについて、予測されるヒープ消費量を取得するヒープ消費量取得手段と、
前記キューの先頭にあるリクエストについて、前記ヒープ消費量取得手段により取得された、予測されるヒープ消費量が前記ヒープ残量よりも大きいことに応答して、前記キュー中で、予測されるヒープ消費量が前記ヒープ残量よりも小さいと期待されるリクエストを見出す手段と、
前記見出されたリクエストを、前記キュー中で、前記キューの先頭にあるリクエストより前に移動させる手段を有する、
リクエスト処理システム。
【請求項２】
前記ヒープ消費量取得手段は、処理済みのリクエストのタイプ毎のヒープ消費量を、リクエストのタイプによって検索可能に記録するデータベースを有する、請求項１に記載のシステム。
【請求項３】
前記キューにある処理すべきリクエストについて、取得された予測されるヒープ消費量に応じて、ヒープ消費量が相対的に大きい第１のクラスと、ヒープ消費量が相対的に小さい第２のクラスに分ける手段をさらに有し、前記リクエストを見出す手段が、該第２のクラスのリクエストを前記キュー中で探す、請求項１に記載のシステム。
【請求項４】
前記リクエストを処理するためのシステムは、インターネット上のサーバであり、前記リクエストは、クライアント・コンピュータから、インターネット経由で送られる、請求項１に記載のシステム。
【請求項５】
前記サーバは、Ｊａｖａ  ＶＭで実装される、請求項４に記載のシステム。
【請求項６】
処理すべきリクエストを入れるためのキューをもち、該キューから取り出されたリクエストを処理する際のヒープ残量不足に応じてガベージ・コレクションを起しえるシステムにおいて、該リクエストを処理するための方法であって、
前記キューにある処理すべきリクエストについて、予測されるヒープ消費量を取得するステップと、
前記キューの先頭にあるリクエストについて、前記予測されるヒープ消費量が前記ヒープ残量よりも大きいことに応答して、前記キュー中で、予測されるヒープ消費量が前記ヒープ残量よりも小さいと期待されるリクエストを見出すステップと、
前記見出されたリクエストを、前記キュー中で、前記キューの先頭にあるリクエストより前に移動させるステップを有する、
リクエスト処理方法。
【請求項７】
前記ヒープ消費量取得するステップは、処理済みのリクエストのタイプ毎のヒープ消費量を、リクエストのタイプによって検索可能に記録するステップを有する、請求項６に記載の方法。
【請求項８】
前記キューにある処理すべきリクエストについて、取得された予測されるヒープ消費量に応じて、ヒープ消費量が相対的に大きい第１のクラスと、ヒープ消費量が相対的に小さい第２のクラスに分けるステップをさらに有し、前記リクエストを見出すステップが、該第２のクラスのリクエストを前記キュー中で探す、請求項６に記載の方法。
【請求項９】
前記システムは、インターネット上のサーバであり、前記リクエストは、クライアント・コンピュータから、インターネット経由で送られる、請求項６に記載の方法。
【請求項１０】
前記サーバは、Ｊａｖａ  ＶＭで実装される、請求項９に記載の方法。
【請求項１１】
処理すべきリクエストを入れるためのキューをもち、該キューから取り出されたリクエストを処理する際のヒープ残量不足に応じてガベージ・コレクションを起しえるシステムにおいて、該リクエストを処理するためのプログラムであって、
前記システムのコンピュータをして、
前記キューにある処理すべきリクエストについて、予測されるヒープ消費量を取得するステップと、
前記キューの先頭にあるリクエストについて、前記予測されるヒープ消費量が前記ヒープ残量よりも大きいことに応答して、前記キュー中で、予測されるヒープ消費量が前記ヒープ残量よりも小さいと期待されるリクエストを見出すステップと、
前記見出されたリクエストを、前記キュー中で、前記キューの先頭にあるリクエストより前に移動させるステップを実行させる、
リクエスト処理プログラム。
【請求項１２】
前記ヒープ消費量を取得するステップは、処理済みのリクエストのタイプ毎のヒープ消費量を、リクエストのタイプによって検索可能に記録するステップを有する、請求項１１に記載のプログラム。
【請求項１３】
前記キューにある処理すべきリクエストについて、取得された予測されるヒープ消費量に応じて、ヒープ消費量が相対的に大きい第１のクラスと、ヒープ消費量が相対的に小さい第２のクラスに分けるステップをさらに有し、前記リクエストを見出すステップが、該第２のクラスのリクエストを前記キュー中で探す、請求項１１に記載のプログラム。
【請求項１４】
前記システムは、インターネット上のサーバであり、前記リクエストは、クライアント・コンピュータから、インターネット経由で送られる、請求項１１に記載のプログラム。
【請求項１５】
前記サーバは、Ｊａｖａ  ＶＭで実装される、請求項１４に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ウェブ・サーバなどのように、リクエストを順次受け付けてキューに入れ、処理するコンピュータ・システムに関し、キュー上で待機するリクエストの処理の効率化に関する。
【背景技術】
【０００２】
近年、インターネット技術が隆盛するにつれて、インターネット上に配置され、クラアイント・システムからアクセス可能なウェブ・サーバが増大している。ウェブ・サーバは通常、インターネットを介して多数のクライアント・コンピュータから、処理リクエストを受け取るので、これを一度に処理することはできず、一旦キューに入れて、順次処理する。
【０００３】
このようにキューに入れられたリクエストを、少しでも早く合理的に処理する技法が要望されている。
【０００４】
特開２００３−２８３５５６号公報は、クライアントからサーバへの要求を、データ通信中継装置を介して行い、データ通信中継装置は要求の優先度付きのキューイング手段を持ち、ある優先度に応じて、要求の中継順序も入れ替える手段を持ち、これにより、サーバへの同時要求数をサーバの処理能力内に押さえもとともに、安定したサービスを提供することを開示する。
【０００５】
特開２００６−７２７６０号公報は、情報装置からのリクエスト情報に応じてサービスを提供するサーバの負荷を監視し、情報装置からのリクエスト情報を受信した際に、前記監視の結果、負荷が所定条件を満たしていれば該リクエスト情報を前記サーバに通知し、負荷が所定条件を満たしていなければ該リクエスト情報を保留にして当該情報装置の情報を待ち行列に加え、前記待ち行列に加えた情報装置に対し、待ち時間に応じたインセンティブの発行を通知すると共に、この情報装置とインセンティブとを対応付けて記憶し、前記監視の結果、新規リクエストが可能な場合に、所定の順で前記情報装置の情報を待ち行列から除き、当該情報装置からのリクエスト情報を前記サーバへ通知することを開示する。
【０００６】
特開２００７−３２９６１７号公報は、ＩＰネットワークでの呼処理サーバに関し、呼処理バッファに優先度の異なる２種類以上のキューを用意することにより、接続要求処理の実行を切断要求処理の実行よりも優先して行い、呼処理タスクが次の処理を行うために、キューからイベントを取り出す際に、キューの間で取り出し順の優先制御を行うことを開示する。この際、ルータなどのパケット転送処理と同様に、ＰＱ、あるいは、ＷＲＲなどのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する。
【０００７】
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に分けたが、特にクラス分けせず、ステップ７０４のところで、リクエストの平均ヒープ消費量Ｈと、ヒープ残量Ｆだけに基づき、ＧＣを引き起こさないと判断されるリクエストをキューで繰り上げて先に処理するようにしてもよい。
【００７０】
また、上記実施例は、Ｊａｖａ  ＶＭでの実装に基づき説明したが、処理キューをもち、ＧＣを引き起こしえるシステムであれば、サーバ・クライアント環境であることに拘わらず、スタンド・アロン環境でも本発明は適用可能であることを理解されたい。もちろん、特定のＯＳやアプリケーションにも限定されるものではない。
【符号の説明】
【００７１】
１０２  アプリケーション・サーバ
１０４  インターネット
２０２  バス
２０６  主記憶
２０４  ＣＰＵ
２０８  ＩＤＥコントローラ
２１２  ＤＶＤドライブ
２１４  ディスプレイ・コントローラ
２１８  通信インターフェース
２２０  ＵＳＢインターフェース
２２２  オーディオ・インターフェース
２２８  キーボード・マウス・コントローラ
２１６  ディスプレイ装置
２３０  キーボード
２３２  マウス
２１０  ハードディスク・ドライブ
２０６  メインメモリ
３０２  通信インターフェース
３０４  バス
３０６  ＣＰＵ
３１０  ハードディスク・ドライブ
３０８  主記憶
４０２  リクエスト受信モジュール
４０４  キュー
４０６  処理スケジューラ
４０８  リクエスト処理モジュール
４１０  ヒープ領域
４１２  ヒープ残量監視モジュール
４１４  ガベージ・コレクション機能
４１６  ヒープ消費量データベース
４１８  処理結果送信モジュール
【図１】
0005476208.tif 000002
【図２】
0005476208.tif 000003
【図３】
0005476208.tif 000004
【図４】
0005476208.tif 000005
【図５】
0005476208.tif 000006
【図６】
0005476208.tif 000007
【図７】
0005476208.tif 000008
【図８】
0005476208.tif 000009
【図９】
0005476208.tif 000010
【図１０】
0005476208.tif 000011
【図１１】
0005476208.tif 000012