JP2017174038A - 情報処理システム、情報処理方法およびプログラム - Google Patents

Abstract

【課題】サーバの処理能力に起因するセッションタイムアウトを防止すること。
【解決手段】
情報処理システムは、複数のクライアント装置と通信を行うために確立された複数のセッションの情報を記憶するセッション情報記憶部と、受信した複数のリクエストのうち、処理が開始されないリクエストを一時的に記憶するリクエスト記憶部と、前記セッション情報記憶部にセッションの情報が記憶された複数のセッションのうち、処理が実行されていない状態で経過した経過時間が予め定められたタイムアウト時間を経過したセッションについて、当該セッションに対応するクライアント装置から受信したリクエストが前記リクエスト記憶部に格納されていることに応じて、前記タイムアウト時間の経過に起因する当該セッションの無効化を抑止する制御部とを備える。
【選択図】図３

Description

本発明は、情報処理システム、情報処理方法およびプログラムに関する。

ネットワークを介してサーバとクライアント装置が接続され、クライアント装置からのリクエストに応じた処理をサーバが行うようなシステムでは、サーバとクライアント装置間で確立されるセッションを用いてサーバ、クライアント装置間の通信が管理される。

クライアント装置とサーバ間の通信を管理する技術としていくつかの技術が知られている。例えば、Ｗｅｂサーバからの要求に基づく処理を実行している間は、Ｗｅｂサーバが送信したリクエストをＷｅｂブラウザが無効化しないようにする技術がある（例えば、特許文献１参照）。また、他のサーバが記録するアクセス履歴を参照し、クライアント端末が他のサーバにアクセスしていることを確認したときに、自サーバのアプリケーションに対するタイムアウト時間を調整する技術がある（例えば、特許文献２参照）。他の技術として、ネットワーク上のパケットを転送する通信装置において、転送するパケットを転送順に蓄積するキューを備え、往復遅延時間がより短い通信セッションに属するパケットほど、より優先的に転送されるようにキュー上のパケットを並べ替える技術がある（例えば、特許文献３参照）。

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

クライアント側の様々な機器がインターネットに接続され、アプリケーションサーバ等のサーバと情報交換を行うＩｏＴ（Internet of Things）技術の普及により、多くのクライアント装置がサーバに接続される。例えば、ネットワークに接続された、各家庭内にある家電製品や、様々な設備に設けられたセンサ等の機器等から、多くのリクエストがサーバに送信される。このような状況では、サーバとクライアント装置との間に確立されるセッション数について、例えば、従来は数百から数万といったセッションの数だったものが、数百万や数千万といった数のセッションになることも想定される。

アプリケーションサーバは、通常、各クライアント装置からは間欠的にしかリクエストを受信しないため、同時に処理できるリクエストの数よりも多くのセッションを開始した状態で、クライアント装置からのリクエストを受け付ける。そのため、多くのクライアント装置との間でセッションが確立された状態で、アプリケーションサーバが各クライアント装置から一時期に多くのリクエストを受信する状況が発生する場合がある。

例えば、ネットワークに接続されたテレビに配信される人気番組の中で人気投票等が行われた場合、そのテレビ端末からテレビ番組の投票データの処理を行うサーバに対して、視聴者が入力した投票データを送信するリクエストが一斉に送信される。また、人気のあるミュージシャンのコンサートのチケットの販売をインターネット上で実施する場合、チケット販売に関する処理を行うサーバに対して、チケット販売開始と同時にチケット購入に関する多くのリクエストが集中する。

他の例としては、特定の地域で一時的な停電等が起こった場合、ネットワークに接続してアプリケーションサーバと通信を行う冷蔵庫等の家電機器から、停電から復帰した直後に一斉にリクエストがアプリケーションサーバに送信されることが想定される。このような場合、各家電機器との通信を行うためのセッションを開始するリクエストはすぐに処理されて多数のセッションが確立される。しかし、セッション確立後に、各家電機器から一定量の処理負荷を要するリクエストが続けて大量にサーバに送信されることになる。

多くのクライアント装置との間でセッションが確立された状態で、アプリケーションサーバが各クライアント装置から一時期に多くのリクエストを受信すると、アプリケーションサーバが受信したリクエストを処理しきれない場合が発生し得る。この場合、アプリケーションサーバは受信した多くのリクエストを処理しきれず、実行待ちとなるリクエストの多くは、セッションタイムアウトによって無効化（又は破棄）されてしまうことが想定される。

ここで、サーバの負荷に応じてセッションのタイムアウト時間を長くすることが考えられるが、どの程度のタイムアウト時間に設定すれば良いかの判断は容易ではない。また、タイムアウト時間を長く設定すると、機器の障害に起因するエラーの検出が遅くなってしまう。そのため、同時期に多くのリクエストを受信した場合などにおいて、サーバ側の処理能力に起因するセッションのタイムアウトを回避できることが望ましい。

１つの側面では、本発明は、サーバの処理能力に起因するセッションタイムアウトを防止することを目的とする。

発明の一観点によれば、複数のクライアント装置からのリクエストを受信するリクエスト受付部と、前記複数のクライアント装置と通信を行うために確立された複数のセッションの情報を記憶するセッション情報記憶部と、前記リクエスト受付部が受信した複数のリクエストのうち、処理が開始されないリクエストを一時的に記憶するリクエスト記憶部と、前記セッション情報記憶部にセッションの情報が記憶された複数のセッションのうち、セッションに対応するリクエストの処理が実行されていない状態で経過した経過時間が予め定められたタイムアウト時間を経過したセッションを検出するタイムアウト検出部と、前記タイムアウト検出部によって前記経過時間が前記タイムアウト時間を経過したと検出されたセッションについて、当該セッションに対応するクライアント装置から受信したリクエストが前記リクエスト記憶部に格納されていることに応じて、前記タイムアウト時間の経過に起因する当該セッションの無効化を抑止する制御部とを有する情報処理システムが提供される。

一実施態様によれば、サーバの処理能力に起因するセッションタイムアウトを防止することができる。

図１は、情報処理システムのシステム構成の一例を示す図である。 図２は、サーバのハードウェア構成の一例を示す図である。 図３は、情報処理システムの機能ブロック図の一例を示す図である。 図４は、クライアント装置とサーバ間で確立されるセッションを説明する図である。 図５は、サーバの機能ブロック図の一例を示す図である。 図６は、キューに格納されたリクエストを処理する順序とセッション格納領域との関係の一例を説明する図である。 図７は、キューイング処理部の一例を示す図である。 図８は、タイムアウト時間管理テーブルの一例を説明する図である。 図９は、セッション管理テーブルの一例を説明する図である。 図１０は、ウェブサーバ処理及びアプリケーションサーバ処理の一例を示すフローチャートである。 図１１は、受付セッションＩＤ書込み処理の一例を示すフローチャートである。 図１２は、アプリケーション処理の一例を示すフローチャートである。 図１３は、受付セッションＩＤ削除処理の一例を示すフローチャートである。 図１４は、セッションタイムアウト監視処理の一例を示すフローチャートである。 図１５は、キュー読出し制御処理の一例を示すフローチャートである。

以下、図面を参照して、一実施形態について説明する。

［システム構成］
図１は、実施例１における情報処理システム１０のシステム構成の一例を示す図である。図１に示すように、本実施形態に係る情報処理システム１０は、Ｎ（Ｎは自然数）個のサーバ１００−１〜１００−Ｎと、データベース（ＤＢ）サーバ１１０と、ネットワークスイッチ１２０と、管理サーバ１３０とを備える。情報処理システム１０は、インターネット等の外部通信回線であるネットワーク２０を介してクライアント装置３０と接続される。クライアント装置３０は、ユーザからの操作を受けてサーバに処理を要求する端末装置だけでなく、ネットワークに接続された様々な電子機器を含む。ネットワークに接続された電子機器の例としては、例えば、インターネットを介してサーバに機器の状態を通知する冷蔵庫等のネットワーク家電や、通信機能付きのテレビ、オフィスビルや各家庭に設置された電気メータやガスメータ、温度センサ等のセンサ機器等を含む。

情報処理システム１０は、例えばクライアント装置３０を介して受信したユーザからのリクエストに応じた処理を行う。情報処理システム１０は、各クライアント装置３０から受信したリクエストによって要求された処理を行った結果をクライアント装置３０に応答する。

サーバ１００−１〜１００−Ｎのそれぞれは、クライアント装置から送信されたリクエストに係る様々な処理を行うアプリケーションプログラムを実行するサーバ装置である。以下、サーバ１００−１〜１００−Ｎは、それらを区別不要の場合、サーバ１００と記述する。サーバ１００は、図１では、Ｎ個のサーバ１００−１〜１００−Ｎを備える例としているが、サーバ１００の数は複数個である必要はなく、１つであってもよい。

データベース（ＤＢ）サーバ１１０は、サーバ１００で行う処理に関連するデータを記憶するデータベース装置であり、サーバ１００上で実行されるＯＳやアプリケーションが用いるデータ等を記憶する。ＤＢサーバ１１０は、ストレージ装置や、大きな記憶容量の記憶装置を有するサーバ等によって実現される。

ネットワークスイッチ１２０は、ネットワーク２０に接続され、サーバ１００や管理サーバ１３０と、ネットワークに接続された装置との間の通信パケットを適切な宛先装置に転送する。管理サーバ１３０は、情報処理システム１０内の通信回線であるローカルバス１３１を介して、情報処理システム１０内のサーバ１００−１〜１００−Ｎ、ＤＢサーバ１１０、ネットワークスイッチ１２０等と通信を行うことにより、各装置の管理を行う。

［ハードウェア構成］
図２は、サーバ１００のハードウェア構成の一例を示す図である。サーバ１００は、ＣＰＵ１０１（１０１Ａ〜１０１Ｄ）と、入出力装置インタフェース回路１０２と、メモリ１０３と、ネットワークインタフェース回路１０４と、ＤＢサーバインタフェース回路１０５と、ローカルバスインタフェース回路１０６と、ハードディスクドライブ（ＨＤＤ）１０７とを備える。各ＣＰＵ（Central Processing Unit）１０１は、内部バス１０８を介して、メモリ１０３や入出力装置インタフェース回路１０２等の各インタフェース回路（１０４〜１０６）にアクセスする。

ＣＰＵ１０１（１０１Ａ〜１０１Ｄ）は、サーバ１００上で様々な処理を行うプロセッサのハードウェア資源であり、サーバを構成する電子部品の一つである。図２の例では、サーバ１００が、ＣＰＵ１０１Ａ、ＣＰＵ１０１Ｂ、ＣＰＵ１０１Ｃ、ＣＰＵ１０１Ｄの４つのＣＰＵを備える例を示しているが、ＣＰＵの数は４つに限られず、より多くのＣＰＵを備えてもよい。また、ＣＰＵの中に複数のＣＰＵコアや、ハードウェアスレッドを備え、１つのＣＰＵによって、複数のアプリケーションプログラムのプロセスの処理を並行して行えるＣＰＵをＣＰＵ１０１として用いてもよい。さらに、ＣＰＵは、サーバによってその搭載数が異なっていてもよい。

入出力装置インタフェース回路１０２は、サーバ１００にマウスやキーボード等の周辺デバイスが接続される場合に、それら周辺デバイスへの入出力を制御するための回路である。メモリ１０３は、Random Access Memory（ＲＡＭ）等の記憶デバイスである。図２では、１つのメモリ１０３を図示しているが、メモリ１０３は複数のＲＡＭを含んでもよく、また、ＣＰＵ１０１−１〜１０１−Ｎごとに対応する別々のメモリ１０３（１０３−１〜１０３−Ｎ）を備えるようにしてもよい。

ネットワークインタフェース回路１０４は、ネットワーク２０を介して他の装置と通信を行うためのインタフェース回路であり、図１の例では、ネットワークスイッチ１２０を介してネットワーク２０と接続される。ＤＢサーバインタフェース回路１０５は、ＤＢサーバ１１０へのアクセスを行うためのインタフェース回路である。ローカルバスインタフェース回路１０６は、ローカルバス１３１を介して情報処理システム内の管理サーバ１３０や他のサーバ１００等と通信を行うためのインタフェース回路である。

ハードディスクドライブ１０７は、ＣＰＵ１０１で実行されるプログラムや、ＣＰＵ１０１上で実行される処理が扱うデータを記憶する記憶媒体である。

以下に説明する、サーバ１００で実行されるウェブサーバ１４０、アプリケーションサーバ１５０等の処理を行うためのプログラムやデータはメモリ１０３やＨＤＤ１０７、または、ＤＢサーバ１１０に格納される。ＣＰＵ１０１は、ＨＤＤ１０７等に格納されたプログラムやデータを読み出して、ウェブサーバ１４０、アプリケーションサーバ１５０等で実行される処理に関するプログラムを実行する。

尚、管理サーバ１３０を図２に示すハードウェア構成によって実現してもよい。この場合、図２のように４つのＣＰＵ（１０１Ａ〜１０１Ｄ）を実装することに替えて、１つのＣＰＵ１０１Ａのみ実装するようにしてもよい。管理サーバ１３０が行う情報処理システム１０内の各装置の管理を行う処理は、管理サーバ１３０のメモリ１０３に格納したプログラムをＣＰＵ１０１Ａが実行することによって行われる。

［機能ブロック１］
図３は、実施例１に係る情報処理システムの機能ブロック図の一例を示す図である。図３において、サーバ１００は、ウェブサーバ１４０とアプリケーションサーバ１５０とを含む。図３では、説明の便宜上、サーバ１００に１つのクライアント装置３０が接続される図としているが、実際には、ネットワークを介して多くのクライアント装置３０がサーバ１００に接続される。

ウェブサーバ１４０の処理及びアプリケーションサーバ１５０の処理は、サーバ１００に含まれるＣＰＵ１０１によって所定のプログラムを実行することによって実現される。ここで、ウェブサーバ１４０及びアプリケーションサーバ１５０の処理は、１つのＣＰＵで実行されてもよいし、それぞれ異なるＣＰＵで実行されてもよい。また、ウェブサーバ１４０の処理を情報処理システム１０に含まれるサーバ１００−１で実行し、アプリケーションサーバ１５０の処理を、他のサーバ１００−２〜１００−Ｎで実行するようにしてもよい。

サーバ１００は、クライアント装置３０から受信したリクエストを、ウェブサーバ１４０とアプリケーションサーバ１５０とを用いて処理を行う。具体的には、ウェブサーバ１４０は、クライアント装置３０からのリクエストを受信する。アプリケーションサーバ１５０は、ウェブサーバ１４０が受信したリクエストで要求された処理を実行し、実行結果をウェブサーバ１４０に受け渡す。ウェブサーバ１４０は、アプリケーションサーバ１５０から受信した実行結果をクライアント装置３０に返信する。

ウェブサーバ１４０は、キュー１４１を有する構成としてもよい。キュー１４１は、クライアント装置３０から受信したリクエストをアプリケーションサーバ１５０に転送するまでの間、受信したリクエストを一時的に格納する記憶領域である。キュー１４１の記憶領域は、例えば、メモリ１０３の一部の領域をキュー１４１の領域として割り当てることによって得られる。ウェブサーバ１４０が受信したリクエストをアプリケーションサーバ１５０がすぐに受信できる場合、ウェブサーバ１４０はクライアント装置３０から受信したリクエストをキュー１４１に格納することなくアプリケーションサーバ１５０に転送するようにしてもよい。

アプリケーションサーバ１５０は、キュー１５１と、リクエスト処理部１５２と、セッション格納部１５３と、セッションタイムアウト監視部１５４とを有する。リクエスト処理部１５２とセッションタイムアウト監視部１５４等の処理は、アプリケーションサーバ１５０の処理を実行するＣＰＵ１０１によって、メモリ１０３やＨＤＤ１０６等に格納された所定のプログラムを実行することにより実現される。

リクエスト処理部１５２は、ウェブサーバ１４０から受信したリクエストで要求された処理を実行する。また、リクエスト処理部１５２は、リクエストを送信したクライアント装置３０との通信に用いるセッションの作成や削除、及び、セッションに関連する情報の更新等の処理を行う。リクエスト処理部１５２の処理は、ウェブサーバ１４０からリクエストを受信することに応じて呼び出されるアプリケーション処理を行うプログラムによって実行される。アプリケーション処理の詳細については、図１０（Ｂ）及び図１２を用いて後述する。

キュー１５１は、リクエスト処理部１５２がリクエストを処理できるようになるまでの間、ウェブサーバ１４０から受信したリクエストを一時的に格納する記憶領域である。キュー１５１の記憶領域は、例えば、メモリ１０３の一部の領域をキュー１５１の領域として割り当てることによって得られる。なお、図３の機能ブロック図の例において、キュー１５１の記憶領域として十分大きな領域を確保できる場合、ウェブサーバ１４０に含まれるキュー１４１を設けない実装としても良い。また、他の実装例として、ウェブサーバ１４０とアプリケーションサーバ１５０との間で共有するキューをメモリ１０３上の共有メモリ領域に設ける実装としてもよい。

セッション格納部１５３は、メモリ１０３又はＨＤＤ１０７の一部の記憶領域に割り当てられた、セッションに関連する情報を記憶する領域である。セッションに関連する情報としては、セッション識別情報（セッションＩＤ）、アプリケーション識別情報（アプリケーションＩＤ）、クライアント装置の識別情報（クライアントＩＤ）、セッションを確立したクライアント装置との通信を行うための各種設定情報が含まれる。ここで、セッション識別情報（セッションＩＤ）は、サーバ１００とクライアント装置３０との間で確立されるセッションごとに付与される固有の識別情報である。アプリケーション識別情報（アプリケーションＩＤ）は、アプリケーションサーバ１５０上で実行されるアプリケーションごとに付与される固有の識別情報である。また、クライアント装置の識別情報（クライアントＩＤ）は、クライアント装置ごとに付与される固有の識別情報である。

セッションタイムアウト監視部１５４は、定期的に、又は管理サーバ１３０からの要求があった場合やその他の特定のタイミングで、セッションタイムアウトの監視処理を行う。セッションタイムアウトの監視処理において、セッションタイムアウト監視部１５４は、セッション格納部１５３に格納されたセッション情報に対応する各セッションが所定のタイムアウト時間を経過したか否かを監視する。セッションタイムアウト監視部１５４による処理の詳細については、後述する。

［クライアント装置とサーバ間で確立されるセッション］
図４は、クライアント装置３０とサーバ１００間で確立されるセッションに関する説明を行うための図である。クライアント装置３０は、定期的に、または、外部入力に応じて、サーバ１００と通信を行う。クライアント装置３０は、サーバ１００との通信を行うために、まず、サーバ１００に対してセッション開始要求のリクエストを送信する。

クライアント装置３０からサーバ１００にセッション開始要求のリクエストが送信されると、クライアント装置３０とサーバ１００間で通信プロトコルに沿ったハンドシェイクが行われ、セッションが確立される。セッションを確立する処理において、サーバ１００は、クライアント装置３０から要求されたセッションに関するセッション情報を生成し、セッション格納部１５３に格納する。

クライアント装置３０とサーバ１００間でセッションが確立されると、サーバ１００は、クライアント装置３０にセッションの識別情報を送信する。クライアント装置は、サーバ１００に対してアプリケーションの処理を要求するリクエストを送信する際、セッションの識別情報と共にリクエストを送信する。

サーバ１００は、クライアント装置３０からリクエストを受信すると、セッション格納部１５３に格納した、リクエストに対応するセッションに関連する情報を更新し、リクエストで要求されたアプリケーションの処理を実行する。実行された処理結果は、リクエストに対する応答としてクライアント装置３０に送信される。

クライアント装置３０とサーバ１００間で確立されたセッションは、クライアント装置３０からのセッション終了要求によって終了する。サーバ１００がクライアント装置３０からセッション終了要求のリクエストを受信すると、対応するセッションの情報をセッション格納部１５３から削除し、クライアント装置３０にセッション終了処理が完了した旨の応答を行う。

クライアント装置３０とサーバ１００間で確立されたセッションは、セッション終了要求による終了以外に、セッションタイムアウトによっても終了する。サーバ１００は、クライアント装置３０とのセッションが確立された後、対応するセッションに係るクライアント装置３０から要求された処理が実行されていない期間を監視する。

図４の例では、セッション開始後にクライアント装置３０から要求された処理がサーバ１００で実行されるまでの期間や、サーバ１００での処理実行後にセッション終了要求が処理されるまでの期間がセッションタイムアウト監視期間として図示されている。なお、セッションタイムアウト監視期間は図４に図示した期間に限られず、サーバ１００でクライアント装置３０から要求された処理が実行された後に、同じセッションに関する次に要求された処理が実行されるまでの期間も監視期間に含まれる。

セッションタイムアウトの監視は、セッションを確立したクライアント装置３０から要求される処理を実行していない期間が所定のタイムアウト時間を経過するか否かによって行われる。その際、本実施例では、タイムアウト時間の経過だけでなく、クライアント装置３０からのリクエストがサーバ１００に届いているか否かも考慮してセッションタイムアウトに起因するセッションの無効化（破棄）を判断する。

本実施例におけるセッションタイムアウトの判定処理について図３を参照しながら説明する。サーバ１００は、多くのクライアント装置３０と通信を行うためのセッションを確立し、各クライアント装置３０からリクエストを受信する。そのため、サーバ１００のセッション格納部１５３には、多くのクライアント装置３０との間で確立されたセッションに関する情報が格納される。

セッションタイムアウト監視部１５４は、例えば定期的なタイミングで、セッション格納部１５３に格納されたセッション情報のそれぞれに対応するセッションについて、セッションタイムアウトを監視する。セッションタイムアウト監視部１５４は、監視対象となる複数のセッションのうち、サーバ１００が対象となるセッションに関する処理を実行していない期間が各セッションについて定められた所定のタイムアウト時間を超えているか否かを判定する。

従来の技術においては、セッションタイムアウト監視部１５４がセッションタイムアウトを検出したセッションについては、強制的にセッションを無効化又は破棄していた。しかし、ＩｏＴ技術の普及に伴ってサーバ１００が非常に多くのクライアント装置３０から要求された処理を行う状況では、クライアント装置３０からのリクエストが一時期に集中する場合がある。このような場合、サーバ１００の物理的な処理能力不足によってアプリケーションサーバ１５０が処理できなかったリクエストについては、一時的にキュー１５１又はキュー１４１に格納される。

キュー１５１又はキュー１４１に大量の処理待ちリクエストが格納されている場合、従来技術ではキュー１５１又はキュー１４１に格納された多くのリクエストはセッションタイムアウトによって破棄され、リクエストを送信したクライアント装置にセッションタイムアウトのエラー応答がされていた。すると、セッションタイムアウトのエラー応答を受信した多くのクライアント装置は、再度、セッション開始リクエストからやり直すということになる。このような動作は、サーバ１００の処理負荷を増加させるだけでなく、ネットワークの輻輳をも招くという問題があった。そのため、サーバ１００の処理能力不足に起因するセッションタイムアウトは、できる限り回避できることが望ましい。

本実施例では、セッションタイムアウトの判定において、タイムアウト時間を経過したか否かを判定するだけでなく、セッションタイムアウトの判定を行う時点でセッションに対応するクライアント装置３０からの処理のリクエストが届いているか否かも判定する。

セッションタイムアウト監視部１５４は、例えば定期的なセッションタイムアウトの判定を行う際、所定のタイムアウト時間が経過したセッションを抽出する。抽出したセッションのそれぞれに対して、セッションタイムアウト監視部１５４は、各セッションに関連したリクエストがキュー１５１に格納されているかどうかを判定する。ここで、キュー１４１用に確保するメモリ領域をアプリケーションサーバとウェブサーバ１４０が共有するメモリ領域に設ける実装も考えられる。この場合、セッションタイムアウト監視部１５４は、キュー１５１だけでなく、キュー１４１も参照でき、各セッションに関連したリクエストがキュー１４１又はキュー１５１のいずれかに格納されているかどうかを判定する。以下、説明を簡単にするために、セッションタイムアウト監視部１５４がキュー１５１だけでなくキュー１４１も参照できるものとして説明する。

タイムアウト時間を経過したものとして抽出されたセッションであっても、関連したリクエストがキュー１５１又はキュー１４１に格納されている場合には、セッションタイムアウト監視部１５４は、セッションタイムアウトに起因するセッションの無効化（破棄）を抑止する。キュー１５１又はキュー１４１に実行すべきリクエストが格納されている場合、サーバ１００の処理能力に起因してリクエストの処理が待たされている状態となっている。そのため、キュー１５１又はキュー１４１に実行待ちの状態で格納されているリクエストに関するセッションについては、たとえセッションタイムアウトとなる場合であっても、セッションタイムアウト監視部１５４は無効化（破棄）しない。

一方、タイムアウト時間を経過したものとして抽出されたセッションであって、関連したリクエストがキュー１５１又はキュー１４１に格納されていないセッションについては、セッションタイムアウト監視部１５４によるセッションの無効化が行われる。これは、使われないままセッション管理用として確保され続けているメモリを解放して、他のセッションの管理に使用できるようにするためである。

［実施例１の効果］
上述のように、実施例１では、セッションタイムアウトと判定されるセッションであっても、セッションに関連したリクエストが実行待ち状態でキューに格納されている場合にはセッションタイムアウトと判定されたセッションの無効化を行わない。このように制御することで、サーバ１００の処理能力に起因するセッションタイムアウトを防止することができるようになる。

［機能ブロック２］
図５は、実施例２に係るサーバ１００の機能ブロック図の一例を示す図である。図５において、図３の実施例１での機能ブロック図と同じ符号が付された構成要素については、基本的に、実施例１での構成要素と同様の機能を有するものとする。

実施例２では、セッションタイムアウトとなったセッションに関連したリクエストがキュー１５１又はキュー１４１に格納されているかどうかを判定することを容易にするために、実施例１の図３に示される機能ブロックに加えて、受付セッションＩＤ格納部１６０が設けられる。

受付セッションＩＤ格納部１６０は、サーバ１００がクライアント装置３０からリクエストを受信する度に、受信したリクエストに対応するセッションのセッション識別情報を格納する記憶領域である。受付セッションＩＤ格納部１６０の記憶領域は、例えば、メモリ１０３の一部の領域を割り当てることによって確保される。サーバ１００に受付セッションＩＤ格納部１６０を設けたことに伴い、ウェブサーバ１４０に、受付セッションＩＤ書込み部１４２と、受付セッションＩＤ削除部１４３を設ける。

受付セッションＩＤ書込み部１４２は、ウェブサーバ１４０が、クライアント装置３０からリクエストを受信する度に、受信したリクエストのそれぞれに対応するセッションの識別情報を、受付セッションＩＤ格納部１６０に格納する。受付セッションＩＤ削除部１４３は、リクエストに対応する処理の実行結果がクライアント装置３０に応答されるのに合わせて、実行結果を応答したリクエストに対応するセッション識別情報を受付セッションＩＤ格納部１６０から削除する。

実施例２でのセッションタイムアウト監視部１５４は、セッションタイムアウト判定を行う際に、キュー１５１又はキュー１４１に新たなリクエストが格納されているかどうかを判定する代わりに受付セッションＩＤ識別部に格納された情報を判定する。ここで、受付セッションＩＤ格納部１６０に格納されたセッション識別情報は、リクエストを受信してからリクエストが要求する処理が完了してクライアント装置３０に実行結果が応答されるまで保持される。すなわち、受信したリクエストをリクエスト処理部１５２が処理している期間だけでなく、処理が開始される前にリクエストがキュー１５１又はキュー１４１に格納されている期間も、受付セッションＩＤ格納部１６０に対応するセッション識別情報が格納されていることとなる。

ここで、実施例１の場合と比較すると、実施例１におけるセッションタイムアウト監視部１５４は、まず、セッションタイムアウトを検出したセッションに対して「セッションに関連する処理が行われていないかどうか」を判定する（第１の判定）。そして、抽出したセッションに対して、対応するリクエストがキュー１５１又はキュー１４１に格納されているか否かについて判定を行う（第２の判定）。すなわち、実施例１では、セッションタイムアウトを検出したセッションに対して、さらに２段階の判定を行っていた。

しかし、実施例２では、セッションタイムアウト監視部１５４は、セッションタイムアウトの監視処理を行う際にセッションタイムアウトを検出したセッションに対応するセッション識別情報が受付セッションＩＤ格納部１６０に格納されているか否かを確認するだけでよい。そのため、実施例２では、受付セッションＩＤ格納部１６０を設けることで、実行待ちのリクエストも考慮したセッションタイムアウトによるセッションの無効化制御をより容易に行うことができる。

［リクエストを処理する順序について］
図６は、キューに格納されたリクエストを処理する順序とセッション格納領域との関係の一例を説明する図である。図６では、説明に必要な構成要素のみが図示されている。

図６（Ａ）では、リクエスト処理部１５２で処理待ちとなっているリクエストがキュー１５１に格納されている様子を示した図である。図６（Ａ）の例では、白い丸は処理時間の長いセッションのリクエストを表し、斜線が付された丸は処理時間の短いセッションのリクエストを表す。ここで、「処理時間の長いセッションのリクエスト」とは、例えば、新規セッションを開始するリクエストのように、セッションを終了するまでに要する時間が長いと予想されるリクエストを意味する。また、「処理時間の短いセッションのリクエスト」とは、セッションに関連したリクエストの処理がすぐに終了することが見込めるリクエストを意味する。

図６（Ｂ）は、キュー１５１に格納された順に従って、リクエスト処理部１５２がリクエストを処理した場合の例を示した図である。図６（Ｂ）の中央の矢印の左側がリクエストを処理する前の状態を表し、矢印の右側が数十秒経過して白丸のリクエストの１つを処理中となっている状態を表したものである。また、図６（Ｂ）では、キュー１５１の下に、数十秒の時間が経過する前後のセッション格納部１５３の格納領域の様子の変化を示している。

図６（Ｂ）の左側では、説明の便宜上、セッション格納部１５３の格納領域に、セッション格納済領域Ｂの他に、１つの新たなセッションを作成できる領域（白い部分）が残っているものとする。この状態で数十秒経過して、キュー１５１の先頭の最も古い時点で受信したリクエストの処理を１つ開始し、そのリクエストの処理を継続中の状態を図６（Ｂ）の右側に示す。この場合、新たに作成されたセッションによって、セッション格納部１５３の格納領域は全てセッション格納済領域Ｂ’で占められ、セッション格納部１５３の格納領域に空きが無い状態となっている。そのため、後続する新たなセッションを開始するリクエストの処理を実行できず、関連する処理の実行が完了したセッションの情報がセッション格納領域Ｂ’から削除されるまで、キュー１５１に格納したリクエストの処理が待たされ続けることになる。

図６（Ｃ）は、図６（Ａ）のキュー１５１に格納されたリクエストの順番を入れ替えて、処理時間の短いセッションのリクエストから順に処理させた場合の例を示した図である。図６（Ｃ）の左側の状態では、例えばセッション終了要求に関するリクエストをキュー１５１の最初に２つ配置するように、リクエストの順番を入れ替えたものとする。この場合、数十秒経過して図６（Ｃ）の右側の状態になると、先頭の２つのセッション終了リクエストの処理が完了している。そのため、セッション格納部１５３の格納領域は、セッション格納領域Ｃ’の領域の他に、図６（Ｃ）の左側の状態に比べてさらなる空き領域（白い部分）ができていることが分かる。そのため、キュー１５１に格納されている２つ目の白丸のリクエストまで、すなわち、キュー１５１の先頭から３つ分のリクエストを続けてリクエスト処理部１５２に処理させることが可能となる。

このように、キュー１５１に格納された実行待ち状態となっているリクエストの順序を入れ替えることができる場合には、リクエストの実行順序を入れ替えることで、より多くのリクエストを処理することが可能となる。つまり、実行待ち状態のリクエストがキュー１５１に多く溜まっている状況におけるアプリケーションサーバ１５０の処理のスループットを向上させることが可能となる。

ところで、リクエストにも種類があり、順序を入れ替えてはいけないリクエストと、順序を入れ替えても良いリクエストとがある。順序を入れ替えてはいけないリクエストとしては、例えば、人がクライアント装置３０を用いてチケット予約をする場合のように、入力される情報や処理を順に処理する必要があるリクエストがある。また、電子機器から送信されたリクエストの中にも、順に処理を実行しなければならないリクエストも存在し得る。このような順序保証をしなければならないリクエストについては、リクエストを実行する順番の追い越しをしてはならない。

一方、順序を入れ替えても良いリクエストとしては、例えば、ネットワークに接続された家電機器等のクライアント装置３０から各家電機器の状態を定期的にサーバに通知するためのステータスレポートを送信するリクエストがある。家電機器等から送信されたステータスレポートを送信するリクエスト等については、リクエストを処理する順序を入れ替えても良く、また、処理内容も人の操作に基づく処理に比べて短時間に終了するものが多い。

このように、リクエストにも、実行順序を入れ替えても良いリクエストと、実行順序を入れ替えてはいけないリクエストとがある。また、リクエストによって処理時間が長くかかるものと、短いものとがある。そのため、リクエストの種別を判定し、順序を入れ替えても良いリクエストについては、各リクエストの処理時間に応じてリクエストの順序を入れ替えることが望ましい。図７を用いて、リクエストの順序を入れ替える制御を行うキューイング処理部の一例について説明する。

図７は、実施例２に係るキューイング処理部の一例を説明する図である。キューイング処理部１７０は、図３や図５に示されたキュー１５１又はキュー１４１の具体的な実施態様の一例である。キューイング処理部１７０は、順序保証キュー１７１と、順序可変キュー１７２と、リクエスト種別判定部１７３と、キュー読出制御部１７４とを有する。

順序保証キュー１７１は、実行順序を入れ替えてはいけないリクエストを一時的に格納するためのキューである。一方、順序可変キュー１７２は、実行順序を入れ替えても良いリクエストを一時的に格納するためのキューである。リクエスト種別判定部１７３は、受信したリクエストの種別を判定し、受信したリクエストを順序保証キュー１７１と順序可変キュー１７２のいずれのキューに格納するかを決定する。キュー読出制御部１７４は、順序保証キュー１７１及び順序可変キュー１７２のそれぞれから、所定の方法でリクエストを読み出して出力する。

図７の例では、リクエストを順序保証キュー１７１と順序可変キュー１７２に分けて格納することで、キューに格納されたリクエストの順序制御を容易に行うことが可能となる。具体的には、順序保証キュー１７１に格納したリクエストについては、リクエストを格納した順に取り出すことで容易に順序保証を行うことができる。また、順序可変キュー１７２に格納したリクエストについては、リクエストを受信した順序に関係なく、後述するような所定の条件で読み出すリクエストの読出し順序を決定することができる。

順序保証キュー１７１と順序可変キュー１７２のキューの数については、それぞれ１個ずつにする必要はなく、それぞれ複数個のキューにしてもよい。例えば、順序保証キュー１７１と順序可変キュー１７２のそれぞれについて、異なる優先順位を設定した複数のキューを設けてもよいし、格納するリクエストの処理内容やアプリケーションの内容に応じた複数のキューを設けてもよい。

キューイング処理部１７０は、ウェブサーバ１４０のキュー１４１に実装するようにしてもよい。特に、アプリケーション処理を実行するサーバ１００を複数用いる場合等において、キューイング処理部１７０を、ウェブサーバ１４０のキュー１４１に実装し、サーバ１００の数分だけ複数の順序保証キュー１７１と順序可変キュー１７２を設けてもよい。

順序保証をする必要があるリクエストについて、異なるクライアント装置３０から送信されたリクエストや、異なるアプリケーションによって処理されるリクエストの間では順序保証をする必要がない場合が多い。そのため、順序保証キュー１７１を複数設けるようにすることで、複数の順序保証すべきリクエストのグループを並列的に扱うことが可能となる。

リクエスト種別判定部１７３は、受信したリクエストが要求する処理の内容に応じて、受信したリクエストの種別が実行順序を入れ替えても良い種別のリクエストであるか、あるいは、実行順序を入れ替えてはいけない種別のリクエストであるのかを判定する。便宜上、実行順序を入れ替えても良い種別のリクエストを「順序可変リクエスト」と称し、実行順序を入れ替えてはいけない種別のリクエストを「順序保証リクエスト」と称する。リクエストの種別の判定方法としては、以下に述べる複数の観点のいずれか、あるいはその組み合わせによって判定することができる。

（１）リクエストの処理の内容に基づく判定方法
受信したリクエストの処理の内容がセッション開始要求やセッション終了要求である場合には、リクエストの実行順序を保証する必要がないため、受信したリクエストは順序可変リクエストと判定される。

また、受信したリクエストによって要求された処理内容に順序保証を要しないものが含まれることが既知であれば、予め順序保証すべきリクエストの内容をテーブルとして保持しておき、テーブルと比較することで、リクエストの種別を判定することもできる。リクエストに含まれる情報には、例えば、ＵＲＬの末尾に操作内容を記載した情報が含まれる場合がある（例：http://xxx/yyy/zzz/operation1）。このような場合ＵＲＬの末尾の「operation1」の内容を確認することで要求された処理の内容を判定することができ、処理の内容に基づく順序保証の要否を判定できる。

（２）リクエストを実行するアプリケーションの種類に基づく判定方法
リクエストを処理するアプリケーションの種類によって、リクエストの順序保証の要否を判定できる場合もある。例えば、チケット予約等のサービスを提供するアプリケーションに対する処理を要求するリクエストであれば、順序保証が必要なリクエストと予想することができる。一方、テレビ番組の人気投票の集計アプリケーションが処理するリクエストについては、データ収集さえできれば良いので、リクエストの順序保証は不要なリクエストであると予想することができる。このように、リクエストを処理するアプリケーションの種類に応じて、リクエストの順序保証の要否を判定できる。

（３）リクエストを送信したクライアント装置の種類に基づく判定方法
リクエストを送信したクライアント装置３０の種類から、受信したリクエストが順序可変リクエストか否かを判定できる場合もある。例えば、リクエストを送信したクライアント装置３０が、センサによって取得したデータを定期的にサーバに送る装置であるような場合には、データを受け取る順序はサーバ１００で実行されるデータを収集するアプリケーションの処理に影響しない。このような場合、リクエストを送信するクライアント装置３０の種類、あるいは固有の識別情報に基づいて、受信したリクエストが順序可変リクエストであると判定することができる。クライアント装置３０の識別情報としては、例えば、クライアント装置３０のＩＰアドレス等の識別情報や、クライアント装置３０の属性を示す情報がリクエストに含まれる場合には、その属性情報を用いてもよい。

（４）リクエストに含まれる制御情報に基づく判定方法
リクエストによっては、リクエストに含まれる情報の中に順序保証をする必要があるか否かを示す制御情報を含む場合もある。そのようなリクエストについては、リクエストに含まれる制御情報に基づいて、受信したリクエストの順序保証の要否を判定することもできる。

キュー読出制御部１７４は、順序保証キュー１７１からは、入力された順にリクエストを読み出す。また、キュー読出制御部１７４は、順序可変キュー１７２からは、所定の条件に基づいて決定した順序に基づいてリクエストの読出しを行う。キュー読出制御部１７４の処理の詳細については、図９、図１５を用いて後述する。

［クライアント装置の種別に応じたセッションタイムアウト値の設定］
図８は、クライアント装置の種別に応じたセッションタイムアウト値の設定を説明する図である。

従来のアプリケーションサーバでは、アプリケーションの種別に応じてセッションタイムアウト時間が設定されていた。例えば、チケット販売アプリケーションや、企業内の勤怠管理アプリケーション等、人の操作に応じて処理を行うアプリケーションについては、その処理内容に応じて、２０分、１時間といった異なるセッションタイムアウト時間が設定されていた。

しかし、ＩｏＴ技術の普及に伴って様々なクライアント装置がアプリケーションサーバと更新する場面においては、１つのアプリケーションに対して様々な種類のクライアント装置がリクエストを送信することもあり得る。例えば、同じアプリケーションに対して、人が入力した情報に基づくリクエストと、電子機器の処理に基づくリクエストとが送信される場合がある。この場合、人の操作に対しては、操作途中にセッションタイムアウトが発生しないよう、十分長いタイムアウト時間とする必要がある。一方、電子機器等のモノ（機械）の場合、機械的にリクエストに関連する処理が行われるため、タイムアウト時間は短くても問題ない。むしろ、電子機器等について発生する異常としては、機器の故障やネットワーク切断等に起因する場合が多いため、異常の早期発見のためにもセッションタイムアウト値は短い方が望ましい。

また、同じ種類のクライアント装置でも、性能の低い１０年前の装置と最新式の装置とでは、処理を行うスピードが全く異なる。そのため、リクエストを送信する機器の種類が同じであったとしても、リクエストを送信した機器の型番によってセッションタイムアウト時間を適切な値に設定することが望ましい場合もある。

このような状況に対応するために、本実施例では、リクエストの処理を実行するアプリケーションの種類だけでなく、リクエストを送信したクライアント装置の種別も踏まえて、各セッションのそれぞれに応じたセッションタイムアウト時間を設定する。タイムアウト時間管理テーブル１８０は、アプリケーション種別及びクライアント装置の種別に基づいて異なるセッションタイムアウト時間を設定した場合のセッションタイムアウト時間管理テーブルの一例である。

アプリケーション種別やクライアント装置の種別に基づいて、セッション毎に適切なセッションタイムアウト時間を設定することで、処理が実行されない状態のセッションに関するセッション格納領域より早い段階でタイムアウトによって解放することが可能となる。

図８の例において、クライアント識別情報が「CID11」で始まる識別情報に対応するクライアント装置３０は、インターネット家電等の電子機器であるものとする。また、クライアント識別情報が「CID22」で始まる識別情報に対応するクライアント装置３０は、ユーザが操作する端末装置となっているクライアント装置であるものとする。

タイムアウト時間管理テーブル１８０に示す例では、アプリケーション１に対してリクエストを送信する新型のクライアント装置（クライアント識別情報：CID1151、CID1152）については、タイムアウト時間は１０秒に設定される。一方、同じアプリケーション１に対してリクエストを送信する旧型のクライアント装置（クライアント識別情報：CID1181）については、タイムアウト時間は２分に設定される。また、アプリケーション２に対してリクエストを送信するユーザが操作するクライアント装置１（クライアント識別情報：CID2201）のタイムアウト時間は１０分に設定され、ユーザが操作する他のクライアント装置２（クライアント識別情報：CID2202）のタイムアウト時間は３０分に設定される。

アプリケーションの種別とクライアント装置の種別の両方の情報に基づいて異なるセッションタイムアウト時間を設定する場合、セッションタイムアウト時間は、セッションごとに管理することが望ましい。そのため、本実施例では、多数のクライアント装置との間で確立された複数のセッションごとに適切なセッション管理を行うために、図９に示すようなセッション管理テーブル１９０を用いてセッションの管理を行う。

なお、上述の説明ではアプリケーションの種別とクライアント装置の種別の両方の情報に基づいて異なるセッションタイムアウト時間を設定する例を説明したが、クライアント装置の種別のみに応じてセッションタイムアウト時間を設定するようにしてもよい。また、アプリケーションの種類のみに応じてセッションタイムアウト時間を設定する態様も本実施例に含まれる。

［セッション管理テーブル］
図９は、セッション管理テーブルの一例を説明する図である。セッション管理テーブル１９０は、各セッションの情報とともにセッション格納部１５３の記憶領域に格納してもよいし、セッション格納部１５３とは別にメモリ１０３中に割り当てた領域に格納しても良い。セッション管理テーブル１９０は、セッションＩＤ、アプリケーションＩＤ、クライアントＩＤ、各セッションのタイムアウト監視開始時刻の情報、セッションタイムアウト時間、順序入替制御フラグ、セッション予測処理時間の情報を含む。

セッションＩＤは、各セッションを識別するための識別情報であり、この識別情報と同じ情報が、対応するリクエストに関連付けて受付セッションＩＤ格納部１６０にも格納される。アプリケーションＩＤは、リクエストで要求された処理を行うアプリケーションの識別情報である。クライアントＩＤは、リクエストを送信するクライアント装置の識別情報である。例えば、クライアントＩＤが「CID11xx」（xは任意の文字列）で始まる場合には、電子機器であることを示し、クライアントＩＤが「CID22xx」で始まる場合には、ユーザ端末であることを示すといったネーミングルールとすることもできる。そのようなネーミングルールにすることで、容易にクライアント装置の種別を識別でき、セッションタイムアウト時間等の設定を容易に行うことが可能となる。図９の「タイムアウト時間」は複数のセッションのそれぞれに対して設定されたセッションタイムアウト時間を示す。

順序入替制御フラグが「１」の場合、セッションに関するリクエストの実行順序を入れ替えても良いことを示す。順序入替制御フラグが「０」の場合、セッションに関するリクエストの実行順序を入れ替えできないことを示す。

セッション予測処理時間は、各セッションについての処理を完了させるための予測処理時間を示したものである。このセッション予測処理時間は、同じアプリケーションＩＤとクライアントＩＤの組み合わせを有する過去のセッションの実行時間の履歴や、セッションに係るリクエストに含まれる処理の内容等に基づいて定めることができる。

具体的には、処理の操作名を含むＵＲＬ（例：http://xxx/yyy/zzz/operation1）がリクエスト含まれる場合、セッション予測処理時間は、その処理（operation1）のリクエストが送信された回数や、リクエストが送信された時間間隔等の情報等を用いて推測できる。リクエストが送信された時間間隔については、例えば、同じセッションについて複数回送信されたリクエストのタイムアウト監視開始時刻の差分から推測してもよい。また、リクエストで要求される処理の内容によっても処理時間が異なるので、リクエストに含まれる処理（operation-x）の内容と過去に同じ処理が行われた際の処理時間とを比較して、予測処理時間を推測しても良い。リクエストがセッション終了要求などの場合には、セッション予測処理時間を最も短い時間、例えば０．０１秒や０秒に設定することもできる。

セッション管理テーブル１９０に記録された情報の内、セッションＩＤ、タイムアウト監視開始時刻とタイムアウト時間は、セッションタイムアウト監視部１５４による定期的なセッションタイムアウトの監視処理で使用される。また、セッションＩＤ、順序入替制御フラグ、及びセッション予測処理時間は、キュー読出制御部１７４によるキューからのリクエストの読出し制御で使用される。これらの詳細については、図１４、図１５を用いて後述する。

［フローチャート］
次に、図１０を参照しながら、サーバ１００による情報処理方法について説明する。図１０は、（Ａ）ウェブサーバ処理、及び（Ｂ）アプリケーションサーバ処理の一例を示すフローチャートである。

ウェブサーバ１４０は、クライアント装置３０からのリクエストを受信する。ウェブサーバ１４０は、クライアント装置３０からのリクエストを受信するまで待ち続ける（Ｓ１０１でＮｏ）。ウェブサーバ１４０は、クライアント装置３０からのリクエストを受信した場合（Ｓ１０１でＹｅｓ）、受付セッションＩＤ書き込み処理を行う（Ｓ１０２）。

図１１は、図１０における受付セッションＩＤ書き込み処理（Ｓ１０２）の一例を示すフローチャートである。ウェブサーバ１４０がクライアント装置３０からリクエストを受信すると、受付セッションＩＤ書込み部１４２は、受信したリクエストに対応するセッションが新規セッションかどうかを判断する（Ｓ１２１）。具体的には、受付セッションＩＤ書込み部１４２は、受信したリクエストにセッション情報が含まれていない場合に、受信したリクエストに対するセッションは新規セッションであると判断する。また、受付セッションＩＤ書込み部１４２は、受信したリクエストがセッション開始リクエストである場合にも新規セッションと判断する。

受信したリクエストに対応するセッションが新規セッションである場合（Ｓ１２１でＹｅｓ）、リクエストに対応するセッションの識別情報がまだないため、受付セッションＩＤ書込み部１４２は、受付セッションＩＤ書込み処理を終了する。一方、受信したリクエストに対応するセッションが新規セッションでない場合（Ｓ１２１でＮｏ）、受付セッションＩＤ書込み部１４２は、リクエストに含まれるセッション識別情報を、受付セッションＩＤ格納部１６０に、リクエストに関連付けて格納し（Ｓ１２２）、受付セッションＩＤ書込み処理を終了する。図１０のＳ１０２の受付セッションＩＤ書込み処理が完了すると、ウェブサーバ１４０は、受信したリクエストをアプリケーションサーバ１５０に送信する（Ｓ１０３）。

アプリケーションサーバ１５０は、ウェブサーバ１４０からのリクエストを受信するまで待ち続け（Ｓ１１１でＮｏ）、ウェブサーバ１４０からのリクエストを受信した場合（Ｓ１１１でＹｅｓ）、アプリケーション処理の呼出しを行う（Ｓ１１２）。

図１２は、図１０におけるアプリケーション処理（Ｓ１１２）の一例を示すフローチャートである。アプリケーションサーバ１５０のリクエスト処理部１５２は、ウェブサーバ１４０からリクエストを受信すると、受信したリクエストに対応するセッションが作成済みであるかどうかを判定する（Ｓ１４１）。その際、受信したリクエストに対応するセッション識別情報が無い場合や、リクエストがセッション開始リクエストである場合、リクエスト処理部１５２は、対応するセッションが作成済みではないと判断する（Ｓ１４１でＮｏ）。セッションが作成済みでない場合（Ｓ１４１でＮｏ）、リクエスト処理部１５２は、リクエストに対応するセッションを作成し（Ｓ１４２）、作成したセッションに関連する情報をセッション格納部１５３やセッション管理テーブル１９０に格納する。

セッションが作成済みである場合（Ｓ１４１でＹｅｓ）や、Ｓ１４２でセッションを作成した後、リクエスト処理部１５２は、リクエストで要求された処理を実行する（Ｓ１４３）。リクエストで要求された処理には、クライアント装置から要求されるアプリケーションの処理だけでなく、セッション開始要求に関連する処理やセッション終了要求に関連する処理も含まれる。

リクエストがセッション終了要求である場合には（Ｓ１４４でＹｅｓ）、リクエスト処理部１５２は、セッション格納部１５３やセッション管理テーブル１９０に格納された対応するセッションの情報を削除する（Ｓ１４５）。リクエストがセッション終了要求ではない場合（Ｓ１４４でＮｏ）、図１２の処理を終了する。なお、Ｓ１４５によるセッション削除処理を行う際、一部の情報については履歴情報として、履歴情報を記録するための記憶領域に記憶するようにしてもよい。後に、セッション管理テーブル１９０のセッション予測処理時間の予測に使用するためである。

図１２のアプリケーション処理が終了すると、アプリケーションサーバ１５０は、アプリケーション処理の実行結果をウェブサーバに応答する（図１０のＳ１１３）。ウェブサーバ１４０が、アプリケーションサーバ１５０からリクエストの実行結果を受信すると（Ｓ１０４）、受付セッションＩＤ削除処理を行う（Ｓ１０５）。

図１３は、受付セッションＩＤ削除部１４３によって実行される図１０の受付セッションＩＤ削除処理（Ｓ１０５）の一例を示すフローチャートである。アプリケーションサーバ１５０で処理されたリクエストが新規リクエストである場合（Ｓ１３１でＹｅｓ）、受付セッションＩＤ格納部１６０には対応するセッション識別情報は格納されていないので、処理を終了する。一方、アプリケーションサーバ１５０で処理されたリクエストが新規リクエストでない場合（Ｓ１３１でＮｏ）、受付セッションＩＤ削除部１４３が、リクエストに対応するセッションの識別情報を受付セッションＩＤ格納部から削除し（Ｓ１３２）、受付セッションＩＤ削除処理を終了する。

受付セッション削除処理（Ｓ１０５）が終了すると、ウェブサーバ１４０は、アプリケーションサーバ１５０から受信した実行結果を、クライアント装置３０に、リクエストに対する応答として送信する（Ｓ１０６）。こうして１つのリクエストに関するウェブサーバ処理及びアプリケーションサーバ処理が実行される。アプリケーションサーバ１５０では、受信したリクエストに関する処理と並行して、セッションのタイムアウト監視処理を行う（Ｓ１１４）。

図１４は、図１０のセッションタイムアウト監視処理（Ｓ１１４）の一例を示すフローチャートである。セッションタイムアウト監視部１５４は、定期的にセッション格納部１５３に格納されたセッション情報に対応する全てのセッションについて（Ｓ１５１〜Ｓ１５７のループ）、セッションタイムアウトとなっているか否かを判定する。

まず、セッションタイムアウト監視部１５４は、セッション格納部１５３に格納されたセッション情報に対応するセッションの中から順に１つセッションを選択する（Ｓ１５１）。次に、セッションタイムアウト監視部１５４は、選択したセッションに対応するセッションのタイムアウト監視開始時刻の情報と、セッションタイムアウト時間の情報とをセッション管理テーブル１９０から取得する（Ｓ１５２）。

セッションタイムアウト監視部１５４は、Ｓ１５２で取得したタイムアウト監視開始時刻と現在時刻とに基づいて、タイムアウト監視開始時刻からの経過時間を算出する（Ｓ１５３）。算出した経過時間がＳ１５２で取得したセッションタイムアウト時間を超過していなければ（Ｓ１５４でＮｏ）、セッションタイムアウトをしていないことになるので、Ｓ１５７の処理に進む。算出した経過時間がＳ１５２で取得したセッションタイムアウト時間を超過している場合には（Ｓ１５４でＹｅｓ）、セッションタイムアウトしていることになるので、Ｓ１５５の処理に進む。

Ｓ１５５では、セッションタイムアウト監視部１５４は、セッションタイムアウトしているセッションに対応するセッション識別情報が受付セッションＩＤ格納部１６０に格納されているかどうかを判定する。対応するセッション識別情報が受付セッションＩＤ格納部１６０に格納されている場合（Ｓ１５５でＹｅｓ）、すでにセッションに対応したリクエストを受信済みであるのでセッションタイムアウトに起因するセッションの無効化はせずにＳ１５７に進む。

一方、Ｓ１５５の判定において、対応するセッション識別情報が受付セッションＩＤ格納部１６０に格納されていない場合（Ｓ１５５でＮｏ）、セッションタイムアウト監視部１５４は、該当するセッションを無効化（破棄）する処理を行う（Ｓ１５６）。Ｓ１５６の処理では、セッションタイムアウト監視部１５４は、セッション格納部１５３、セッション管理テーブル１９０、及び受付セッションＩＤ格納部１６０に格納された該当するセッションに関する情報を削除する。

本実施例では、セッションタイムアウト監視部１５４が各セッションのタイムアウトの監視を行う際に、セッションタイムアウト時間の経過だけでなく受付セッションＩＤ格納部１６０に格納対応するセッション識別情報が格納されているかどうかを判定する。このようにすることで、タイムアウト時間を経過したセッションであっても、関連したリクエストが既に受信されている場合や関連したリクエストを実行中の場合にセッションタイムアウトに起因するセッションの無効化（破棄）を抑止することが可能となる。

Ｓ１５７において、全てのセッションについてセッションタイムアウトの判定が完了した場合には処理を終了し、セッションタイムアウトの判定がまだのセッションがある場合、Ｓ１５１に戻って次のセッションを選択してＳ１５２〜Ｓ１５６の処理を行う。図１４のセッションタイムアウト監視処理が完了すると、図１０のＳ１１５の処理に進み、一定時間が経過するのを待つ。そして、再度Ｓ１１４に進んで定期的なセッションタイムアウト監視処理を行う。

図１０のＳ１１４、Ｓ１１５及び図１４の処理では、セッションタイムアウト監視部１５４による定期的なセッションタイムアウト監視処理について説明した。しかし、セッションタイムアウト監視部１５４によるセッションタイムアウト監視処理は、定期的な監視処理に限られず、管理サーバ１３０からの要求があった場合やその他の特定のタイミングで行うようにしても良い。

図１５は、キュー読出し制御処理の一例を示すフローチャートである。図７に示されるキューイング制御部１７０のキュー読出制御部１７４は、順序保証キュー１７１及び順序可変キュー１７２に格納されたリクエストの読出し処理を図１５のフローに沿って行う。前述の通り、キューイング処理部１７０は、図３や図５に示されたキュー１５１やキュー１４１の具体的な一実施態様として実装できるが、ここでは説明の便宜上、アプリケーションサーバ１５０内のキュー１５１に実装する場合を例に説明する。

順序保証キュー１７１、順序可変キュー１７２は、アプリケーションサーバ１５０のリクエスト処理部１５２が処理を開始できるようになるまでの間、リクエストを保持するものである。そのため、キュー読出制御部１７４は、リクエスト処理部１５２が次のリクエストを処理できない期間は（Ｓ１６１でＮｏ）、順序保証キュー１７１、順序可変キュー１７２からのリクエストの読出しを行わずに待機する。ここで、リクエスト処理部１５２が次のリクエストを処理できる状態になったか否かの判定（Ｓ１６１）は、キュー読出制御部１７４がリクエスト処理部１５２の実行状態を監視するようにしてもよいし、リクエスト処理部１５２からの要求を待つようにしてもよい。

リクエスト処理部１５２が次のリクエストを処理できるようになった場合（Ｓ１６１でＹｅｓ）、キュー読出制御部１７４は、リクエストを読み出すキューを決定する（Ｓ１６２）。

キュー読出制御部１７４が、順序保証キュー１７１と順序可変キュー１７２のいずれから読み出すのかを決定する方法として、例えば、以下の方法のいずれか、またはそれらを組み合わせて用いることができる。

（１）２つのキューから交互に読み出す方法
順序保証キュー１７１と順序可変キュー１７２が１つずつの場合には、キュー読出制御部１７４がリクエスト処理部１５２にリクエストを出力するにあたって、それぞれのキューから交互にリクエストを読み出すようにすることができる。また、複数の順序保証キュー１７１と複数の順序可変キュー１７２がある場合には、読み出すキューをラウンド・ロビン方式等のルールに基づいて決定することもできる。

（２）それぞれのキューに格納されたリクエストの数で決定する方法
順序保証キュー１７１と順序可変キュー１７２のそれぞれに格納されたリクエストの数に対応した配分に沿って、順序保証キュー１７１と順序可変キュー１７２のどちらからリクエストを読み出すかを決定してもよい。各キュー１７１、１７２が複数存在する場合にも、それぞれのキューに格納されたリクエスト数の配分に応じて読み出すキューを決定してもよい。

（３）人の操作によるリクエストと、機器からのリクエストの違いに応じて決定する方法
人の操作によるリクエストの場合、リクエストの処理が遅れると操作している人が待たされることになる。そのため、順序保証キュー１７１、順序可変キュー１７２のそれぞれに対してさらに人の操作によるリクエストを格納するキューと、機器（人の操作によらない電子機器）から受信したリクエストを格納するキューを設け、人の操作によるリクエストが格納されているキューから優先的にリクエストを読み出すことも考えられる。

（４）セッション格納部１５３の記憶領域の残量に応じて決定する方法
セッション格納部１５３の記憶領域の残量がある閾値以下になった場合に、順序可変キュー１７２から優先的にリクエストを読み出すようにしてもよい。そのようにすることで、すぐに処理が完了するセッションに関するリクエストを早く処理することができ、セッション情報を記憶するメモリの記憶領域の空き容量をより速い段階で増やすことができるようになるためである。

図１５のＳ１６３では、読出しキュー決定処理（Ｓ１６２）で決定されたキューが順序可変キュー１７２であるか否かが判定される。読出しキュー決定処理（Ｓ１６２）において順序可変キュー１７２から読み出すと決定された場合（Ｓ１６３でＹｅｓ）、Ｓ１６４の処理に進む。Ｓ１６４では、キュー読出制御部１７４は、順序可変キュー１７２から入力順とは異なる順序でリクエストを読み出し、読み出したリクエストをリクエスト処理部１５２に出力する。

読出しキュー決定処理（Ｓ１６２）において順序可変キュー１７２からのリクエストの読み出しは行わず順序保証キュー１７１からリクエストを読み出すと決定された場合（Ｓ１６３でＮｏ）、Ｓ１６５の処理に進む。Ｓ１６５では、キュー読出制御部１７４は、順序保証キュー１７１に格納された順に、リクエストを読み出し、読み出したリクエストをリクエスト処理部１５２に出力する。

Ｓ１６４において、順序可変キュー１７２から入力順とは異なる順序でリクエストを読み出す順序を決定する方法としては、例えば以下のいずれかの方法、あるいはこれらを組み合わせた方法を用いることができる。

（１）セッションの予測処理時間の小さい順にリクエストを読み出す方法
順序可変キュー１７２に格納されたリクエストのそれぞれに対応するセッションの予測処理時間を比較するにあたり、キュー読出制御部１７４は、セッション管理テーブル１９０に格納された対応するセッションの項目からセッション予測処理時間を読み出す。キュー読出制御部１７４は、読み出した各セッションの予測処理時間をソートし、予測処理時間の最も短いセッションに対応するリクエストを順序可変キュー１７２から読み出す。

（２）緊急度の高い順にリクエストを読み出す方法
受信したリクエストの内容や、要求された処理を実行するアプリケーションの種類に基づいて、リクエストの緊急度を判定し、緊急度の高いリクエストが含まれている場合には、その緊急度の高いリクエストが早く読み出されるように順序制御しても良い。緊急度の高いリクエストを早く読み出せるように順序制御することで、障害が発生した場合等の緊急のリクエストに迅速に処理して応答できるようになるためである。

なお、緊急度の高いリクエストの間接的な判定方法として、過去の履歴から把握できるリクエストの受信頻度が低いリクエストが先に読み出されるように順序制御しても良い。発生頻度の低いリクエストは緊急度の高いリクエストである可能性があるためである。

次に、キュー読出制御部１７４が順序可変キュー１７２からリクエストを読み出す制御方法については、例えば以下のいずれかの方法、あるいはこれらを組み合わせた方法により実装することができる。

（１）予め順序可変キュー１７２のリクエスト格納位置を入れ替える方法
キュー読出制御部１７４が順序可変キュー１７２からリクエストを読み出す処理を行う前に、予め順序可変キュー１７２のリクエスト格納位置を入れ替えておく実装とすることができる。そうすることで、順序可変キュー１７２からの読出しが決定された場合に（Ｓ１６３でＹｅｓ）、キュー読出制御部１７４は、単に順序可変キュー１７２の先頭からリクエストを読み出せばよく、読み出すべきリクエストをすぐに読み出せるようになる。

（２）順序可変キュー１７２から読み出す際のポインタの並び順を予め決定する方法
順序可変キュー１７２からのリクエストを読み出す際の他の実装例として、順序可変キュー１７２からの読出しポインタ（リクエスト格納アドレス）をリクエストに対応する予測処理時間でソートして、ポインタテーブルに格納してもよい。この場合、キュー読出制御部１７４が順序可変キュー１７２からリクエストを読み出す場合に、ポインタテーブルの先頭に格納されたポインタを用いてリクエストを読み出すことが可能となる。

（３）リクエスト格納位置の入替制御タイミング
順序可変キュー１７２のリクエスト格納位置の入替は、順序可変キュー１７２にリクエストが格納されるタイミング、又は、リクエストを読み出すタイミングで行っても良い。リクエストを順序可変キュー１７２に格納又は読み出すタイミングで、リクエストの順序を入れ替えることで、最新のリクエスト受信状況に応じた適切な順序でリクエストを読み出すことが可能となるからである。

また、定期的なタイミングで、リクエストの並び替えを行うようにしても良い。定期的なタイミングでリクエストの並び替えを行うことによって、リクエストの並べ替える順序を判定する処理の負荷を軽減できるからである。

［実施例２の効果］
実施例２では、受付セッションＩＤ格納部１６０を設け、セッションタイムアウトの監視処理を行う際にセッションタイムアウトを検出したセッションに対応する識別情報が受付セッションＩＤ格納部１６０に格納されているか否かを判定する。このようにすることで、実行待ちのリクエストも考慮したセッションタイムアウトによるセッションの無効化制御がより容易に行うことができるようになる。

また、リクエストを格納するキューとして、順序保証キュー１７１と順序可変キュー１７２とを設け、順序を保証する必要のないリクエストの読出し順序を入れ替えることで、より効率的にリクエストの処理を実行できるようになる。さらに、実施例２では、アプリケーション種別やクライアント装置の種別に基づいて、セッション毎に適切なセッションタイムアウト時間を設定する。そうすることで、処理が実行されない状態のセッションに関するセッション格納領域を、より早い段階でタイムアウトによって解放することが可能となる。

以上、本発明の好ましい実施例について詳述したが、本発明は特定の実施例に限定されるものではなく、以下のような種々の変形や変更が可能である。

（１）複数のサーバ１００を用いた分散処理
１つのウェブサーバ１４０が受け付けたリクエストを、複数のサーバ１００のハードウェア上で実行されるアプリケーションサーバ１５０を用いて分散処理することも可能である。その際、リクエストの受信数に応じて、使用するサーバ１００の台数を動的に変更し、使用していないサーバ１００の電源供給を止めておくといった制御を行うこともできる。そのように制御することで、リクエストを処理するために必要となるシステムのスループットを確保しつつ、システムの低消費電力化を図ることができるためである。

（２）アプリケーションサーバをサーブレットコンテナ等で実現
アプリケーションサーバ１５０の機能を、各サーバ１００上で稼働させた仮想マシン環境上で動作するサーブレットコンテナ等で実現することもできる。そのようにすることで、サーバ１００のメンテナンス時や低消費電力化のための制御を行う際に、アプリケーションサーバ１５０の処理を他のサーバ１００にライブマイグレーションによって移動させることが可能となる。

（３）セッション格納部１５３のセッション格納領域の分割
セッションの情報を格納するセッション格納部１５３の格納領域を、順序保証をするリクエストや人の操作によるリクエストに関連するセッション用の領域と、他のリクエストに関連するセッション用の領域とに分割するようにしてもよい。そのようにすることで、順序保証をしなくてもよい電子機器からのリクエストを一時期に大量に受信した場合等においても、順序保証をする必要のあるリクエストや人の操作によるリクエストにそれまでと同様に処理することが可能となる。

（４）その他
前述したクライアント装置３０から受信したリクエストを処理するウェブサーバ１４０やアプリケーションサーバ１５０の処理を実行させるプログラムをコンピュータ読み取り可能な記録媒体に記憶しておくことができる。記録媒体としては、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどを使用できる。磁気ディスクにはＨＤＤなどが含まれる。光ディスクには、ＣＤ、ＣＤ−Ｒ（Recordable）／ＲＷ（Rewritable）、ＤＶＤおよびＤＶＤ−Ｒ／ＲＷなどが含まれる。

なお、本発明に係るプログラムの流通は、前記記録媒体による流通したものに限られず、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク等を経由して伝送され、ＨＤＤ等の記録媒体に格納されて使用されるものも含まれる。

１０：情報処理システム
２０：ネットワーク
３０：クライアント装置
１００、１００−１〜１００−Ｎ：サーバ
１０１、１０１Ａ、１０１Ｂ、１０１Ｃ、１０１Ｄ：ＣＰＵ
１０２：入出力装置インタフェース回路
１０３：メモリ
１０４：ネットワークインタフェース回路
１０５：ＤＢサーバインタフェース回路
１０６：ローカルバスインタフェース回路
１０７：ハードディスクドライブ
１０８：内部バス
１１０：ＤＢサーバ
１２０：ネットワークＳＷ
１３０：管理サーバ
１３１：ローカルバス
１４０：ウェブサーバ
１４１：キュー
１４２：受付セッションＩＤ書込み部
１４３：受付セッションＩＤ削除部
１５０：アプリケーションサーバ
１５１：キュー
１５２：リクエスト処理部
１５３：セッション格納部
１５４：セッションタイムアウト監視部
１６０：受付セッションＩＤ格納部
１７０：キューイング処理部
１７１：順序保証キュー
１７２：順序可変キュー
１７３：リクエスト種別判定部
１７４：キュー読出制御部
１８０：タイムアウト時間管理テーブル
１９０：セッション管理テーブル

Claims (10)

1. 複数のクライアント装置からのリクエストを受信するリクエスト受付部と、
   前記複数のクライアント装置と通信を行うために確立された複数のセッションの情報を記憶するセッション情報記憶部と、
   前記リクエスト受付部が受信した複数のリクエストのうち、処理が開始されないリクエストを一時的に記憶するリクエスト記憶部と、
   前記セッション情報記憶部にセッションの情報が記憶された複数のセッションのうち、セッションに対応するリクエストの処理が実行されていない状態で経過した経過時間が予め定められたタイムアウト時間を経過したセッションを検出するタイムアウト検出部と、
   前記タイムアウト検出部によって前記経過時間が前記タイムアウト時間を経過したと検出されたセッションについて、当該セッションに対応するクライアント装置から受信したリクエストが前記リクエスト記憶部に格納されていることに応じて、前記タイムアウト時間の経過に起因する当該セッションの無効化を抑止する制御部と、
   を備えることを特徴とする情報処理システム。
   
2. 前記制御部は、前記タイムアウト検出部によって前記経過時間が前記タイムアウト時間を経過したと検出されたセッションについて、当該セッションに対応するクライアント装置から受信したリクエストが前記リクエスト記憶部に格納されていない場合、当該セッションの無効化を行う、
   ことを特徴とする請求項１記載の情報処理システム。
   
3. 受信したリクエストの処理が完了するまでの間、該リクエストに対応するセッションの識別情報を記憶する識別情報記憶部をさらに備え、
   前記リクエスト受付部は、前記クライアント装置からのリクエストを受信すると、受信したリクエストに対応するセッションの識別情報を前記受信したリクエストに関連付けて前記識別情報記憶部に格納し、
   前記制御部は、前記タイムアウト検出部によって前記経過時間が前記タイムアウト時間を経過したと検出されたセッションについて、当該セッションの識別情報が前記識別情報記憶部に記憶されていることに応じて当該セッションの無効化を抑止する、
   ことを特徴とする請求項１記載の情報処理システム。
   
4. 前記リクエスト受付部は、前記識別情報記憶部に記憶した識別情報に対応するリクエストの処理が完了するごとに、対応するセッションの識別情報を前記識別情報記憶部から削除する、
   ことを特徴とする請求項３に記載の情報処理システム。
   
5. 前記タイムアウト検出部は、所定の期間ごとに、終了していない全てのセッションについて、各セッションについての前記経過時間が前記タイムアウト時間を経過したセッションを検出し、
   前記制御部は、前記タイムアウト検出部によって前記経過時間が前記タイムアウト時間を経過したと検出されたセッションについて、対応するセッションの識別情報が前記識別情報記憶部に記憶されていない場合に、当該セッションを無効化する、
   ことを特徴とする請求項３又は４に記載の情報処理システム。
   
6. 前記リクエスト記憶部は、
   受信した順に実行するリクエストを記憶する第１リクエスト記憶部と、
   実行する順序を変更可能なリクエストを記憶する第２リクエスト記憶部と、を備え、
   前記制御部は、
   前記第２リクエスト記憶部に記憶した複数のリクエストのそれぞれに対応するセッションに関する処理に要する見積もり時間を算出し、
   前記第１リクエスト記憶部に記憶したリクエストについては、リクエストを受信した順に実行し、
   前記第２リクエスト記憶部に記憶したリクエストについては、前記見積もり時間が短いセッションに関するリクエストから順に実行する、
   ことを特徴とする請求項１に記載の情報処理システム。
   
7. 前記セッション情報記憶部は、各リクエストを送信したクライアント装置の識別情報に対応付けて、各クライアント装置の種類に応じて異なるタイムアウト時間を記憶し、
   前記タイムアウト検出部は、前記セッション情報記憶部に記憶された複数のセッションについて、前記セッション情報記憶部に記憶された各セッションに対応するタイムアウト時間と比較することによって、各セッションのタイムアウトを検出する、
   ことを特徴とする請求項１記載の情報処理システム。
   
8. 前記タイムアウト時間は、
   前記クライアント装置が外部入力を受信することに応じて前記リクエストを発行するクライアント装置である場合には、前記タイムアウト時間は前記外部入力の間隔に応じた第１の時間に設定され、
   前記クライアント装置が外部入力を受信することに係わりなく前記リクエストを発行するクライアント装置である場合には、前記タイムアウト時間は前記第１の時間よりも短い第２の時間に設定される、
   ことを特徴とする請求項３記載の情報処理システム。
   
9. 複数のクライアント装置からのリクエストを受信し、
   前記複数のクライアント装置から受信した複数のリクエストのうち、処理が開始されないリクエストを、一時的にリクエストを記憶するリクエスト記憶部に格納し、
   前記複数のクライアント装置と通信を行うために確立された複数のセッションの情報がセッション情報記憶部に記憶された複数のセッションのうち、セッションに対応するリクエストの処理が実行されていない状態で経過した経過時間が予め定められたタイムアウト時間を経過したセッションを検出し、
   前記経過時間が前記タイムアウト時間を経過したと検出されたセッションについて、当該セッションに対応するクライアント装置から受信したリクエストが前記リクエスト記憶部に格納されていることに応じて、前記タイムアウト時間の経過に起因する当該セッションの無効化を抑止する、
   処理をコンピュータに実行させることを特徴とする情報処理方法。
   
10. コンピュータに、
    複数のクライアント装置からのリクエストを受信し、
    前記複数のクライアント装置から受信した複数のリクエストのうち、処理が開始されないリクエストを、一時的にリクエストを記憶するリクエスト記憶部に格納し、
    前記複数のクライアント装置と通信を行うために確立された複数のセッションの情報がセッション情報記憶部に記憶された複数のセッションのうち、セッションに対応するリクエストの処理が実行されていない状態で経過した経過時間が予め定められたタイムアウト時間を経過したセッションを検出し、
    前記経過時間が前記タイムアウト時間を経過したと検出されたセッションについて、当該セッションに対応するクライアント装置から受信したリクエストが前記リクエスト記憶部に格納されていることに応じて、前記タイムアウト時間の経過に起因する当該セッションの無効化を抑止する、
    処理を実行させるためのプログラム。

Images