JP2006189932A - ファイル登録システム及びそのファイル登録方法、そのサーバ、そのプログラム、並びに記憶媒体 - Google Patents

Abstract

【課題】ジョブ発生量が予測可能な期間において、投入されたジョブを多段処理で実施するときのスループットが向上するスレッドの多重化の最適値を得ると共に、その最適値を得る際の負荷を低くする。
【解決手段】電子帳票登録システム１１は、ホストコンピュータ１５から受信した入力ファイルを帳票変換部１１３、帳票仕分け部１１４、帳票送信部１１５から成る複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録する。最適化テンプレート定義設定ファイルに予め設定された最適化対象期間中の測定時間となったとき、処理部スレッド数最適化処理を起動して、変化させた処理部スレッド数Ｗ_ｋ別にＡ_ｋの値を取得し、このＡ_ｋの平均値が最大となり、最高のパフォーマンスを得ることができるＷ_ｋの値を処理部スレッド数に決定し、このＷ_ｋの値を最適値として最適化テンプレートファイルに保管する。
【選択図】図１

Description

本発明は、ファイル登録システム及びそのファイル登録方法、そのサーバ、そのプログラム、並びに記憶媒体に関し、特に、期間毎にシステムへの運用負荷が異なるファイル登録システム及びそのファイル登録方法、そのサーバ、そのプログラム、並びに記憶媒体に関する。

近年、電子帳票登録システムは、本システムの構成要素であるサーバマシンのＣＰＵ多重化、ディスクアクセススピードの高速化に伴い、複数スレッドによるジョブの並行処理が可能となり、スループットの向上が図られるようになった。

一方、スレッドの多重化についてはシステムの負荷、マシンスペック等により予め最適値を決定しておくことは難しい。このため、スレッドの多重化の最適値を決定する様々な方法が従来技術で開示されている。

例えば、実際のジョブ処理データを蓄積し、各ジョブクラスへのイニシエータの割当て（ジョブ多重度）を設定する第１の従来技術（例えば、特許文献１参照）や、ジョブの状況に応じて動的にスレッドの多重度を変更する第２の従来技術（例えば、特許文献２参照）が開示されている。
特開平２−４２５３９号公報 特開２０００−２１５０６９号公報

しかしながら、第１の従来技術及び第２の従来技術のように、常時ジョブの実施状況を監視すると、監視行為自体がシステムに負荷を掛けることとなる。さらに、予めユーザの業務との関係でシステムへの負荷が大きい繁忙期（例えば月末や期末等）及びその期間中に投入されるジョブの内容が予測できる場合、第１の従来技術及び第２の従来技術のようなリアルタイム修正よりも、設定期間に応じて修正を行った方がより大きなスループットを得ることができる。

また、複数のキューに対して順番にジョブが投入され処理が実施されるような多段処理においては、高負荷が掛かる処理実施単位のキューにジョブが滞留してしまいシステムのリソースが有効に利用されないという問題が発生するが、第１の従来技術及び第２の従来技術はこのような多段処理におけるスループットの向上について何ら言及していない。

本発明の目的は、ジョブ発生量が予測可能な期間において、投入されたジョブを多段処理で実施するときのスループットが向上するスレッドの多重化の最適値を得ると共に、その最適値を得る際の負荷を低くすることができるファイル登録システム及びそのファイル登録方法、そのサーバ、そのプログラム、並びに記憶媒体を提供することにある。

上記の目的を達成するため、請求項１記載のファイル登録システムは、コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムにおいて、前記システムへの運用負荷が異なる期間を予め設定する期間設定手段と、前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得手段と、前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定手段と、前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行手段とを備えることを特徴とする。

請求項５記載のファイル登録方法は、コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムのファイル登録方法において、前記システムへの運用負荷が異なる期間を予め設定する期間設定ステップと、前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得ステップと、前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定ステップと、前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行ステップとを備えることを特徴とする。

請求項６記載のサーバは、コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバにおいて、前記システムへの運用負荷が異なる期間を予め設定する期間設定手段と、前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得手段と、前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定手段と、前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行手段とを備えることを特徴とする。

請求項７記載のプログラムは、コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムのファイル登録方法をコンピュータにより実行するプログラムにおいて、前記システムへの運用負荷が異なる期間を予め設定する期間設定モジュールと、前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得モジュールと、前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定モジュールと、前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行モジュールとを備えることを特徴とする。

本発明によれば、システムへの運用負荷が異なる期間を予め設定し、この設定された一の期間中の所定の測定期間となったときにシステムが備える複数の処理部別スレッド優先度を変化させ、その変化した処理部別スレッド優先度毎にスループットを取得し、この取得したスループットが最大となる処理部別スレッド優先度を上記一の期間における処理部別スレッド優先度に決定し、上記一の期間となったときに決定された処理部別スレッド優先度で上記複数の処理部によるスレッド処理を実行するので、ジョブ発生量が予測可能な期間において、投入されたジョブを多段処理で実施するときのスループットが向上するスレッドの多重化の最適値を得ると共に、常態的に測定の負荷を掛けることなく、その最適値を得る際の負荷を低くすることができる。

好ましくは、システムは、複数の処理部の負荷の度合いを示すパターン毎にスレッド優先度の複数の組み合わせが設定されたシナリオを備え、変化した処理部別スレッド優先度毎にスループットを取得する際に、算出された複数の処理部別の平均処理待ち時間に基づき上記パターンの一つを選択し、この選択されたパターンのシナリオに設定されたスレッド優先度の複数の組み合わせを順に処理部別スレッド優先度に設定するので、ジョブ発生量が予測可能な期間別にスループットが向上するスレッドの多重化の最適値を得ることができる。

好ましくは、上記測定期間となったときに複数の処理部のスレッド数を変化させ、その変化したスレッド数毎にスループットを取得し、この取得したスループットが最大となるスレッド数を上記一の期間における複数の処理部のスレッド数に決定し、上記一の期間となったときに決定されたスレッドで上記複数の処理部によるスレッド処理を実行するので、ジョブ発生量が予測可能な期間において、複数キューを持ち、複数の処理部による多段処理をする場合の負荷を平衡化することができ、よりスループットを向上することができる。

好ましくは、上記測定期間中にスレッド処理が行われた全イベントについて取得された上記複数の処理部別の処理時間と、上記全イベントのジョブの種別毎に算出された平均処理時間に基づいてイベント別優先度を決定し、上記一の期間となったときに上記決定されたイベント別優先度で上記複数の処理部によるスレッド処理をするので、ジョブ発生量が予測可能な期間において、スレッド処理の実施に要する時間が短いジョブについては、優先的に処理を実施することができ、システム全体に滞留するジョブ量を減らすことができる。

以下、本発明の実施形態を図面を用いて詳述する。

図１は、本発明の第１の実施の形態に係るファイル登録システムとしての電子帳票登録システムの構成を概略的に示すブロック図である。

図１の電子帳票登録システム１１は、１つのプラットホーム（サーバ）から構成されるものであって、ネットワークとしてのイーサネット（登録商標）を介して他のプラットホームである入力ファイルを電子帳票登録システム１１に送信するホストコンピュータ１５と、ホストコンピュータ１５からの入力データを電子帳票システム１１の独自ファイルフォーマットに変換するための変換用データ、変換されたデータの仕分け方法が記載された仕分けデータ、仕分けされた電子帳票の格納先データ、及びファイル名別の個別イベントの優先順位を保管するＤＢＭＳ１２１を備える電子帳票マネージャシステム１２と、上記変換電子帳票の保管先である電子帳票保管システム１３と、電子帳票保管システムで保管されている電子帳票を取得可能なＷＥＢサーバ１４とに接続する。

尚、本実施の形態では、ネットワーク接続される１つのプラットホーム（サーバ）上に一つの電子帳票登録システムが構成されるが、これに限定されるわけでなく、用途や目的に応じて、同一のプラットホーム内に複数の電子帳票登録システムを構成したり、異なるプラットホームにそれぞれ別の電子帳票登録システムを構成したりしてもよい。

図１において、電子帳票登録システム１１は、ホストコンピュータ１５から送信される入力ファイルのパスである入力ファイル検出ディレクトリ１１２１と、入力ファイル検出ディレクトリに送信された入力ファイルを定期的に検出する帳票検出部１１２と、入力ファイルを電子帳票マネージャシステム１２の備えるＤＢＭＳ１２１に基づき電子帳票システム１１の独自ファイルフォーマットへの変換を施す帳票変換部１１３と、変換された電子帳票内に設定されたキーワードにより異なる帳票格納先別に電子帳票を分割し仕分けする処理を施す帳票仕分部１１４と、仕分けられた電子帳票を電子帳票マネージャシステム１２のＤＢＭＳ１２１に保管してある所定の格納先（ＷＥＢサーバ１４）に配信する帳票送信部１１５とを備える。

帳票変換部１１３、帳票仕分部１１４、及び帳票送信部１１５からなる各処理部は、それぞれ別スレッド上で稼動し、非同期にシステム１１がホストコンピュータ１５から受信した入力ファイルから生成されたジョブオブジェクト（以下「イベント」という。）の送受信を行っている。また、帳票変換部１１３、帳票仕分け部１１４、及び帳票送信部１１５は、夫々から送信されるイベントを優先順位を付けた待ち行列とする優先順位付キュー１１３１，１１４１，１１５１を持つ。

また、電子帳票登録システム１１は、帳票検出部１１２から送信されるイベントを優先順位を付けた待ち行列とする優先順位付付キュー１１１１を持ち、優先順位付キュー１１１１，１１３１，１１４１，１１５１にあるイベントをその優先順位の順番に取り出して処理するイベント制御部１１１１と、システムの運用負荷が異なる期間（以下「最適化対象期間」という。）毎に高いスループットを得るための各種パラメータを設定する最適化テンプレートファイル（図６（ｃ））及び上記最適化対象期間や各処理部でのスレッド処理に用いられる最大ワークパス（一時作業領域）数等を定義する設定ファイル（図６（ａ），（ｂ））を記録する記録部１１０を備える。

記録部１１０で記録される設定ファイルの１つであるワークパス定義用設定ファイルは、最大いくつのワークパスが各処理部のスレッド処理に用いることができるかが記載される。例えば、図６（ｂ）に示すようにワークパス定義用設定ファイルでワークパス数が１０であると定義されているとき、帳票変換部１１３、帳票仕分け部１１４、帳票送信部１１５の３つの優先順位付キューにはそれぞれ最大１０の処理実施スレッドがプールできる。また、最適化対象期間毎にワークパス定義用設定ファイルに記載されるワークパスのうちいくつのワークパスを用いてスレッド処理を行うかが最適化テンプレートファイルに記載される。例えば、図６（ｃ）に示すように、優先順位１の最適化対象期間においては、５つのワークパス数を用いてスレッド処理を行う旨が記載されている。

また、記録部１１０で記録される設定ファイルの１つである最適化テンプレート定義用設定ファイルは、最適化対象期間を優先度をつけて記載するファイルであり、また、最適化対象期間別に最適化テンプレートファイル中の各種パラメータの値を見直して最適化する際のスケジュール（以下「最適化実施スケジュール」という。）を記載している。

例えば、図６（ａ）に示すように、優先順位が「１」の行については、最適化対象期間として１１／１５から１２／３１の平日（月〜金）が記載され、最適化実施スケジュールとして、最適化対象期間となる度に最適化を実施し（見直し実施：Ｙ）、最適化の実施日数は最適化対象期間となった後の最初の平日の４日間であり、毎日２０:００から１０時間(翌日０６：００)の間を測定時間として、毎朝０７:００に見直し処理（図１０）を実施する設定が記載されている。また、優先順位「３」の行はデフォルトの最適化設定であって、最適化対象期間として全期間が記載され、最適化実施スケジュールとして、最適化対象期間となった後の最初の１回目だけ最適化を実施し（見直し実施：Ｎ）、最適化の実施日数は最適化対象期間が適用された後の週末を含む最初の８日間であり、毎日２０：００から８時間（翌日０４：００）の間を測定期間として、毎朝０７：００に後述する見直し処理（図１０）を実施する設定が記載されている。

各最適化対象期間の各種パラメータが最適化テンプレートファイルに記載されている場合、システム１１は最適化対象期間毎に最適化テンプレートファイルの各種パラメータを読み込み、その読み込んだ各種パラメータを帳票変換部１１３、帳票仕分け部１１４、及び帳票送信部１１５から成る各処理部に適用した後に、イベント処理を行う。

図２〜図５は、図１のシステム１１により実行されるイベント処理の手順を示すフローチャートである。

図２において、まず入力ファイル検出ディレクトリ１１２１を定期的に監視して、入力ファイルを検出する帳票検出部１１２により、ホストコンピュータ１５からネットワーク（イーサネット（登録商標））経由で転送された入力ファイル検出ディレクトリ１１２１にある入力ファイルを検出すると（ステップＳ２１１）、イベントを生成する（ステップＳ２１２）。次に、後述する図１５のイベント優先順位設定処理により、電子帳票システムマネージャ１２経由でＤＢＭＳ１２１から入力ファイル名をキーとして検索された変換情報、仕分け情報、配信先情報、優先順位情報、優先実行マークをイベントに格納した後、最適化テンプレートファイルに記載された処理部別スレッドの優先順位及び、ＤＢＭＳ１２１中に保管された個別イベントの優先順位を適用する（ステップＳ２１３）。

その後、そのイベント優先順位と共に優先順位付キュー１１１１にイベントをポストした後（ステップＳ２１４）、ステップＳ２１１からの処理を繰り返す。

次に、イベント制御部１１１により、ステップＳ２１４で優先順位付キュー１１１１にポストされたイベントを優先順位の高いものから優先して優先順位付キュー１１１１から取得し（ステップＳ２２１）、そのイベントの処理を行うためのワークパスを要求する（ステップＳ２２２）。このとき、ワークパス定義用設定ファイル（図６（ｂ））に記載されるワークパスのすべてで各処理部の処理が行われているときは、貸し付けられるワークパスが生じるまで待機する。また、帳票変換部１１３を実装するスレッドの多重度は、後述する図１２のスレッド数登録処理により最適化対象期間毎に最適化されており、最適化対象期間内で最もパフォーマンスが得られる設定となっている。

その後、イベント制御部１１１により、貸し付けられたワークパスがステップＳ２２１で取得したイベントにセットされ（ステップＳ２２３）、イベント処理開始のタイムスタンプを押した後（ステップＳ２２４）、イベント優先順位と共に優先順位付キュー１１３１にイベントをポストした後（ステップＳ２２５）、ステップＳ２２１からの処理を繰り返す。

次に、帳票変換部１１３により、ステップＳ２２５でポストされたイベントを優先順位順に優先順位付キュー１１３１から取得し（図３のステップＳ２３１）、帳票変換処理開始のタイムスタンプを押した後（ステップＳ２３２）、そのイベントに対するスレッド処理の優先度を最適化テンプレートファイルの記載に基づきインクリメントした後に（ステップＳ２３３）、そのイベントの帳票変換処理を施し（ステップＳ２３４）、イベント制御部１１１にイベントをポストする（ステップＳ２３５）。

ステップＳ２３５で帳票変換部１１３からポストがあったときに、イベント制御部１１１により帳票変換処理終了のタイムスタンプを押し（ステップＳ２２６）、その後イベント優先順位と共に優先順位付キュー１１４１にイベントをポストすると同時に（ステップＳ２２７）、帳票変換部１１３においてイベント処理可能なスレッドができたと判断して、ステップＳ２３１からの処理を繰り返す。

次に、帳票仕分け部１１４により、ステップＳ２２７でポストされたイベントを優先順位順に優先順位付キュー１１４１から取得する（図４のステップＳ２４１）。このとき、帳票仕分け部１１４を実装するスレッドの多重度は、後述するスレッド数登録処理（図１２）により最適化対象期間毎に最適化されており、最適化対象期間内で最もパフォーマンスが得られる設定となっている。

次に、帳票仕分け処理開始のタイムスタンプを押した後（ステップＳ２４２）、そのイベントに対するスレッド処理の優先度を最適化テンプレートファイルの記載に基づきインクリメントした後に（ステップＳ２４３）、そのイベントの帳票仕分け処理を施し（ステップＳ２４４）、イベント制御部１１１にイベントをポストする（ステップＳ２４５）。

ステップＳ２４５で帳票仕分け部１１４からポストがあったときに、イベント制御部１１１により帳票仕分け処理終了のタイムスタンプを押し（ステップＳ２２８）、その後イベント優先順位と共に優先順位付キュー１１５１にイベントをポストすると同時に（ステップＳ２２９）、帳票仕分け部１１４においてイベント処理可能なスレッドができたと判断して、ステップＳ２４１からの処理を繰り返す。

次に、帳票送信部１１５により、ステップＳ２２９でポストされたイベントを優先順位順に優先順位付キュー１１５１から取得する（図５のステップＳ２５１）。このとき、帳票送信部１１５を実装するスレッドの多重度は、後述するスレッド数登録処理（図１２）により最適化対象期間毎に最適化されており、最適化対象期間内で最もパフォーマンスが得られる設定となっている。

次に、帳票送信処理開始のタイムスタンプを押した後（ステップＳ２５２）、そのイベントに対するスレッド処理の優先度を最適化テンプレートファイルの記載に基づきインクリメントした後に（ステップＳ２５３）、そのイベントの帳票送信処理を施し（ステップＳ２５４）、イベント制御部１１１にイベントをポストする（ステップＳ２５５）。

ステップＳ２５５で帳票送信部１１５からポストがあったときに、イベント制御部１１１により帳票送信処理終了のタイムスタンプを押し（ステップＳ２２１０）、その後イベントからワークパスを返却し（ステップＳ２２１１）、後述する図７のロギング処理を行った後に（ステップＳ２２１２）、このイベント処理を終了する（ステップＳ２２１３）。このとき同時に、帳票送信部１１５においてイベント処理可能なスレッドができたと判断して、ステップＳ２５１からの処理を繰り返す。

図７は、図２のステップＳ２２１２のロギング処理の手順を示すフローチャートである。

図７において、まず、図２のステップＳ２２１１でイベントからワークパスが返却され（ステップＳ４１０でＹＥＳ）、且つ、現在、最適化テンプレート定義用設定ファイル（図６（ａ））に記載された最適化対象期間中の指定された測定時間であるときに（ステップＳ４１１でＹＥＳ）、その返却されたイベントについて、図３のステップＳ２３２，Ｓ２２６、図４のステップＳ２４２，Ｓ２２８、図５のステップＳ２５２，Ｓ２２１０において各処理部の処理開始時及び処理終了時に押されたタイムスタンプの値から各処理部における待ち時間、即ち、各キュー１１３１，１１４１，１１５１にイベントがポストされてから、実際にそのイベントが各処理部で処理されるまでの時間を除いたイベントの純粋処理時間を算出し（ステップＳ４１２）、ステップＳ４１２で算出された純粋処理時間をそのイベントのジョブである入力ファイル名でロギングする（ステップＳ４１３）。ここで、ロギングするとは、ロギングデータ中にデータを保存することをいう。

次に、上記タイムスタンプの値から各処理部における待ち時間を夫々算出し（ステップＳ４１４）、処理部毎に待ち時間をロギングした後（ステップＳ４１５）、一の測定期間においてワークパスがｋ回返却されたことを示す処理量カウンタＡ_ｋの値を一つインクリメントし（ステップＳ４１６）、本処理を終了する。

一方、ステップＳ４１１の判別の結果、現在、最適化対象期間中の指定された測定時間でないときは、そのまま本処理を終了する。

図７の処理によれば、指定された測定期間中に各処理部で処理が行われた全てのイベントは、入力ファイル名別に各処理部における待ち時間を除いた純粋処理時間（ステップＳ４１３）、及び各処理部別の待ち時間（ステップＳ４１５）がロギングされ、また測定時間内に返却されたワークパスの数をカウントする処理量カウンタＡ_ｋもロギングされる（ステップＳ４１６）ので、後述する図１０の見直し処理を適切に行うことができる。

図８は、図１のシステム１１により実行される最適化対象期間切り替えスケジュール処理の手順を示すフローチャートである。

図８において、まず、システム１１は起動すると、記録部１１０が保存する設定ファイルの一つである最適化テンプレート定義用設定ファイル（図６（ａ））の設定を読み込み（ステップＳ５１１）、後述する図９の最適化対象期間切り替え処理により、最適化対象期間の切り替えを行う（ステップＳ５１２）。

次に、上記最適化テンプレート定義用設定ファイルに記載されている最適化対象期間の切り替わり時期に後述する図９の最適化対象期間切り替え処理が呼び出されるようにスケジューリングし（ステップＳ５１３）、本処理を終了する。

図９は、システム１１により実行される最適化対象期間切り替え処理の手順を示すフローチャートである。

図９において、まず、システム１１は、設定ファイルの一つである最適化テンプレート定義用設定ファイル（図６（ａ））に記載されているいずれかの最適化対象期間への切り替わり時期となったとき（ステップＳ５２１でＹＥＳ）、その最適化対象期間について、最適化テンプレートファイルに記載される値の見直しが必要か否かを判別する（ステップＳ５２２）。この判別は、最適化テンプレート定義用設定ファイルで見直し処理がＹとなっているかＮとなっているかによって判断される。

ステップＳ５２２の判別の結果、見直しが不要である場合は、最適化テンプレートファイルにその最適化対象期間における値が存在するか否かを判別し（ステップＳ５２４）、見直しが必要である場合は、ステップＳ５２３の処理に進む。

ステップＳ５２４の判別の結果、最適化テンプレートファイルに上記最適化対象期間における値が存在しないときは、ステップＳ５２３の処理に進み、最適化テンプレートファイルに値が存在するときは、既存の最適化テンプレートファイルの値をシステム１１に適用して（ステップＳ５２６）、本処理を終了する。

次に、ステップＳ５２３において、ロギングデータが初期化される。その後、後述する図１０の見直し処理が最適化対象期間内と最適化対象期間終了後１日目に起動されるようにスケジューリングして（ステップＳ５２５）、本処理を終了する。

図９の処理によれば、最適化テンプレートファイルに記載されている値の見直しが必要である場合（ステップＳ５２２でＹＥＳ）、見直し処理は最適化対象期間内と最適化対象期間終了後１日目に起動されるようにスケジューリングされるので（ステップＳ５２５）、常態的に測定の負荷を掛けることなく、その最適値を得る際の負荷を低くすることができる。

ここで、ステップＳ５２５で最適化対象期間内に見直し処理が起動されるようにスケジューリングするのは、見直し処理で得られる最適値を導出するための測定値を取得するためであり、最適化対象期間終了後１日目に見直し処理が起動されるようにスケジューリングするのは、取得した測定値から導出された最適値をテンプレート化してその値でロックするためである。

本処理を、システム起動直後に最適化テンプレート定義用設定ファイル（図６（ａ））にある優先順位３の最適化対象期間に切り替わった場合を用いて具体的に説明する。

まず、システム１１は、最適化テンプレート定義用設定ファイルで優先順位３の見直しは不要(Ｎ)となっているため、ステップＳ５２２で見直し不要と判別し、ステップＳ５２４で最適化テンプレートファイルにその最適化対象期間における値が存在するか否かを判別する。

システム１１は、起動直後は初期状態であり、最適化テンプレートファイルにその最適化対象期間における値は存在しないため、ステップＳ５２３の処理に進んでロギングデータを初期化し、ステップＳ５２５で見直し処理の起動がスケジューリングされて、本処理は終了する。

その後、ステップＳ５２５でスケジューリングされた期間となったときに、システム１１は後述する図１０の見直し処理を行い、優先順位３の最適化対象期間における最適値を最適化テンプレートファイル中にロックする。この見直し処理は、測定期間中に行われる前述の図７のロギング処理によりロギングされた測定値を用いて最適値を導出する。

その後、再度優先順位３の最適化対象期間に切り替わると、システム１１は、まず、最適化テンプレート定義用設定ファイル（図６（ａ））で優先順位３の見直しは不要(Ｎ)となっているため、ステップＳ５２２で見直し不要と判別し、上述したように、すでに優先順位３の最適化対象期間における最適値は最適化テンプレートファイル中にロックされているため、ステップＳ５２４で最適化テンプレートファイルにその最適化対象期間における最適値が存在すると判断し、ステップＳ５２６でその最適化テンプレートファイルの値をシステム１１に適用して、本処理を終了する。

図１０は、システム１１により実行される見直し処理の手順を示すフローチャートである。

本処理は、見直し処理の起動がスケジューリングされた期間となると起動する。

図１０において、まず、システム１１は、現在、図９のステップＳ５２４で見直し処理の起動がスケジューリングされた期間（最適化対象期間終了後１日目）への切り替わり時期であるか判別し（ステップＳ５３１）、この切り替わり時期でないときは、後述する図１１の処理部スレッド数最適化処理により各処理部のスレッド数を最適化して（ステップＳ５３２）、後述する図１３の処理部別スレッド優先順位最適化処理により処理部別スレッドの優先順位を最適化した後に（ステップＳ５３３）、ロギングデータ中の処理量カウンタＡ_ｋの値を初期化して（ステップＳ５３９）、本処理を終了する。これにより、この最適化対象期間の測定期間中に図２〜図５のイベント処理が実施されることにより、ステップＳ５３２のスレッド数最適化処理及びＳ５３３の処理別スレッド優先度最適化処理で最適化テンプレートファイルの値が変更される。

一方、ステップＳ５３１の判別の結果、現在、上記切り替わり時期であるときは、、図１２の処理部スレッド数登録処理により、測定期間中にロギングされた測定値から処理部別スレッド数の最適値を導出して、これを最適化テンプレートファイルに保存（ロック）する（ステップＳ５３６）。その後、図１４の処理部別スレッド優先順位登録処理により、同じく測定期間中にロギングされた測定値から処理部別スレッド優先順位の最適値を導出して、これを最適化テンプレートファイルに保存（ロック）する（ステップＳ５３７）。これにより、最適化対象期間毎に処理部別スレッド数及び処理部別スレッド優先度を最適化テンプレートファイルに保存（ロック）することができる。

次に、後述する図１７のイベント優先度最適化処理により、上記ロックされた後に得られた測定値に基づいて、優先実行すべき入力ファイル（個別イベントの優先順位）を判別し、最適化テンプレートファイルに保存（ロック）する（ステップＳ５３８）。これにより、最適化対象期間毎に最適な個別イベントの優先順位を最適化テンプレートファイルに保存（ロック）することができる。

その後、ロギングデータを初期化して（ステップＳ５３９）、本処理を終了する。

図１１は、図１０のステップＳ５３２の処理部スレッド数最適化処理の手順を示すフローチャートである。

本処理は、図１０のステップＳ５３１で見直し処理の切り替わり時期であると判別される毎に起動する。以下、説明を簡略化するため、具体例として、最適化テンプレート定義用設定ファイルに最適化実施スケジュールの実施日数として８日間が指定され、且つ最適なスレッド数が５である場合について説明する。また、システム１１は３つのＣＰＵを有しており、処理部スレッド数の初期値Ｗ_ｓはＣＰＵの数に１を加えた値である４とする。

まず、１日目の測定期間（ｋ＝１）となり、本処理を起動すると、処理量カウンタＡ_ｋがロギングデータ中に存在するか否かを判別する（ステップＳ６１１）。本具体例では、測定期間が開始してから本処理実行時までの間に、イベント処理が一度も行われておらず、ロギングデータ中に処理量カウンタＡ_ｋはないため（ステップＳ６１１でＮＯ）、前回のイベント処理における処理部スレッド数Ｗ_ｋ＋１（＝Ｗ_２）を初期値Ｗ_ｓ（＝４）として（ステップＳ６１２）、本処理を終了する。

次に、２日目の測定期間（ｋ＝２）となり、本処理を起動したとき、処理量カウンタＡ_ｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間２日目が開始してから本処理実行時までの間に、イベント処理が１０００回行われており、ロギングデータ中に処理量カウンタＡ_２（＝１０００）があるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ_２の値及び処理部スレッド数Ｗ_２を取得する（ステップＳ６１３）。

その後、処理量カウンタＡ_ｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、現時点でイベント処理が１回しか行われておらず、ロギングデータ中に処理量カウンタＡ_１のみが保管され、その前に行われたイベント処理による処理量カウンタＡ_ｋ−１はないため（ステップＳ６１４でＮＯ）、処理部スレッド数Ｗ_ｋ＋１（＝Ｗ_３）＝Ｗ_ｋ＋１（＝５）として（ステップＳ６１５）、本処理を終了する。

次に、３日目の測定期間（ｋ＝３）となり、本処理を起動したとき、処理量カウンタＡ_ｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間３日目が開始してから本処理実行時までの間に、イベント処理が１５００回行われており、ロギングデータ中に処理量カウンタＡ_３（＝１５００）はあるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ_３の値及び処理部スレッド数Ｗ_３を取得する（ステップＳ６１３）。

その後、処理量カウンタＡ_ｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、２日目にもイベント処理が行われており、ロギングデータ中に今回の処理量カウンタＡ_３のみならず、前回の処理量カウンタＡ_２も保管しているため（ステップＳ６１４でＹＥＳ）、前回の処理量カウンタＡ_２及び前回の処理部スレッド数Ｗ_２を取得する（ステップＳ６１６）。

その後、ステップＳ６１３で取得した処理量カウンタＡ_３の値より処理量カウンタＡ_２の値の方が大きいか否かを判別する（ステップＳ６１７）。ここで、Ａ_ｋの値とは、測定期間ｋ日目が開始してから本処理実行時までの間に返却されたワークパスの数であり、本具体例においては、Ａ_３≧Ａ_２であるので（ステップＳ６１７でＹＥＳ）、ステップＳ６１９に進み、次に、Ｗ_３が最大スレッド数Ｍ未満であるか否かを判別する。本具体例では、２日目のステップＳ６１５の処理により、Ｗ_３は５に設定されている一方、最大スレッド数は１０であるため、Ｗ_３＜Ｍとなり（ステップＳ６１９でＹＥＳ）、次回（４日目）の処理部スレッド数Ｗ_４＝Ｗ_３＋（Ｗ_３−Ｗ_２）＝６に設定する（ステップＳ６１１１）。

その後、Ｗ_ｋ＋１とＷ_ｋを比較すると（ステップＳ６１１２）、Ｗ_４（＝６）＞Ｗ_３（＝５）であるので、各処理部におけるスレッド数を一つずつ増加させて（ステップＳ６１１５）、本処理を終了する。

次に、４日目の測定期間（ｋ＝４）となり、本処理を起動したとき、処理量カウンタＡ_ｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間４日目が開始してから本処理実行時までの間に、イベント処理が１２００回行われており、ロギングデータ中に処理量カウンタＡ_４（＝１２００）があるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ_４の値及び処理部スレッド数Ｗ_４を取得する（ステップＳ６１３）。

その後、処理量カウンタＡ_ｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、３日目にもイベント処理が行われており、ロギングデータ中に今回の処理量カウンタＡ_４のみならず、前回の処理量カウンタＡ_３も保管しているため（ステップＳ６１４でＹＥＳ）、前回の処理量カウンタＡ_３及び前回の処理部スレッド数Ｗ_３を取得する（ステップＳ６１６）。

その後、ステップＳ６１３で取得した処理量カウンタＡ_４の値より処理量カウンタＡ_３の値の方が大きいか否かを判別する（ステップＳ６１７）。本具体例においては、Ａ_４＜Ａ_３であるので（ステップＳ６１７でＮＯ）、次回の処理部スレッド数Ｗ_５＝Ｗ_４−１＝Ｗ_３＝５として（ステップＳ６１８）、本処理を終了する。

次に、５日目の測定期間（ｋ＝５）となり、本処理を起動したとき、処理量カウンタＡ_ｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間５日目が開始してから本処理実行時までの間に、イベント処理が１５００回行われており、ロギングデータ中に処理量カウンタＡ_５（＝１５００）があるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ_５の値及び処理部スレッド数Ｗ_５を取得する（ステップＳ６１３）。

その後、処理量カウンタＡ_ｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、４日目にもイベント処理が行われており、ロギングデータ中に今回の処理量カウンタＡ_５のみならず、前回の処理量カウンタＡ_４も保管しているため（ステップＳ６１４でＹＥＳ）、前回の処理量カウンタＡ_４及び前回の処理部スレッド数Ｗ_４を取得する（ステップＳ６１６）。

その後、ステップＳ６１３で取得した処理量カウンタＡ_５の値より処理量カウンタＡ_４の値の方が大きいか否かを判別する（ステップＳ６１７）。本具体例においては、Ａ_５≧Ａ_４であるので（ステップＳ６１７でＹＥＳ）、次に、Ｗ_５が最大スレッド数Ｍ未満であるか否かを判別する（ステップＳ６１９）。本具体例では、４日目のステップＳ６１５の処理により、Ｗ_５は５に設定されている一方、最大スレッド数は１０であるため、Ｗ_５＜Ｍとなり（ステップＳ６１９でＹＥＳ）、次回（６日目）の処理部スレッド数Ｗ_６＝Ｗ_５＋（Ｗ_５−Ｗ_４）＝４に設定する（ステップＳ６１１１）。

その後、Ｗ_ｋ＋１とＷ_ｋを比較すると（ステップＳ６１１２）、Ｗ_５（＝５）＜Ｗ_４（＝６）であるので、各処理部におけるスレッド数を一つずつ削除させて（ステップＳ６１１６）、本処理を終了する。

次に、６日目の測定期間（ｋ＝６）となり、本処理を起動したとき、処理量カウンタＡ_ｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間６日目が開始してから本処理実行時までの間に、イベント処理が１０００回行われており、ロギングデータ中に処理量カウンタＡ_６（＝１０００）があるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ_６の値及び処理部スレッド数Ｗ_６を取得する（ステップＳ６１３）。

その後、処理量カウンタＡ_ｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、５日目にもイベント処理が行われており、ロギングデータ中に今回の処理量カウンタＡ_６のみならず、前回の処理量カウンタＡ_５も保管しているため（ステップＳ６１４でＹＥＳ）、前回の処理量カウンタＡ_５及び前回の処理部スレッド数Ｗ_５を取得する（ステップＳ６１６）。

その後、ステップＳ６１３で取得した処理量カウンタＡ_６の値より処理量カウンタＡ_５の値の方が大きいか否かを判別する（ステップＳ６１７）。本具体例においては、Ａ_６＜Ａ_５であるので（ステップＳ６１７でＮＯ）、次回の処理部スレッド数Ｗ_７＝Ｗ_５（＝５）とする（ステップＳ６１８）。

その後、Ｗ_ｋ＋１とＷ_ｋを比較すると（ステップＳ６１１２）、Ｗ_７（＝５）＞Ｗ_６（＝４）であるので、各処理部におけるスレッド数を一つずつ増加させて（ステップＳ６１１５）、本処理を終了する。

以降の７日目、８日目においても同様の処理がおこなわれ、処理部スレッド数は５をはさむ４から６の間で推移する。

尚、本具体例では、ステップＳ６１１２でＷ_ｋ＋１とＷ_ｋを比較した結果、両者が等しい値であるケースは存在しなかったが、図１１に示すように、この場合（Ｗ_ｋ＋１＝Ｗ_ｋ）、各処理部スレッドの数は維持してそのまま本処理を終了する。

引き続き、図１０のステップＳ５３５で最適化対象期間の終了後１日目になったときに起動する処理部スレッド数登録処理が上記具体例について行われた場合について説明する。

図１２は、図１０のステップＳ５３６の処理部スレッド数登録処理の手順を示すフローチャートである。

図１２において、まず、処理部スレッド数Ｗ_ｋの値別に処理量カウンタＡ_ｋの値の平均を算出し、その平均値が最大値となり、最高のパフォーマンスをえた処理部スレッド数Ｗｋを決定する（ステップＳ６２１）。本具体例では、（Ｗ_２，Ａ_２）＝（４，１０００）、（Ｗ_３，Ａ_３）＝（５，１５００）、（Ｗ_４，Ａ_４）＝（６，１２００）、（Ｗ_５，Ａ_５）＝（５，１５００）、（Ｗ_６，Ａ_６）＝（４，１０００）、（Ｗ_７，Ａ_７）＝（５，１５００）、（Ｗ_８，Ａ_８）＝（６，１２００）である。従って、Ｗ_ｋ＝４のとき、処理量カウンタＡ_ｋの値の平均値は１０００、Ｗ_ｋ＝５のとき、処理量カウンタＡ_ｋの値の平均値は１５００、Ｗ_ｋ＝６のとき、処理量カウンタＡ_ｋの値の平均値は１２００と計算され、平均値が最大値（＝１５００）となる処理部スレッド数Ｗ_ｋ＝５が最高のパフォーマンスを得るものに決定される。次に、その決定された処理部スレッド数Ｗ_ｋの値を最適値に設定し（ステップＳ６２２）、この最適値に設定された処理部スレッド数Ｗ_ｋの値を最適化対象期間別に処理部スレッド数の値を保管する最適化テンプレートファイルに保管し（ステップＳ６２３）、本処理を終了する。

以上、図１１及び図１２の処理によれば、最適化テンプレート定義設定ファイル（図６（ａ））に予め設定された最適化対象期間中の測定時間となったとき、即ち、見直し処理の切り替わり時期であるときに（図１０のステップＳ５３１でＹＥＳ）、図１１の処理部スレッド数最適化処理を起動して、変化させた処理部スレッド数Ｗ_ｋ別にＡ_ｋの値を取得し（図１１のステップＳ６１３）、この取得した処理部スレッド数別Ａ_ｋの平均値が最大となり、最高のパフォーマンスを得ることができるＷ_ｋの値を処理部スレッド数に決定し（図１２のステップＳ６２１）、この処理部スレッド数Ｗ_ｋの値を最適値として最適化テンプレートファイルに保管するので（ステップＳ６２３）、ジョブ発生量が予測可能である最適化対象期間中において、複数の優先順位付キュー１１３１，１１４１，１１５１を持ち、複数の処理部（帳票変換部１１３，帳票仕分け部１１４，帳票送信部１１５）による多段処理をする場合の負荷を平衡化することができ、スループットを向上することができる。

図１３は、図１０のステップＳ５３３の処理部別スレッド優先順位最適化処理の手順を示すフローチャートである。

本処理は、図１０に示すように、処理部スレッド数最適化処理（図１０のステップＳ５３２，図１１）が行われ次第、起動する。

以下説明を簡略化するため、図１１と同様に、具体例として、最適化テンプレート定義用設定ファイルの最適化実施スケジュールの実施日数として８日間が指定されている場合について説明する。

まず、１日目の測定期間（ｋ＝１）の処理部スレッド数最適化処理が終了して、本処理が起動すると、処理量カウンタＡ_ｋがロギングデータ中に存在するか否かを判断する（ステップＳ７１１）。本処理実行時には、１日目のイベント処理が一度も行われなかったときは、ロギングデータ中にＡ_ｋの値はないため（ステップＳ７１１でＮＯ）、全処理部のスレッド優先順位をシステムデフォルトとし（ステップＳ７１２）、本処理を終了する。

次に、２日目の測定期間（ｋ＝２）の処理部スレッド数最適化処理が終了して、本処理が起動すると、処理量カウンタＡ_ｋがロギングデータ中に存在するか否か判別する（ステップＳ７１１）。本具体例では、測定期間が開始してから２日目が経過している本処理実行時までの間に、イベント処理が１回行われており、ロギングデータ中に処理量カウンタＡ_ｋはあるため（ステップＳ７１１でＹＥＳ）、Ａ_ｋの値を取得する（ステップＳ７１３）。

次に、図７のステップＳ４１５でロギングされている処理部毎の待ち時間により各処理部の平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋを算出し（ステップＳ７１４）、各処理部の優先度の組み合わせにおける測定順序を記述したシナリオＳ_ｊが存在するか否かを判別する（ステップＳ７１５）。

上述したように、１日目の処理では、各処理部の優先度の組み合わせにおける測定順序を記述したシナリオの設定はなされていないため、設定されたシナリオは存在しないため（ステップＳ７１５でＮＯ）、電子帳票マネージャシステム１２のＤＢＭＳ１２１に予め保存されている複数のシナリオ（図１６）のうち、各処理部の平均待ち時間と一致するシナリオＳ_ｊを選択する（ステップＳ７１６）。このシナリオＳ_ｊの選択は具体的には、各処理部の平均待ち時間の比率を比べ、１つの処理部の平均待ち時間の比率が高く、この処理部に突出して高い負荷が掛かっているパターン１（図１６（ａ））、２つの処理部の平均待ち時間の比率が高く、この２つの処理部に突出して高い負荷が掛かっているパターン２（図１６（ｂ））、平均待ち時間の比率が中位である処理部の負荷が、その他２つの処理部の平均待ち時間の比率の中間程度であるパターン３（図１６（ｃ））、全ての処理部の平均待ち時間の比率がほぼ同じで、３つの処理部共に同程度の負荷が掛かっているパターン４（図１６（ｄ））のうち、一致するパターンを選択することにより行う。本具体例では、帳票変換部１１３と帳票仕分け部１１４が、帳票送信部１１５に比べて平均待ち時間の比率が高い場合について説明する。即ち、本具体例では、ステップＳ７１６では、パターン２のシナリオが選択される。

ステップＳ７１４で算出された各処理部の平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋは、各処理部の優先度の組み合わせが設定されていない状態、即ち、全ての優先度が０の状態で算出されているため、各処理部の優先度組み合わせが全て０に設定されているｊ＝１の履歴として保管する（ステップＳ７１８）。図１６に示すように、いずれのパターンのシナリオもｊ＝１優先度組み合わせＳ１は、各処理部の優先度を全て０としているため、ステップＳ７１６でいずれのパターンのシナリオが選択された場合であっても、初めて履歴として保管される各処理部の平均待ち時間はｊ＝１のシナリオによるものとする。

その後、jを１つインクリメントして２とし（ステップＳ７１１２）、各処理部の優先順位の組み合わせとして、シナリオＳ２を適用して（ステップＳ７１１３）、本処理を終了する。本具体例では、パターン２のシナリオＳ２が適用されるので、帳票変換部１１３と帳票仕分け部１１４の全処理スレッドの優先度をそれぞれデフォルト値よりも１つずつ上げる。

その後、この２日目に適用されたパターン２のシナリオＳ２でイベント処理され、処理量カウンタＡ_ｋがロギングデータ中に保管されていく。

次に、３日目の測定期間（ｋ＝３）の処理部スレッド数最適化処理が終了して、本処理が起動すると、上述のようにロギングデータ中に保管されていった処理量カウンタＡ_ｋの値を取得した後（ステップＳ７１１でＹＥＳ，ステップＳ７１４）、各処理部の平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋを算出し（ステップＳ７１４）、２日目に適用されたシナリオＳ２をキーに履歴として処理量カウンタＡ_ｋ及び各処理部の平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋ保存し（ステップＳ７１７）、次に、ｊがその最大値未満であるか判別する（ステップＳ７１９）。

本具体例では、現在のｊの値は２であり、また、図１６（ｂ）に示すようにｊの最大値は４であるため、ｊの値はその最大値未満であると判別し（ステップＳ７１９でＹＥＳ）、ｊの値を１つインクリメントして３とし（ステップＳ７１１０）、各処理部の優先順位の組み合わせとして、シナリオＳ３を適用して（ステップＳ７１１３）、本処理を終了する。本具体例では、パターン２のシナリオＳ３が適用されるので、帳票変換部１１３と帳票仕分け部１１４のいずれか一方の全処理スレッドの優先度のみを現在の優先度１から１つ上げる。

その後、この３日目に適用されたパターン２のシナリオＳ３でイベント処理され、処理量カウンタＡ_ｋがロギングデータ中に保管されていった後、４日目で同様の処理部別スレッド優先度順位最適化処理でパターン２のシナリオＳ４が適用され、イベント処理及び処理用カウンタＡ_ｋの保管が行われる。

次に、５日目の測定期間（ｋ＝５）の処理部スレッド数最適化処理が終了して、本処理が起動すると、上述のようにロギングデータ中に保管されていった処理量カウンタＡ_ｋの値を取得した後（ステップＳ７１１でＹＥＳ，ステップＳ７１４）、各処理部の平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋを算出し（ステップＳ７１４）、４日目に適用されたシナリオＳ４をキーに履歴として処理量カウンタＡ_ｋ及び各処理部の平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋ保存する（ステップＳ７１７）。

次に、現在のｊの値「４」はその最大値であるので（ステップＳ７１９でＮＯ）、ｊの値を再度「１」とし（ステップＳ７１１１）、各処理部の優先順位の組み合わせとして、シナリオＳ０を適用して（ステップＳ７１１３）、本処理を終了する。

その後、この５日目に適用されたパターン２のシナリオＳ_１でイベント処理され、処理量カウンタＡ_ｋがロギングデータ中に保管されていった後、６日目で同様の処理部別スレッド優先度順位最適化処理が行われて、パターン２のシナリオＳ_２が適用され、イベント処理及び処理用カウンタＡ_ｋの保管が行われる。さらに、７日目、８日目における本処理は、夫々３日目、４日目の処理と同様の処理となる。

図１４は、図１０のステップＳ５３７の処理部別スレッド優先順位登録処理の手順を示すフローチャートである。

本処理は、図１０のステップＳ５３５で最適化対象期間の終了後１日目になったときに起動する。

図１４において、まず、測定期間中の最後の（８日目の）処理部別スレッド優先順位最適化処理で適用されたシナリオＳ_ｊ（パターン２のシナリオＳ４）でイベント処理がされ、ロギングデータ中に保管されていた処理量カウンタＡ_ｋの値、及びそのときの各処理部の平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋをシナリオＳ_ｊをキーに履歴として保存した後（ステップＳ７２１）、履歴中の処理量カウンタＡ_ｋに基づき、履歴中のシナリオＳ_ｊ別に処理量Ａ_ｋの値の平均を算出し、その平均値が最大値となり、最高のパフォーマンスをえたシナリオＳ_ｊを決定する(ステップＳ７２２)。本具体例では、パターン２のシナリオＳ_１〜Ｓ_４が適用されたイベント処理を２日間ずつ実施しているので、シナリオＳ_ｊ別に処理量カウンタＡ_ｋに基づく２日間の処理量の平均が算出される。

ステップＳ７２２で決定されたシナリオＳ_ｊを最適値に設定する（ステップＳ７２３）、例えば、本具体例でパターン２のシナリオＳ_２が最適値に設定された場合、図１６（ｂ）に示すように、帳票変換部１１３と帳票仕分け部１１４の全処理スレッドの優先度をそれぞれデフォルト値よりも１つずつ上げたものが各処理部の優先度として設定される。

その後、ステップＳ７２３で最適値に設定されたシナリオＳ_ｊを最適化対象期間別にシナリオを保管する最適化テンプレートファイルに保管し（ステップＳ７２４）、次の最適化対象期間における最適化処理のために、図１３のステップＳ７１１３で適用されたシナリオを取り消して（ステップＳ７２５）、本処理を終了する。

図１３及び図１４の処理によれば、処理部スレッド数最適化処理が終了したときに（図１０のステップＳ５３２）、図１３の処理部別スレッド優先順位最適化処理を起動して、スレッド優先度の複数の組み合わせが設定されたシナリオＳ_ｊに基づき処理部別スレッド優先度を変化させてＡ_ｋの値を取得し（図１３のステップＳ７１３）、その後シナリオＳ_ｊ別にＡ_ｋの値を履歴として保存した後に（図１３のステップＳ７１８，図１４のステップＳ７２１）、Ｓ_ｊ別Ａ_ｋの値の平均値が最大となり、最高のパフォーマンスをえるシナリオＳ_ｊを決定し（ステップＳ７２２）、このシナリオＳ_ｊの値を最適値として最適化テンプレートファイルに保管するので（ステップＳ７２４）、ジョブ発生量が予測可能である最適化対象期間別にスループットが向上するスレッドの多重化の最適値を得ることができる。

以下、図１３のステップＳ７１６における、各処理部の平均待ち時間よりパターンを決定する方法について説明する。以下、各処理部の平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋがそれぞれ５００秒、４５０秒、３００秒 とした場合について各種パターン決定方法の例を説明する。

第１のパターン決定方法は、各処理部の平均待ち時間のうち、最大のもの（ＣＶＴ_ｋ）と、最小もの（ＳＮＴ_ｋ）の差（２００秒）を求め、この差の時間を３等分して平均待ち時間が中位のもの（ＳＯＴ_ｋ）がどのレンジに存在するかによりパターンを決定する方法である。

本具体例では、差の３等分の値は、２００秒／３≒６６．７秒であるから、３００〜３６６．７秒の間にあるときは下位レンジに、３６６．７〜４３３．４秒の間にあるときは中位レンジに、４３３．４〜５００秒の間にあるときは上位レンジに存在することとなる。中位の平均待ち時間ＳＯＴ_ｋは４５０秒であるので上位レンジに属することなり、パターン２が選択される。

しかしながら、このように平均待ち時間の差分からパターンを決定すると、どんなに小さくとも差は差分と解釈されるためパターン４を採る場合はありえない。

第２のパターン決定方法は、３つの平均待ち時間を、予め設定されたしきい値より大きいときに上位レベル、しきい値以下のときに下位レベルとすることによりパターンを決定する方法である。

例えば、３つの平均待ち時間のうち最小のものを基準値とし、この基準値の１．６倍の値を上記しきい値とすると、しきい値は、最小の平均待ち時間であるＳＮＴ_ｋ（＝３００秒）に１．６を乗じた４８０秒となる。この場合、平均待ち時間ＣＶＴ_ｋ（＝５００秒）はしきい値より大きいので上位レベル、平均待ち時間ＳＯＴ_ｋ（＝４５０秒），ＳＮＴ_ｋ（＝３００秒）はしきい値以下であるので下位レベルとなり、パターン１が選択される。

また、上記しきい値を上記基準値の１．４倍の値とすると、しきい値は４２０秒となる。この場合、平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋは共にしきい値よりも大きいので上位レベル、平均待ち時間ＳＮＴ_ｋはしきい値以下であるので下位レベルとなり、パターン２が選択される。

更に、上記しきい値を上記基準値の１．８倍の値とすると、しきい値は５４０秒となる。この場合、平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋは全てしきい値以下であるので下位レベルとなり、パターン４が選択される。

しかしながら、このようにしきい値からパターンを決定すると、平均待ち時間は上位レベルと下位レベルのいずれかになるので、パターン３を採る場合はありえない。

第３のパターン決定方法は、３つの平均待ち時間を、予め設定された第１のしきい値と第２のしきい値で比較し（第１のしきい値＞第２のしきい値）、第１のしきい値より大きいときに上位レベル、第２のしきい値より大きいときに中位レベル、第２のしきい値以下であるときに下位レベルとすることによりパターンを決定する方法である。

例えば、３つの平均待ち時間のうち最小のものを基準値とし、この基準値の１．６倍の値を上記第１のしきい値、この基準値の１．３倍の値を上記第２のしきい値とすると、第１のしきい値は、最小の平均待ち時間であるＳＮＴ_ｋ（＝３００秒）に１．６を乗じた４８０秒、第２のしきい値は３９０秒となる。この場合、平均待ち時間ＣＶＴ_ｋ（＝５００秒）は上位レベル、平均待ち時間ＳＯＴ_ｋ（＝４５０秒）は中位レベル、平均待ち時間ＳＮＴ_ｋ（＝３００秒）は下位レベルとなり、パターン３が選択される。

また、上記しきい値を夫々上記基準値の１．８倍、１．５倍の値とすると、第１のしきい値は５４０秒、第２のしきい値は４５０秒となる。この場合、平均待ち時間ＣＶＴ_ｋ、ＳＯＴ_ｋは共に中位レベルとなり、パターン２が選択される。

さらに、上記しきい値を夫々上記基準値の２．０倍、１．８倍とすると、第１のしきい値は６００秒、第２のしきい値は５４０秒となる。この場合、平均待ち時間ＣＶＴ_ｋ，ＳＯＴ_ｋ，ＳＮＴ_ｋは全て下位レベルとなり、パターン４が選択される。

以上、第１〜第３のパターン決定方法によれば、算出された複数の処理部別の平均処理待ち時間に基づき、上記複数の処理部の負荷の度合いを示すパターンを決定し、この決定されたパターン毎にスレッドの優先度の組み合わせが設定されたシナリオのうちの最適なものを選択して、複数の処理部別にスレッドの優先度を決定するので、最適化対象期間別にスループットが向上するスレッドの多重化の最適値を確実に得ることができる。

図１５は、図２のステップＳ２１３のイベント優先順位設定処理の手順を示すフローチャートである。

本処理は、図２〜図５で前述したイベント処理において行われる処理の一つであり、図２に示すように、帳票検出部１１２が入力ファイル検出ディレクトリ１１２１にある入力ファイルを検出し（図２のステップＳ２１１）、イベントを生成する（ステップＳ２１２）毎に起動し、その処理終了後は図２のステップＳ２１４以降の処理が行われる。

以下説明を簡略化するため、図１１、図１３と同様に、具体例として、最適化テンプレート定義用設定ファイルの最適化実施スケジュールの実施日数として８日間が指定されている場合について説明する。

まず、１日目の測定期間（ｋ＝１）に本処理が起動すると、イベントに格納されたファイル名をキーとして、電子帳票マネージャシステム１２に保管されている変換用データ、仕分けデータ、格納先データ、及び個別イベントの優先度を取得し、イベントに格納する（ステップＳ８１１）。

その後、測定期間１日目は最適化実施中であるので（ステップＳ８１２でＹＥＳ）、本処理をそのまま終了する。

同様の処理を２日目〜８日目の測定期間においても行った後、最適化対象期間終了後１日目に本処理が起動すると、イベントに格納されたファイル名をキーとして、電子帳票マネージャシステム１２に保管されている上述のデフォルトデータを取得し、イベントに格納した後（ステップＳ８１１）、現在は最適化実施中ではないので（ステップＳ８１２でＮＯ）、イベントに格納されたファイル名と、現在日付をキーとして、電子帳票マネージャシステム１２のＤＢＭＳ１２１から現在の最適化対象期間における優先実行マーク情報を取得する（ステップＳ８１３）。ここで、優先実行マーク情報とは、最適化対象期間及び入力ファイルの種別（ファイル名）毎にある情報であって、イベント処理を優先的に実行する場合にマークが立てられる。

次に、現在の最適化対象期間においてイベントのファイル名についての現在の最適化対象期間における優先実行マーク情報にマークが立てられていない場合は直接、マークがたてられている場合は（ステップＳ８１４でＹＥＳ）、イベントの優先順位を一つインクリメントして（ステップＳ８１５）、本処理を終了する。

図１７は、図１０のステップＳ５３８の個別イベント優先度最適化処理の手順を示すフローチャートである。

本処理は、図１０に示すように、図９のステップＳ５２４で見直し処理の起動がスケジューリングされた期間（最適化対象期間終了後１日目）への切り替わり時期となり（ステップＳ５３５でＹＥＳ）、図１２の処理部スレッド数登録処理（ステップＳ５３６）及び図１３の処理部別スレッド優先度登録処理（ステップＳ５３７）が終了した時に起動する。

以下説明を簡略化するため、最適化テンプレート定義用設定ファイルの最適化実施スケジュールの実施日数として８日間が指定されており、測定期間中において図１５のイベント優先順位設定処理が行われた後に、最適化対象期間終了後１日目となり、本処理が起動した場合を例として説明する。

まず、図７のステップＳ４１３において、入力ファイル毎にロギングされたデータから全入力ファイル毎の全イベントの平均処理時間μと標準偏差σを算出し（ステップＳ８２１）、次に、入力ファイル毎にその入力ファイルの平均処理時間を算出する（ステップＳ８２３）。

次に、上記入力ファイルの平均処理時間がμ-σの値未満であるか否かを判別する（ステップＳ８２４）。ここで、上記入力ファイルの平均処理時間がμ-σの値以上であるときは直接、μ-σの値未満であるときはその入力ファイルについて優先実行マークを電子帳票マネージャシステム１２のＤＢＭＳ１２１中に立てる（ステップＳ８２５）。

全ての入力ファイル毎のロギングデータについて上記処理を施し、全ての入力ファイルについて処理が完了すると（ステップＳ８２２でＮＯ）、本処理を終了する。

図１５及び図１７の処理によれば、測定期間がが終了したときに本処理を起動し、測定時間中に処理された全イベントについて算出された平均処理時間μ及び標準偏差σ（ステップＳ８２１）と、ロギングされている各入力ファイルの平均処理時間（ステップＳ８２３）とに基づき、優先実行マークを立て（ステップＳ８２５）、この優先実行マークが立てられているイベントの優先順位を一つインクリメントするので（図１５のステップＳ８１５）、ジョブ発生量が予測可能である最適化対象期間中において、処理の実施に要する時間が短いジョブについては、優先的に処理を実施することができ、システム全体に滞留するジョブ量を減らすことができる。

次に、上記具体例で最適なＷ_ｋ，Ｓ_ｊが最適化テンプレートファイルに保管されると共に、電子帳票マネージャシステム１２のＤＢＭＳ１２１にファイル名別に最適な優先順位が格納された後、図２〜図５のイベント処理が行われた場合について説明する。

まず、ステップＳ２１４で帳票検出部１１２により優先度１と共にこのイベントが優先順位付キュー１１１１にポストされる。その後、ステップＳ２２１で、イベント制御部により、優先度がデフォルト値（０）のイベントよりも優先してこのイベントがキュー１１１１から取得される。

ステップＳ２２３でイベント制御部１１１により貸し付けられたワークパスがイベントにセットされ、ステップＳ２２５でその優先度１と共にイベントが優先順位付キュー１１３１にポストされる。その後、ステップＳ２３１で、帳票変換部１１３により、優先度がデフォルト値（０）のイベントよりも優先してこのイベントがキュー１１３１から取得される。

帳票変換部１１３は、ステップＳ２３３において、図１４の処理により最適化テンプレートファイルに登録された自身のスレッドの優先順位にこのイベントの優先度である１を加えて、このイベントの処理を開始する。例えば、自身のスレッドの優先順位が５である場合、これにこのイベントの優先度である１を加えた６に、このイベントを実行するスレッドの優先順位を設定し、優先順位が５であるスレッドにおけるイベント処理よりも優先的に処理を進行する。

同様のキューからのイベント取得及びスレッドによるイベント処理実行が、帳票仕分け部１１４、帳票送信部１１５において行われる。この結果、同じ純粋処理時間を要する処理をデフォルトの優先度で処理した場合と比べ、処理時間の短縮が図られる。このように処理時間の短いものを優先実行することにより、システムそれぞれのキューに滞留するイベントの低減がはかられ、全体のスループットの向上を見込むことができる。

また、本発明の目的は、上記実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（又は記録媒体）を、システム又は装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(ＯＳ)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、上記プログラムは、上述した実施の形態の機能をコンピュータで実現することができればよく、その形態は、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給されるスクリプトデータ等の形態を有するものでもよい。

プログラムを供給する記録媒体としては、例えば、ＲＡＭ、ＮＶ−ＲＡＭ、フロッピー（登録商標）ディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＭＯ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ）、磁気テープ、不揮発性のメモリカード、他のＲＯＭ等の上記プログラムを記憶できるものであればよい。或いは、上記プログラムは、インターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続される不図示の他のコンピュータやデータベース等からダウンロードすることにより供給される。

本発明の第１の実施の形態に係るファイル登録システムとしての電子帳票登録システムの構成を概略的に示すブロック図である。 図１のシステム１１により実行されるイベント処理の手順を示すフローチャートである。 図３のフローチャートの続きである。 図４のフローチャートの続きである。 図５のフローチャートの続きである。 図１のシステムにより実行される見直し処理に用いられる各種ファイルの記述例を説明する図であり，（ａ）は最適化テンプレート定義用設定ファイルを示し、（ｂ）はワークパス定義用設定ファイルを示し、（ｃ）は最適化テンプレートファイルを示す。 図２のステップＳ２２１２のロギング処理の手順を示すフローチャートである。 図１のシステムにより実行される最適化対象期間切り替えスケジュール処理の手順を示すフローチャートである。 システムにより実行される最適化対象期間切り替え処理の手順を示すフローチャートである。 システムにより実行される見直し処理の手順を示すフローチャートである。 図１０のステップＳ５３２の処理部スレッド数最適化処理の手順を示すフローチャートである。 図１０のステップＳ５３６の処理部スレッド数登録処理の手順を示すフローチャートである。 図１０のステップＳ５３３の処理部別スレッド優先順位最適化処理の手順を示すフローチャートである。 図１０のステップＳ５３７の処理部別スレッド優先順位登録処理の手順を示すフローチャートである。 図２のステップＳ２１３のイベント優先順位設定処理の手順を示すフローチャートである。 図１の電子帳票マネージャシステムのＤＢＭＳに予め保存されている複数のシナリオを示す図であり、（ａ）はパターン１の場合、（ｂ）はパターン２の場合、（ｃ）はパターン３の場合、（ｄ）はパターン４の場合を示す。 図１０のステップＳ５３８の個別イベント優先度最適化処理の手順を示すフローチャートである。

符号の説明

１１ 電子帳票登録システム
１５ ホストコンピュータ
１２１ ＤＢＭＳ
１２ 電子帳票マネージャシステム
１３ 電子帳票保管システム
１４ ＷＥＢサーバ
１１２１ 入力ファイル検出ディレクトリ
１１２ 帳票検出部
１１３ 帳票変換部
１１４ 帳票仕分け部
１１５ 帳票送信部
１１１ イベント制御部
１１０ 記録部

Claims (8)

1. コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムにおいて、
   前記システムへの運用負荷が異なる期間を予め設定する期間設定手段と、
   前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得手段と、
   前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定手段と、
   前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行手段とを備えることを特徴とするファイル登録システム。
2. 前記システムは、前記複数の処理部の負荷の度合いを示すパターン毎に前記スレッド優先度の複数の組み合わせが設定されたシナリオを備え、
   前記取得手段は、
   前記複数の処理部別の平均処理待ち時間を算出する待ち時間算出処理と、
   前記算出された平均処理待ち時間に基づき前記パターンの一つを選択するパターン選択手段と、
   前記選択されたパターンのシナリオに設定された前記スレッド優先度の複数の組み合わせを順に前記処理部別スレッド優先度に設定する優先度設定手段とを備えることを特徴とする請求項１に記載のファイル登録システム。
3. 前記測定期間となったときに前記複数の処理部のスレッド数を変化させ、前記変化したスレッド数毎にスループットを取得する他の取得手段と、
   前記取得したスループットが最大となる前記スレッド数を前記一の期間における前記複数の処理部のスレッド数に決定する他の決定手段と、
   前記一の期間となったときに前記決定されたスレッドで前記複数の処理部によるスレッド処理を実行する他の実行手段とを備えることを特徴とする請求項１又は２記載のファイル登録システム。
4. 前記測定期間中に前記スレッド処理が行われた全イベントについて前記複数の処理部別の処理時間を取得する処理時間取得手段と、
   前記全イベントのジョブの種別毎に平均処理時間を算出する平均算出手段と、
   前記取得された全イベントの処理時間及び前記ジョブの種別毎の平均処理時間に基づいて前記イベント別優先度を決定するさらにその他の決定手段と、
   前記一の期間となったときに前記決定されたイベント別優先度で前記複数の処理部によるスレッド処理を実行するさらにその他の実行手段とを備えることを特徴とする請求項１乃至３のいずれか１項に記載のファイル登録システム。
5. コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムのファイル登録方法において、
   前記システムへの運用負荷が異なる期間を予め設定する期間設定ステップと、
   前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得ステップと、
   前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定ステップと、
   前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行ステップとを備えることを特徴とするファイル登録方法。
6. コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバにおいて、
   前記システムへの運用負荷が異なる期間を予め設定する期間設定手段と、
   前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得手段と、
   前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定手段と、
   前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行手段とを備えることを特徴とするサーバ。
7. コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムのファイル登録方法をコンピュータにより実行するプログラムにおいて、
   前記システムへの運用負荷が異なる期間を予め設定する期間設定モジュールと、
   前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得モジュールと、
   前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定モジュールと、
   前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行モジュールとを備えることを特徴とするプログラム。
8. 前記請求項７記載のプログラムを格納することを特徴とするコンピュータ読取り可能な記憶媒体。

Images