(57)【要約】【課題】Ｗｅｂサーバと複数のＡＰサーバからなるシステムにおいて、トータル性能を向上させるように、各ＡＰサーバにユーザリクエストを振り分ける従来方法において、不要リソース解放処理中のユーザリクエスト処理の中断によりシステム性能が悪化する。【解決手段】ＡＰサーバは自サーバ内のリソース情報を取得し、それをＷｅｂサーバに送信する。Ｗｅｂサーバは、各ＡＰサーバから受信したリソース情報をもとに、ユーザリクエストを振り分けするのに最適なＡＰサーバを選択し、選択したＡＰサーバにユーザリクエストを振り分けする。また、Ｗｅｂサーバにはリソースの使用中領域が閾値以上になったＡＰサーバに対してガベージコレクション要求を送信し、そのＡＰサーバに対してはガベージコレクション処理が終了するまでは、ユーザリクエストを振り分けしないか、またはレスポンスタイムが長くなってもかまわないユーザリクエストのみを振り分けする。【選択図】図１
2007328413.tif 000002
【特許請求の範囲】
【請求項１】
第１のサーバと、前記第１のサーバに接続された複数台の第２のサーバ群から構成され、前記第１のサーバには、前記第１のサーバに受信されたユーザリクエスト内容を実行させるサーバとして前記第２のサーバ群の中から１台のサーバを選択し、前記選択されたサーバにユーザリクエスト内容を送信するステップを有する計算機システムの負荷分散方法において、
前記第２のサーバ群の各々は、自サーバ内のリソース情報を取得するステップと、取得した前記リソース情報を前記第１のサーバに送信するステップを有し、
前記第１のサーバは、受信した前記リソース情報を元にユーザリクエストを振り分けるべきサーバを前記第２のサーバ群の中から選択するステップと、選択した前記サーバに対して前記ユーザリクエストを送信するステップを有することを特徴とする負荷分散方法。
【請求項２】
前記第２のサーバ群の各々は、オブジェクトを保存する領域を管理する機能の一つにガベージコレクションの機能を持つ処理系を採用した環境であり、
前記第２のサーバ群の各々の前記リソース情報を取得するステップは、ガベージコレクションが動作中であるか否かをリソース情報として取得し、
前記第１のサーバの前記ユーザリクエストを送信すべきサーバを選択するステップは、ガベージコレクションが発生していないサーバから選択する請求項１記載の負荷分散方法。
【請求項３】
前記第２のサーバ群の各々は、オブジェクトを保存する領域を管理する機能の一つにガベージコレクションの機能を持つ処理系を採用した環境であり、
前記第２のサーバ群の各々の前記リソース情報を取得するステップは、ガベージコレクションを実行中であるか否かという情報とオブジェクトを保存するための領域全体に占める使用中領域の割合をリソース情報として取得し、
前記第１のサーバの前記ユーザリクエストを送信すべきサーバを選択するステップは、ガベージコレクションが発生しておらず、且つ、前記割合が閾値以下であるサーバから選択する請求項１記載の負荷分散方法。
【請求項４】
前記第２のサーバ群の各々は、オブジェクトを保存する領域を管理する機能の一つにガベージコレクションの機能を持つ処理系を採用した環境であり、
前記第２のサーバ群の前記リソース情報を取得するステップは、オブジェクトを保存するための領域全体に占める使用中領域の割合をリソース情報として取得し、
前記ユーザリクエストを送信すべきサーバを選択するステップは、レスポンスタイムが要求されるユーザリクエストに関しては前記割合が閾値以下であるサーバから選択し、レスポンスタイムが要求されないユーザリクエストに関しては従来手法のアルゴリズムにより振り分けするサーバを選択する請求項１記載の負荷分散方法。
【請求項５】
前記第２のサーバ群の各々は、オブジェクトを保存する領域を管理する機能の一つにガベージコレクションの機能を持つ処理系を採用した環境であり、
前記第１のサーバは、受信した前記リソース情報をもとに、前記第２のサーバ群の中から１台以上のガベージコレクションを実行すべきサーバ群を選択するステップを有し、
前記第１のサーバは、前記選択したサーバ群に対してガベージコレクションを実行するよう指示する情報を送信するステップを有し、
前記選択されたサーバ群は前記第１のサーバからの指示を受信するステップを有し、
前記選択されたサーバ群はガベージコレクションの指示に従って、ガベージコレクションを実行するステップを有する請求項３または４記載の負荷分散方法。
【請求項６】
第１のサーバと、複数台の第２のサーバ群から構成され、前記第１のサーバには、前記第１のサーバに受信されたユーザリクエスト内容を実行させるサーバとして前記第２のサーバ群の中から１台のサーバを選択し、前記選択されたサーバにユーザリクエスト内容を送信するステップを有する計算機システムの負荷分散方法において、
前記第２のサーバ群の各々は、自サーバ内のリソース情報を取得するステップと、取得した前記リソース情報を基礎にユーザリクエストの受付可否を判定するステップと、当該判定結果を前記第１のサーバに送信するステップを有し、
前記第１のサーバは、受信した前記ユーザリクエストの受付可否情報を元にユーザリクエストを振り分けるべきサーバを前記第２のサーバ群の中から選択するステップと、選択した前記サーバに対して前記ユーザリクエストを送信するステップを有することを特徴とする負荷分散方法。
【請求項７】
前記第２のサーバ群の各々は、オブジェクトを保存する領域を管理する機能の一つにガベージコレクションの機能を持つ処理系を採用した環境であり、
前記第２のサーバ群の各々の前記リソース情報を取得するステップは、ガベージコレクションが動作中であるか否かをリソース情報として取得し、前記取得した前記リソース情報を基礎にユーザリクエストの受付可否を判定するステップは、ガベージコレクションが動作中であるとのリソース情報を与えられたときは受付否と判定するものであり、
前記第１のサーバの前記ユーザリクエストを送信すべきサーバを選択するステップは、前記ユーザリクエストの受付否情報を受信したときは、当該受付否情報を送信したサーバを除いて前記第２のサーバ群の中から選択する請求項６記載の負荷分散方法。
【請求項８】
ネットワークを介してユーザに接続される第１のサーバと、前記第１のサーバに接続された複数台の第２のサーバ群とから構成される計算機システムであって、
前記第１のサーバは、前記ユーザの送信したユーザリクエストを受信したとき、前記ユーザリクエストを実行させるサーバとして前記第２のサーバ群の中から１台のサーバを選択し、前記選択されたサーバにユーザリクエスト内容を送信するプログラムを備えるとともに、
前記第２のサーバ群の各々は、自サーバ内のリソース情報を取得して、当該取得した前記リソース情報を前記第１のサーバに送信するプログラムを備え、
前記第１のサーバの備える前記選択されたサーバにユーザリクエスト内容を送信するプログラムは、前記第２のサーバ群の各々から受信した前記リソース情報を元にユーザリクエストを振り分けるべきサーバを前記第２のサーバ群の中から選択するステップと、選択した前記サーバに対して前記ユーザリクエストを送信するステップとを有することを特徴とする計算機システム。
【請求項９】
ネットワークを介してユーザに接続される第１のサーバと、前記第１のサーバに接続された複数台の第２のサーバ群とから構成される計算機システムであって、
前記第１のサーバは、前記ユーザの送信したユーザリクエストを受信したとき、前記ユーザリクエストを実行させるサーバとして前記第２のサーバ群の中から１台のサーバを選択し、前記選択されたサーバにユーザリクエスト内容を送信するプログラムを備えるとともに、
前記第２のサーバ群の各々は、自サーバ内のリソース情報を取得し、当該取得した前記リソース情報を基礎にユーザリクエストの受付可否を判定し、当該判定結果を前記第１のサーバに送信するプログラムを備え、
前記第１のサーバの備える前記選択されたサーバにユーザリクエスト内容を送信するプログラムは、受信した前記ユーザリクエストの受付可否判定結果を元にユーザリクエストを振り分けるべきサーバを前記第２のサーバ群の中から選択するステップと、選択した前記サーバに対して前記ユーザリクエストを送信するステップを有することを特徴とする計算機システム。
【請求項１０】
前記第２のサーバ群の各々は、オブジェクトを保存する領域を管理する機能の一つにガベージコレクションの機能を持つ処理系を採用した環境であり、
前記第２のサーバ群の各々の前記リソース情報を基礎にユーザリクエストの受付可否を判定し当該判定結果を前記第１のサーバに送信するプログラムは、ガベージコレクションが動作中であるか否かをリソース情報として取得し、前記取得した前記リソース情報がガベージコレクションが動作中であるときは前記ユーザリクエストの受付否と判定するステップを有し、
前記第１のサーバの備える前記選択されたサーバにユーザリクエスト内容を送信するプログラムは前記ユーザリクエストの受付否情報を受信したときは、当該受付否情報を送信したサーバを除いて前記第２のサーバ群の中から選択する請求項９記載の計算機システム。
【請求項１１】
前記第１のサーバが受信した前記リソース情報をもとに、前記第２のサーバ群の中から１台以上のガベージコレクションを実行すべきサーバ群を選択するステップは、
前記使用中の割合が閾値以上であるサーバのうち、前記使用中の割合が高いサーバから順に割り当てる請求項５記載の負荷分散方法。
【請求項１２】
前記第１のサーバは、前記ガベージコレクションを実行するよう指示する第２のサーバ群を選択した後は、
前記選択された第２のサーバ群のうち、処理中のリクエストが存在するサーバに対しては、前記処理中のリクエストの処理が完了してからガベージコレクションの実行指示を出すとともに、
前記第１のサーバの前記ユーザリクエストを送信すべきサーバを選択するステップとして、前記ガベージコレクションを実行するよう選択されたサーバ以外であり、且つ、ガベージコレクションが発生しておらず、且つ、前記使用中の割合が閾値以下であるサーバから選択する請求項１１記載の負荷分散方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバがユーザリクエストに応じてレスポンスをする計算機システムにおいて複数のサーバの負荷を適正に分散してシステムのトータルスループットの向上を図る負荷分散方法に関する。
【背景技術】
【０００２】
フロントエンドサーバとアプリケーションサーバ（以下、ＡＰサーバと記す）とバックエンドサーバからなる３層システムが普及している。特にフロントエンドサーバにＷｅｂサーバを使用し、バックエンドサーバとしてデータベースサーバ（以下、ＤＢサーバと記す）を使用するシステムが普及している。
【０００３】
このようなシステムでは、システムのトータルスループットの向上を図ることを目的に、複数台のＡＰサーバを用意することが一般的となりつつある。この場合、個々のＡＰサーバを効率よく利用することで、トータルスループットを向上させることができる。そのため、フロントエンドサーバは個々のユーザリクエストを各ＡＰサーバに適切に振り分ける必要がある。
【０００４】
振り分け方法としては、一般的には、単に順番に振り分ける方法（ラウンドロビン方法）が最も一般的であり、他にも、過去の動作実績からレスポンスタイムが速いＡＰサーバに動的に振り分け先を決定する振り分け方法などが知られている。
【０００５】
また、特許文献１（特開２００２−９１９３６）には、サービス要求パケットのヘッダ情報から前記サービス要求がサーバに与える負荷の大きさを見積もる手段と、見積もり値を振り分けられたサーバ毎に管理する手段とを有することにより、サーバのリアルタイムな負荷状態に基づく負荷分散を可能とする方法についての記載がある。
【０００６】
また、近年ＡＰサーバにＪａｖａ（Ｊａｖａはサン・マイクロシステムズ・インコーポレーテッドの商標または登録商標）を用いる例が増えている。Ｊａｖａはオブジェクトを保存する領域を管理する機能の一つにガベージコレクション（ＧＣ）の機能を持つ処理系の一つである。
【０００７】
【特許文献１】特開２００２−９１９３６公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上述したラウンドロビン方法やレスポンスタイムが速いＡＰサーバに振り分ける方法を採用すると、個々のユーザリクエストの負荷が異なる場合や、ＡＰサーバにおいて処理速度が異なるような場合では、複数あるＡＰサーバ間で負荷に偏りが生じ、ＡＰサーバの利用効率が低下するといった課題が生ずる。これは、ラウンドロビン方法を採用すると、負荷の高いＡＰサーバに対しても負荷の低いＡＰサーバと同様にユーザリクエストを割り振ってしまうし、レスポンスタイムが速いＡＰサーバに振り分けるといっても、これまでレスポンスタイムが速かったサーバが今後も速いとは限らないためである。
【０００９】
特許文献１（特開２００２−９１９３６）に記載の方法により、サービス要求パケットのヘッダ情報から将来のＡＰサーバの負荷状態を見積もり、その見積もりに基づいた負荷分散を実現できるが、ＡＰサーバの負荷状態はサービス要求パケットのみに左右されるわけではないため、前記課題の完全な解決には至っていない。
【００１０】
つまり、ＡＰサーバの負荷状況はユーザリクエストの処理以外にも左右されるということである。例えばリソースの管理の状態にも左右される。特にＯＳやミドルウェアがガベージコレクションの処理を実施する時にユーザリクエストの処理などの他の処理を止めてしまうことがある。このような場合には、ユーザリクエストに対してはリソース管理処理が終わるまでレスポンスが返らなくなってしまい、レスポンスタイムやスループットが悪化してしまう。
【００１１】
具体的には、例えば、ＡＰサーバの動作環境としてＪａｖａバーチャルマシン（以下、ＪａｖａＶＭと記載する）を用いたＡＰサーバの場合、ＧＣ（ガベージコレクション）が発生するとＪａｖａＶＭはユーザリクエスト処理を中断してＧＣの作業に専念するため、前記ＡＰサーバに要求されたユーザリクエスト処理は滞ってしまい、レスポンスタイムが悪化するような状況がおこる。
【００１２】
前記課題に鑑み、本発明の目的は、複数のＡＰサーバを効率よく利用し、システムのトータルスループットを向上すると共に個々のユーザリクエストに対するレスポンスタイムのばらつきを抑制することができる負荷分散方法を提供することにある。
【課題を解決するための手段】
【００１３】
前記課題を解決するために、ＡＰサーバの各々には、自サーバ内のリソース情報を取得するステップと、取得した前記リソース情報をＡＰサーバの各々に送信するステップを用意する。一方、フロントエンドサーバには、各ＡＰサーバのリソースを監視するステップと、各ＡＰサーバから受信したリソース情報をもとに、リソースに余裕のあるＡＰサーバを選択するステップと、選択したＡＰサーバに振り分けされたユーザリクエストを送信するステップを用意する。
【発明の効果】
【００１４】
本発明によれば、ユーザリクエストを適切なＡＰサーバに振り分けることができ、ＡＰサーバがガベージコレクションの処理によりレスポンスを遅らせてしまうことが防止でき、システム全体の利用効率が向上し、システムのトータルスループットを向上させ、レスポンスタイムのばらつきを抑制することができる。
【発明を実施するための最良の形態】
【００１５】
（実施例１）
最初に本明細書における語句の定義を行う。
【００１６】
本明細書において、ミドルウェアとはオペレーティングシステム（以下、単にＯＳと書くこともある）とアプリケーションプログラム（以下、単にアプリケーションと書くこともある）の中間で働き、アプリケーションをＯＳが実行できる形式に変換したり、アプリケーションが必要とするリソースの管理を行ったりするソフトウェアのことを言う。リソースの管理として例えばアプリケーションがオブジェクトを生成した場合、ＯＳに対してメモリ確保の要求を行い、確保したメモリ空間をオブジェクト情報の記憶場所としたり、ガベージコレクションを行ったりする。ミドルウェアの代表例としてＪａｖａＶＭが挙げられる。
【００１７】
また、本明細書においてガベージコレクションとは「アプリケーションがオブジェクトを必要としなくなったとき、該当オブジェクトが占有していたメモリ空間はガベージ（不要リソース）として登録しておくシステムにおいて、溜まったガベージを掻き集めて解放することで他のオブジェクトが使用できるようにする処理」のことを言う。つまりガベージコレクションは不要リソースの解放処理の一種である。ガベージコレクションが発生する処理系の一つにＪａｖａＶＭがある。
【００１８】
以下図１と図５を参照して説明する。
【００１９】
実施例１では、図１に示すように、フロントエンドサーバにＷｅｂサーバ１０１、バックエンドサーバにＤＢサーバ１２１、両者の間にＡＰサーバ１１１、ＡＰサーバ１１２およびＡＰサーバ１１３を用いた３層システム構成を例に用いて説明する。ここで、フロントエンドサーバにはＷｅｂサーバに限らず、単なるロードバランサを用いてもかまわないし、Ｗｅｂ以外のプロトコルを用いるものでもかまわない。この図ではＡＰサーバは３台であるが、２台の構成の場合もあるし、４台以上の構成の場合もある。また、ＷｅｂサーバとＤＢサーバはそれぞれ１台で記述してあるが、複数台の構成も考えられるし、ＤＢサーバが無い構成も考えられる。Ｗｅｂサーバの手前に一つ以上のロードバランサを置く構成も考えられる。その場合、本発明におけるＷｅｂサーバの処理の一部または全てをロードバランサに処理させる構成をとることもできる。
【００２０】
Ｗｅｂサーバ１０１は、ユーザ１３１から送信されたユーザリクエストを送受信プログラム１０２で受信し、ユーザリクエスト振り分けＡＰサーバ選択プログラム１０３により決定されるＡＰサーバにユーザリクエストを振り分ける。この際、ＡＰサーバ情報管理テーブル４００に収集されている各ＡＰサーバの状況を参照する。一方、ユーザリクエスト振り分けＡＰサーバ選択プログラム１０３は、ガベージコレクション処理指示プログラム１０４に指令を送り、各ＡＰサーバにガベージコレクション処理を実行するようにトリガーをかけるよう指示させる。
【００２１】
各ＡＰサーバ１１１−１１３は、ユーザリクエスト処理プログラム１１４、リソース情報取得プログラム１１５およびガベージコレクション処理プログラム１１６を備える。ユーザリクエスト処理プログラム１１４は、ユーザリクエスト振り分けＡＰサーバ選択プログラム１０３から送られるユーザリクエストを受信して処理する、この際、必要ならＤＢサーバ１２１を利用する。リソース情報取得プログラム１１５は、ＡＰサーバ内のリソース情報を収集してＷｅｂサーバ１０１のＡＰサーバ情報管理テーブル４００に送信する。ガベージコレクション処理プログラム１１６はＷｅｂサーバ１０１のガベージコレクション処理指示プログラム１０４のガベージコレクション処理のトリガー指示を受けて、ガベージコレクション処理を実行する。
【００２２】
図５は上述したＷｅｂサーバ、ＡＰサーバおよびバックエンドサーバの機能およびユーザリクエストに関するそれぞれの間の連携の状況を示すフロー図である。ユーザ１３１からのユーザリクエストはインターネットやイントラネットなどのネットワークを通してＷｅｂサーバ１０１に送られる（ステップ５０１）。Ｗｅｂサーバ１０１はユーザリクエストを３台のＡＰサーバ１１１，１１２，１１３のいずれに振り分けるかを決定する（ステップ５０２）。この振り分け処理、すなわち、ＡＰサーバへのユーザリクエストの振り分けの処理がこの発明のポイントとなる点であり、詳細は後から述べる。Ｗｅｂサーバ１０１は決定された振り分け先のＡＰサーバ１１１，１１２，１１３にユーザリクエストを振り分けする（ステップ５０３）。ユーザリクエストを振り分けられたＡＰサーバ１１１，１１２，１１３は、Ｗｅｂサーバ１０１からのユーザリクエストを受け付け、内部でユーザリクエストに対する処理を行う。ＡＰサーバ１１１，１１２，１１３は必要に応じてＤＢサーバ１２１にアクセスしデータの参照・更新を行う（ステップ５０４）。処理が完了した後、ＡＰサーバ１１１，１１２，１１３は処理結果をＷｅｂサーバ１０１に返す（ステップ５０５）。Ｗｅｂサーバ１０１はその結果をユーザ１３１に返す（ステップ５０６）。
【００２３】
ここで、各サーバのハードウェア的な中身に関して図３を参照して説明する。この図ではＡＰサーバ１１１を示しているが、ＡＰサーバ１１２やＡＰサーバ１１３はもとよりＷｅｂサーバ１０１やＤＢサーバ１２１も同じ構成と考えてよい。
【００２４】
ソフトウェアプログラムは、不揮発性記憶装置３０２に保存されており、揮発性記憶装置３０１に転送されて中央演算処理装置３０３により実行される。中央演算処理装置３０３はネットワーク制御装置３０４を用いて外部のサーバと通信することができる。また、揮発性記憶装置３１０、不揮発性記憶装置３０２、中央演算処理装置３０３およびネットワーク制御装置３０４は内部バス３０６で接続されている。内部バス３０６には入出力装置３０５も接続されており、例えば、システム管理者がＡＰサーバ１１１の内部情報を制御するときなどに使用される。
【００２５】
ここで、ＡＰサーバ１１１のソフトウェア的な中身を図２と図６を参照して説明する。なお、ＡＰサーバ１１２およびＡＰサーバ１１３もソフトウェア的な中身はＡＰサーバ１１１と同様である。
【００２６】
ユーザリクエスト処理プログラム１１４は、Ｗｅｂサーバ１０１のユーザリクエスト振り分けＡＰサーバ選択プログラム１０３から送られるユーザリクエストを送受信部２０５で受信してアプリケーションプログラム２０３を起動して処理する。この際、必要ならＤＢサーバ１２１を利用する。
【００２７】
ＡＰサーバ１１１では、オペレーティングシステム２０１（以下、オペレーティングシステムのことをＯＳと記す）が動作しており、その上でミドルウェア２０２が動作している。なお、ここからの説明ではミドルウェアとしてＪａｖａＶＭを例として説明するが、ガベージコレクションなどの不要リソースの解放処理を発生するようなミドルウェアであればＪａｖａＶＭに限らず本発明による処理を行うことができるし、ＯＳがガベージコレクション処理を行う場合は以後の説明のＪａｖａＶＭをＯＳに置き換えて読めばよい。
【００２８】
さらにＪａｖａＶＭ２０２上でアプリケーションプログラム２０３が動作している。アプリケーションプログラム２０３は単体のＪａｖａプログラムで構築されている場合もあるし、Ｊ２ＥＥ（Ｊ２ＥＥはサン・マイクロシステムズ・インコーポレーテッドの登録商標）上のアプリケーションとして構築されている場合もある。
【００２９】
一般にＡＰサーバは様々なリソースを用いながら動作している。例えばメモリであり、ＣＰＵ時間である。メモリにはＯＳの管理するメモリや、ＪａｖａＶＭの管理するメモリやＡＰが管理するメモリなどがある。これらのリソースが不足すると性能劣化やシステムダウンの原因となる。例えばＪａｖａＶＭ２０２ではオブジェクトの管理にヒープ領域が確保され使用されるが、確保されたメモリは前記オブジェクトが不要になった後もすぐには解放されない。ガベージコレクション（ＧＣ）が発生すると、不要となったオブジェクトが占有していたメモリがＧＣによって解放され、新たなオブジェクトの管理をすることができるようになる。ＧＣはヒープ領域が不足してくるときなどＪａｖａＶＭが自動的に行うこともあるし、ユーザアプリケーションが明示的にＧＣを指示することで行われることもある。ＧＣを行っている最中にはＧＣ以外の処理であるユーザリクエストへの処理が中断される処理系が存在する。特にフルＧＣ（フルガベージコレクション）と呼ばれるＧＣの場合には他の処理が全て中断され、ユーザリクエストに対するスループットやレスポンスタイムの低下の原因となる。
【００３０】
リソース情報取得プログラム１１５は、ＪａｖａＶＭ２０２からはＪＶＭＴＩ２０４によりＪａｖａＶＭ２０２の内部状態を取得することができる。ＪＶＭＴＩ２０４はＪ２ＳＥ５．０からサポートされた機能である。この取得情報を送信部２０６を用いて、Ｗｅｂサーバ１０１へ送信する。このときＪＶＭＴＩ２０４から得られ、本発明で使用される情報の例は次のようである。（１）メモリ上にクラスがロードされたことを示すクラスのロードの情報、（２）コンパイルされたメソッドがロードされたことを示す情報、（３）ガベージコレクション実行中の情報、（４）これまで必要であったオブジェクトが不要となりガベージが溜まることを意味するオブジェクトの解放の情報である。
【００３１】
なお、ＪａｖａＶＭ２０２からの情報取得はＪＶＭＴＩ２０４のほか、ＪＭＸ（Java Management Extensionsの略。ＪＭＸはサン・マイクロシステムズ・インコーポレーテッドの登録商標）を用いる方法や、Ｊ２ＳＥ５．０以降で使用可能なコマンドライン形式の情報取得ツールであるｊｓｔａｔ（Java Virtual Machine Statistics Monitoring Tool）を用いる方法や、同じくＪ２ＳＥ５．０以降で使用可能な、ＪＳＲ−１７４で策定されているMonitoring and Management Specification for the Java Virtual Machineを用いる方法もある。これらの方法を用いて、ヒープ領域の総量や現在の使用量、ＪａｖａＶＭのシステムプロパティの値、Ｊａｖａスレッドに関する情報などを取得することができる。リソース情報取得プログラム１１５はＪａｖａＶＭ２０２からの情報の他、ＯＳ２０１からの情報やアプリケーションプログラム２０３からの情報も得ることができ、それらの情報も送信部２０６を用いてＷｅｂサーバ１０１へ送信する。
【００３２】
ガベージコレクション処理プログラム１１６はＷｅｂサーバ１０１のガベージコレクション処理指示プログラム１０４のガベージコレクション処理のトリガー指示を受信部２０７で受けて、アプリケーションプログラム２０３、ＪａｖａＶＭ２０２およびＯＳ２０１に対してガベージコレクション処理を実行する。
【００３３】
以下、図６を参照してＡＰサーバ１１１の情報をＷｅｂサーバ１０１が取得するフローチャートを解説する。情報採取のきっかけはＷｅｂサーバ１０１が一定期間ごとに各ＡＰサーバに問い合わせるポーリング方法や、ユーザリクエストを振り分けするタイミングで各ＡＰサーバに問い合わせる方法や、Ｗｅｂサーバ１０１が一定期間ごとにＡＰサーバに自発的に送信を開始する方法や、情報に変化があった時にＡＰサーバからＷｅｂサーバに自発的に送信を開始するプッシュ式などが考えられる。
【００３４】
ＡＰサーバ１１１の情報取得プログラム１１５は、ＪＶＭＴＩ２０４を用いてＪａｖａＶＭ２０２の内部情報を取得する（ステップ６０１）。次いで、送信部２０６は情報取得プログラム２０５が取得した情報をＷＥＢサーバ１０１に送信する（ステップ６０２）。
【００３５】
Ｗｅｂサーバ１０１は各ＡＰサーバの送信部２０６からの情報を受け取り、各ＡＰサーバの内部情報を把握する。内部情報は例えば図４に示す情報テーブル４００のような形式で保存される（ステップ６０３）。ここでは各ＡＰサーバ１１１，１１２及び１１３について、ＧＣの発生状況およびヒープメモリの使用率の列４０１、ロードされているクラスの列４０２、コンパイル済みメソッドの列４０３、０．１秒後のＣＰＵ利用率の予測値の列４０４、０．２秒後のＣＰＵ利用率の予測値の列４０５、０．３秒後のＣＰＵ利用率の予測値の列４０６、ユーザリクエストの受付可否状況の列４０７の項目のデータを保存している。ここで、図４において太い破線で示す領域の情報４１０が、各ＡＰサーバの情報取得プログラム１１５から送信部２０６を介して提供される情報である。
【００３６】
なお、この情報テーブル４００ではＣＰＵ利用率の予測値の列４０４，４０５および４０６では０．１秒後、０．２秒後および０．３秒後の各時間経過後における予測値としているが、時間間隔は０．１秒に限らず、１秒単位や１０秒単位など他の間隔を単位とする構成でもよい。さらに、３単位時間先までではなく、１０単位時間先までなど、大きな単位時間先までを予測する構成とするものでも良いことは言うまでもない。
【００３７】
各ＡＰサーバ１１１，１１２および１１３の情報は、それぞれの行で保存されるが、この値は書き換えられると共に、将来の予測値を計算し直し、更新する（ステップ６０４）。この更新作業は、例えば、次のようにして行われる。
【００３８】
Ｗｅｂサーバ１０１は、ユーザ１３１からユーザリクエストを受けたとき、各ＡＰサーバ１１１，１１２および１１３にユーザリクエストを振り分けるため、各ＡＰサーバの今後の仕事量を見積もることが可能である。つまり、例えばユーザリクエストをＡＰサーバ１１３に割り振った場合、前記ユーザリクエストを処理するために０．２秒間にわたってＣＰＵ利用率の予測値が１０％増加することが見込まれれば、０．１秒後のＣＰＵ利用率の予測値の列４０４のＡＰサーバ１１３の欄と、０．２秒後のＣＰＵ利用率の予測値の列４０５のＡＰサーバ１１３の欄の値をそれぞれ１０％増やす。現在値が共に３０％と予測されているから、これを共に４０％に書き換えることになる。振り分けられたユーザリクエストに応じて、各ＡＰサーバの今後の仕事量を見積もるには、予め、ユーザリクエストの内容に応じた仕事量を定義しておくことが一つの方法である。
【００３９】
また、前回の更新から０．１秒が経過した時に、それまでに新たなユーザリクエストがなければ、０．２秒後のＣＰＵ利用率の予測値の列４０５の情報を０．１秒後のＣＰＵ利用率の予測値の列４０４に、０．３秒後のＣＰＵ利用率の予測値の列４０６の情報を０．２秒後のＣＰＵ利用率の予測値の列４０５にそれぞれコピーし、０．３秒後のＣＰＵ利用率の予測値の列４０６の情報は０でクリアする。
【００４０】
ユーザリクエストの受付可否状況の列４０７の項目には、新たなユーザリクエストに対する現時点での受付可否状況が記録されている。例えばＡＰサーバ１１１のこの欄は「受付不可」になっていることからＡＰサーバ１１１では新たなユーザリクエストの受付ができない状況であることがわかる。したがって、このような場合はＷｅｂサーバ１０１はＡＰサーバ１１１へ新たなユーザリクエストを振り分けしない。一方、ＡＰサーバ１１２あるいは１１３ではユーザリクエストの受付可否状況の列４０７の欄が「受付可」になっていることから、Ｗｅｂサーバ１０１はＡＰサーバ１１２やＡＰサーバ１１３に新たなユーザリクエストを振り分けすることができる。
【００４１】
次に、ステップ５０２の振り分けサーバ選択処理による振り分け先の決定について説明する。
【００４２】
図４に示す情報４００から分るように、ＧＣの発生状況およびヒープメモリの使用率４０１の欄から、ＡＰサーバ１１１ではＧＣが発生中（つまりＧＣ処理中）、ＡＰサーバ１１２，１１３ではＧＣが不発生（つまりＧＣ処理無）が記録されていることが分る。そのため、次のユーザリクエストをＡＰサーバ１１１に振り分けるとＧＣが終わるまで処理してもらえず、レスポンスタイムが長くなることが予想される。しかし、ＡＰサーバ１１２およびＡＰサーバ１１３ではＧＣが発生していないことが記録されている。そこで、ユーザリクエストをＡＰサーバ１１２あるいはＡＰサーバ１１３に振り分けることにより、ユーザリクエストのレスポンスタイムは短くなることが予測でき、Ｗｅｂサーバ１０１はユーザリクエストをＡＰサーバ１１２あるいはＡＰサーバ１１３に振り分けることとする。
【００４３】
このユーザリクエストの振り分け先の判定部分をフローチャートで示すと図７のようになる。
【００４４】
まず、全てのＡＰサーバをユーザリクエスト振り分け先候補とする（ステップ７０１）。次に、情報テーブル４００を参照してＧＣが発生中であるＡＰサーバをユーザリクエスト振り分け先候補からはずす（ステップ７０２）。ユーザリクエスト振り分け先候補の台数を判定してそれぞれ処理を行う（ステップ７０３）。ユーザリクエスト振り分け先候補の台数が０台であった場合は、再び、全てのＡＰサーバをユーザリクエスト振り分け先候補としてステップ７０３に戻る（ステップ７０４）。ユーザリクエスト振り分け先候補の台数が２台以上であった場合は、ユーザリクエスト振り分け先候補の中からラウンドロビンなど従来手法によりユーザリクエスト振り分け先を決定する（ステップ７０５）。ユーザリクエスト振り分け先候補の台数が１台であった場合は前記ユーザリクエスト振り分け先候補をユーザリクエスト振り分け先に決定する（ステップ７０６）。
【００４５】
ここでは、ＧＣ処理中の情報だけを用いてユーザリクエストの振り分け先を決定したが、そのほかの情報も加味して振り分け先を決定することもできる。以下に具体例を説明する。
【００４６】
振り分け先の決定方法として、情報テーブル４００を参照してＧＣが発生していないサーバを選ぶのに加えて、領域４１０に記録されている情報を利用してクラスがすでにロードされているサーバを選ぶ方法を説明する。
【００４７】
ＡＰサーバはクラスのロード、コンパイル済みメソッドのロード、コンパイル済みメソッドのアンロードの事象が発生すると、リソース情報取得プログラム１１５が送信部２０６を介して、Ｗｅｂサーバ１０１のユーザリクエスト振り分けＡＰサーバ選択プログラム１０３に、前記事象の発生を伝達する。Ｗｅｂサーバ１０１のユーザリクエスト振り分けＡＰサーバ選択プログラム１０３は、情報テーブル４００のロードされているクラスの列４０２、コンパイル済みメソッドの列４０３を、この情報に応じて書き換える。
【００４８】
ユーザリクエストがＷｅｂサーバ１０１に受信された時、そのユーザリクエストがＣｌａｓｓ  Ａを利用するものであった場合を考える。Ｗｅｂサーバ１０１は、ユーザリクエストの内容から、どのクラスを利用するものであるか判別することができる。図４に示す情報４００から分るように、ロードされているクラスの列４０２によれば、ＡＰサーバ１１１にはＣｌａｓｓ  Ａ、Ｃｌａｓｓ  ＢおよびＣｌａｓｓ  Ｃがロードされ、ＡＰサーバ１１２にはＣｌａｓｓ  ＢおよびＣｌａｓｓ  Ｃがロードされ、ＡＰサーバ１１３にはＣｌａｓｓ  Ａのみがロードされていることがわかる。よって、ＧＣが発生していないサーバであるＡＰサーバ１１２およびＡＰサーバ１１３の内、ＡＰサーバ１１３にユーザリクエストを振り分ければ、Ｃｌａｓｓ  Ａをロードする必要がないため、ＡＰサーバ１１２にユーザリクエストを振り分けるよりも、短時間で処理され、ターンアラウンドタイムが短くなることが予想できる。よって、Ｗｅｂサーバ１０１は、この場合はユーザリクエストをＡＰサーバ１１３に振り分けることとする。
【００４９】
また、クラスのロード情報のほかに、コンパイルされているインスタンスの情報を用いることもできる。
【００５０】
図４に示す情報４００から分るように、コンパイル済みメソッドの列４０３によれば、ＡＰサーバ１１１にはＩｎｓｔａｎｃｅ  Ａが、ＡＰサーバ１１２にはＩｎｓｔａｎｃｅ  Ｂ１およびＩｎｓｔａｎｃｅ  Ｂ２が、それぞれ、コンパイルされ、ＡＰサーバ１１３にはコンパイルされたインスタンスがないことがわかる。ここでユーザリクエストがＩｎｓｔａｎｃｅ  Ｂ１を用いるユーザリクエストだったときを考える。Ｗｅｂサーバ１０１は、前記ユーザリクエストを振り分けるＡＰサーバを決める際、前記ユーザリクエストの処理にはＩｎｓｔａｎｃｅ  Ｂ１を利用することからＡＰサーバ１１２を選択する。
【００５１】
また、図４に示す情報４００から分るように、０．１秒後、０．２秒後および０．３秒後のＣＰＵ利用率の予測値の列４０４，４０５および４０６の各列に示される各ＡＰサーバのＣＰＵ使用率の予測値の変化に着目したユーザリクエストの振り分けもできる。例えばＡＰサーバ１１１は１００％、１００％、３０％と変化し、ＡＰサーバ１１２は２０％、１０％、１０％と変化し、ＡＰサーバ１１３は３０％、３０％、１０％と変化することから当面のＣＰＵ利用率が低く単位時間経過後もＣＰＵ利用率の予測値が低いＡＰサーバ１１２をユーザリクエストの振り分け先として選択する。
【００５２】
また振り分け先の決定方法として前記のほかに以下のような方法とすることもできる。
【００５３】
前述のように、ＧＣが発生するとＣＰＵの処理はＧＣに費やされ、ユーザからのユーザリクエスト処理が滞ってしまい、スループットやレスポンスタイムが悪化する。そこで、ＧＣの発生を予測することでＧＣが発生しそうなＡＰサーバにはユーザリクエストを振り分けないことにする。各ＡＰサーバのヒープ領域の使用中領域量またはヒープ領域の領域量と使用中領域量の割合からＧＣが発生する可能性を推測することができる。それらが閾値以上であればＧＣが発生する可能性が高いと判断できる。もちろん「ヒープ領域＝使用領域＋空き領域」の関係が成り立つことから、空き領域が閾値以下であること、または、ヒープ領域の領域量における空き領域の割合が閾値以下であること、を判断材料にすることもできることは言うまでも無い。
【００５４】
このＧＣ発生の可能性の高さに対応したユーザリクエスト振り分け先の判定処理の一例を図８に示すフローチャートを参照して説明する。
【００５５】
まず、全てのＡＰサーバをユーザリクエスト振り分け先候補とする（ステップ８０１）。次に、情報テーブル４００を元にヒープ領域の使用中領域の割合が閾値以上であるＡＰサーバをユーザリクエスト振り分け先候補からはずす（ステップ８０２）。ユーザリクエスト振り分け先候補の台数が０台であった場合は、使用中領域の割合が一番小さいものをユーザリクエスト振り分け先として決定する（ステップ８０４）。ユーザリクエスト振り分け先候補の台数が１台であった場合は前記候補をユーザリクエスト振り分け先に決定する（ステップ８０５）。ユーザリクエスト振り分け先候補の台数が２台以上であった場合は、ユーザリクエスト振り分け先候補の中から従来手法を用いてユーザリクエスト振り分け先を決定するか、または使用中領域の割合が小さいＡＰサーバをユーザリクエスト振り分け先とする（ステップ８０６）。すでに述べたが、従来手法としてはラウンドロビン方法やレスポンスタイムが一番速いＡＰサーバを選ぶ方法やＣＰＵ利用率の予測値が低いＡＰサーバを選ぶ方法が挙げられる。
【００５６】
例を挙げて説明すると、図４に示す情報４００から分るように、ＧＣの発生状況およびヒープメモリの使用率の列４０１の欄から、例えば、ＡＰサーバ１１２とＡＰサーバ１１３のそれぞれのヒープ領域の領域量と使用中領域量を示すデータからＧＣの発生の可能性を測ることができる。例えばヒープ領域のうちの空き領域の割合によりＧＣが発生する可能性が高いと判断する。ＧＣ発生の閾値の設定は例えば８０％とする。ＡＰサーバ１１２ではヒープ領域２５６ＭＢのうちすでに２２０ＭＢが使用されている。つまり使用中領域の割合は８０％を上回っていることから近いうちにＧＣが発生する可能性が高いと判断できる。一方、ＡＰサーバ１１３においてはヒープ領域２５６ＭＢのうち８０ＭＢしか使用されておらず、使用中領域の割合は３０％そこそこであるからＧＣがすぐに発生する可能性は高くないと判断できる。よって、使用中領域の割合が閾値以下のＡＰサーバは１台となり、ユーザリクエストはＡＰサーバ１１３にユーザリクエストを振り分けると決定される。
【００５７】
また、この説明では閾値を固定値としたが、動的に変動させても良い。例えばＡＰサーバがユーザリクエスト処理中にＧＣが発生してほしくない要望が高い時は閾値を下げることで早めにＧＣを起こすようにする。この場合、ユーザリクエスト処理中にＧＣが発生する確率は下がるが、閾値を下げたことにより、より多数のＧＣが発生するようになるためシステムの効率は下がる。逆に閾値を上げることによりユーザリクエスト処理中にＧＣが発生してしまう確率は高くなるが、システム全体の効率を上げることができる。
【００５８】
また、前記方法ではＧＣが実行中であったり、使用中領域が閾値以上になりＧＣが発生する確率が高いと判断されたりしたＡＰサーバにはユーザリクエストを振り分けないこととしたが、以下のような形式も考えられる。すなわちＧＣが発生したり、ＧＣが発生する確率が高いと判断されたりしたＡＰサーバにはレスポンスタイムが多少長くなってもかまわないようなユーザリクエストのみを振り分ける。例えばバッチ処理のリクエストなどである。これにより、オンライン処理などのレスポンスタイムが要求されるユーザリクエストはＧＣが発生する確率が高くないＡＰサーバへ振り分けることができ、レスポンスタイムが悪化することを防ぐことができ、システム全体の運用を合理化できる。
【００５９】
上の例ではレスポンスタイムが多少長くなっても良い処理としてバッチ処理からのユーザリクエストを挙げたが、ユーザリクエストごとにレスポンスタイムの要求レベルを設定し、レスポンスタイムが多少長くなっても良い処理としてレスポンスタイムの要求レベルが一定以下のユーザリクエストのみを振り分けるものとしても良い。
【００６０】
この説明では閾値以上であることの判断をＷｅｂサーバ１０１が行ったが、各ＡＰサーバが閾値以上であるかどうかを判断し、判断結果のみをＷｅｂサーバに送信し、Ｗｅｂサーバは各ＡＰサーバから受信した閾値以上であるかどうかの情報のみを用いてユーザリクエストの送信先を決める構成を取ることもできる。
【００６１】
図９はこのためにＡＰサーバの一部を変更した構成を示す。各ＡＰサーバ１１１，１１２，１１３内にはユーザリクエスト受付可否判定プログラム１１８を設ける。リソース情報取得プログラム１１５はリソース情報をＷｅｂサーバ１０１に送信する代わりにユーザリクエスト受付可否判定プログラム１１８にリソース情報を提供する。ユーザリクエスト受付可否判定プログラム１１８は前記リソース情報を元にユーザリクエストの受付可否を判定する。そして、ユーザリクエスト受付可否情報をＷｅｂサーバ１０１に送信し、Ｗｅｂサーバ１０１は前記情報を情報テーブル４００のユーザリクエストの受付可否状況の列４０７に書き込む。情報テーブル４００を用いたユーザリクエストの振り分け処理はこれまでと同様である。なお、ユーザリクエスト受付可否判定プログラム１１８での判定条件はこれまでＷｅｂサーバ１０１内の処理として記述してきたものと同様である。例えばＧＣが発生中であれば受付不可にするとか、例えばリソースの使用領域の割合が閾値以上になったときに受付不可にするとか、例えばリソースの使用領域の割合が閾値以上になった時はレスポンスタイムが長くなってもかまわないユーザリクエストのみを受付可にする、などである。
【００６２】
（実施例２）
実施例１の状況において、Ｗｅｂサーバ１０１が各ＡＰサーバ１１１，１１２および１１３にガベージコレクション処理の要求（以下、この要求をサーバリクエストと記載する）を指示することで、スループットやレスポンスタイムの低下を防ぐことができる。
【００６３】
ＧＣが発生するとＡＰサーバにおけるスループットやレスポンスタイムが低下することは前に説明した。これを防止するためにＧＣの発生が予想されるＡＰサーバにはユーザリクエストを振り分けない具体的な処理を説明した。
【００６４】
しかし、ＧＣの発生は必ずしも予測できるとは限らない。そこで、ＪａｖａＶＭ２０２がＧＣを発生するのを待つのではなく、ＧＣを発生するようにＪａｖａＶＭ２０２に積極的に働きかけることができる。具体的には以下の通りとすればよい。
【００６５】
Ｗｅｂサーバ１０１は次に挙げるタイミングのうち、一つ以上のタイミングにおいてガベージコレクション処理の要求（以下、この要求をサーバリクエストと記載する）のサーバリクエスト処理を行う。
（１）一定時間間隔（例えば「１分ごと」）。
（２）ＡＰサーバからの情報を受信し、情報テーブル４００を書き換えた時。
（３）ＡＰサーバからの情報を受信し、情報テーブル４００を一定回数書き換えた時。
（４）ユーザからのユーザリクエストを受信し、ユーザリクエストを振り分けるＡＰサーバを決定する前。
（５）ユーザからのユーザリクエストを受信し、ユーザリクエストを振り分けるＡＰサーバを決定し、ユーザリクエストをＡＰサーバに伝達する前。
（６）ユーザからのユーザリクエストを受信し、ユーザリクエストを振り分けるＡＰサーバを決定し、ユーザリクエストをＡＰサーバに伝達した後。
（７）ＡＰサーバからのユーザリクエストの返答を受信し、ユーザへ返信した後。
【００６６】
サーバリクエスト処理とこれに続くガベージコレクションは、例えば、図１０に示すフローのようにして実行される。Ｗｅｂサーバ１０１が情報テーブル４００を参照し、リソースの使用中領域（またはリソースの使用中領域の割合）が閾値以上のＡＰサーバをリストアップする（ステップ１００１）。リストアップされたＡＰサーバの台数が０台の時はそのまま処理を終了する。リストアップされたＡＰサーバの台数が１台のときはリストアップされたＡＰサーバをガベージコレクション対象ＡＰサーバ群とする（ステップ１００２）。そしてステップ１００４以下のステップへ進む。リストアップされたＡＰサーバの台数が２台以上の時はリストアップされたＡＰサーバ群から１台以上のＡＰサーバを選択し、ガベージコレクション対象ＡＰサーバ群とする（ステップ１００３）。選択の方法としては、リソースの使用中領域の割合が多い順に一定台数を選ぶ方法や、現在ユーザリクエスト処理を行っていないＡＰサーバを選択する方法などが挙げられる。そしてステップ１００４以下のステップへ進む。
【００６７】
ステップ１００２または１００３においてガベージコレクションを要求するＡＰサーバ郡が決定できた時は、ステップ１００４に進み、ガベージコレクションを要求するＡＰサーバ群の各ＡＰサーバに対して、ガベージコレクションの処理要求を示すサーバリクエストを送信する。このサーバリクエストの送信はＡＰサーバに対して以下の処理を行うことになるが、これらは各ＡＰサーバに対して逐次的に処理するものとしても良いし、並列に処理するものとしても良い。
（１）情報テーブル４００のユーザリクエスト受付可否状況の列４０７の前記ＡＰサーバの行を「受付不可」に書き換える（ステップ１００４）。
（２）前記ＡＰサーバで実行中のユーザリクエストの処理が終了するまで待つ（ステップ１００５）。
（３）前記ＡＰサーバにガベージコレクション要求のサーバリクエストを送信する（ステップ１００６）。
（４）ガベージコレクション要求を受信したＡＰサーバはＯＳまたはミドルウェアに対してガベージコレクションの処理要求を行う（ステップ１００７）。この時、ガベージコレクション処理を開始した旨をＷｅｂサーバに送信するものとしても良い。その場合、ガベージコレクション処理の開始した旨を受信したＷｅｂサーバは、情報管理テーブル４００を更新する。
（５）ガベージコレクションが完了したらＷｅｂサーバに対してガベージコレクション完了通知を送信する（ステップ１００８）。
（６）Ｗｅｂサーバは前記ＡＰサーバからのガベージコレクション完了通知を受信する（ステップ１００９）。
（７）情報テーブル４００のユーザリクエスト受付可否状況の列４０７の前記ＡＰサーバの行を「受付可」に書き換える（ステップ１０１０）。
【００６８】
なお、前記処理のうち、ステップ１００５は省略しても良い。この場合、常時省略するものとしても良いし、前記ＡＰサーバ以外のＡＰサーバの処理能力に余裕がないときのみ省略するものとしても良い。
【００６９】
また、前記方法ではステップ１００５においてユーザリクエスト処理終了を待つ間と、ステップ１０１０の後にＷｅｂサーバ１０１がＡＰサーバに十分な負荷を与えるようにユーザリクエストを振り分けるまでの間にＡＰサーバに負荷が少ない時間ができてしまい、システムの稼動効率が下がってしまう。
【００７０】
システムの稼動効率を上げるために次のような方法を取ることができる。すなわち、ステップ１００４において、単に「受付不可」とするのではなく、「ＧＣ予定中のためレスポンスタイムが長くなってもかまわないユーザリクエストのみ受付可（以下、ＧＣ予定中と記述する）」とする。この時、ステップ５０２のＡＰサーバの振り分け選択処理では、「ＧＣ予定中」のＡＰサーバに対してはバッチ処理のリクエストなどレスポンスタイムが多少長くなってもかまわない処理を振り分けするようにし、オンライン処理などレスポンスタイムが要求されるユーザリクエストは「ＧＣ予定中」のＡＰサーバには振り分けしないよう選択する。ステップ１００５では単に「ユーザリクエストが終了するまで待つ」のではなく、「レスポンスタイムが要求されるユーザリクエストが終了するまで待つ」という処理にする。つまり、バッチ処理によるユーザリクエストなどは処理中であってもステップ１００６に進む。この処理によりステップ１００５やステップ１０１０の後でのＡＰサーバの稼動効率を上げることが可能である。
【００７１】
上の例ではレスポンスタイムが多少長くなっても良い処理としてバッチ処理からのユーザリクエストを挙げたが、ユーザリクエストごとにレスポンスタイムの要求レベルを設定し、レスポンスタイムが多少長くなっても良い処理としてレスポンスタイムの要求レベルが一定以下のユーザリクエストのみを振り分けする形式としても良い。この処理ステップは具体的には、例えば、以下のように進められる。
【００７２】
Ｗｅｂサーバ１０１はＡＰサーバ１１２に対してＧＣを発生させるように要求し、情報テーブル４００を書き換える。ＡＰサーバ１１２は受信部２０７においてＧＣの要求を受信し、ガベージコレクション処理プログラム１１６がその要求を処理する。具体的な例としてはアプリケーションプログラム２０３にＧＣの発生を要求する命令であるｊａｖａ．ｌａｎｇ．Ｓｙｓｔｅｍ．ｇｃ（  ）を実行させる例を挙げることができる。これによりＪａｖａＶＭ２０２はＧＣを実行する。ＪａｖａＶＭ２０２のＧＣ発生開始はＪＶＭＴＩ２０４を介してリソース情報取得プログラム１１５が送信部２０６を用いてＷｅｂサーバ１０１へ送られる。ＪａｖａＶＭ２０２でのＧＣが終了すると、ＪＶＭＴＩ２０４を介してリソース情報取得プログラム１１５が送信部２０６を用いてＷｅｂサーバ１０１へＧＣ終了を送ることにより、ＡＰサーバ２０２が新たなユーザリクエストを受け付けることができる状態になったことをＷｅｂサーバ１０１は知ることができる。そこで、Ｗｅｂサーバ１０１は情報テーブル４００を更新し、次のユーザリクエストからはＡＰサーバ１１２にユーザリクエストを振り分けることを再開する。
【００７３】
ここまでの例ではガベージコレクション処理のきっかけをＡＰサーバの情報から得ていたが、それ以外の情報も用いることができる。例えば、商品の予約システムや購買システムなどのように受付開始時間が設定されているシステムがある。このようなシステムでは受付開始時間後にユーザリクエストが急増する。そのため、受付開始時間より少し前の時刻にガベージコレクション処理を指示することで、受付開始後の高負荷時においてガベージコレクション処理の発生による性能劣化を防ぐことができる。
【００７４】
なお、本発明において「Ｗｅｂサーバ」と「ユーザリクエストの振り分けを行うサーバ」と「ＡＰサーバのリソースを管理するサーバ」と「ガベージコレクションの指示を判断するサーバ」は連携さえできていれば同一サーバである必要は無く、別サーバであっても良い。
【産業上の利用可能性】
【００７５】
Ｗｅｂサーバと複数のアプリケーションサーバで構成されるＷｅｂシステムでの利用が効率よく行われる。
【図面の簡単な説明】
【００７６】
【図１】本発明を適用して効果のある３層システム構成のＷｅｂシステムの例を示す図である。
【図２】ＡＰサーバ１１１のソフトウェア構成の例を示す図である。
【図３】ＡＰサーバ１１１のハードウェア構成の例を示す図である。
【図４】ＡＰサーバの内部情報を示す情報テーブルの例の表である。
【図５】Ｗｅｂサーバ、ＡＰサーバおよびバックエンドサーバの機能およびユーザリクエストに関するそれぞれの間の連携の状況を示すフロー図である。
【図６】ＡＰサーバ１１１の情報をＷｅｂサーバ１０１が取得するフローチャートを説明するフローチャートである。
【図７】ＧＣ発生中のＡＰサーバを避けたユーザリクエスト振り分け先の判定処理の一例を説明するフローチャートである。
【図８】ＧＣ発生の可能性の高さに対応したユーザリクエスト振り分け先の判定処理の一例を説明するフローチャートである。
【図９】ユーザリクエストの送信先ＡＰサーバをヒープ領域の空き領域情報により決定する処理の一例を説明するフローチャートである。
【図１０】Ｗｅｂサーバがガベージコレクション処理をすべきＡＰサーバを選択する処理とこれに続くガベージコレクション処理のフローチャートの例を示す図である。
【符号の説明】
【００７７】
１０１…Ｗｅｂサーバ、１０２…振り分け制御、１１１，１１２，１１３…ＡＰサーバ、１１４，１１５，１１６…情報採取プログラム、１２１…ＤＢサーバ、１３１…ユーザ、２０１…ＯＳ、２０２…ＪａｖａＶＭ、２０３…アプリケーションプログラム、２０４…ＪＶＭＴＩ、２０５…送受信部、２０６…送信部、２０７…受信部、３０１…揮発性記憶装置、３０２…不揮発性記憶装置、３０３…中央演算処理装置、３０４…ネットワーク制御装置、３０５…入出力装置、３０６…バス、４００…情報管理テーブル、４０１…ＧＣの発生状況およびヒープメモリ使用率の列、４０２…ロードされているクラスの列、４０３…コンパイルされているインスタンスの列、４０４…０．１秒後のＣＰＵ利用率の予測値の列、４０５…０．２秒後のＣＰＵ利用率の予測値の列、４０６…０．３秒後のＣＰＵ利用率の予測値の列、４０７…ユーザリクエスト受付状況の列。
【図１】
2007328413.tif 000003
【図２】
2007328413.tif 000004
【図３】
2007328413.tif 000005
【図４】
2007328413.tif 000006
【図５】
2007328413.tif 000007
【図６】
2007328413.tif 000008
【図７】
2007328413.tif 000009
【図８】
2007328413.tif 000010
【図９】
2007328413.tif 000011
【図１０】
2007328413.tif 000012