リクエスト情報処理方法および計算機システム
【課題】
アプリケーションサーバではリクエスト処理のタイムアウトまでの時間は動的に変化させることができないため、一時的なサーバの負荷などによって不当にタイムアウトとなってしまうが、アプリケーションサーバ上ではリクエスト処理が続くため、リクエストの処理が完了してもレスポンスを返す事ができず、無駄な処理になってしまう。
【解決手段】
クライアント装置４０から受信したリクエストの処理結果をアプリケーションサーバ処理プログラム２１０が統計情報として、タイムアウト管理サーバ処理プログラム４１０に通知しリクエスト情報テーブル４２０に格納することで、Ｗｅｂサーバ処理プログラム６１０が統計情報を基にタイムアウト値を変更するかどうかの判定を行い、動的にタイムアウト値を延長することで、上記課題を解決することが可能となる。
アプリケーションサーバではリクエスト処理のタイムアウトまでの時間は動的に変化させることができないため、一時的なサーバの負荷などによって不当にタイムアウトとなってしまうが、アプリケーションサーバ上ではリクエスト処理が続くため、リクエストの処理が完了してもレスポンスを返す事ができず、無駄な処理になってしまう。
【解決手段】
クライアント装置４０から受信したリクエストの処理結果をアプリケーションサーバ処理プログラム２１０が統計情報として、タイムアウト管理サーバ処理プログラム４１０に通知しリクエスト情報テーブル４２０に格納することで、Ｗｅｂサーバ処理プログラム６１０が統計情報を基にタイムアウト値を変更するかどうかの判定を行い、動的にタイムアウト値を延長することで、上記課題を解決することが可能となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受け付けたリクエストを処理する計算機の機能を制御する技術に関するものである。
【背景技術】
【０００２】
従来、クライアント装置からネットワークを介して接続されたシステムにおいて、サーバ装置上のWebサーバ処理プログラムがアプリケーションサーバ処理プログラムにリクエストを転送した後、所定の時間内に処理が完了しなかった際にタイムアウトとしてエラーをクライアント装置に返却する技術がある。
また、画像読み取りシステム、画像読み取り方法およびドキュメント管理サーバなどにおける格納処理においては、サーバ毎にタイムアウト値を設定することができ、負荷が高いときなど、格納処理に時間がかかっている場合は、正常に格納処理が実施されているかどうかを判断し、正常に動作しているのであれば、処理時間を延長する技術がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１６６１００
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら従来技術では、タイムアウトの時間は一度設定すると動的に変化させることができないため、高負荷時など、あと少しで処理が終了するはずだったリクエストもエラーとなってしまい、エラーとなったリクエストについても、サーバ装置のアプリケーションサーバ処理プログラムの中では処理が続くため、無駄な処理となってしまっている。
【０００５】
また、このようにタイムアウトになってしまったクライアント装置からは再度同じリクエストを送信することが多く、それらのリクエストもタイムアウトしてしまう。この動作を繰り返してしまうことで、サーバ装置側の負荷がさらに高くなってしまい、当該リクエストがよりタイムアウトが発生しやすくなってしまうだけでなく、サーバ装置の負荷が高くなってしまうことで、今までタイムアウトしなかったリクエストについてもタイムアウトしてしまう可能性が高まり、さらにサーバ装置の負荷を高騰させる因子となってしまう可能性があり、一方で、リクエスト情報処理システムではドキュメント管理サーバにおける格納処理とは異なり、正常に動作しているかを判断することが困難であるため、リクエストの処理が正常に動作しているかを判断して処理時間を延長することはできない。そこで、本発明はタイムアウト技術におけるのこれらの危険性を、タイムアウトとなるまでの時間を動的に変更する事で排除することを目的とする。
【０００６】
また、タイムアウトとなるまでの時間を適切に延長することによって、クライアント装置からの無駄なリトライが少なくなることによって、サーバ装置の負荷が意味もなく高騰してしまうことを防ぐこと目的とする。
【課題を解決するための手段】
【０００７】
前記目的を達成するために、本発明では、クライアント装置から受け付けたリクエストをサーバ装置で処理した際に、タイムアウトが発生した場合は、タイムアウトが最終的にリクエストの処理に要した時間とクライアント装置からのリクエストＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｅｒ)を、タイムアウトが発生しなかった際は、クライアント装置からのリクエストＵＲＩをサーバ装置と相互に通信が可能な他のサーバ装置のメモリ上に情報として保持させ、クライアント装置からのリクエストをサーバ装置上のＷｅｂサーバ処理プログラムがアプリケーションサーバ処理プログラムに転送する前に、保持させた情報を基にタイムアウトとするまでの時間を変更する。
【発明の効果】
【０００８】
タイムアウトを動的に変更する事によって、あと少しで処理が終了したというリクエストを救う事が可能である。
【図面の簡単な説明】
【０００９】
【図１】本実施形態におけるサーバ装置が接続されたリクエスト処理システムの構成を示す図である。
【図２】本実施形態におけるリクエスト処理システムの処理の流れで、タイムアウトが発生しなかった時の処理の流れを示す図である。
【図３】本実施形態におけるリクエスト処理システムの処理の流れで、タイムアウトが発生した時の処理の流れを示す図である。
【図４】本実施形態におけるタイムアウト管理サーバ処理部でのアプリケーションサーバ処理部が処理したリクエストの統計情報の構成を示す図である。
【図５】本実施形態におけるＷｅｂサーバ処理部での動作を定義するファイルの構成を示す図である。
【図６】本実施形態におけるサーバ装置において、Ｗｅｂサーバ処理プログラムの処理の流れを示すフローチャート図である。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための形態（以下「実施形態」という)について、図面を参照して説明する。
【００１１】
図1は、本実施形態におけるサーバ装置が接続されたリクエスト処理システムを示す図である。図１に示すように、本実施形態におけるリクエスト処理システム１は、複数のサーバ装置１０、サーバ装置２０、サーバ装置３０を含んで構成される。クライアント装置４０とサーバ装置３０はネットワーク５０を介して相互に通信可能に構成されている。ここではサーバ装置１０とサーバ装置３０は１台ずつ示されているが、それぞれ複数であってもその数が限定されるものではなく、サーバ装置１０とサーバ装置３０は１つのサーバ装置に纏めることも可能である。また、クライアント装置４０は２台示されているが、複数であれば特にその数が限定されるものではない。
【００１２】
クライアント装置４０は、ネットワーク５０を介してサーバ装置３０にリクエストを送信する機能を有するとともに、サーバ装置３０からそのリクエストに対するレスポンスを受け取る機能を有する。
【００１３】
サーバ装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１００と、メモリ２００とを含んで構成される。記憶部としてのメモリ２００は、アプリケーションサーバ処理部２１０を含んで記憶する機能を有する。処理部としてのＣＰＵ１００は、メモリ２００に記憶されている処理部を構成するプログラムを実行する機能を有する。
【００１４】
サーバ装置２０は、ＣＰＵ３００と、メモリ４００とを含んで構成される。記憶部としてのメモリ４００は、タイムアウト管理サーバ処理部４１０と、リクエスト情報テーブル４２０を含んで記憶する機能を有する。処理部としてのＣＰＵ３００は、メモリ４００に記憶されている処理部を構成するプログラムを実行する機能を有する。
【００１５】
サーバ装置３０は、ＣＰＵ５００と、メモリ６００とを含んで構成される。記憶部としてのメモリ６００は、Ｗｅｂサーバ処理部６１０と、サーバ動作定義ファイル６２０を含んで記憶する機能を有する。処理部としてのＣＰＵ５００は、メモリ６００に記憶されている処理部を構成するプログラムを実行する機能を有する。
【００１６】
アプリケーションサーバ処理部２１０は、Ｗｅｂサーバ処理部６１０からリクエストが送信されると、そのリクエストの処理を実行し、Ｗｅｂサーバ処理部６１０にその実行結果としてレスポンスを返信し、Ｗｅｂサーバ処理部６１０でタイムアウトが発生していなければタイムアウト管理サーバ処理処理部４１０にＵＲＩを通知し、Ｗｅｂサーバ処理プログラム６１０でタイムアウトが発生して、接続が切断されていたためにＷｅｂサーバ処理部６１０へレスポンスの返信ができなかった場合は、タイムアウト管理サーバ処理部４１０にＵＲＩとリクエストの処理に要した処理時間を通知するコードが記述されたプログラムである。
【００１７】
タイムアウト管理サーバ処理部４１０は、起動時にＷｅｂサーバ処理処理部６１０から、サーバ動作定義ファイル６２０に設定されているタイムアウト値を取得し、Ｗｅｂサーバ処理部６１０がクライアント装置４０からのリクエストを受信した際に、リクエスト情報テーブル４２０からリクエストに関する情報を取得しＷｅｂサーバ処理部６１０に通知するコードと、アプリケーションサーバ処理部２１０からリクエストに関する情報が通知された際にリクエスト情報テーブル４２０に格納するコードが記載されたプログラムである。
【００１８】
リクエスト情報テーブル４２０は統計情報としてＵＲＩと総リクエスト数とタイムアウト設定時間超過回数とタイムアウト設定時間平均超過時間を保持する。
【００１９】
Ｗｅｂサーバ処理部部６１０は、クライアント装置４０からリクエストが送信された際に、当該リクエストのＵＲＩに関する情報をタイムアウト管理サーバ４１０へ送信し、タイムアウト管理サーバ４１０から通知された情報を基に当該リクエストにおけるタイムアウトまでの時間を計算し、アプリケーションサーバ処理部２１０にリクエストを転送した後、計算したタイムアウトまでの時間でアプリケーションサーバ処理部２１０からの返信を得るまでのタイマ監視処理を実行し、アプリケーションサーバ処理部２１０からレスポンスが返信された際は、そのレスポンスをクライアント装置４０に返信し、アプリケーションサーバ処理部２１０からレスポンスが返信される前にサーバ動作定義ファイル６２０に定義されたタイムアウトまでの時間が経過した際は、タイムアウト処理としてアプリケーションサーバ処理部２１０との接続を切断し、クライアント装置４０にはエラーを返信するコードが記載されたプログラムである。
【００２０】
サーバ動作定義ファイル６２０はＷｅｂサーバ６１０の動作を制御するための情報を含み、クライアント装置４０から送信されたリクエストをアプリケーションサーバ処理部２１０に転送し、アプリケーションサーバ処理プログラム２１０からレスポンスが返ってくるまでの待ち時間（タイムアウトまでの時間)と、総リクエスト数に対してどの程度の超過回数まで許容するかの閾値と、タイムアウトまでの時間を最大でどのくらい延長するかの上限値を定義し、閾値は割合で、延長時間の上限値は秒数で定義する。閾値と延長時間の上限については、全てのリクエストに共通した値となるが、ＵＲＩ毎に値を変えて定義することも可能である。
【００２１】
図２は、本実施形態における通常時におけるリクエスト処理システムの処理の流れで、タイムアウトまでの時間を延長し、その後タイムアウトが発生することなくリクエストの処理が完了した際の処理を示す図である。図２に示すように、ここでは、リクエスト処理システム１が、クライアント４０からリクエストを受けた場合を例に挙げて、タイムアウトまでの時間の変更とリクエスト処理について説明する。また、Ｗｅｂサーバ処理部６１０、タイムアウト管理サーバ処理部４１０、およびアプリケーションサーバ処理部２１０はそれぞれ、図１におけるアプリケーションサーバ処理部２１０、タイムアウト管理サーバ処理部４１０、およびＷｅｂサーバ処理部６１０がそれぞれＣＰＵ１００、ＣＰＵ３００およびＣＰＵ５００より、それぞれ実行されることによって実現されるものである。
【００２２】
クライアント４０からリクエスト（ｈｔｔｐ：／／・・・／ｉｎｄｅｘ．ｊｓｐ)が送信された場合（ステップＳ１００１)、Ｗｅｂサーバ処理部６１０はタイムアウト管理サーバ処理部４１０へリクエストのＵＲＩに関する統計情報を要求（ステップＳ１００２)し、タイムアウト管理サーバ処理部４１０は統計情報を取得して（ステップＳ１００３)Ｗｅｂサーバに通知する（ステップＳ１００４)。その後、Ｗｅｂサーバ処理部６１０は、当該リクエストにおいてタイムアウトまでの時間を変更するかどうかのタイムアウト延長判定処理を実施（ステップＳ１００５)し、タイムアウトまでの時間を決定してからアプリケーションサーバ処理部２１０にリクエストを転送（ステップＳ１００６)し、決定したタイムアウトまでの時間でタイマ監視をおこなう。アプリケーションサーバ２１０はＷｅｂサーバ処理部６１０から転送されたリクエストを処理（ステップＳ１００７)し、処理結果をレスポンスとしてＷｅｂサーバ６１０に返信（ステップＳ１００８)した後、タイムアウト管理サーバ４１０処理部に対し、当該リクエストのＵＲＩを通知し（ステップＳ１００９)、タイムアウト管理サーバ処理部４１０は、通知された情報を統計情報として格納する（ステップＳ１０１０)。Ｗｅｂサーバ７３０はアプリケーションサーバ７１０からレスポンスを受信したら（ステップＳ１００８)クライアント４０にレスポンスを返し（ステップＳ１０１１)、クライアント４０はそれを受信する（ステップＳ１０１２)。
【００２３】
図３は、本実施形態におけるリクエスト処理システム１の処理の流れで、タイムアウトまでの時間を延長したが、その後タイムアウトが発生した際の処理を示す図である。図３に示すように、ここでは、リクエスト処理システム１がクライアント装置４０からリクエストを受け、処理を実施したが処理に時間を要しタイムアウトが発生してしまった場合を例に挙げて、タイムアウトが発生した際の処理について説明する。また、Ｗｅｂサーバ６１０、タイムアウト管理サーバ４１０、およびアプリケーションサーバ処理部２１０はそれぞれ、図１におけるアプリケーションサーバ処理処理部２１０、タイムアウト管理サーバ処理部４１０、およびＷｅｂサーバ処理プログラム６１０がそれぞれＣＰＵ１００、ＣＰＵ３００およびＣＰＵ５００によって実行されることによって実現されるものである。
【００２４】
クライアント４０からリクエスト（ｈｔｔｐ：／／・・・／ｉｎｄｅｘ．ｊｓｐ)が送信された場合（ステップＳ２００１)、Ｗｅｂサーバ処理部６１０はタイムアウト管理サーバ処理部４１０へリクエストのＵＲＩに関する統計情報を要求し（ステップＳ２００２)、タイムアウト管理サーバ処理部４１０は、統計情報を取得して（ステップＳ２００３)、Ｗｅｂサーバに通知する（ステップＳ２００４）。その後、Ｗｅｂサーバ処理部６１０は、当該リクエストにおいてタイムアウトまでの時間を変更するかどうかの処理を実施し（ステップＳ２００５)、タイムアウトまでの時間を決定してからアプリケーションサーバ処理部２１０にリクエストを転送し（ステップＳ２００６)、決定したタイムアウトまでの時間でタイマ監視をおこなうが、アプリケーションサーバ処理部２１０がリクエスト処理を開始（ステップＳ２００７)してからレスポンスが返ってくるまでに決定したタイムアウトまでの時間が経過した場合、Ｗｅｂサーバ処理部６１０はタイムアウト処理としてアプリケーションサーバ処理部２１０との接続を切断し（ステップＳ２００８)、クライアント４０に対してはエラーを返却（ステップＳ２００９)し、クライアント４０はそれを受信する（ステップ２０１０)。
その後、アプリケーションサーバ処理部２１０でのリクエスト処理（ステップＳ２００７)が完了した際に、タイムアウト管理サーバ処理部４１０に対し、当該リクエストに要した処理時間をＵＲＩとともに通知し（ステップＳ２０１１)、タイムアウト管理サーバ処理部４１０はアプリケーションサーバ処理部２１０から受け取った当該リクエストの処理時間とＵＲＩをリクエスト情報テーブルに格納する（ステップＳ２０１２)。
【００２５】
図４は、本実施形態におけるリクエスト情報テーブル４２０のデータ構造の例である。図４に示すように、リクエスト情報テーブル４２０は、ＵＲＩ８０１と、タイムアウトが発生した回数である超過回数８０２と、総リクエスト回数８０３と、平均超過時間８０４を含んで構成される。リクエスト情報テーブル４２０では、アプリケーションサーバ処理部２１０（図２参照)でのリクエスト処理が完了した後に、処理したリクエストに関する情報を整理して、管理し、ステップ１００９によって、登録および情報の更新が行われる。
【００２６】
ＵＲＩ８０１は、クライアント装置４０（図２参照)から送信されたリクエストの識別子を示しており、リクエストの処理が完了した際に、アプリケーションサーバ処理部２１０（図２参照)から通知され、既にリクエスト情報テーブル４２０に登録されている場合は当該ＵＲＩに対応する総リクエスト回数８０３に１を加算し、リクエスト情報テーブル４２０に登録されていなければ、総リクエスト数８０１を１としてリクエスト情報テーブル４２０に登録する。
【００２７】
超過回数８０２は、通知されたＵＲＩにおいて設定されたタイムアウト値を超過してタイムアウトとなった回数を示す。
総リクエスト回数８０３は、通知されたＵＲＩに対するリクエストの総回数を示す。
【００２８】
平均超過時間８０４は、｛（計算時点でリクエスト情報テーブルに登録されている平均超過時間８０４×計算時点でリクエスト情報テーブルに登録されている総リクエスト回数８０２＋アプリケーションサーバ処理部２１０から通知されるリクエスト処理時間）÷ 当該リクエストを含めた総リクエスト回数｝−｛Ｗｅｂサーバ動作定義ファイル６２０（図１参照)に定義されているタイムアウト設定値｝の式で計算され、タイムアウトが発生するごとに上書きされる。
【００２９】
図５は、本実施形態におけるＷｅｂサーバ動作定義ファイル６２０のデータ構造の例である。図５に示すようにＷｅｂサーバ動作定義ファイル６２０はクライアントから受信したリクエストをアプリケーションサーバ処理部２１０（図２参照)に転送してからアプリケーションサーバ処理部２１０（図２参照)からレスポンスを受信するまでのタイムアウト値を定義するタイムアウト値９０１と、総リクエスト数に対してどの程度の超過回数まで許容するかを設定する閾値９０２と、タイムアウトまでの時間を変更するときに最大でどのくらい延長するかの上限値を設定するタイムアウト延長上限値９０３を含んで構成される。Ｗｅｂサーバ動作定義ファイル６２０のデータは、リクエスト処理システム１の管理者などにより設定される。
【００３０】
図６は、本実施形態におけるサーバ装置において、ＷｅｂサーバにおけるＷｅｂサーバ処理処理部６１０のタイムアウト値延長判定処理（図２のステップ１００４)の詳細動作を示すフロー図である。
【００３１】
Ｗｅｂサーバ処理部７３０（図２参照)がリクエストを受信した際、リクエストのＵＲＩに対応する統計情報をタイムアウト管理サーバ処理部４１０（図２参照)がリクエスト情報テーブル４２０から取得し（ステップＳ１０１)、超過回数８０２（図４参照)と総リクエスト回数８０３（図４参照)を基に、当該ＵＲＩにおいてどのくらいの割合でタイムアウト設定値を超過しているかを算出し、算出した結果をＷｅｂサーバ動作定義ファイル６２０（図５参照)に設定されている閾値９０２（図５参照)と比較する（ステップＳ１０２）。閾値９０２を超えていなければ（ステップＳ１０２でｎ％未満)タイムアウト値の変更はしないで、タイムアウト値として、サーバ動作定義ファイル６２０のタイムアウト値９０１の設定値を使用し（ステップＳ１０６)処理を終了する。一方、算出した結果が閾値９０２（図５参照)以上であれば（ステップＳ１０２でｎ％以上)、タイムアウト管理サーバ処理部４１０（図２参照)から取得した平均超過時間８０４（図４参照)とＷｅｂサーバ動作定義ファイル６２０（図５参照)に設定されている、タイムアウト延長上限値９０３（図５参照)との比較を実施する（ステップＳ１０３）。平均超過時間８０４（図４参照)がＷｅｂサーバ動作定義ファイル６２０（図５参照)に設定されている、タイムアウト延長上限値９０３（図５参照)よりも長ければ（ステップＳ１０３で上限値より長い)タイムアウト値をタイムアウト延長上限値９０３（図５参照)分タイムアウト値９０１（図５参照)を延長し（ステップＳ１０４)、タイムアウト延長上限値９０３（図５参照)よりも短ければ（ステップＳ１０３で上限値以下)タイムアウト値を平均超過時間８０４（図４参照)分タイムアウト値９０１（図５参照)を延長し（ステップＳ１０５)、処理を終了する。
【００３２】
本実施形態に付随される効果として、タイムアウトになった際は、アプリケーションサーバで引き続き処理されているリクエストに要した時間を統計情報としてリクエストテーブル４２０に蓄積することで、延長すべき時間の精度を上げていくことが可能である。
【００３３】
また、適切なタイマ監視が可能になることで、無駄なリトライが無くなり、クライアント側だけでなくサーバ側の負担も低減することが可能である。
【００３４】
以上、本発明の実施形態を説明したが、この実施形態は本発明の説明のための例示にすぎず、本発明の範囲をその実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。
【符号の説明】
【００３５】
１ リクエスト処理システム
１０ サーバ装置
２０ サーバ装置
３０ サーバ装置
４０ クライアント装置
５０ ネットワーク
１００ ＣＰＵ
２００ メモリ
２１０ アプリケーションサーバ処理部
３００ ＣＰＵ
４００ メモリ
４１０ タイムアウト管理サーバ処理部
４２０ リクエスト情報テーブル
５００ ＣＰＵ
６００ メモリ
６１０ Ｗｅｂサーバ処理処理部
６２０ サーバ動作定義ファイル
【技術分野】
【０００１】
本発明は、受け付けたリクエストを処理する計算機の機能を制御する技術に関するものである。
【背景技術】
【０００２】
従来、クライアント装置からネットワークを介して接続されたシステムにおいて、サーバ装置上のWebサーバ処理プログラムがアプリケーションサーバ処理プログラムにリクエストを転送した後、所定の時間内に処理が完了しなかった際にタイムアウトとしてエラーをクライアント装置に返却する技術がある。
また、画像読み取りシステム、画像読み取り方法およびドキュメント管理サーバなどにおける格納処理においては、サーバ毎にタイムアウト値を設定することができ、負荷が高いときなど、格納処理に時間がかかっている場合は、正常に格納処理が実施されているかどうかを判断し、正常に動作しているのであれば、処理時間を延長する技術がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１６６１００
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら従来技術では、タイムアウトの時間は一度設定すると動的に変化させることができないため、高負荷時など、あと少しで処理が終了するはずだったリクエストもエラーとなってしまい、エラーとなったリクエストについても、サーバ装置のアプリケーションサーバ処理プログラムの中では処理が続くため、無駄な処理となってしまっている。
【０００５】
また、このようにタイムアウトになってしまったクライアント装置からは再度同じリクエストを送信することが多く、それらのリクエストもタイムアウトしてしまう。この動作を繰り返してしまうことで、サーバ装置側の負荷がさらに高くなってしまい、当該リクエストがよりタイムアウトが発生しやすくなってしまうだけでなく、サーバ装置の負荷が高くなってしまうことで、今までタイムアウトしなかったリクエストについてもタイムアウトしてしまう可能性が高まり、さらにサーバ装置の負荷を高騰させる因子となってしまう可能性があり、一方で、リクエスト情報処理システムではドキュメント管理サーバにおける格納処理とは異なり、正常に動作しているかを判断することが困難であるため、リクエストの処理が正常に動作しているかを判断して処理時間を延長することはできない。そこで、本発明はタイムアウト技術におけるのこれらの危険性を、タイムアウトとなるまでの時間を動的に変更する事で排除することを目的とする。
【０００６】
また、タイムアウトとなるまでの時間を適切に延長することによって、クライアント装置からの無駄なリトライが少なくなることによって、サーバ装置の負荷が意味もなく高騰してしまうことを防ぐこと目的とする。
【課題を解決するための手段】
【０００７】
前記目的を達成するために、本発明では、クライアント装置から受け付けたリクエストをサーバ装置で処理した際に、タイムアウトが発生した場合は、タイムアウトが最終的にリクエストの処理に要した時間とクライアント装置からのリクエストＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｅｒ)を、タイムアウトが発生しなかった際は、クライアント装置からのリクエストＵＲＩをサーバ装置と相互に通信が可能な他のサーバ装置のメモリ上に情報として保持させ、クライアント装置からのリクエストをサーバ装置上のＷｅｂサーバ処理プログラムがアプリケーションサーバ処理プログラムに転送する前に、保持させた情報を基にタイムアウトとするまでの時間を変更する。
【発明の効果】
【０００８】
タイムアウトを動的に変更する事によって、あと少しで処理が終了したというリクエストを救う事が可能である。
【図面の簡単な説明】
【０００９】
【図１】本実施形態におけるサーバ装置が接続されたリクエスト処理システムの構成を示す図である。
【図２】本実施形態におけるリクエスト処理システムの処理の流れで、タイムアウトが発生しなかった時の処理の流れを示す図である。
【図３】本実施形態におけるリクエスト処理システムの処理の流れで、タイムアウトが発生した時の処理の流れを示す図である。
【図４】本実施形態におけるタイムアウト管理サーバ処理部でのアプリケーションサーバ処理部が処理したリクエストの統計情報の構成を示す図である。
【図５】本実施形態におけるＷｅｂサーバ処理部での動作を定義するファイルの構成を示す図である。
【図６】本実施形態におけるサーバ装置において、Ｗｅｂサーバ処理プログラムの処理の流れを示すフローチャート図である。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための形態（以下「実施形態」という)について、図面を参照して説明する。
【００１１】
図1は、本実施形態におけるサーバ装置が接続されたリクエスト処理システムを示す図である。図１に示すように、本実施形態におけるリクエスト処理システム１は、複数のサーバ装置１０、サーバ装置２０、サーバ装置３０を含んで構成される。クライアント装置４０とサーバ装置３０はネットワーク５０を介して相互に通信可能に構成されている。ここではサーバ装置１０とサーバ装置３０は１台ずつ示されているが、それぞれ複数であってもその数が限定されるものではなく、サーバ装置１０とサーバ装置３０は１つのサーバ装置に纏めることも可能である。また、クライアント装置４０は２台示されているが、複数であれば特にその数が限定されるものではない。
【００１２】
クライアント装置４０は、ネットワーク５０を介してサーバ装置３０にリクエストを送信する機能を有するとともに、サーバ装置３０からそのリクエストに対するレスポンスを受け取る機能を有する。
【００１３】
サーバ装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１００と、メモリ２００とを含んで構成される。記憶部としてのメモリ２００は、アプリケーションサーバ処理部２１０を含んで記憶する機能を有する。処理部としてのＣＰＵ１００は、メモリ２００に記憶されている処理部を構成するプログラムを実行する機能を有する。
【００１４】
サーバ装置２０は、ＣＰＵ３００と、メモリ４００とを含んで構成される。記憶部としてのメモリ４００は、タイムアウト管理サーバ処理部４１０と、リクエスト情報テーブル４２０を含んで記憶する機能を有する。処理部としてのＣＰＵ３００は、メモリ４００に記憶されている処理部を構成するプログラムを実行する機能を有する。
【００１５】
サーバ装置３０は、ＣＰＵ５００と、メモリ６００とを含んで構成される。記憶部としてのメモリ６００は、Ｗｅｂサーバ処理部６１０と、サーバ動作定義ファイル６２０を含んで記憶する機能を有する。処理部としてのＣＰＵ５００は、メモリ６００に記憶されている処理部を構成するプログラムを実行する機能を有する。
【００１６】
アプリケーションサーバ処理部２１０は、Ｗｅｂサーバ処理部６１０からリクエストが送信されると、そのリクエストの処理を実行し、Ｗｅｂサーバ処理部６１０にその実行結果としてレスポンスを返信し、Ｗｅｂサーバ処理部６１０でタイムアウトが発生していなければタイムアウト管理サーバ処理処理部４１０にＵＲＩを通知し、Ｗｅｂサーバ処理プログラム６１０でタイムアウトが発生して、接続が切断されていたためにＷｅｂサーバ処理部６１０へレスポンスの返信ができなかった場合は、タイムアウト管理サーバ処理部４１０にＵＲＩとリクエストの処理に要した処理時間を通知するコードが記述されたプログラムである。
【００１７】
タイムアウト管理サーバ処理部４１０は、起動時にＷｅｂサーバ処理処理部６１０から、サーバ動作定義ファイル６２０に設定されているタイムアウト値を取得し、Ｗｅｂサーバ処理部６１０がクライアント装置４０からのリクエストを受信した際に、リクエスト情報テーブル４２０からリクエストに関する情報を取得しＷｅｂサーバ処理部６１０に通知するコードと、アプリケーションサーバ処理部２１０からリクエストに関する情報が通知された際にリクエスト情報テーブル４２０に格納するコードが記載されたプログラムである。
【００１８】
リクエスト情報テーブル４２０は統計情報としてＵＲＩと総リクエスト数とタイムアウト設定時間超過回数とタイムアウト設定時間平均超過時間を保持する。
【００１９】
Ｗｅｂサーバ処理部部６１０は、クライアント装置４０からリクエストが送信された際に、当該リクエストのＵＲＩに関する情報をタイムアウト管理サーバ４１０へ送信し、タイムアウト管理サーバ４１０から通知された情報を基に当該リクエストにおけるタイムアウトまでの時間を計算し、アプリケーションサーバ処理部２１０にリクエストを転送した後、計算したタイムアウトまでの時間でアプリケーションサーバ処理部２１０からの返信を得るまでのタイマ監視処理を実行し、アプリケーションサーバ処理部２１０からレスポンスが返信された際は、そのレスポンスをクライアント装置４０に返信し、アプリケーションサーバ処理部２１０からレスポンスが返信される前にサーバ動作定義ファイル６２０に定義されたタイムアウトまでの時間が経過した際は、タイムアウト処理としてアプリケーションサーバ処理部２１０との接続を切断し、クライアント装置４０にはエラーを返信するコードが記載されたプログラムである。
【００２０】
サーバ動作定義ファイル６２０はＷｅｂサーバ６１０の動作を制御するための情報を含み、クライアント装置４０から送信されたリクエストをアプリケーションサーバ処理部２１０に転送し、アプリケーションサーバ処理プログラム２１０からレスポンスが返ってくるまでの待ち時間（タイムアウトまでの時間)と、総リクエスト数に対してどの程度の超過回数まで許容するかの閾値と、タイムアウトまでの時間を最大でどのくらい延長するかの上限値を定義し、閾値は割合で、延長時間の上限値は秒数で定義する。閾値と延長時間の上限については、全てのリクエストに共通した値となるが、ＵＲＩ毎に値を変えて定義することも可能である。
【００２１】
図２は、本実施形態における通常時におけるリクエスト処理システムの処理の流れで、タイムアウトまでの時間を延長し、その後タイムアウトが発生することなくリクエストの処理が完了した際の処理を示す図である。図２に示すように、ここでは、リクエスト処理システム１が、クライアント４０からリクエストを受けた場合を例に挙げて、タイムアウトまでの時間の変更とリクエスト処理について説明する。また、Ｗｅｂサーバ処理部６１０、タイムアウト管理サーバ処理部４１０、およびアプリケーションサーバ処理部２１０はそれぞれ、図１におけるアプリケーションサーバ処理部２１０、タイムアウト管理サーバ処理部４１０、およびＷｅｂサーバ処理部６１０がそれぞれＣＰＵ１００、ＣＰＵ３００およびＣＰＵ５００より、それぞれ実行されることによって実現されるものである。
【００２２】
クライアント４０からリクエスト（ｈｔｔｐ：／／・・・／ｉｎｄｅｘ．ｊｓｐ)が送信された場合（ステップＳ１００１)、Ｗｅｂサーバ処理部６１０はタイムアウト管理サーバ処理部４１０へリクエストのＵＲＩに関する統計情報を要求（ステップＳ１００２)し、タイムアウト管理サーバ処理部４１０は統計情報を取得して（ステップＳ１００３)Ｗｅｂサーバに通知する（ステップＳ１００４)。その後、Ｗｅｂサーバ処理部６１０は、当該リクエストにおいてタイムアウトまでの時間を変更するかどうかのタイムアウト延長判定処理を実施（ステップＳ１００５)し、タイムアウトまでの時間を決定してからアプリケーションサーバ処理部２１０にリクエストを転送（ステップＳ１００６)し、決定したタイムアウトまでの時間でタイマ監視をおこなう。アプリケーションサーバ２１０はＷｅｂサーバ処理部６１０から転送されたリクエストを処理（ステップＳ１００７)し、処理結果をレスポンスとしてＷｅｂサーバ６１０に返信（ステップＳ１００８)した後、タイムアウト管理サーバ４１０処理部に対し、当該リクエストのＵＲＩを通知し（ステップＳ１００９)、タイムアウト管理サーバ処理部４１０は、通知された情報を統計情報として格納する（ステップＳ１０１０)。Ｗｅｂサーバ７３０はアプリケーションサーバ７１０からレスポンスを受信したら（ステップＳ１００８)クライアント４０にレスポンスを返し（ステップＳ１０１１)、クライアント４０はそれを受信する（ステップＳ１０１２)。
【００２３】
図３は、本実施形態におけるリクエスト処理システム１の処理の流れで、タイムアウトまでの時間を延長したが、その後タイムアウトが発生した際の処理を示す図である。図３に示すように、ここでは、リクエスト処理システム１がクライアント装置４０からリクエストを受け、処理を実施したが処理に時間を要しタイムアウトが発生してしまった場合を例に挙げて、タイムアウトが発生した際の処理について説明する。また、Ｗｅｂサーバ６１０、タイムアウト管理サーバ４１０、およびアプリケーションサーバ処理部２１０はそれぞれ、図１におけるアプリケーションサーバ処理処理部２１０、タイムアウト管理サーバ処理部４１０、およびＷｅｂサーバ処理プログラム６１０がそれぞれＣＰＵ１００、ＣＰＵ３００およびＣＰＵ５００によって実行されることによって実現されるものである。
【００２４】
クライアント４０からリクエスト（ｈｔｔｐ：／／・・・／ｉｎｄｅｘ．ｊｓｐ)が送信された場合（ステップＳ２００１)、Ｗｅｂサーバ処理部６１０はタイムアウト管理サーバ処理部４１０へリクエストのＵＲＩに関する統計情報を要求し（ステップＳ２００２)、タイムアウト管理サーバ処理部４１０は、統計情報を取得して（ステップＳ２００３)、Ｗｅｂサーバに通知する（ステップＳ２００４）。その後、Ｗｅｂサーバ処理部６１０は、当該リクエストにおいてタイムアウトまでの時間を変更するかどうかの処理を実施し（ステップＳ２００５)、タイムアウトまでの時間を決定してからアプリケーションサーバ処理部２１０にリクエストを転送し（ステップＳ２００６)、決定したタイムアウトまでの時間でタイマ監視をおこなうが、アプリケーションサーバ処理部２１０がリクエスト処理を開始（ステップＳ２００７)してからレスポンスが返ってくるまでに決定したタイムアウトまでの時間が経過した場合、Ｗｅｂサーバ処理部６１０はタイムアウト処理としてアプリケーションサーバ処理部２１０との接続を切断し（ステップＳ２００８)、クライアント４０に対してはエラーを返却（ステップＳ２００９)し、クライアント４０はそれを受信する（ステップ２０１０)。
その後、アプリケーションサーバ処理部２１０でのリクエスト処理（ステップＳ２００７)が完了した際に、タイムアウト管理サーバ処理部４１０に対し、当該リクエストに要した処理時間をＵＲＩとともに通知し（ステップＳ２０１１)、タイムアウト管理サーバ処理部４１０はアプリケーションサーバ処理部２１０から受け取った当該リクエストの処理時間とＵＲＩをリクエスト情報テーブルに格納する（ステップＳ２０１２)。
【００２５】
図４は、本実施形態におけるリクエスト情報テーブル４２０のデータ構造の例である。図４に示すように、リクエスト情報テーブル４２０は、ＵＲＩ８０１と、タイムアウトが発生した回数である超過回数８０２と、総リクエスト回数８０３と、平均超過時間８０４を含んで構成される。リクエスト情報テーブル４２０では、アプリケーションサーバ処理部２１０（図２参照)でのリクエスト処理が完了した後に、処理したリクエストに関する情報を整理して、管理し、ステップ１００９によって、登録および情報の更新が行われる。
【００２６】
ＵＲＩ８０１は、クライアント装置４０（図２参照)から送信されたリクエストの識別子を示しており、リクエストの処理が完了した際に、アプリケーションサーバ処理部２１０（図２参照)から通知され、既にリクエスト情報テーブル４２０に登録されている場合は当該ＵＲＩに対応する総リクエスト回数８０３に１を加算し、リクエスト情報テーブル４２０に登録されていなければ、総リクエスト数８０１を１としてリクエスト情報テーブル４２０に登録する。
【００２７】
超過回数８０２は、通知されたＵＲＩにおいて設定されたタイムアウト値を超過してタイムアウトとなった回数を示す。
総リクエスト回数８０３は、通知されたＵＲＩに対するリクエストの総回数を示す。
【００２８】
平均超過時間８０４は、｛（計算時点でリクエスト情報テーブルに登録されている平均超過時間８０４×計算時点でリクエスト情報テーブルに登録されている総リクエスト回数８０２＋アプリケーションサーバ処理部２１０から通知されるリクエスト処理時間）÷ 当該リクエストを含めた総リクエスト回数｝−｛Ｗｅｂサーバ動作定義ファイル６２０（図１参照)に定義されているタイムアウト設定値｝の式で計算され、タイムアウトが発生するごとに上書きされる。
【００２９】
図５は、本実施形態におけるＷｅｂサーバ動作定義ファイル６２０のデータ構造の例である。図５に示すようにＷｅｂサーバ動作定義ファイル６２０はクライアントから受信したリクエストをアプリケーションサーバ処理部２１０（図２参照)に転送してからアプリケーションサーバ処理部２１０（図２参照)からレスポンスを受信するまでのタイムアウト値を定義するタイムアウト値９０１と、総リクエスト数に対してどの程度の超過回数まで許容するかを設定する閾値９０２と、タイムアウトまでの時間を変更するときに最大でどのくらい延長するかの上限値を設定するタイムアウト延長上限値９０３を含んで構成される。Ｗｅｂサーバ動作定義ファイル６２０のデータは、リクエスト処理システム１の管理者などにより設定される。
【００３０】
図６は、本実施形態におけるサーバ装置において、ＷｅｂサーバにおけるＷｅｂサーバ処理処理部６１０のタイムアウト値延長判定処理（図２のステップ１００４)の詳細動作を示すフロー図である。
【００３１】
Ｗｅｂサーバ処理部７３０（図２参照)がリクエストを受信した際、リクエストのＵＲＩに対応する統計情報をタイムアウト管理サーバ処理部４１０（図２参照)がリクエスト情報テーブル４２０から取得し（ステップＳ１０１)、超過回数８０２（図４参照)と総リクエスト回数８０３（図４参照)を基に、当該ＵＲＩにおいてどのくらいの割合でタイムアウト設定値を超過しているかを算出し、算出した結果をＷｅｂサーバ動作定義ファイル６２０（図５参照)に設定されている閾値９０２（図５参照)と比較する（ステップＳ１０２）。閾値９０２を超えていなければ（ステップＳ１０２でｎ％未満)タイムアウト値の変更はしないで、タイムアウト値として、サーバ動作定義ファイル６２０のタイムアウト値９０１の設定値を使用し（ステップＳ１０６)処理を終了する。一方、算出した結果が閾値９０２（図５参照)以上であれば（ステップＳ１０２でｎ％以上)、タイムアウト管理サーバ処理部４１０（図２参照)から取得した平均超過時間８０４（図４参照)とＷｅｂサーバ動作定義ファイル６２０（図５参照)に設定されている、タイムアウト延長上限値９０３（図５参照)との比較を実施する（ステップＳ１０３）。平均超過時間８０４（図４参照)がＷｅｂサーバ動作定義ファイル６２０（図５参照)に設定されている、タイムアウト延長上限値９０３（図５参照)よりも長ければ（ステップＳ１０３で上限値より長い)タイムアウト値をタイムアウト延長上限値９０３（図５参照)分タイムアウト値９０１（図５参照)を延長し（ステップＳ１０４)、タイムアウト延長上限値９０３（図５参照)よりも短ければ（ステップＳ１０３で上限値以下)タイムアウト値を平均超過時間８０４（図４参照)分タイムアウト値９０１（図５参照)を延長し（ステップＳ１０５)、処理を終了する。
【００３２】
本実施形態に付随される効果として、タイムアウトになった際は、アプリケーションサーバで引き続き処理されているリクエストに要した時間を統計情報としてリクエストテーブル４２０に蓄積することで、延長すべき時間の精度を上げていくことが可能である。
【００３３】
また、適切なタイマ監視が可能になることで、無駄なリトライが無くなり、クライアント側だけでなくサーバ側の負担も低減することが可能である。
【００３４】
以上、本発明の実施形態を説明したが、この実施形態は本発明の説明のための例示にすぎず、本発明の範囲をその実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。
【符号の説明】
【００３５】
１ リクエスト処理システム
１０ サーバ装置
２０ サーバ装置
３０ サーバ装置
４０ クライアント装置
５０ ネットワーク
１００ ＣＰＵ
２００ メモリ
２１０ アプリケーションサーバ処理部
３００ ＣＰＵ
４００ メモリ
４１０ タイムアウト管理サーバ処理部
４２０ リクエスト情報テーブル
５００ ＣＰＵ
６００ メモリ
６１０ Ｗｅｂサーバ処理処理部
６２０ サーバ動作定義ファイル
【特許請求の範囲】
【請求項１】
Ｗｅｂサーバ処理装置と、クライアント装置から受け付けたリクエストを処理し、記憶装置を備えた通信制御装置とを含む計算機システムにおける通信制御方法において、
タイムアウト管理処理部は、前記リクエストの統計情報を記憶装置に格納し、
前記タイムアウト管理サーバ処理部は、前記リクエストを受信した際に、前記タイムアウト管理に前記蓄積されたリクエストの統計情報を読み出し、
前記Ｗｅｂサーバ処理装置は、前記タイムアウト情報の統計情報を基にタイムアウトまでの時間を変更させることを特徴とするリクエスト情報処理方法。
【請求項２】
前記アプリケーションサーバ処理部は、前記Ｗｅｂサーバ処理装置から転送された前記リクエストを処理し、処理の結果を前記タイムアウト管理サーバに通知することをとした請求項１の記載のリクエスト情報処理方法。
【請求項３】
前記タイムアウト管理サーバ処理部は、前記Ｗｅｂサーバ処理装置の前記動作定義ファイルにタイムアウトまでの時間を変更させる基準となるタイムアウト超過率閾値を保持するようにしたことを特徴とした請求項１の記載のリクエスト情報処理方法。
【請求項４】
前記タイムアウト管理サーバ処理部は、前記Ｗｅｂサーバ処理装置の動作定義ファイルにタイムアウトを延長する上限の時間であるタイムアウト延長上限値を保持するようにしたことを特徴とした請求項１の記載のリクエスト情報処理方法。
【請求項５】
Ｗｅｂサーバ処理装置と、クライアント装置から受け付けたリクエストを処理し、記憶装置を備えた通信制御装置とを含む計算機システムにおいて、
タイムアウト管理処理部は、前記リクエストの統計情報を記憶装置に格納し、
前記タイムアウト管理サーバ処理部は、前記リクエストを受信した際に、前記タイムアウト管理に前記蓄積されたリクエストの統計情報を読み出し、
前記Ｗｅｂサーバ処理装置は、前記タイムアウト情報の統計情報を基にタイムアウトまでの時間を変更させることを特徴とする計算機システム。
【請求項１】
Ｗｅｂサーバ処理装置と、クライアント装置から受け付けたリクエストを処理し、記憶装置を備えた通信制御装置とを含む計算機システムにおける通信制御方法において、
タイムアウト管理処理部は、前記リクエストの統計情報を記憶装置に格納し、
前記タイムアウト管理サーバ処理部は、前記リクエストを受信した際に、前記タイムアウト管理に前記蓄積されたリクエストの統計情報を読み出し、
前記Ｗｅｂサーバ処理装置は、前記タイムアウト情報の統計情報を基にタイムアウトまでの時間を変更させることを特徴とするリクエスト情報処理方法。
【請求項２】
前記アプリケーションサーバ処理部は、前記Ｗｅｂサーバ処理装置から転送された前記リクエストを処理し、処理の結果を前記タイムアウト管理サーバに通知することをとした請求項１の記載のリクエスト情報処理方法。
【請求項３】
前記タイムアウト管理サーバ処理部は、前記Ｗｅｂサーバ処理装置の前記動作定義ファイルにタイムアウトまでの時間を変更させる基準となるタイムアウト超過率閾値を保持するようにしたことを特徴とした請求項１の記載のリクエスト情報処理方法。
【請求項４】
前記タイムアウト管理サーバ処理部は、前記Ｗｅｂサーバ処理装置の動作定義ファイルにタイムアウトを延長する上限の時間であるタイムアウト延長上限値を保持するようにしたことを特徴とした請求項１の記載のリクエスト情報処理方法。
【請求項５】
Ｗｅｂサーバ処理装置と、クライアント装置から受け付けたリクエストを処理し、記憶装置を備えた通信制御装置とを含む計算機システムにおいて、
タイムアウト管理処理部は、前記リクエストの統計情報を記憶装置に格納し、
前記タイムアウト管理サーバ処理部は、前記リクエストを受信した際に、前記タイムアウト管理に前記蓄積されたリクエストの統計情報を読み出し、
前記Ｗｅｂサーバ処理装置は、前記タイムアウト情報の統計情報を基にタイムアウトまでの時間を変更させることを特徴とする計算機システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１１−９５８６９（Ｐ２０１１−９５８６９Ａ）
【公開日】平成２３年５月１２日（２０１１．５．１２）
【国際特許分類】
【出願番号】特願２００９−２４７２０３（Ｐ２００９−２４７２０３）
【出願日】平成２１年１０月２８日（２００９．１０．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年５月１２日（２０１１．５．１２）
【国際特許分類】
【出願日】平成２１年１０月２８日（２００９．１０．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]