JPH06314263A - サーバ処理方式 - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】 サーバプロセスの数をシステムの負荷状況に
応じて管理することにより、クライアントプロセスを待
たせることなく応答性が良く、サービス効率の良いサー
バシステムを提供する。 【構成】 ステップ１からステップ７までは各々起動さ
れたサーバプロセスの処理を示しており、ステップ８か
らステップ１６まではサーバ管理プロセスの処理を示し
ている。クライアントプログラムからの処理要求に対し
て待ち状態にあるサーバプロセスの数やクライアントか
らの要求の到着の頻度などの負荷状況をサーバ管理プロ
セスが監視し、負荷が増加したと判断した場合にはサー
バプロセスを新規に起動してサーバプロセスの総数を増
やし、負荷が減少したと判断した場合には一部のサーバ
プロセスを終了させることによりサーバプロセスの総数
を減らす。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、複数の計算機がネッ
トワーク接続された分散システムにおけるプログラム処
理方式に関するものであり、さらに詳しくはクライアン
トマシンとサーバマシンから構成されたクライアントサ
ーバシステムにおける、サーバプロセスの処理方式に関
するものである。

【０００２】

【従来の技術】従来のサーバ処理方式について、図９お
よび図１０に基づいて説明する。図９は、従来のサーバ
処理方式によるシステムの構成図であり、同図において
１はサーバプロセス５が稼働するサーバマシン、２はサ
ーバプロセスに対してサービスを要求するクライアント
プロセス６が搭載されたクライアントマシンであり、３
は上記サーバマシンとクライアントマシンを接続してい
るネットワークである。サーバマシン１において、５は
クライアントプロセス６からの処理要求を実行するサー
バプロセス、７は論理的な接続機構であるプロセス間通
信実現のためにオペレーティングシステムが提供してい
るリクエスト受付用ポートである。クライアントプロセ
ス６は、処理要求を上記リクエスト受付用ポート７に送
信することによりサーバプロセスに対して処理を依頼す
る。すると、サーバプロセス５のうちの１つのプロセス
が、クライアントプロセスからの処理要求を上記リクエ
スト受付用ポート７から受け取り所望の処理を開始す
る。

【０００３】図１０は、図９の構成による従来のサーバ
処理方式における各サーバプロセスの動作を示したフロ
ーチャートである。以下に従来の方式によるサーバプロ
セスの動作について図１０を用いて説明する。まず、ス
テップ１の初期化処理で、システムの立ちあげ時の設定
値として予め決められた数のサーバプロセス５が起動さ
れる。サーバプロセスの総数はこの時点で決まり、その
後は増減しない。ステップ２で、サーバプロセス５は、
リクエスト受付用ポート７に対しクライアントプロセス
からの処理要求データが到着しているか否かをチェック
する。処理要求データが到着している場合には、ステッ
プ３でその処理要求データをリクエスト受付用ポート７
からサーバプロセス５に取り込むための要求を出す。処
理要求データが到着していない場合には再びステップ２
に戻る。ステップ３では、この時、同時に複数のサーバ
プロセス５が取り込み動作を開始することがあるが、そ
のうちのただひとつのサーバプロセスに処理要求データ
が取り込まれることになる。ステップ４では、実際に処
理要求データが取り込めたか否かをチェックする。ステ
ップ４により、実際に処理要求データが取り込めていた
場合には、ステップ６で処理要求データに対する所望の
処理を行い、その後再度次のサービスを行うためにステ
ップ２に戻る。ステップ４で、処理要求データが取り込
めなかった場合には、再度次のサービス要求に備えてス
テップ２に戻る。

【０００４】サーバプロセスの動作は以上のように行わ
れるが、サーバプロセス数よりも多くのクライアントプ
ロセスがほぼ同時にリクエストを送信した場合には、サ
ーバプロセス数相当分のリクエストは、すぐ処理が開始
されるが、残りのリクエストに関してはその期間リクエ
スト受付用ポートで処理されずに待たされることにな
る。

【０００５】

【発明が解決しようとする課題】上記のような構成をと
るサーバ処理方式においては、サーバプロセスの数が一
定なため、クライアントプロセス群からの処理要求の頻
度が一定以上に高まると、サービス受け付け可能なサー
バプロセスが不足するという状況が発生し、他のクライ
アントプロセスに対するサーバプロセスの処理が終了す
るまでクライアントプロセスが待たされることになり、
サービスの効率が悪くなるという問題点があった。ま
た、クライアントプロセス群からの処理要求の頻度が高
くなることを事前に予想して対処するには、初期化の時
点で、その最大の負荷に対応できるだけの数のサーバプ
ロセスを起動しておかなければならず、処理要求の頻度
が変動するようなシステムにおいては、処理要求の頻度
が低い時には、多くのサーバプロセスが無駄に待機して
いるだけの状態が発生することになり、メモリなどのシ
ステム資源を浪費するという問題点があった。

【０００６】この発明は、上記のような問題点を解消す
るためになされたもので、サーバプロセスの数をシステ
ムの負荷状況に応じて管理することにより、クライアン
トプロセスを待たせることなく応答性が良く、サービス
効率の良いサーバシステムを提供することを目的として
いる。また、常時待機させておくサーバプロセスの数
を、システムの負荷状況を反映して調整することによっ
て、システム資源の有効活用を計ろうとするものであ
る。

【０００７】

【課題を解決するための手段】この発明におけるサーバ
処理方式は、サーバマシン上に搭載されたサーバプロセ
スとサーバ管理プロセスにおいて、サーバプロセスは、
サーバ管理プロセスに対するメッセージ送出手段を設
け、サーバ管理プロセスは、上記サーバプロセスからの
メッセージを受信し、該メッセージ内容に従って、サー
バプロセスに対し待機、生成、消滅を指令する手段を設
けるようにしたものである。また、この発明におけるサ
ーバ処理方式は、サーバマシン上に搭載されたサーバプ
ロセスとサーバ管理プロセスにおいて、サーバプロセス
は、サーバ管理プロセスに対するメッセージ送出手段
と、該サーバ管理プロセスに対する問い合わせ手段を設
け、サーバ管理プロセスは、クライアントマシンから送
出されてきて待ち状態にある処理要求を周期的に監視
し、該結果を負荷情報として記録する手段と、受信メッ
セージ内容と前記負荷情報からサーバプロセスに対し待
機、生成、消滅を指令する手段を設けるようにしたもの
である。また、この発明におけるサーバ処理方式は、サ
ーバマシン上に搭載されたサーバプロセスとサーバ管理
プロセスにおいて、サーバプロセスは、サービスの開
始、終了と該サービスに相当する負荷情報をメッセージ
として送出する手段と、サーバ管理プロセスに対する問
い合わせ手段を設け、サーバ管理プロセスは、メッセー
ジ内の負荷情報よりサーバプロセスの積算負荷結果を計
算する手段と、該積算結果と上記メッセージ内容に基づ
いて、サーバプロセスに対する待機、生成、消滅を指令
する手段を設けるようにしたものである。

【０００８】

【作用】この発明によるサーバ処理方式では、サーバプ
ロセスの数をシステムの負荷状態に応じて制御するよう
にしたので、クライアントプロセスからの処理要求に対
してクライアントプロセスに対する処理待ち状態を発生
させることなく直ちに対応することができる。また、待
機状況にあるクライアントプロセスの数を負荷状況に応
じて制御することにより、システム資源の無駄な消費を
抑制しようとするものである。

【０００９】

【実施例】

実施例１．図１はこの発明によるサーバ処理方式による
サーバプロセスの一実施例を示すフローチャートであ
る。なお、図において、図１０と同一符号は、同一また
は相当部分を示す。図において、ステップ１からステッ
プ７までは各々起動されたサーバプロセスの処理を示し
ており、ステップ８からステップ１６まではサーバ管理
プロセスの処理を示している。また、ステップ１からス
テップ４およびステップ６は従来の方式によるサーバプ
ロセスの動作と同じである。サーバプロセスは、ステッ
プ５において所望の処理を行う前に、サーバ管理プロセ
スに対して処理開始の旨のメッセージを送出する。ま
た、ステップ６の所望の処理が終了した時点で、ステッ
プ７においてサーバ管理プロセスに対して処理終了の旨
のメッセージを送出する。

【００１０】サーバ管理プロセスは、ステップ８におい
て、初期化処理を実施する。この初期化処理は、通常シ
ステムのコンフィグレーションファイルなどから、この
サーバプロセス群の最小待ち状態サーバプロセス数と、
最大待ち状態サーバプロセス数を起動時のパラメータと
して読みとり、その数をサーバ管理プロセス内の論理的
なカウンタである待ち状態サーバプロセス数に設定す
る。ステップ９では、サーバプロセス群からのメッセー
ジを受け付けるための待ち状態に入る。ステップ１０で
は、サーバプロセスから到着したメッセージが、所望の
処理の開始を示すものか、終了を示すものかのチェック
を行う。到着したメッセージが終了を示すものであった
場合には、ステップ１１において、待ち状態サーバプロ
セス数を１増やす。ステップ１２において、待ち状態サ
ーバプロセス数が既定値の最大待ち状態サーバプロセス
数より大きくなったか否かをチェックする。ステップ１
２で、待ち状態サーバプロセス数が初期化処理で決めら
れた既定値の最大待ち状態サーバプロセス数より大きく
なった場合には、必要以上に待ち状態サーバプロセスが
存在すると判断し、ステップ１３で待ち状態サーバプロ
セスのひとつを強制終了させる。ステップ１２で、待ち
状態サーバプロセス数が既定値の最大待ち状態サーバプ
ロセス数を越えなかった場合には、ステップ９に戻る。
ステップ１０において、メッセージの種類が所望の処理
の開始であった場合には、ステップ１４において、待ち
状態サーバプロセス数を１減らし、ステップ１５におい
て、待ち状態サーバプロセス数が既定値の最小待ちサー
バプロセス数よりも小さくなったか否かをチェックす
る。待ち状態サーバプロセス数が既定値の最小待ちサー
バプロセス数よりも小さくなった場合にはステップ１６
において、サーバプロセスをひとつ新規に起動する。ス
テップ１５で、待ち状態サーバプロセス数が既定値の最
小待ちサーバプロセス数よりも小さくなかった場合には
ステップ９に戻る。

【００１１】実施例２．またこの発明の第２の実施例に
ついて図２〜図４について説明する。図２はこの発明の
実施例におけるサーバプロセスの動作を示すフローチャ
ート、図３はこの発明による一実施例におけるサーバ管
理プロセスの動作を示すフローチャートである。図４は
この発明の実施例におけるサーバ管理プロセスが保持す
る履歴情報の例である。この履歴情報は、ある単位時間
に到着したリクエストメッセージの数を数単位時間分保
持している。例では５単位時間分の履歴情報を保持して
いる。

【００１２】サーバプロセスの動作について図２につい
て説明する。図において、図１と同一符号は、同一また
は相当部分を示す。ステップ１でサーバプロセスが起動
される。ステップ１０２で、サーバプロセスは、リクエ
スト受付用ポートに処理要求が到着しているか否かをチ
ェックする。ステップ１０２で、処理要求メッセージが
届いていた場合には、ステップ３で処理要求メッセージ
を取り込む処理を行う。この取り込み処理は複数のサー
バプロセスが同時に行う可能性があり、自サーバプロセ
スが取り込めるか否かは不明なので、ステップ４で実際
に取り込めたか否かをチェックする。ステップ４で処理
要求メッセージが取り込めなかった場合は、ステップ１
０２に戻る。メッセージが取り込めた場合は、ステップ
５で、サーバ管理プロセスに対し、所望の処理開始の旨
のメッセージを通知する。ステップ６で所望の処理を行
う。ステップ１０７でサーバ管理プロセスに対し、所望
の処理が終了した旨のメッセージを通知する。ステップ
１０８でサーバ管理プロセスに対し、自サーバプロセス
の次の処理について指示を待つ。ステップ１０９で、サ
ーバ管理プロセスからのメッセージの内容をチェックす
る。ステップ１０９でのメッセージの内容が「終了」せ
よであった場合には、ステップ１１１でこのサーバプロ
セスは自ら終了処理を行い消滅する。メッセージの内容
が「待機」せよであった場合には、ステップ１０２に戻
る。また、ステップ１０２で、処理要求メッセージが届
いていなかった場合は、ステップ１１１で自プロセスが
最後にクライアントの要求に応じた所望の処理を行って
から、あるいはサーバ管理プロセスから待機の指示を受
けてから一定の時間が経過しているか否かをチェックす
る。ステップ１１１で、一定の時間が経過していた場合
には、ステップ１０８の処理を行う。ステップ１１１で
一定の時間が経過していなかった場合には、ステップ１
０２に戻る。

【００１３】次に、サーバ管理プロセスの動作について
図３に基づいて説明を行う。サーバ管理プロセスは、サ
ーバプロセスに対する応答処理部と、履歴情報更新処理
部より成る。まず、サーバプロセスに対するリクエスト
応答処理部について説明する。ステップ２０１におい
て、サーバプロセスから自サーバ管理プロセスに対する
メッセージが到着しているかのチェックを行う。サーバ
プロセスからのメッセージが到着していた場合には、ス
テップ２０２において、そのメッセージがサーバプロセ
スが所望の処理を開始する旨のメッセージか、終了した
旨のメッセージかをチェックする。終了メッセージであ
った場合には、まず、ステップ２０３で、図４に示した
ような履歴情報管理テーブルを参照し、最近のｎ単位時
間におけるクライアントプロセスからの処理要求の頻度
が単調減少か否かをチェックする。単調減少であった場
合には、処理要求が減る状況にあると判断し、ステップ
２０５で問い合わせをしてきたサーバプロセスに対し
「終了せよ」の指示を行う。単調減少でなかった場合に
は、現状のサーバプロセス数を適当と判断し、ステップ
２０４で問い合わせをしてきたサーバプロセスに対し
「待機せよ」の指示を行う。

【００１４】ステップ２０２で、開始メッセージであっ
た場合には、まず、ステップ２０６で、図４に示したよ
うな履歴情報管理テーブルを参照し、最近のｎ単位時間
におけるクライアントプロセスからの処理要求の頻度が
単調増加か否かをチェックする。もし、単調増加であっ
た場合は、処理要求が増す状況にあると判断し、ステッ
プ２０７で新規にサーバプロセスを起動する。もし、単
調増加でなかった場合には、なにもしない。

【００１５】次に、履歴情報更新処理部について説明す
る。履歴情報更新処理部は定期的にタイマールーチンか
ら起動される。ステップ２１０において、リクエスト受
付用ポートにメッセージが到着しているかどうかチェッ
クし、到着していた場合には、ステップ２１１にて、こ
こ１単位時間以内の履歴情報を更新する。具体的には、
図４に示すように時間の経過につれてＦＩＦＯ（Ｆｉｒ
ｓｔ ｉｎ Ｆｉｒｓｔ ｏｕｔ）のアルゴリズムに従
って、履歴情報テーブルの最も最近の１単位時間の値
を、増加させる。

【００１６】実施例３．次にこの発明による第３の実施
例について、図５〜図７について説明する。図５はこの
発明による一実施例を示すサーバプロセスの動作を示す
フローチャート、図６はこの発明の一実施例を示すサー
バ管理プロセスの動作を示すフローチャート、図７はこ
の発明による一実施例におけるサーバ管理プロセスが保
持する負荷情報テーブルの例である。ここでは、処理の
種類に対応して、予め数値化された負荷量が設定されて
いる。

【００１７】まず、サーバプロセスの動作について図５
について説明する。尚、図において、図２と同一符号
は、同一または相当部分を示す。ステップ１でサーバプ
ロセスが起動される。ステップ１０２で、サーバプロセ
スは、リクエスト受付用ポートに処理要求が到着してい
るか否かをチェックする。処理要求メッセージが届いて
いた場合は、ステップ３で処理要求メッセージを取り込
む処理を行う。この取り込み処理は複数のサーバプロセ
スが同時に行う可能性があり、自サーバプロセスが取り
込めるか否かは不明なので、ステップ４で実際に取り込
めたか否かをチェックする。ステップ４で処理要求メッ
セージが取り込めなかった場合は、ステップ１０２に戻
る。ステップ４で処理要求メッセージが取り込めた場合
は、ステップ５０５で、サーバ管理プロセスに対し、所
望の処理の開始とその処理の種類を通知する。ステップ
６で実際の所望の処理を行う。ステップ５０７でサーバ
管理プロセスに対し、所望の処理の終了とその処理の種
類を通知する。ステップ１０８でサーバ管理プロセスに
対し、自サーバプロセスの次の処理について指示を求め
る。ステップ１０９で、サーバ管理プロセスからのメッ
セージの内容をチェックする。ステップ１０９でのメッ
セージの内容が「終了」せよであった場合には、ステッ
プ１１０でこのサーバプロセスは終了処理を行い消滅す
る。ステップ１０９でのメッセージの内容が「待機」せ
よであった場合には、ステップ１０２に戻る。また、ス
テップ１０２で、処理要求メッセージが届いていなかっ
た場合は、ステップ１１１で自プロセスが最後にクライ
アントの要求に応じた所望の処理を行ってから、あるい
はサーバ管理プロセスから待機の指示を受けてから一定
の時間が経過しているか否かをチェックする。ステップ
１１１で、一定の時間が経過していた場合には、ステッ
プ１０８の処理を行う。ステップ１１１で一定の時間が
経過していなかった場合には、ステップ１０２に戻る。

【００１８】次に、サーバ管理プロセスの動作について
図６に基づいて説明する。サーバ管理プロセスは、ステ
ップ６０１において、初期化を行う。この初期化では、
システムのコンフィグレーションファイルから許容負荷
の上限値、下限値の情報を読みとる。また、サーバ全体
の負荷を計算し、初期値とする。ステップ６０２では、
サーバプロセス群からのメッセージを受け付けるための
待ち状態に入る。ステップ６０３では、サーバプロセス
から到着したメッセージが、所望の処理の開始を示すも
のか、終了を示すものかのチェックを行う。到着したメ
ッセージが、所望の処理の終了を示すものであった場合
には、ステップ６０４において、図７に示すような負荷
情報管理テーブルから、終了した処理の種類に応じた負
荷の値を求め、積算負荷をその分減少させる。ステップ
６０５において、積算負荷が最小許容負荷よりも小さい
か否かをチェックする。積算負荷が最小許容負荷よりも
小さくなった場合には、ステップ６０６において必要以
上に待ち状態サーバが存在していると判断し、先に問い
合わせてきたサーバプロセスに対し、「終了せよ」の指
示を送り負荷調整をする。積算負荷が最小許容負荷より
も小さくならなかった場合には、ステップ６０７におい
て、問い合わせてきたサーバプロセスに対し、「待機せ
よ」の指示を送出し、ステップ６０２に戻る。ステップ
６０３において、メッセージの種類が、処理の開始であ
った場合には、ステップ６０８において図７で示す負荷
情報管理テーブルから、終了した処理の種類に応じた負
荷の値を求め、積算負荷をその分増加させる。ステップ
６０９において、積算負荷が最大許容負荷よりも大きい
か否かをチェックする。積算負荷が最大許容負荷よりも
大きくなった場合には、待ち状態サーバプロセスが不足
していると判断し、ステップ６１０で、新規にサーバプ
ロセスを起動し、ステップ６１１で問い合わせてきたサ
ーバプロセスに対しては、「待機せよ」の指示を送り、
負荷調整を行う。

【００１９】実施例４．次にこの発明による第４の実施
例について、図８について、説明する。図８は、実施例
１から実施例３までで説明した処理フローにおいて、
「サーバプロセスの起動」の処理に関するステップの部
分を変更したものである。具体的には、実施例１を説明
した図１におけるステップ１６、実施例２を説明した図
３におけるステップ２０７、および実施例３を説明した
図６におけるステップ６１０で示す個所の実施例を示し
たものである。まず、ステップ７０１でサーバプロセス
の合計に１を加算した数が、あらかじめ指定されている
最大サーバプロセス数を越えたか否かをチェックする。
上記、加算値があらかじめ指定されている最大サーバプ
ロセス数より小さかった場合には、ステップ７０２で新
規にサーバプロセスを起動する。また、上記加算値が最
大サーバプロセス数に達していた場合には、新規にプロ
セスを起動することなく戻る。

【００２０】

【発明の効果】この発明は、以上説明したように構成さ
れているので、クライアントプロセスに対するサービス
提供のために常時待機しているサーバプロセスの数がシ
ステムの負荷状況によって決定されるので、クライアン
トプロセスからの処理要求を待たせることなしに応答性
がよく、サービス効率のよいサーバシステムを実現する
ことができる。また、サーバプロセス数をシステム負荷
に連動して増減するようにしたので、単に待ち状態とし
て待機状態にあるサーバプロセスの数、及び待機時間を
極力減らすことができ、システム資源の無駄な消費を回
避することができるという効果を奏する。

【図面の簡単な説明】

【図１】本発明の実施例１におけるサーバ処理方式を示
すフローチャートである。

【図２】本発明の実施例２のサーバ処理方式におけるサ
ーバプロセスのフローチャートである。

【図３】本発明の実施例２のサーバ処理方式におけるサ
ーバ管理プロセスのフローチャートである。

【図４】本発明の実施例２におけるサーバ管理プロセス
の内部に保持される履歴情報テーブルである。

【図５】本発明の実施例３のサーバ処理方式におけるサ
ーバプロセスのフローチャートである。

【図６】本発明の実施例３のサーバ処理方式におけるサ
ーバ管理プロセスのフローチャートである。

【図７】本発明の実施例３におけるサーバ管理プロセス
の内部に保持される負荷情報テーブルである。

【図８】本発明の実施例４のサーバ処理方式におけるサ
ーバ管理プロセスのフローチャートの一部である。

【図９】本発明の対象となるクライアントサーバシステ
ムの構成図である。

【図１０】従来のサーバ処理方式のフローチャートであ
る。

【符号の説明】

１ サーバマシン ２ クライアントマシン ３ ネットワーク ５ サーバプロセス ６ クライアントプロセス ７ リクエスト受付用ポート

Claims (3)

【特許請求の範囲】
1. 【請求項１】 サーバマシンにサービス要求を行う少な
   くとも１台より成るクライアントマシンと、前記サービ
   スをユーザに提供するサーバマシンとが互いに通信接続
   されたクライアント・サーバシステムであって、 前記サーバマシンは、 前記クライアントマシンからのサービス要求受付け手段
   と、 該サービス要求実行に係わるサーバ・プロセス群を管理
   し、該プロセスを生成させ、消滅させる手段と、 プロセス間における通信手段、を提供するオペレーティ
   ングシステム相当手段を含んで成り、前記オペレーティ
   ングシステム相当手段が提供する通信手段を有して構成
   された、サーバプロセスと、サーバ管理プロセスにおい
   て、 前記サーバプロセスは、前記サービス要求実行に係る開
   始、終了を示す旨のメッセージ送出手段を備え、 前記サーバ管理プロセスは、上記メッセージを受信し、
   メッセージ内容に応じて、サーバプロセスに対する、待
   機、生成、消滅を指令する手段を備えたことを特徴とす
   るサーバ処理方式。
2. 【請求項２】 サーバマシンにサービス要求を行う少な
   くとも１台より成るクライアントマシンと、前記サービ
   スをユーザに提供するサーバマシンとが互いに通信接続
   されたクライアント・サーバシステムであって、 前記サーバマシンは、 前記クライアントマシンからのサービス要求受付け手段
   と、 該サービス要求実行に係わるサーバ・プロセス群を管理
   し、該プロセスを生成させ、消滅させる手段と、 プロセス間における通信手段、を提供するオペレーティ
   ングシステム相当手段を含んで成り、前記オペレーティ
   ングシステム相当手段が提供する通信手段を有して構成
   された、サーバプロセスと、サーバ管理プロセスにおい
   て、 前記サーバプロセスは、 前記サービス要求実行に係る開始、終了を示す旨のメッ
   セージ送出手段と、 前記サーバ管理プロセスに対する問い合わせ手段を備
   え、 前記サーバ管理プロセスは、 周期的に起動されて、クライアントマシンから送出され
   待ち状態にある処理要求を監視し、システム負荷情報と
   して記録する手段と、 上記メッセージを受信し、メッセージ内容と、システム
   負荷状態に応じて、サーバプロセスに対する、待機、生
   成、消滅を指令する手段を備えたことを特徴とするサー
   バ処理方式。
3. 【請求項３】 サーバマシンにサービス要求を行う少な
   くとも１台より成るクライアントマシンと、前記サービ
   スをユーザに提供するサーバマシンとが互いに通信接続
   されたクライアント・サーバシステムであって、 前記サーバマシンは、 前記クライアントマシンからのサービス要求受付け手段
   と、 該サービス要求実行に係わるサーバ・プロセス群を管理
   し、該プロセスを生成させ、消滅させる手段と、 プロセス間における通信手段、を提供するオペレーティ
   ングシステム相当手段を含んで成り、前記オペレーティ
   ングシステム相当手段が提供する通信手段を有して構成
   された、サーバプロセスと、サーバ管理プロセスにおい
   て、 前記サーバプロセスは、前記サービス要求実行に係る開
   始、終了と該サービス実行に係わる負荷情報を示す旨の
   メッセージ送出手段と、 前記サーバ管理プロセスに対する問い合わせ手段を備
   え、 前記サーバ管理プロセスは、 前記サーバプロセスからのメッセージを受信し、メッセ
   ージ内容に応じて、サーバプロセスの積算負荷結果を計
   算保持する手段と、 上記メッセージを受信し、メッセージ内容と、積算負荷
   結果に応じて、サーバプロセスに対する、待機、生成、
   消滅を指令する手段を備えたことを特徴とするサーバ処
   理方式。