JP2017037539A - サーバ制御プログラム、サーバ制御方法およびサーバ制御装置 - Google Patents

Abstract

【課題】初期化後のアプリケーションプログラムに対するリクエストに応じたサーバの応答性能低下を抑制することを目的とする。【解決手段】サーバ制御装置は、サーバで実行されるアプリケーションプログラムの初期化が完了した旨の通知に応じて、前記サーバが実行する前記アプリケーションプログラムの実行単位の数を取得する取得部と、前記サーバで実行される全ての前記実行単位の動作を停止する指示を送信する停止指示部と、取得された前記実行単位の数と少なくとも同数のリクエストを前記サーバに送信する送信部と、前記送信部が前記リクエストを送信した後に、停止された前記全ての実行単位の動作を再開させる指示を前記サーバに送信する再開指示部と、を含む。【選択図】図２

Description

本発明は、サーバ制御プログラム、サーバ制御方法およびサーバ制御装置に関する。

クラウドサービスの利用形態の１つとして、サービス提供側のサーバで動作するアプリケーションを利用者側のクライアントが利用する形態がある。サーバで動作するアプリケーションは、修正や変更等が行われることがある。この場合、アプリケーションの初期化が行われる。

関連する技術として、プロセスが初期化のときに、またはアプリケーションマネージャからのコマンドに応答して、コンテキストをダイナミックに再初期化するように、更新されたマスタウォームアッププログラムを実行する技術が提案されている。

また、アクティブな制御ユニットにおいて複製されるべき能動的なプロセスまたは大きなプロセスグループの動作を一時的に凍結すると同時に、アクティブな制御ユニットの他のプロセスを動作状態に保持する技術が提案されている。

また、プロセスの切り替えをなくし、オペレーティングシステムのプロセスやアプリケーションプログラムをシステムで唯一つ用意したプロセス配下のスレッドとして動作させる技術が提案されている（特許文献１乃至３を参照）。

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

アプリケーション（アプリケーションプログラム）の初期化が行われると、アプリケーションは実行可能な状態になる。

ただし、アプリケーションの初回実行時に、アプリケーションの実行に使用される情報がロードされていないこと等を要因として、クライアントから送られたリクエストに対して、アプリケーションがレスポンスを返すときのサーバの応答性能が低下する。

１つの側面として、本発明は、初期化後のアプリケーションプログラムに対するリクエストに応じたサーバの応答性能低下を抑制することを目的とする。

１つの態様では、サーバ制御プログラムは、サーバで実行されるアプリケーションプログラムの初期化が完了した旨の通知に応じて、前記サーバが実行する前記アプリケーションプログラムの実行単位の数を取得し、前記サーバで実行される全ての前記実行単位の動作を停止する指示を送信し、取得された前記実行単位の数と少なくとも同数のリクエストを前記サーバに送信し、停止された前記全ての実行単位の動作を再開させる指示を前記サーバに送信する、処理をコンピュータに実行させる。

１つの側面によれば、初期化後のアプリケーションプログラムに対するリクエストに応じたサーバの応答性能低下を抑制することができる。

システム構成の一例を示す図である。 サーバ制御装置の一例を示す機能ブロック図である。 サーバ管理テーブルの一例を示す図である。 アプリ管理テーブルの一例を示す図である。 制御側スレッド管理テーブルの一例を示す図である。 サーバ側スレッド管理テーブルの一例を示す図である。 実施形態の処理の流れの一例を示すフローチャートである。 初期化後制御の処理の流れの一例を示すフローチャート（その１）である。 初期化後制御の処理の流れの一例を示すフローチャート（その２）である。 初期化後制御の処理の流れの一例を示すフローチャート（その３）である。 スレッド停止処理の流れの一例を示すフローチャートである。 対象スレッド停止処理の流れの一例を示すフローチャートである。 スレッド再開処理の流れの一例を示すフローチャートである。 対象スレッド再開処理の流れの一例を示すフローチャートである。 実行状況確認処理の流れの一例を示すフローチャートである。 対象スレッド実行状況確認処理の流れの一例を示すフローチャート（その１）である。 対象スレッド実行状況確認処理の流れの一例を示すフローチャート（その２）である。 全スレッド再開処理の一例を示すフローチャートである。 サーバ制御装置のハードウェア構成の一例を示す図である。

＜システムの一例＞
以下、図面を参照して、実施形態のシステムの一例について説明する。実施形態のシステム１は、クライアント２と複数のサーバ３とサーバロードバランシング４とサーバ制御装置５とデータベース６とを含む。

図１では、クライアント２は１つの場合を例示しているが、クライアント２の数は複数であってもよい。また、図１では、複数のサーバ３（サーバ３−１およびサーバ３−２）を例示しているが、サーバ３の数は１つであってもよいし、３つ以上であってもよい。

サーバ３は、物理的なコンピュータであってもよいし、仮想的なコンピュータであってもよい。例えば、サーバ３−１およびサーバ３−２は、１台の物理的なコンピュータで実現される仮想的なコンピュータであってもよい。

サーバロードバランシング４は、Server Load Balancing(SLB)とも称され、クライアント２からのリクエストを各サーバ３に分散出力する。各サーバ３で動作するアプリケーションプログラム（以下、単にアプリケーションと称する）は、受信したリクエストに対するレスポンスをクライアント２に返信する。

サーバ制御装置５は、各サーバ３の制御を行う。実施形態のサーバ制御装置５は、サーバ３で動作するアプリケーションが初期化された後、クライアント２からアプリケーションに送信されたリクエストに応じたサーバ３の応答性能低下を抑制する制御を行う。

データベース６は、各サーバ３で動作するアプリケーションが使用する各種の情報を記憶する。

次に、サーバ３について説明する。サーバ３は、アプリサーバ１１と実行部１２とサブマネージャ１３とログ記憶部１４とサーバ側テーブル記憶部１５とを含む。アプリサーバ１１は、アプリケーションサーバである。

アプリサーバ１１は、サーバ３で動作するアプリケーションを管理する。実施形態では、アプリケーションは複数のスレッドに分割される。図１の例では、アプリケーションＡｐｐ１のスレッド１番とスレッド２番とが示されている。

スレッドは、アプリケーションの実行単位の一例である。アプリケーションの実行単位は、例えばプロセスであってもよい。複数のスレッドや複数のプロセスは、並列実行されてもよい。アプリケーションはプログラムにより実現されるため、スレッドやプロセス等の実行単位もプログラムにより実現される。

アプリサーバ１１は、クライアント２から受信したリクエストをアプリケーションの各スレッドに振り分ける。また、アプリサーバ１１は、サーバ制御装置５から受信したリクエストをアプリケーションの各スレッドに振り分ける。

実行部１２では、リクエストに応じて、アプリケーションＡｐｐ１の各スレッドが実行される。実行部１２は、アプリケーションＡｐｐ１だけでなく、複数のアプリケーションの各スレッドを含んでもよい。

サブマネージャ１３は、アプリサーバ１１やアプリケーションの各スレッドに対して所定の制御を行う。また、サブマネージャ１３は、ログ記憶部１４に記憶される情報を参照する。また、サブマネージャ１３は、サーバ側テーブル記憶部１５が記憶するテーブルに所定の情報を記憶し、記憶された情報を参照する。

実施形態では、アプリサーバ１１と実行部１２とサブマネージャ１３とは、サーバ３で動作するプログラムにより、その機能が実現される。

ログ記憶部１４は、アプリサーバ１１が管理する各アプリケーションに関するログ（以下、アプリサーバログと称する）またはアプリケーションに関するログ（以下、アプリログ）を記憶する。なお、ログが使用されない場合、サーバ３はログ記憶部１４を含まなくてもよい。

サーバ３で実行されるアプリケーションは、修正や更新等が行われることがある。修正や更新されるアプリケーションのデータはパッチとも称される。アプリケーションが修正や更新されると、サーバ３はアプリケーションを初期化（イニシャライズ）する。この初期化により、該アプリケーションは実行可能な状態になる。

例えば、アプリケーションの修正や更新等を行うための手法の１つとして、ローリングアップデートと呼ばれる手法がある。ローリングアップデートでは、複数のサーバ３のうち１台のサーバ３を離脱させて、離脱したサーバ３で動作するアプリケーションに対して修正や更新等が行われる。

これにより、複数のサーバ３により実現されるサービスの運用を停止させることなく、アプリケーションの修正や更新等が行われる。修正や更新されたアプリケーションは、サーバ３により初期化されて、実行可能な状態になる。

また、サーバ３が起動されるとき（例えば、サーバ３の電源がＯＮになったとき）にも、該サーバ３で動作するアプリケーションの初期化が行われる。アプリケーションが初期化され、且つ該アプリケーションが実行されていない場合、該アプリケーションが使用する情報（例えば、アプリケーションのプログラムコード等）はロードされていない。

また、アプリケーションが初期化され、且つ該アプリケーションが実行されていない場合、他のリソースとの接続が確立されていない。この場合、例えば、サーバ３とデータベース６との接続が確立していない。

このため、初期化後のアプリケーションが、クライアント２からのリクエストに応じて、最初（初回）に実行される場合、上記の情報をロードする処理や接続の確立等が行われるため、所定の時間がかかる。このため、クライアント２から送られたリクエストに対するサーバ３の応答性能が低下する。

クライアント２は、サーバ３にアプリケーションの実行のリクエストを送信する。アプリサーバ１１は、受信したリクエストをアプリケーションの各スレッドに振り分ける。これにより、各スレッドが実行される。

このとき、アプリケーションが初期化後、且つ未実行である場合、該アプリケーションに対するリクエストに応じたサーバ３の応答性能は低下しているため、クライアント２からのリクエストに対するレスポンス速度が低下する。

実施形態では、サーバ制御装置５が、初期化後、且つ未実行のアプリケーションが動作するサーバ３に対して所定の制御（以下、初期化後制御と称する）を行うことで、サーバ３の応答性能低下を抑制する。初期化後制御は、ウォームアップ制御とも称される。

＜サーバ制御装置の一例＞
次に、図２を参照して、サーバ制御装置５について説明する。サーバ制御装置５は、主制御部２１とスレッド数取得部２２と停止指示部２３とリクエスト送信部２４と判定部２５と再開指示部２６と制御側テーブル記憶部２７と通信部２８とを含む。

主制御部２１は、サーバ制御装置５の全体的な制御を行う。スレッド数取得部２２は、サーバ３のサブマネージャ１３から、初期化後制御の対象となるアプリケーションのスレッド数を取得する。スレッド数取得部２２は、実行単位数取得部の一例である。

停止指示部２３は、初期化後制御の対象となるアプリケーションの全てのスレッドの動作を停止（サスペンド）させる指示（動作停止指示）をサブマネージャ１３に送信する。サーバ３のサブマネージャ１３は、この動作停止指示に基づいて、アプリケーションの各スレッドの動作を停止させる。これにより、各スレッドは実行を停止する。

リクエスト送信部２４は、スレッド数取得部２２が取得したスレッド数と少なくとも同数のリクエストをサーバ３に送信する制御を行う。送信されるリクエストは、例えばダミーリクエストであってもよい。リクエスト送信部２４は、送信部の一例である。

判定部２５は、初期化後制御を行うための所定の判定を行う。再開指示部２６は、停止している全てのスレッドの動作を再開（レジューム）させる指示（動作再開指示）をサブマネージャ１３に送信する。

サーバ３のサブマネージャ１３は、動作再開指示に基づいて、停止中の各スレッドの動作を再開させる。サブマネージャ１３は、例えばサーバ３のＯＳの機能を利用して、各スレッドの動作を再開させる。

制御側テーブル記憶部２７は、初期化後制御を行うために参照される各種テーブルを記憶する。通信部２８は、スレッド数取得部２２、停止指示部２３、リクエスト送信部２４および再開指示部２６の制御により、サーバ３と通信を行う。

＜各種テーブルの一例＞
次に、各種テーブルの一例について説明する。図３は、サーバ制御装置５の制御側テーブル記憶部２７に記憶されるサーバ管理テーブルの一例を示している。サーバ管理テーブルは、サーバ制御装置５が制御の対象とする複数のサーバ３を管理するためのテーブルである。

図３の例のサーバ管理テーブルは、サーバＩＤとＩＰアドレスとアプリＩＤとサーバ状態とスレッド数確認と全スレッド数と機能ＩＤと停止方法と確認方法と制御状態との項目を含む。ＩＤはIdentificationの略称であり、ＩＰはInternet Protocolの略称である。

サーバＩＤは、サーバ３を識別する識別子である。ＩＰアドレスは、サーバＩＤに対応するサーバ３のＩＰアドレスを表す。アプリＩＤは、アプリケーションを識別する識別子である。サーバ状態は、サーバ３の状態を表す。

図３の例において、「停止中」はサーバ３が停止している状態であることを表す。「起動途中」はサーバ３が起動中であり、初期化が完了していない状態であることを表す。「制御中」は、サーバ３が初期化後制御を行っていることを表す。「運用中」は、サーバ３が運用中であることを表す。

スレッド数確認は、各サーバ３で動作するアプリケーションのスレッド数を確認する方法を表す。図３の例において、ps(pat)はオペレーティングシステムのプロセス一覧を取得した上で該当するスレッドを指定したパターンと一致するか判定することで、スレッド数を確認することを示す。スレッド数を取得する方法は、他の方法であってもよい。全スレッド数は、アプリＩＤで特定されるアプリケーションの機能ごとの全スレッドの数を表す。

機能について説明する。機能ＩＤは、アプリケーションに含まれる機能を特定する識別子である。実施形態では、アプリケーションはＷｅｂアプリケーションであり、該Ｗｅｂアプリケーションには複数の機能が含まれているものとする。

なお、アプリケーションは、Ｗｅｂアプリケーションには限定されない。また、アプリケーションに含まれる機能の数は１つであってもよい。

例えば、図３の例において、「toppage」はＷｅｂアプリケーションのトップページを表示する機能である。「loginpage」はログイン画面を表示する機能である。例えば、「authentication」は認証を行う機能である。

図３の例に示すように、アプリＩＤで特定されるアプリケーションのスレッドは、アプリケーションの各機能を実行するスレッドでもある。従って、図３の例において、アプリＩＤで特定されるスレッド数が１０の場合、各機能を実行するスレッド数も１０になる。

停止方法は、スレッドの動作を停止させる方法である。図３の例の「sigstop」はオペレーティングシステムにスレッド停止を指示することにより、スレッドを停止させる手法を表している。スレッドの動作を停止させる方法は、他の方法であってもよい。

確認方法は、スレッドが実行しているかを判定する手法を表す。図３の例において、「cpuload(30ms)」は、Central Processing Unit(CPU)の負荷の増分に基づいて、スレッドが実行しているかを確認する方法であることを表している。「cpuload(30ms)」の例では、ＣＰＵ負荷の増分が閾値（以下、負荷閾値と称する）である「３０ｍｓ」を超えているかに基づいて、スレッドが実行しているかが確認される。

また、「syscall(300回)」は、スレッドによるシステムコールの発行数が閾値（以下、発行数閾値と称する）である「３００回」を超えているかに基づいて、スレッドが実行しているかが確認される。

制御状態は、実施形態の初期化後制御の実行状況を表す。「完」は、機能ＩＤで特定される機能について、初期化後制御が完了したことを表す。「実行中」は、機能ＩＤで特定される機能について、初期化後制御が行われていることを表す。「未」は、機能ＩＤで特定される機能について、初期化後制御が行われていないことを表す。

例えば、サーバ制御装置５の主制御部２１は、実施形態の初期化後制御が完了したことを認識したときに、制御状態を「完」に設定してもよい。また、主制御部２１は、実施形態の初期化後制御を開始したが、まだ完了していないことを認識したときに、制御状態を「実行中」にしてもよい。実施形態では、１つのサーバ３で「実行中」になる機能は１つである。

次に、図４の例を参照して、アプリ管理テーブルの一例について説明する。アプリ管理テーブルは、制御側テーブル記憶部２７に記憶される。アプリ管理テーブルは、アプリＩＤと機能ＩＤとプロトコルとポートとＵＲＬとＢＯＤＹと応答との項目を含む。

プロトコルは、機能ＩＤで特定される機能のプロトコルを表す。ポートは、機能ＩＤで特定される機能のポート番号を表す。Uniform Resource Locator(URL)は、機能ＩＤで特定される機能のＵＲＬを表す。

ＢＯＤＹは、機能ＩＤで特定される機能に関する情報を表す。応答は、機能ＩＤで特定される機能に対して、期待する応答が何かを表す。図４の例の場合、応答は全て単に成功したという応答が返ることを期待しているが、特定の内容を含む応答を期待する場合や、失敗という応答を期待する場合もある。

次に、図５の例を参照して、アプリ管理テーブルの一例について説明する。制御側スレッド管理テーブルは、制御側テーブル記憶部２７に記憶される。制御側スレッド管理テーブルは、サーバＩＤとアプリＩＤと全スレッド数と機能ＩＤと実行済スレッド数と送信済スレッド数との項目を含む。

実行済スレッド数は、機能ＩＤで特定される機能のスレッドのうち、サーバ制御装置５が送信したリクエストを実行したスレッドの数を表す。送信済みリクエスト数は、サーバ制御装置５が、初期化後制御の対象となるアプリケーションを管理するアプリサーバ１１に対して送信したリクエスト数を表す。

初期化後制御が行われている間、制御側スレッド管理テーブルの実行済スレッド数および送信済みリクエスト数の値は随時更新されていく。

次に、図６の例を参照して、サーバ側スレッド管理テーブルの一例について説明する。サーバ側スレッド管理テーブルは、サーバ３のサーバ側テーブル記憶部１５に記憶される。サーバ側スレッド管理テーブルは、アプリＩＤとスレッドＩＤとスレッド状態と実行確認との項目を含む。

スレッドＩＤは、スレッドを特定する識別子である。スレッド状態は、スレッドＩＤで特定されるスレッドが実行中であるか、または停止中（サスペンド中）であるかを表す。実行確認は、スレッドＩＤで特定されるスレッドが、サーバ制御装置５が送信したリクエストを実行したかを表す。

実行確認が「未」であれば、スレッドがリクエストを実行したことが確認されていないことを表す。「実行済み」であれば、スレッドがリクエストを実行したことが確認されたことを表す。

＜実施形態の処理の流れの一例を示すフローチャート＞
次に、図７のフローチャートを参照して、実施形態の処理の一例について説明する。サーバ制御装置５の主制御部２１は、サーバ３に対して、サブマネージャ１３の動作を開始する指示（動作開始指示）を送信する（ステップＳ１）。

この動作開始指示に基づいて、サーバ３のサブマネージャ１３は動作を開始する。サブマネージャ１３の動作が開始すると、サブマネージャ１３が保持している情報は初期値に設定される。

上述したように、サブマネージャ１３は、サーバ３で動作するプログラムである。よって、サーバ制御装置５は、動作開始指示を送信するときに、サーバ３に新たにサブマネージャ１３を生成する制御を行ってもよい。

スレッド数取得部２２は、アプリケーションのスレッド数を含むスレッド情報をサブマネージャ１３から取得する（ステップＳ２）。

例えば、サブマネージャ１３は、スレッド数取得部２２からの取得要求に応じて、サーバ３のＯＳの機能を使用して、アプリケーションのスレッド数を認識し、認識したスレッド数を含むスレッド情報をサーバ制御装置５に送信してもよい。これにより、スレッド数取得部２２はスレッド情報を取得する。

サーバ３で動作するアプリケーションが初期化されると、サブマネージャ１３は、アプリケーションが初期化されたことを検知する。この検知に応じて、サブマネージャ１３は、アプリケーションの初期化が完了したことを示す通知（初期化完了通知）をサーバ制御装置５に送信する。

サーバ制御装置５の主制御部２１は、通信部２８が初期化完了通知を受信したかを判定する（ステップＳ３）。初期化完了通知を受信しない場合（ステップＳ３でＮＯ）、処理は、次のステップに進まない。

通信部２８が初期化完了通知を受信した場合（ステップＳ３でＹＥＳ）、サーバ制御装置５は初期化後制御を行う（ステップＳ４）。実施形態では、アプリケーションの機能ごとに初期化後制御を行う。なお、初期化後制御は、１つのアプリケーションに対して行われてもよい。

サーバ制御装置５の主制御部２１は、アプリケーションの全ての機能について初期化後制御が終了したかを判定する（ステップＳ５）。全ての機能の初期化後制御が終了していなければ（ステップＳ５でＮＯ）、処理はステップＳ４に戻る。

全ての機能の初期化後制御が終了してれば（ステップＳ５でＹＥＳ）、主制御部２１は、サーバ３のサブマネージャ１３に対して動作を終了する指示（動作終了指示）を送信する（ステップＳ６）。そして、処理は終了する。

ステップＳ６において、主制御部２１は、サーバ３に対して、サブマネージャ１３を削除する指示を送信してもよい。ステップＳ６の時点で、サブマネージャ１３の役割は終わるため、サーバ３からサブマネージャ１３が削除されてもよい。サブマネージャ１３はプログラムにより実現されるため、サブマネージャ１３が削除されることで、サーバ３のリソースの消費量が低減する。

＜初期化後制御の処理の一例＞
次に、図８乃至図１０のフローチャートを参照して、初期化後制御の処理の一例について説明する。主制御部２１は、制御側テーブル記憶部２７の各種テーブルの情報のうち所定の情報をクリアする（ステップＳ１１）。

例えば、主制御部２１は、図３で示したサーバ管理テーブルのうち、制御状態をクリア（初期値に設定）する。また、主制御部２１は、図５で示した制御側スレッド管理テーブルのうち、実行済スレッド数および送信済リクエスト数の値をゼロに設定する。

主制御部２１は、サーバ３のサーバ側テーブル記憶部１５の情報をクリアする指示をサブマネージャ１３に送信する（ステップＳ１２）。サブマネージャ１３は、この指示に基づいて、サーバ側テーブル記憶部１５のサーバ側スレッド管理テーブルの情報をクリアする。

例えば、サブマネージャ１３は、図６で示したサーバ側スレッド管理テーブルのうち、スレッド状態および実行確認を初期値に設定する。

リクエスト送信部２４は、送信したリクエストの数（送信済みリクエスト数）を管理する。このため、リクエスト送信部２４は、制御側スレッド管理テーブルの送信済みリクエスト数をゼロに設定する（ステップＳ１３）。

次に、停止指示部２３は、初期化後制御の対象となるアプリケーションの全てのスレッドの動作を停止する動作停止指示をサブマネージャ１３に送信する（ステップＳ１４）。サブマネージャ１３は、例えば、サーバ３のＯＳの機能を利用して、各スレッドの動作を停止させる。

スレッド数取得部２２は、サブマネージャ１３に対して、停止済みのスレッド数を取得する要求をサブマネージャ１３に送信する。この要求に応じて、サブマネージャ１３は、ＯＳの機能を利用して、停止済みのスレッド数を認識し、認識した停止済みのスレッド数の情報をサーバ制御装置５に送信する。

これにより、スレッド数取得部２２は、停止済みスレッド数を取得する（ステップＳ１５）。最初にステップＳ１５が実行されるときの停止済みスレッド数は、アプリケーションのスレッド数と同じである。

判定部２５は、ループ回数が停止済みスレッド数に達したかを判定する（ステップＳ１６）。ステップＳ１７およびステップＳ１８の処理は繰り返し行われる。ループ回数は、ステップＳ１７およびステップＳ１８の処理が行われた回数である。

ループ回数が停止済みスレッド数に達していない場合（ステップＳ１６でＮＯ）、リクエスト送信部２４は、リクエストをアプリサーバ１１に送信し（ステップＳ１７）、送信済みリクエスト数をインクリメントする（ステップＳ１８）。

従って、ステップＳ１８の処理が実行されるごとに、制御側スレッド管理テーブルの送信済みリクエスト数がインクリメントされていく。

ステップＳ１７の処理が１回行われることにより、１つのリクエストがサーバ３に送信される。ループ回数が停止済みスレッド数に達した場合（ステップＳ１６でＹＥＳ）、サーバ制御装置５は、停止済みスレッド数と同数のリクエストをアプリサーバ１１に送信したことになる。

ここで、サーバ制御装置５によるリクエストの送信について説明する。上述したように、初期化後のアプリケーションの初回実行時において、該アプリケーションに対するリクエストに応じたサーバ３の応答性能は低下する。

従って、初期化後のアプリケーションが未実行の場合、クライアント２から該アプリケーションに対して送信されたレスポンスに対するサーバ３の応答性能は低下する。このため、クライアント２からのアプリケーションに対するリクエストに応じたレスポンス速度は低下する。

そこで、実施形態では、サーバ制御装置５は、初期化完了通知を受信したことに応じて、ステップＳ１０で取得されたスレッド数と同数のリクエストをアプリサーバ１１に送信する。

アプリサーバ１１は、受信したリクエストをアプリケーションの各スレッドに振り分ける。リクエストが振り分けられたスレッドは、該リクエストに応じて、実行する。スレッドが実行されると、該スレッドが使用する情報がロードされ、他のリソースとの接続も確立される。

従って、実行済みのスレッドの実行速度は、該スレッドが未実行のときよりも高速になる。このため、実行済みのスレッドに対するリクエストについては、サーバ３の応答性能が良好になる。

ただし、未実行のスレッドの実行速度は、実行済みのスレッドの実行速度よりも低速である。このため、未実行のスレッド数が多くなると、サーバ３の応答性能低下の抑制効果が高くならないことが想定される。

アプリサーバ１１は、サーバ制御装置５からアプリケーションのスレッド数と同数のリクエストを受信する。ただし、アプリケーションの各スレッドが実行状態にある場合、アプリサーバ１１は、受信したリクエストを各スレッドに均等に割り振らない。このため、リクエストの割り振りに大きな偏りを生じる可能性が高い。

そこで、停止指示部２３は、初期化後制御の対象となるアプリケーションの全てのスレッドの動作を停止する動作停止指示をサブマネージャ１３に送信する。サブマネージャ１３は、例えば、サーバ３のＯＳの機能を利用して、スレッド停止指示を行うことで、各スレッドの動作を停止させる。

各スレッドの動作が停止されると、各スレッドはＢＵＳＹ状態になる。全てのスレッドがＢＵＳＹ状態になると、アプリサーバ１１は、受信したリクエストを各スレッドに均等に割り振る可能性が高くなる。

この場合、アプリサーバ１１によるリクエストの割り振りが均等化されるため、未実行のスレッドが少なくなり、実行済みのスレッドが多くなる。このため、アプリケーションに対するリクエストに応じたサーバ３の応答性能低下が抑制される。従って、停止指示部２３は動作停止指示をアプリサーバ１１に送信する。

ただし、各スレッドの動作が停止したとしても、アプリサーバ１１は、サーバ制御装置５から受信したリクエストを、全てのスレッドに対して割り振らない可能性がある。この場合、リクエストが割り振られていないスレッドが生じる。

ステップＳ１６でＹＥＳの場合、処理は「Ａ」に進む。「Ａ」以降の処理について、図９のフローチャートを参照して、説明する。再開指示部２６は、サブマネージャ１３に対して、動作が停止している全てのスレッドの動作を再開させる動作開始指示を送信する（ステップＳ１９）。

サブマネージャ１３は、動作開始指示に応じて、各スレッドの動作を再開させる制御を行う。各スレッドのうち、リクエストが割り振られたスレッドは動作を再開する。一方、リクエストが割り振られていないスレッドは動作を再開しない。

サブマネージャ１３は、例えばサーバ３のＯＳの機能を利用して、各スレッドのうち、動作を再開したスレッドの数（再開済みスレッド数）を認識し、再開済みスレッド数の情報をサーバ制御装置５に送信する。

これにより、サーバ制御装置５は、再開済みスレッド数の情報を取得する（ステップＳ２０）。アプリサーバ１１が全てのスレッドにリクエストを割り振っていれば、再開済みスレッド数は、アプリケーションの全スレッド数になる。

判定部２５は、レスポンス数をゼロに設定する（ステップＳ２１）。そして、判定部２５は、レスポンス数が再開済みスレッド数と同じ数になったかを判定する（ステップＳ２２）。

リクエストが割り振られたスレッドが動作を再開すると、該スレッドは実行されて、実行されたスレッドはレスポンスをサーバ制御装置５に送信する。通信部２８は、レスポンスを受信する（ステップＳ２３）。

通信部２８がレスポンスを受信すると、判定部２５は、レスポンス数をインクリメントする（ステップＳ２４）。また、判定部２５は、送信済みリクエスト数をデクリメントする（ステップＳ２５）。そして、処理はステップＳ２２に戻る。

通信部２８がレスポンスを受信するごとに、ステップＳ２３乃至ステップＳ２５の処理が行われる。レスポンス数が再開済みスレッド数と同じ数になったと判定部２５が判定した場合（ステップＳ２２でＹＥＳ）、処理は「Ｂ」に進む。

「Ｂ」以降の処理について、図１０のフローチャートを参照して、説明する。主制御部２１は、各スレッドのそれぞれについて実行済みであるかを示す実行状況を確認する指示（実行状況確認指示）をサブマネージャ１３に送信する（ステップＳ２６）。

サブマネージャ１３は、各スレッドのそれぞれについて、実行済みであるかを確認する。サブマネージャ１３は、ログ記憶部１４が記憶しているログに基づいて、スレッドが実行されたかを確認してもよい。

また、サブマネージャ１３は、各スレッドのＣＰＵ負荷の増分が負荷閾値を超えたかに基づいて、またはシステムコールの発行数が発行数閾値を超えたかに基づいて、スレッドが実行されたかを確認してもよい。

また、アプリサーバ１１やアプリケーションが、スレッドの実行状況を確認する機能を有している場合、サブマネージャ１３は該機能を利用して、スレッドが実行済みであるかを確認してもよい。

サブマネージャ１３は、各スレッドの実行状況を確認し、実行済みのスレッドの数である実行済スレッド数の情報をサーバ制御装置５に送信する。これにより、サーバ制御装置５は、実行済スレッド数を取得する（ステップＳ２７）。

主制御部２１は、制御側スレッド管理テーブルの実行済スレッド数に、取得した実行済スレッド数を記憶する。判定部２５は、取得された実行済みスレッド数がアプリケーションの全スレッド数に達したかを判定する（ステップＳ２８）。

上述したように、停止指示部２３が、サーバ３のアプリケーションの各スレッドの動作を停止させることで、アプリサーバ１１は、受信したリクエストを多くのスレッドに割り振る。

アプリサーバ１１は、全てのスレッドに対してリクエストを割り振ることもあるが、一部のスレッドに対してリクエストを割り振らないこともある。この場合、リクエストが割り振られていないスレッドが動作を再開したとしても、該スレッドは実行しない。

この場合、実行済スレッド数はアプリケーションの全スレッド数に達しない（ステップＳ２８でＮＯ）。実施形態では、サーバ制御装置５は、サーバ３で動作するアプリケーションの全てのスレッドを実行させる。

従って、ステップＳ２８でＮＯの場合、処理は「Ｃ」からステップＳ１４に戻る。そして、実行済スレッド数がアプリケーションの全スレッド数に達するまで、ステップＳ１４乃至ステップＳ２７の処理が繰り返される。

これにより、サーバ３で動作するアプリケーションの全てのスレッドが実行されるため、アプリケーションの実行速度は、該アプリケーションが初期化された直後のときよりも高速になる。このため、アプリケーションに対してリクエストが送信されたときのサーバ３の応答性能低下が抑制される。

実施形態では、サーバ制御装置５はアプリケーションの全てのスレッドを実行させるが、全てのスレッドが実行されなくてもよい。上述したように、サーバ制御装置５は、各スレッドの動作を停止させ、その後、リクエストを送信している。

このため、アプリサーバ１１は、多くのスレッドに対してリクエストを割り振る。そして、リクエストが割り振られたスレッドの動作が再開するため、多くのスレッドが実行されることになる。

従って、アプリケーションに対してリクエストが送信されたときのサーバ３の応答性能低下が抑制される。

実行済みスレッド数が全スレッド数に達した場合（ステップＳ２９でＹＥＳ）、再開指示部２６は、サブマネージャ１３に対して、全てのスレッドを再開させる指示を送信する（ステップＳ２９）。

上述したように、停止指示部２３は、各スレッドの動作を停止させる。また、再開指示部２６は、停止中のスレッドの動作を再開させる。このとき、各スレッドのうち一部のスレッドが動作を再開していない可能性がある。

そこで、ステップＳ２９において、再開指示部２６は、全てのスレッドの動作を再開させる指示をサーバ３に送信する。判定部２５は、送信済みリクエスト数がゼロであるかを判定する（ステップＳ３０）。

ステップＳ２９の時点で、全てのスレッドの動作が再開していれば、送信済みリクエスト数はゼロになる（ステップＳ３０でＹＥＳ）。この場合、初期化後制御処理は終了する。

一方、ステップＳ２９の時点で、一部のスレッドの動作が再開していなければ、送信済みリクエスト数はゼロではない（ステップＳ３０でＮＯ）。この場合、ステップＳ２９により、スレッドの動作は再開するため、通信部２８はレスポンスを受信する（ステップＳ３１）。

通信部２８がレスポンスを受信すると、主制御部２１は、送信済みリクエスト数をデクリメントする（ステップＳ３２）。ステップＳ３１およびステップＳ３２の処理は、送信済みリクエスト数がゼロになるまで繰り返される。

以下、サブマネージャ１３が行う各処理について説明する。サブマネージャ１３は、サーバ制御装置５によって制御される。従って、サブマネージャ１３が行う各処理は、サーバ制御装置５の制御に基づく処理になる。

＜スレッド停止処理の一例＞
次に、図１１のフローチャートを参照して、スレッド停止処理の一例について説明する。スレッド停止処理は、サーバ制御装置５の停止指示部２３から動作停止指示に基づいて、サブマネージャ１３により行われる。

サブマネージャ１３は、停止済みスレッド数をゼロに設定する（ステップＳ４０）。サブマネージャ１３は、ループ回数が全スレッド数に達したかを判定する（ステップＳ４１）。ループ回数は、ステップＳ４２乃至ステップＳ４６の処理を行った回数である。

サブマネージャ１３は、アプリケーションの各スレッドのうち１つのスレッドを対象のスレッドに設定する。サブマネージャ１３は、対象のスレッドは停止済みであるかを判定する（ステップＳ４２）。

対象のスレッドが停止済みでなければ（ステップＳ４２でＮＯ）、サブマネージャ１３は、対象のスレッドを停止させる（ステップＳ４３）。サブマネージャ１３は、サーバ側スレッド管理テーブルのうち、対象のスレッド状態を「停止中」に設定する（ステップＳ４４）。

サブマネージャ１３は、停止済みスレッド数をインクリメントする（ステップＳ４５）。サブマネージャ１３は、対象のスレッドを次のスレッドに設定する（ステップＳ４６）。そして、処理はステップＳ４１に戻る。

対象のスレッドが停止済みであった場合（ステップＳ４２でＹＥＳ）、ステップＳ４３乃至ステップＳ４５の処理は行われず、ステップＳ４６の処理が行われる。ループ回数が全スレッド数に達したとき（ステップＳ４２でＹＥＳ）、スレッド停止処理は終了する。

図１２は、ステップＳ４３の処理の一例を示している。サブマネージャ１３は、対象のスレッドを停止させる指示をサーバ３のＯＳに出力する（ステップＳ４３−１）。サーバ３のＯＳは、この指示に基づいて、対象のスレッドを停止させる。スレッドを停止させる手法は、図１２の例には限定されない。

＜スレッド再開処理の一例＞
次に、図１３のフローチャートを参照して、スレッド再開処理の一例について説明する。スレッド再開処理は、サーバ制御装置５の再開指示部２６から動作再開指示に基づいて、サブマネージャ１３により行われる。

サブマネージャ１３は、再開済みスレッド数をゼロに設定する（ステップＳ５０）。サブマネージャ１３は、ループ回数が全スレッド数に達したかを判定する（ステップＳ４２）。ループ回数は、ステップＳ５２乃至ステップＳ５６の処理を行った回数である。

サブマネージャ１３は、アプリケーションの各スレッドのうち１つのスレッドを対象のスレッドに設定する。サブマネージャ１３は、対象のスレッドが実行済みであるかを判定する（ステップＳ５２）。

サブマネージャ１３は、サーバ側スレッド管理テーブルのうち、対象のスレッドの実行確認を参照して、該対象のスレッドが実行済みであるかを判定する。上述したように、ステップＳ２８でＮＯの場合、ステップＳ１４乃至ステップＳ２７の処理が繰り返される。

最初にスレッド再開処理が行われる場合、アプリケーションの各スレッドに実行済みのスレッドはない。一方、２回目以降にスレッド再開処理が行われる場合、実行済みのスレッドが存在している。

対象のスレッドが実行済みでなければ（ステップＳ５２でＮＯ）、サブマネージャ１３は、対象のスレッドを再開させる（ステップＳ５３）。サブマネージャ１３は、サーバ側スレッド管理テーブルのスレッド状態のうち対象のスレッドに設定されている「停止中」の設定をクリアする（ステップＳ５４）。

サブマネージャ１３は、再開済みスレッド数をインクリメントする（ステップＳ５５）。サブマネージャ１３は、対象のスレッドを次のスレッドに設定する（ステップＳ５６）。そして、処理はステップＳ５１に戻る。

対象のスレッドが実行済みであった場合（ステップＳ５２でＹＥＳ）、ステップＳ５３乃至ステップＳ５５の処理は行われず、ステップＳ５６の処理が行われる。ループ回数が全スレッド数に達したとき（ステップＳ５２でＹＥＳ）、スレッド停止処理は終了する。

従って、アプリケーションの各スレッドのうち、実行済みのスレッドについては、ステップＳ５３乃至ステップＳ５５の処理が行われないため、サブマネージャ１３が行う処理が省略される。これにより、実行済みスレッドに対しては停止状態が維持され、リクエストが処理されない状態となるため、アプリサーバが、該スレッドが高負荷状態と判断してさらなるリクエストを割り振らなくなることが期待できる。

図１４は、ステップＳ５３の処理の一例を示している。サブマネージャ１３は、アプリサーバ１１がログをログ記憶部１４に記憶する機能（アプリサーバログ機能）を有している場合、アプリサーバログ機能を使用するかを判定する（ステップＳ６１）。

アプリサーバログ機能は、アプリサーバ１１がアプリケーションの各スレッドの実行状況をログ記憶部１４に記憶する機能である。アプリサーバログ機能は、アプリサーバ１１の機能である。

例えば、アプリサーバ１１がアプリサーバログ機能を有していない場合、サブマネージャ１３は、アプリサーバログ機能を使用しないと判定する（ステップＳ６１でＮＯ）。この場合、アプリサーバログ機能は使用されない。

サブマネージャ１３は、アプリケーションがログをログ記憶部１４に記憶する機能（アプリログ機能）を有している場合、アプリログ機能を使用するかを判定する（ステップＳ６２）。

アプリログ機能は、アプリケーションが各スレッドの実行状況をログ記憶部１４に記憶する機能である。アプリログ機能は、サーバ３で動作するアプリケーションの機能である。

例えば、アプリケーションがアプリログ機能を有していない場合、サブマネージャ１３は、アプリログ機能を使用しないと判定する（ステップＳ６２でＮＯ）。この場合、アプリログ機能は使用されない。

ステップＳ６２でＮＯの場合、アプリサーバログ機能およびアプリログ機能は使用されない。この場合、サブマネージャ１３は、システムコールトレース機能を使用するかを判定する（ステップＳ６３）。

システムコールトレース機能が使用されるか否かは、予めサブマネージャ１３に設定されていてもよい。システムコールトレース機能は、システムコールが行われことをトレースする機能である。

サブマネージャ１３がシステムコールトレース機能を使用しない場合（ステップＳ６３でＮＯ）、サブマネージャ１３は、再開時点でのＣＰＵ負荷を取得する（ステップＳ６４）。例えば、サブマネージャ１３は、サーバ３のＯＳからＣＰＵ負荷を取得してもよい。

サブマネージャ１３がシステムコールトレース機能を使用する場合(ステップＳ６３でＹＥＳ)、サブマネージャ１３は、対象のスレッドにトレース機能をアタッチする（ステップＳ６５）。これにより、システムコールトレース機能が使用される。

ステップＳ６１でＹＥＳの場合、ステップＳ６２でＹＥＳの場合、ステップＳ６４が実行された場合またはステップＳ６５が実行された場合、サブマネージャ１３は、対象のスレッドを再開する指示をＯＳに出力する（ステップＳ６６）。これにより、対象のスレッドは動作を再開する。

＜実行状況確認処理の一例＞
次に、図１５のフローチャートを参照して、実行状況確認処理の一例について説明する。実行状況確認処理は、サーバ制御装置５からの実行状況確認指示に基づいて、サブマネージャ１３により行われる。

サブマネージャ１３は、ループ回数が全スレッド数に達したかを判定する（ステップＳ７１）。ループ回数は、ステップＳ７２乃至ステップＳ７６の処理を行った回数である。

サブマネージャ１３は、アプリケーションの各スレッドのうち１つのスレッドを対象のスレッドに設定する。サブマネージャ１３は、対象のスレッドが実行済みであることを確認したかを判定する（ステップＳ７２）。

サブマネージャ１３が、サーバ側スレッド管理テーブルのうち、対象のスレッドの実行確認が「実行済み」でない場合（ステップＳ７２でＮＯ）、サブマネージャ１３は、対象のスレッドの実行状況を確認する（ステップＳ７３）。

サブマネージャ１３は、対象スレッドの実行状況に基づいて、該対象スレッドが実行済みであることを確認した場合、戻り値に「ＹＥＳ」を設定する。一方、サブマネージャ１３は、対象スレッドが実行済みでないことを確認した場合、戻り値に「ＮＯ」を設定する。

サブマネージャ１３は、戻り値が「ＹＥＳ」であるかを判定する（ステップＳ７４）。戻り値が「ＹＥＳ」の場合（ステップＳ７４でＹＥＳ）、サブマネージャ１３は、サーバ側スレッド管理テーブルに「実行済み」を設定する（ステップＳ７５）。

つまり、サブマネージャ１３は、サーバ側スレッド管理テーブルのうち、対象のスレッドの実行確認の項目に「実行済み」を設定する。ステップＳ７５の処理が実行された場合、またはステップＳ７４でＮＯの場合、サブマネージャ１３は、対象のスレッドを次のスレッドに設定する（ステップＳ７６）。

ループ回数が全スレッド数に達したとき（ステップＳ７１でＹＥＳ）、実行状況確認処理は終了する。従って、アプリケーションの各スレッドのうち、実行済みのスレッドについては、ステップＳ７２乃至ステップＳ７６の処理が行われない。

図１６は、ステップＳ７３の処理の一例を示している。サブマネージャ１３は、アプリサーバログ機能を使用するかを判定する（ステップＳ８１）。

アプリサーバログ機能が使用される場合（ステップＳ８１でＹＥＳ）、サブマネージャ１３は、ログ記憶部１４に記憶されているアプリサーバログから対象スレッドの実行状況を取得する（ステップＳ８２）。これにより、サブマネージャ１３は、対象スレッドの実行状況を確認する。

アプリサーバログ機能が使用されない場合（ステップＳ８１でＮＯ）、サブマネージャ１３は、アプリログ機能を使用するかを判定する（ステップＳ８３）。

アプリログ機能が使用される場合（ステップＳ８３でＹＥＳ）、サブマネージャ１３は、ログ記憶部１４に記憶されているアプリログから対象スレッドの実行状況を取得する（ステップＳ８４）。これにより、サブマネージャ１３は、対象スレッドの実行状況を確認する。

サブマネージャ１３がアプリサーバログ機能を使用する場合と、アプリログ機能を使用する場合との何れの場合も、サブマネージャ１３はログ記憶部１４に記憶されているログに基づいて、対象スレッドの実行状況を確認する。

そして、サブマネージャ１３は、対象スレッドが実行済みであるかを判定する（ステップＳ８５）。対象スレッドが実行済みであることをサブマネージャ１３が確認した場合（ステップＳ８５でＹＥＳ）、サブマネージャ１３は戻り値に「ＹＥＳ」を設定する（ステップＳ８６）。

対象スレッドが実行済みでないことをサブマネージャ１３が確認した場合（ステップＳ８５でＮＯ）、サブマネージャ１３は戻り値に「ＮＯ」を設定する（ステップＳ８７）。以上により、ログに基づく対象スレッドの実行状況の確認が行われる。

ステップＳ８３でＮＯの場合、ログに基づく対象スレッドの実行状況の確認は行われない。この場合、処理は「Ｄ」に進み。「Ｄ」以降の処理について、図１７のフローチャートを参照して、説明する。

サブマネージャ１３は、システムコールトレース機能を使用するかを判定する（ステップＳ８８）。システムコールトレース機能が使用されない場合（ステップＳ８８でＮＯ）、サブマネージャ１３は、例えばサーバ３のＯＳの機能を利用して、現時点でのＣＰＵ負荷を取得する（ステップＳ８９）。

ステップＳ６４において、サブマネージャ１３は、スレッドの動作が再開した時点でのＣＰＵ負荷を取得している。サブマネージャ１３は、現時点でのＣＰＵ負荷からスレッドの再開時点でのＣＰＵ負荷を減じて、ＣＰＵ負荷の増分を求める。

サブマネージャ１３は、ＣＰＵ負荷増分が負荷閾値を超えているかを判定する（ステップＳ９０）。ＣＰＵ負荷増分が負荷閾値を超えている場合（ステップＳ９０でＹＥＳ）、戻り値に「ＹＥＳ」を設定する（ステップＳ９１）。

この場合、対象スレッドによるＣＰＵ負荷が増加していることから、サブマネージャ１３は該対象スレッドが実行されたことが推定される。従って、戻り値は「ＹＥＳ」になる。

一方、ＣＰＵ負荷増分が負荷閾値以下の場合（ステップＳ９０でＮＯ）、サブマネージャ１３は、ＣＰＵ負荷が増加していないか、それほど増加していないことから、対象スレッドが実行されていないことが推定される。従って、サブマネージャ１３は、戻り値に「ＮＯ」を設定する（ステップＳ９２）。

また、ステップＳ９０の判定は、対象スレッドによりサーバ３のハードウェア資源の使用量が所定の閾値を超えているかに基づいて、行われてもよい。例えば、対象スレッドによるサーバ３のメモリの使用量が所定の閾値を超えているかに基づいて、該対象スレッドが実行されたか否かが確認されてもよい。

サブマネージャ１３がシステムコールトレース機能を使用する場合（ステップＳ８８でＹＥＳ）、サブマネージャ１３は、トレース機能をデタッチして、システムコール発行数をカウントする（ステップＳ９３）。

サブマネージャ１３は、システムコール発行数が発行数閾値を超えているかを判定する（ステップＳ９４）。システムコール発行数が発行数閾値を超えている場合（ステップＳ９４でＹＥＳ）、対象スレッドが実行されたことが推定される。従って、サブマネージャ１３は戻り値を「ＹＥＳ」に設定する（ステップＳ９５）。

システムコール発行数が発行数閾値以下の場合（ステップＳ９４でＮＯ）、対象スレッドが実行されていないことが推定される。従って、サブマネージャ１３は戻り値を「ＮＯ」に設定する（ステップＳ９６）。

＜全スレッド再開処理の一例＞
次に、図１８のフローチャートを参照して、全スレッド再開処理の一例について説明する。全スレッド再開処理は、サーバ制御装置５の再開指示部２６からの指示に基づいて、サブマネージャ１３により行われる。

サブマネージャ１３は、ループ回数が全スレッド数に達したかを判定する（ステップＳ１０１）。ループ回数は、ステップＳ１０２乃至ステップＳ１０４の処理を行った回数である。

サブマネージャ１３は、アプリケーションの各スレッドのうち１つのスレッドを対象のスレッドに設定する。サブマネージャ１３は、対象のスレッドが再開済みであるかを判定する（ステップＳ１０２）。

対象のスレッドが再開済みでなければ（ステップＳ１０２でＮＯ）、サブマネージャ１３は、対象のスレッドを再開させる（ステップＳ１０３）。サブマネージャ１３は、対象のスレッドを再開する指示を、サーバ３で動作するＯＳに出力することで、対象のスレッドを再開させる。

ステップＳ１０３が実行された場合、またはステップＳ１０２でＹＥＳの場合、サブマネージャ１３は、対象のスレッドを次のスレッドに設定する（ステップＳ１０４）。ループ回数が全スレッド数に達したとき（ステップＳ１０１でＹＥＳ）、全スレッド再開処理は終了する。

＜サーバ制御装置のハードウェア構成の一例＞
次に、図１９の例を参照して、サーバ制御装置５のハードウェア構成の一例を説明する。図１９の例に示すように、バス１００に対して、ＣＰＵ１１１とＲＡＭ１１２とＲＯＭ１１３と補助記憶装置１１４と媒体接続部１１５と通信インタフェース１１６とが接続されている。

ＣＰＵ１１１は任意の処理回路である。ＣＰＵ１１１はＲＡＭ１１２に展開されたプログラムを実行する。実行されるプログラムとしては、実施形態の処理を行うサーバ制御プログラムを適用してもよい。ＲＯＭ１１３はＲＡＭ１１２に展開されるプログラムを記憶する不揮発性の記憶装置である。

補助記憶装置１１４は、種々の情報を記憶する記憶装置であり、例えばハードディスクドライブや半導体メモリ等を補助記憶装置１１４に適用してもよい。媒体接続部１１５は、可搬型記録媒体１１９と接続可能に設けられている。

可搬型記録媒体１１９としては、可搬型のメモリや光学式ディスク（例えば、Compact Disk(CD)やDigital Versatile Disk(DVD)等）を適用してもよい。この可搬型記録媒体１１９に実施形態の処理を行うプログラムが記録されていてもよい。

サーバ制御装置５のうち、主制御部２１とスレッド数取得部２２と停止指示部２３とリクエスト送信部２４と判定部２５と再開指示部２６とは、与えられたプログラムをＣＰＵ１１１が実行することにより実現されてもよい。

制御側テーブル記憶部２７は、ＲＡＭ１１２や補助記憶装置１１４等により実現されてもよい。通信部２８は、通信インタフェース１１６により実現されてもよい。

ＲＡＭ１１２、ＲＯＭ１１３、補助記憶装置１１４および可搬型記録媒体１１９は、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。

＜その他＞
本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ システム
２ クライアント
３ サーバ
５ サーバ制御装置
１１ アプリサーバ
１２ 実行部
１３ サブマネージャ
１４ ログ記憶部
１５ サーバ側テーブル記憶部
２１ 主制御部
２２ スレッド数取得部
２３ 停止指示部
２４ リクエスト送信部
２５ 判定部
２６ 再開指示部
２７ 制御側テーブル記憶部
２８ 通信部
１１１ プロセッサ
１１２ ＲＡＭ
１１３ ＲＯＭ

Claims (8)

1. サーバで実行されるアプリケーションプログラムの初期化が完了した旨の通知に応じて、前記サーバが実行する前記アプリケーションプログラムの実行単位の数を取得し、
   前記サーバで実行される全ての前記実行単位の動作を停止する指示を送信し、
   取得された前記実行単位の数と少なくとも同数のリクエストを前記サーバに送信し、
   停止された前記全ての実行単位の動作を再開させる指示を前記サーバに送信する、
   処理をコンピュータに実行させるためのサーバ制御プログラム。
2. 前記サーバから前記リクエストに応じたレスポンスを受信し、
   受信した前記レスポンスの数と送信した前記リクエストの数とに基づいて、前記全ての実行単位が前記リクエストに応じて実行したかを判定する、
   処理をさらに前記コンピュータに実行させるための請求項１記載のサーバ制御プログラム。
3. 前記全ての実行単位が実行されていないと判定された場合、前記全ての実行単位が前記リクエストを実行するまで、前記実行単位を停止する指示を送信し、前記リクエストを前記サーバに送信し、前記再開させる指示を前記サーバに送信する、
   処理をさらに前記コンピュータに実行させるための請求項２記載のサーバ制御プログラム。
4. 前記実行単位のうち、実行済みの実行単位を除外した実行単位の動作を再開させる指示を前記サーバに送信する、
   処理をさらに前記コンピュータに実行させるための請求項３記載のサーバ制御プログラム。
5. 前記サーバのハードウェア資源の使用量の増分が所定の閾値を超えたかに基づいて、前記実行単位が実行されたかを判定する、
   処理をさらに前記コンピュータに実行させるための請求項１乃至４のうち何れか１項に記載のサーバ制御プログラム。
6. 前記サーバが発行したシステムコールの発行数が所定の閾値を超えたかに基づいて、前記実行単位が実行されたかを判定する、
   処理をさらに前記コンピュータに実行させるための請求項１乃至４のうち何れか１項に記載のサーバ制御プログラム。
7. サーバで実行されるアプリケーションプログラムの初期化が完了した旨の通知に応じて、前記サーバが実行する前記アプリケーションプログラムの実行単位の数を取得し、
   前記サーバで実行される全ての前記実行単位の動作を停止する指示を送信し、
   取得された前記実行単位の数と少なくとも同数のリクエストを前記サーバに送信し、
   停止された前記全ての実行単位の動作を再開させる指示を前記サーバに送信する、
   処理をコンピュータが実行するサーバ制御方法。
8. サーバで実行されるアプリケーションプログラムの初期化が完了した旨の通知に応じて、前記サーバが実行する前記アプリケーションプログラムの実行単位の数を取得する取得部と、
   前記サーバで実行される全ての前記実行単位の動作を停止する指示を送信する停止指示部と、
   取得された前記実行単位の数と少なくとも同数のリクエストを前記サーバに送信する送信部と、
   前記送信部が前記リクエストを送信した後に、停止された前記全ての実行単位の動作を再開させる指示を前記サーバに送信する再開指示部と、
   を備えるサーバ制御装置。

Images