(57)【要約】      （修正有）【課題】ジョブ発生量が予測可能な期間において、投入されたジョブを多段処理で実施するときのスループットが向上するスレッドの多重化の最適値を得ると共に、その最適値を得る際の負荷を低くする。【解決手段】電子帳票登録システム１１は、ホストコンピュータ１５から受信した入力ファイルを帳票変換部１１３、帳票仕分け部１１４、帳票送信部１１５から成る複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録する。最適化テンプレート定義設定ファイルに予め設定された最適化対象期間中の測定時間となったとき、処理部スレッド数最適化処理を起動して、変化させた処理部スレッド数Ｗｋ別にＡｋの値を取得し、このＡｋの平均値が最大となり、最高のパフォーマンスを得ることができるＷｋの値を処理部スレッド数に決定し、このＷｋの値を最適値として最適化テンプレートファイルに保管する。【選択図】図１
2006189932.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムにおいて、
前記システムへの運用負荷が異なる期間を予め設定する期間設定手段と、
前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得手段と、
前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定手段と、
前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行手段とを備えることを特徴とするファイル登録システム。
【請求項２】
前記システムは、前記複数の処理部の負荷の度合いを示すパターン毎に前記スレッド優先度の複数の組み合わせが設定されたシナリオを備え、
前記取得手段は、
前記複数の処理部別の平均処理待ち時間を算出する待ち時間算出処理と、
前記算出された平均処理待ち時間に基づき前記パターンの一つを選択するパターン選択手段と、
前記選択されたパターンのシナリオに設定された前記スレッド優先度の複数の組み合わせを順に前記処理部別スレッド優先度に設定する優先度設定手段とを備えることを特徴とする請求項１に記載のファイル登録システム。
【請求項３】
前記測定期間となったときに前記複数の処理部のスレッド数を変化させ、前記変化したスレッド数毎にスループットを取得する他の取得手段と、
前記取得したスループットが最大となる前記スレッド数を前記一の期間における前記複数の処理部のスレッド数に決定する他の決定手段と、
前記一の期間となったときに前記決定されたスレッドで前記複数の処理部によるスレッド処理を実行する他の実行手段とを備えることを特徴とする請求項１又は２記載のファイル登録システム。
【請求項４】
前記測定期間中に前記スレッド処理が行われた全イベントについて前記複数の処理部別の処理時間を取得する処理時間取得手段と、
前記全イベントのジョブの種別毎に平均処理時間を算出する平均算出手段と、
前記取得された全イベントの処理時間及び前記ジョブの種別毎の平均処理時間に基づいて前記イベント別優先度を決定するさらにその他の決定手段と、
前記一の期間となったときに前記決定されたイベント別優先度で前記複数の処理部によるスレッド処理を実行するさらにその他の実行手段とを備えることを特徴とする請求項１乃至３のいずれか１項に記載のファイル登録システム。
【請求項５】
コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムのファイル登録方法において、
前記システムへの運用負荷が異なる期間を予め設定する期間設定ステップと、
前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得ステップと、
前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定ステップと、
前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行ステップとを備えることを特徴とするファイル登録方法。
【請求項６】
コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバにおいて、
前記システムへの運用負荷が異なる期間を予め設定する期間設定手段と、
前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得手段と、
前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定手段と、
前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行手段とを備えることを特徴とするサーバ。
【請求項７】
コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムのファイル登録方法をコンピュータにより実行するプログラムにおいて、
前記システムへの運用負荷が異なる期間を予め設定する期間設定モジュールと、
前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得モジュールと、
前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定モジュールと、
前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行モジュールとを備えることを特徴とするプログラム。
【請求項８】
前記請求項７記載のプログラムを格納することを特徴とするコンピュータ読取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイル登録システム及びそのファイル登録方法、そのサーバ、そのプログラム、並びに記憶媒体に関し、特に、期間毎にシステムへの運用負荷が異なるファイル登録システム及びそのファイル登録方法、そのサーバ、そのプログラム、並びに記憶媒体に関する。
【背景技術】
【０００２】
近年、電子帳票登録システムは、本システムの構成要素であるサーバマシンのＣＰＵ多重化、ディスクアクセススピードの高速化に伴い、複数スレッドによるジョブの並行処理が可能となり、スループットの向上が図られるようになった。
【０００３】
一方、スレッドの多重化についてはシステムの負荷、マシンスペック等により予め最適値を決定しておくことは難しい。このため、スレッドの多重化の最適値を決定する様々な方法が従来技術で開示されている。
【０００４】
例えば、実際のジョブ処理データを蓄積し、各ジョブクラスへのイニシエータの割当て（ジョブ多重度）を設定する第１の従来技術（例えば、特許文献１参照）や、ジョブの状況に応じて動的にスレッドの多重度を変更する第２の従来技術（例えば、特許文献２参照）が開示されている。
【特許文献１】特開平２−４２５３９号公報
【特許文献２】特開２０００−２１５０６９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、第１の従来技術及び第２の従来技術のように、常時ジョブの実施状況を監視すると、監視行為自体がシステムに負荷を掛けることとなる。さらに、予めユーザの業務との関係でシステムへの負荷が大きい繁忙期（例えば月末や期末等）及びその期間中に投入されるジョブの内容が予測できる場合、第１の従来技術及び第２の従来技術のようなリアルタイム修正よりも、設定期間に応じて修正を行った方がより大きなスループットを得ることができる。
【０００６】
また、複数のキューに対して順番にジョブが投入され処理が実施されるような多段処理においては、高負荷が掛かる処理実施単位のキューにジョブが滞留してしまいシステムのリソースが有効に利用されないという問題が発生するが、第１の従来技術及び第２の従来技術はこのような多段処理におけるスループットの向上について何ら言及していない。
【０００７】
本発明の目的は、ジョブ発生量が予測可能な期間において、投入されたジョブを多段処理で実施するときのスループットが向上するスレッドの多重化の最適値を得ると共に、その最適値を得る際の負荷を低くすることができるファイル登録システム及びそのファイル登録方法、そのサーバ、そのプログラム、並びに記憶媒体を提供することにある。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、請求項１記載のファイル登録システムは、コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムにおいて、前記システムへの運用負荷が異なる期間を予め設定する期間設定手段と、前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得手段と、前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定手段と、前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行手段とを備えることを特徴とする。
【０００９】
請求項５記載のファイル登録方法は、コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムのファイル登録方法において、前記システムへの運用負荷が異なる期間を予め設定する期間設定ステップと、前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得ステップと、前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定ステップと、前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行ステップとを備えることを特徴とする。
【００１０】
請求項６記載のサーバは、コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバにおいて、前記システムへの運用負荷が異なる期間を予め設定する期間設定手段と、前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得手段と、前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定手段と、前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行手段とを備えることを特徴とする。
【００１１】
請求項７記載のプログラムは、コンピュータから受信したジョブを複数の処理部の夫々が有するスレッドでの処理により所定の形式に変換して登録するサーバからなるファイル登録システムのファイル登録方法をコンピュータにより実行するプログラムにおいて、前記システムへの運用負荷が異なる期間を予め設定する期間設定モジュールと、前記設定された一の期間中の所定の測定期間となったときに前記処理部別スレッド優先度を変化させ、前記変化した処理部別スレッド優先度毎にスループットを取得する取得モジュールと、前記取得したスループットが最大となる前記処理部別スレッド優先度を前記一の期間における処理部別スレッド優先度に決定する決定モジュールと、前記一の期間となったときに前記決定された処理部別スレッド優先度で前記複数の処理部によるスレッド処理を実行する実行モジュールとを備えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、システムへの運用負荷が異なる期間を予め設定し、この設定された一の期間中の所定の測定期間となったときにシステムが備える複数の処理部別スレッド優先度を変化させ、その変化した処理部別スレッド優先度毎にスループットを取得し、この取得したスループットが最大となる処理部別スレッド優先度を上記一の期間における処理部別スレッド優先度に決定し、上記一の期間となったときに決定された処理部別スレッド優先度で上記複数の処理部によるスレッド処理を実行するので、ジョブ発生量が予測可能な期間において、投入されたジョブを多段処理で実施するときのスループットが向上するスレッドの多重化の最適値を得ると共に、常態的に測定の負荷を掛けることなく、その最適値を得る際の負荷を低くすることができる。
【００１３】
好ましくは、システムは、複数の処理部の負荷の度合いを示すパターン毎にスレッド優先度の複数の組み合わせが設定されたシナリオを備え、変化した処理部別スレッド優先度毎にスループットを取得する際に、算出された複数の処理部別の平均処理待ち時間に基づき上記パターンの一つを選択し、この選択されたパターンのシナリオに設定されたスレッド優先度の複数の組み合わせを順に処理部別スレッド優先度に設定するので、ジョブ発生量が予測可能な期間別にスループットが向上するスレッドの多重化の最適値を得ることができる。
【００１４】
好ましくは、上記測定期間となったときに複数の処理部のスレッド数を変化させ、その変化したスレッド数毎にスループットを取得し、この取得したスループットが最大となるスレッド数を上記一の期間における複数の処理部のスレッド数に決定し、上記一の期間となったときに決定されたスレッドで上記複数の処理部によるスレッド処理を実行するので、ジョブ発生量が予測可能な期間において、複数キューを持ち、複数の処理部による多段処理をする場合の負荷を平衡化することができ、よりスループットを向上することができる。
【００１５】
好ましくは、上記測定期間中にスレッド処理が行われた全イベントについて取得された上記複数の処理部別の処理時間と、上記全イベントのジョブの種別毎に算出された平均処理時間に基づいてイベント別優先度を決定し、上記一の期間となったときに上記決定されたイベント別優先度で上記複数の処理部によるスレッド処理をするので、ジョブ発生量が予測可能な期間において、スレッド処理の実施に要する時間が短いジョブについては、優先的に処理を実施することができ、システム全体に滞留するジョブ量を減らすことができる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施形態を図面を用いて詳述する。
【００１７】
図１は、本発明の第１の実施の形態に係るファイル登録システムとしての電子帳票登録システムの構成を概略的に示すブロック図である。
【００１８】
図１の電子帳票登録システム１１は、１つのプラットホーム（サーバ）から構成されるものであって、ネットワークとしてのイーサネット（登録商標）を介して他のプラットホームである入力ファイルを電子帳票登録システム１１に送信するホストコンピュータ１５と、ホストコンピュータ１５からの入力データを電子帳票システム１１の独自ファイルフォーマットに変換するための変換用データ、変換されたデータの仕分け方法が記載された仕分けデータ、仕分けされた電子帳票の格納先データ、及びファイル名別の個別イベントの優先順位を保管するＤＢＭＳ１２１を備える電子帳票マネージャシステム１２と、上記変換電子帳票の保管先である電子帳票保管システム１３と、電子帳票保管システムで保管されている電子帳票を取得可能なＷＥＢサーバ１４とに接続する。
【００１９】
尚、本実施の形態では、ネットワーク接続される１つのプラットホーム（サーバ）上に一つの電子帳票登録システムが構成されるが、これに限定されるわけでなく、用途や目的に応じて、同一のプラットホーム内に複数の電子帳票登録システムを構成したり、異なるプラットホームにそれぞれ別の電子帳票登録システムを構成したりしてもよい。
【００２０】
図１において、電子帳票登録システム１１は、ホストコンピュータ１５から送信される入力ファイルのパスである入力ファイル検出ディレクトリ１１２１と、入力ファイル検出ディレクトリに送信された入力ファイルを定期的に検出する帳票検出部１１２と、入力ファイルを電子帳票マネージャシステム１２の備えるＤＢＭＳ１２１に基づき電子帳票システム１１の独自ファイルフォーマットへの変換を施す帳票変換部１１３と、変換された電子帳票内に設定されたキーワードにより異なる帳票格納先別に電子帳票を分割し仕分けする処理を施す帳票仕分部１１４と、仕分けられた電子帳票を電子帳票マネージャシステム１２のＤＢＭＳ１２１に保管してある所定の格納先（ＷＥＢサーバ１４）に配信する帳票送信部１１５とを備える。
【００２１】
帳票変換部１１３、帳票仕分部１１４、及び帳票送信部１１５からなる各処理部は、それぞれ別スレッド上で稼動し、非同期にシステム１１がホストコンピュータ１５から受信した入力ファイルから生成されたジョブオブジェクト（以下「イベント」という。）の送受信を行っている。また、帳票変換部１１３、帳票仕分け部１１４、及び帳票送信部１１５は、夫々から送信されるイベントを優先順位を付けた待ち行列とする優先順位付キュー１１３１，１１４１，１１５１を持つ。
【００２２】
また、電子帳票登録システム１１は、帳票検出部１１２から送信されるイベントを優先順位を付けた待ち行列とする優先順位付付キュー１１１１を持ち、優先順位付キュー１１１１，１１３１，１１４１，１１５１にあるイベントをその優先順位の順番に取り出して処理するイベント制御部１１１１と、システムの運用負荷が異なる期間（以下「最適化対象期間」という。）毎に高いスループットを得るための各種パラメータを設定する最適化テンプレートファイル（図６（ｃ））及び上記最適化対象期間や各処理部でのスレッド処理に用いられる最大ワークパス（一時作業領域）数等を定義する設定ファイル（図６（ａ），（ｂ））を記録する記録部１１０を備える。
【００２３】
記録部１１０で記録される設定ファイルの１つであるワークパス定義用設定ファイルは、最大いくつのワークパスが各処理部のスレッド処理に用いることができるかが記載される。例えば、図６（ｂ）に示すようにワークパス定義用設定ファイルでワークパス数が１０であると定義されているとき、帳票変換部１１３、帳票仕分け部１１４、帳票送信部１１５の３つの優先順位付キューにはそれぞれ最大１０の処理実施スレッドがプールできる。また、最適化対象期間毎にワークパス定義用設定ファイルに記載されるワークパスのうちいくつのワークパスを用いてスレッド処理を行うかが最適化テンプレートファイルに記載される。例えば、図６（ｃ）に示すように、優先順位１の最適化対象期間においては、５つのワークパス数を用いてスレッド処理を行う旨が記載されている。
【００２４】
また、記録部１１０で記録される設定ファイルの１つである最適化テンプレート定義用設定ファイルは、最適化対象期間を優先度をつけて記載するファイルであり、また、最適化対象期間別に最適化テンプレートファイル中の各種パラメータの値を見直して最適化する際のスケジュール（以下「最適化実施スケジュール」という。）を記載している。
【００２５】
例えば、図６（ａ）に示すように、優先順位が「１」の行については、最適化対象期間として１１／１５から１２／３１の平日（月〜金）が記載され、最適化実施スケジュールとして、最適化対象期間となる度に最適化を実施し（見直し実施：Ｙ）、最適化の実施日数は最適化対象期間となった後の最初の平日の４日間であり、毎日２０:００から１０時間(翌日０６：００)の間を測定時間として、毎朝０７:００に見直し処理（図１０）を実施する設定が記載されている。また、優先順位「３」の行はデフォルトの最適化設定であって、最適化対象期間として全期間が記載され、最適化実施スケジュールとして、最適化対象期間となった後の最初の１回目だけ最適化を実施し（見直し実施：Ｎ）、最適化の実施日数は最適化対象期間が適用された後の週末を含む最初の８日間であり、毎日２０：００から８時間（翌日０４：００）の間を測定期間として、毎朝０７：００に後述する見直し処理（図１０）を実施する設定が記載されている。
【００２６】
各最適化対象期間の各種パラメータが最適化テンプレートファイルに記載されている場合、システム１１は最適化対象期間毎に最適化テンプレートファイルの各種パラメータを読み込み、その読み込んだ各種パラメータを帳票変換部１１３、帳票仕分け部１１４、及び帳票送信部１１５から成る各処理部に適用した後に、イベント処理を行う。
【００２７】
図２〜図５は、図１のシステム１１により実行されるイベント処理の手順を示すフローチャートである。
【００２８】
図２において、まず入力ファイル検出ディレクトリ１１２１を定期的に監視して、入力ファイルを検出する帳票検出部１１２により、ホストコンピュータ１５からネットワーク（イーサネット（登録商標））経由で転送された入力ファイル検出ディレクトリ１１２１にある入力ファイルを検出すると（ステップＳ２１１）、イベントを生成する（ステップＳ２１２）。次に、後述する図１５のイベント優先順位設定処理により、電子帳票システムマネージャ１２経由でＤＢＭＳ１２１から入力ファイル名をキーとして検索された変換情報、仕分け情報、配信先情報、優先順位情報、優先実行マークをイベントに格納した後、最適化テンプレートファイルに記載された処理部別スレッドの優先順位及び、ＤＢＭＳ１２１中に保管された個別イベントの優先順位を適用する（ステップＳ２１３）。
【００２９】
その後、そのイベント優先順位と共に優先順位付キュー１１１１にイベントをポストした後（ステップＳ２１４）、ステップＳ２１１からの処理を繰り返す。
【００３０】
次に、イベント制御部１１１により、ステップＳ２１４で優先順位付キュー１１１１にポストされたイベントを優先順位の高いものから優先して優先順位付キュー１１１１から取得し（ステップＳ２２１）、そのイベントの処理を行うためのワークパスを要求する（ステップＳ２２２）。このとき、ワークパス定義用設定ファイル（図６（ｂ））に記載されるワークパスのすべてで各処理部の処理が行われているときは、貸し付けられるワークパスが生じるまで待機する。また、帳票変換部１１３を実装するスレッドの多重度は、後述する図１２のスレッド数登録処理により最適化対象期間毎に最適化されており、最適化対象期間内で最もパフォーマンスが得られる設定となっている。
【００３１】
その後、イベント制御部１１１により、貸し付けられたワークパスがステップＳ２２１で取得したイベントにセットされ（ステップＳ２２３）、イベント処理開始のタイムスタンプを押した後（ステップＳ２２４）、イベント優先順位と共に優先順位付キュー１１３１にイベントをポストした後（ステップＳ２２５）、ステップＳ２２１からの処理を繰り返す。
【００３２】
次に、帳票変換部１１３により、ステップＳ２２５でポストされたイベントを優先順位順に優先順位付キュー１１３１から取得し（図３のステップＳ２３１）、帳票変換処理開始のタイムスタンプを押した後（ステップＳ２３２）、そのイベントに対するスレッド処理の優先度を最適化テンプレートファイルの記載に基づきインクリメントした後に（ステップＳ２３３）、そのイベントの帳票変換処理を施し（ステップＳ２３４）、イベント制御部１１１にイベントをポストする（ステップＳ２３５）。
【００３３】
ステップＳ２３５で帳票変換部１１３からポストがあったときに、イベント制御部１１１により帳票変換処理終了のタイムスタンプを押し（ステップＳ２２６）、その後イベント優先順位と共に優先順位付キュー１１４１にイベントをポストすると同時に（ステップＳ２２７）、帳票変換部１１３においてイベント処理可能なスレッドができたと判断して、ステップＳ２３１からの処理を繰り返す。
【００３４】
次に、帳票仕分け部１１４により、ステップＳ２２７でポストされたイベントを優先順位順に優先順位付キュー１１４１から取得する（図４のステップＳ２４１）。このとき、帳票仕分け部１１４を実装するスレッドの多重度は、後述するスレッド数登録処理（図１２）により最適化対象期間毎に最適化されており、最適化対象期間内で最もパフォーマンスが得られる設定となっている。
【００３５】
次に、帳票仕分け処理開始のタイムスタンプを押した後（ステップＳ２４２）、そのイベントに対するスレッド処理の優先度を最適化テンプレートファイルの記載に基づきインクリメントした後に（ステップＳ２４３）、そのイベントの帳票仕分け処理を施し（ステップＳ２４４）、イベント制御部１１１にイベントをポストする（ステップＳ２４５）。
【００３６】
ステップＳ２４５で帳票仕分け部１１４からポストがあったときに、イベント制御部１１１により帳票仕分け処理終了のタイムスタンプを押し（ステップＳ２２８）、その後イベント優先順位と共に優先順位付キュー１１５１にイベントをポストすると同時に（ステップＳ２２９）、帳票仕分け部１１４においてイベント処理可能なスレッドができたと判断して、ステップＳ２４１からの処理を繰り返す。
【００３７】
次に、帳票送信部１１５により、ステップＳ２２９でポストされたイベントを優先順位順に優先順位付キュー１１５１から取得する（図５のステップＳ２５１）。このとき、帳票送信部１１５を実装するスレッドの多重度は、後述するスレッド数登録処理（図１２）により最適化対象期間毎に最適化されており、最適化対象期間内で最もパフォーマンスが得られる設定となっている。
【００３８】
次に、帳票送信処理開始のタイムスタンプを押した後（ステップＳ２５２）、そのイベントに対するスレッド処理の優先度を最適化テンプレートファイルの記載に基づきインクリメントした後に（ステップＳ２５３）、そのイベントの帳票送信処理を施し（ステップＳ２５４）、イベント制御部１１１にイベントをポストする（ステップＳ２５５）。
【００３９】
ステップＳ２５５で帳票送信部１１５からポストがあったときに、イベント制御部１１１により帳票送信処理終了のタイムスタンプを押し（ステップＳ２２１０）、その後イベントからワークパスを返却し（ステップＳ２２１１）、後述する図７のロギング処理を行った後に（ステップＳ２２１２）、このイベント処理を終了する（ステップＳ２２１３）。このとき同時に、帳票送信部１１５においてイベント処理可能なスレッドができたと判断して、ステップＳ２５１からの処理を繰り返す。
【００４０】
図７は、図２のステップＳ２２１２のロギング処理の手順を示すフローチャートである。
【００４１】
図７において、まず、図２のステップＳ２２１１でイベントからワークパスが返却され（ステップＳ４１０でＹＥＳ）、且つ、現在、最適化テンプレート定義用設定ファイル（図６（ａ））に記載された最適化対象期間中の指定された測定時間であるときに（ステップＳ４１１でＹＥＳ）、その返却されたイベントについて、図３のステップＳ２３２，Ｓ２２６、図４のステップＳ２４２，Ｓ２２８、図５のステップＳ２５２，Ｓ２２１０において各処理部の処理開始時及び処理終了時に押されたタイムスタンプの値から各処理部における待ち時間、即ち、各キュー１１３１，１１４１，１１５１にイベントがポストされてから、実際にそのイベントが各処理部で処理されるまでの時間を除いたイベントの純粋処理時間を算出し（ステップＳ４１２）、ステップＳ４１２で算出された純粋処理時間をそのイベントのジョブである入力ファイル名でロギングする（ステップＳ４１３）。ここで、ロギングするとは、ロギングデータ中にデータを保存することをいう。
【００４２】
次に、上記タイムスタンプの値から各処理部における待ち時間を夫々算出し（ステップＳ４１４）、処理部毎に待ち時間をロギングした後（ステップＳ４１５）、一の測定期間においてワークパスがｋ回返却されたことを示す処理量カウンタＡｋの値を一つインクリメントし（ステップＳ４１６）、本処理を終了する。
【００４３】
一方、ステップＳ４１１の判別の結果、現在、最適化対象期間中の指定された測定時間でないときは、そのまま本処理を終了する。
【００４４】
図７の処理によれば、指定された測定期間中に各処理部で処理が行われた全てのイベントは、入力ファイル名別に各処理部における待ち時間を除いた純粋処理時間（ステップＳ４１３）、及び各処理部別の待ち時間（ステップＳ４１５）がロギングされ、また測定時間内に返却されたワークパスの数をカウントする処理量カウンタＡｋもロギングされる（ステップＳ４１６）ので、後述する図１０の見直し処理を適切に行うことができる。
【００４５】
図８は、図１のシステム１１により実行される最適化対象期間切り替えスケジュール処理の手順を示すフローチャートである。
【００４６】
図８において、まず、システム１１は起動すると、記録部１１０が保存する設定ファイルの一つである最適化テンプレート定義用設定ファイル（図６（ａ））の設定を読み込み（ステップＳ５１１）、後述する図９の最適化対象期間切り替え処理により、最適化対象期間の切り替えを行う（ステップＳ５１２）。
【００４７】
次に、上記最適化テンプレート定義用設定ファイルに記載されている最適化対象期間の切り替わり時期に後述する図９の最適化対象期間切り替え処理が呼び出されるようにスケジューリングし（ステップＳ５１３）、本処理を終了する。
【００４８】
図９は、システム１１により実行される最適化対象期間切り替え処理の手順を示すフローチャートである。
【００４９】
図９において、まず、システム１１は、設定ファイルの一つである最適化テンプレート定義用設定ファイル（図６（ａ））に記載されているいずれかの最適化対象期間への切り替わり時期となったとき（ステップＳ５２１でＹＥＳ）、その最適化対象期間について、最適化テンプレートファイルに記載される値の見直しが必要か否かを判別する（ステップＳ５２２）。この判別は、最適化テンプレート定義用設定ファイルで見直し処理がＹとなっているかＮとなっているかによって判断される。
【００５０】
ステップＳ５２２の判別の結果、見直しが不要である場合は、最適化テンプレートファイルにその最適化対象期間における値が存在するか否かを判別し（ステップＳ５２４）、見直しが必要である場合は、ステップＳ５２３の処理に進む。
【００５１】
ステップＳ５２４の判別の結果、最適化テンプレートファイルに上記最適化対象期間における値が存在しないときは、ステップＳ５２３の処理に進み、最適化テンプレートファイルに値が存在するときは、既存の最適化テンプレートファイルの値をシステム１１に適用して（ステップＳ５２６）、本処理を終了する。
【００５２】
次に、ステップＳ５２３において、ロギングデータが初期化される。その後、後述する図１０の見直し処理が最適化対象期間内と最適化対象期間終了後１日目に起動されるようにスケジューリングして（ステップＳ５２５）、本処理を終了する。
【００５３】
図９の処理によれば、最適化テンプレートファイルに記載されている値の見直しが必要である場合（ステップＳ５２２でＹＥＳ）、見直し処理は最適化対象期間内と最適化対象期間終了後１日目に起動されるようにスケジューリングされるので（ステップＳ５２５）、常態的に測定の負荷を掛けることなく、その最適値を得る際の負荷を低くすることができる。
【００５４】
ここで、ステップＳ５２５で最適化対象期間内に見直し処理が起動されるようにスケジューリングするのは、見直し処理で得られる最適値を導出するための測定値を取得するためであり、最適化対象期間終了後１日目に見直し処理が起動されるようにスケジューリングするのは、取得した測定値から導出された最適値をテンプレート化してその値でロックするためである。
【００５５】
本処理を、システム起動直後に最適化テンプレート定義用設定ファイル（図６（ａ））にある優先順位３の最適化対象期間に切り替わった場合を用いて具体的に説明する。
【００５６】
まず、システム１１は、最適化テンプレート定義用設定ファイルで優先順位３の見直しは不要(Ｎ)となっているため、ステップＳ５２２で見直し不要と判別し、ステップＳ５２４で最適化テンプレートファイルにその最適化対象期間における値が存在するか否かを判別する。
【００５７】
システム１１は、起動直後は初期状態であり、最適化テンプレートファイルにその最適化対象期間における値は存在しないため、ステップＳ５２３の処理に進んでロギングデータを初期化し、ステップＳ５２５で見直し処理の起動がスケジューリングされて、本処理は終了する。
【００５８】
その後、ステップＳ５２５でスケジューリングされた期間となったときに、システム１１は後述する図１０の見直し処理を行い、優先順位３の最適化対象期間における最適値を最適化テンプレートファイル中にロックする。この見直し処理は、測定期間中に行われる前述の図７のロギング処理によりロギングされた測定値を用いて最適値を導出する。
【００５９】
その後、再度優先順位３の最適化対象期間に切り替わると、システム１１は、まず、最適化テンプレート定義用設定ファイル（図６（ａ））で優先順位３の見直しは不要(Ｎ)となっているため、ステップＳ５２２で見直し不要と判別し、上述したように、すでに優先順位３の最適化対象期間における最適値は最適化テンプレートファイル中にロックされているため、ステップＳ５２４で最適化テンプレートファイルにその最適化対象期間における最適値が存在すると判断し、ステップＳ５２６でその最適化テンプレートファイルの値をシステム１１に適用して、本処理を終了する。
【００６０】
図１０は、システム１１により実行される見直し処理の手順を示すフローチャートである。
【００６１】
本処理は、見直し処理の起動がスケジューリングされた期間となると起動する。
【００６２】
図１０において、まず、システム１１は、現在、図９のステップＳ５２４で見直し処理の起動がスケジューリングされた期間（最適化対象期間終了後１日目）への切り替わり時期であるか判別し（ステップＳ５３１）、この切り替わり時期でないときは、後述する図１１の処理部スレッド数最適化処理により各処理部のスレッド数を最適化して（ステップＳ５３２）、後述する図１３の処理部別スレッド優先順位最適化処理により処理部別スレッドの優先順位を最適化した後に（ステップＳ５３３）、ロギングデータ中の処理量カウンタＡｋの値を初期化して（ステップＳ５３９）、本処理を終了する。これにより、この最適化対象期間の測定期間中に図２〜図５のイベント処理が実施されることにより、ステップＳ５３２のスレッド数最適化処理及びＳ５３３の処理別スレッド優先度最適化処理で最適化テンプレートファイルの値が変更される。
【００６３】
一方、ステップＳ５３１の判別の結果、現在、上記切り替わり時期であるときは、、図１２の処理部スレッド数登録処理により、測定期間中にロギングされた測定値から処理部別スレッド数の最適値を導出して、これを最適化テンプレートファイルに保存（ロック）する（ステップＳ５３６）。その後、図１４の処理部別スレッド優先順位登録処理により、同じく測定期間中にロギングされた測定値から処理部別スレッド優先順位の最適値を導出して、これを最適化テンプレートファイルに保存（ロック）する（ステップＳ５３７）。これにより、最適化対象期間毎に処理部別スレッド数及び処理部別スレッド優先度を最適化テンプレートファイルに保存（ロック）することができる。
【００６４】
次に、後述する図１７のイベント優先度最適化処理により、上記ロックされた後に得られた測定値に基づいて、優先実行すべき入力ファイル（個別イベントの優先順位）を判別し、最適化テンプレートファイルに保存（ロック）する（ステップＳ５３８）。これにより、最適化対象期間毎に最適な個別イベントの優先順位を最適化テンプレートファイルに保存（ロック）することができる。
【００６５】
その後、ロギングデータを初期化して（ステップＳ５３９）、本処理を終了する。
【００６６】
図１１は、図１０のステップＳ５３２の処理部スレッド数最適化処理の手順を示すフローチャートである。
【００６７】
本処理は、図１０のステップＳ５３１で見直し処理の切り替わり時期であると判別される毎に起動する。以下、説明を簡略化するため、具体例として、最適化テンプレート定義用設定ファイルに最適化実施スケジュールの実施日数として８日間が指定され、且つ最適なスレッド数が５である場合について説明する。また、システム１１は３つのＣＰＵを有しており、処理部スレッド数の初期値ＷｓはＣＰＵの数に１を加えた値である４とする。
【００６８】
まず、１日目の測定期間（ｋ＝１）となり、本処理を起動すると、処理量カウンタＡｋがロギングデータ中に存在するか否かを判別する（ステップＳ６１１）。本具体例では、測定期間が開始してから本処理実行時までの間に、イベント処理が一度も行われておらず、ロギングデータ中に処理量カウンタＡｋはないため（ステップＳ６１１でＮＯ）、前回のイベント処理における処理部スレッド数Ｗｋ＋１（＝Ｗ２）を初期値Ｗｓ（＝４）として（ステップＳ６１２）、本処理を終了する。
【００６９】
次に、２日目の測定期間（ｋ＝２）となり、本処理を起動したとき、処理量カウンタＡｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間２日目が開始してから本処理実行時までの間に、イベント処理が１０００回行われており、ロギングデータ中に処理量カウンタＡ２（＝１０００）があるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ２の値及び処理部スレッド数Ｗ２を取得する（ステップＳ６１３）。
【００７０】
その後、処理量カウンタＡｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、現時点でイベント処理が１回しか行われておらず、ロギングデータ中に処理量カウンタＡ１のみが保管され、その前に行われたイベント処理による処理量カウンタＡｋ−１はないため（ステップＳ６１４でＮＯ）、処理部スレッド数Ｗｋ＋１（＝Ｗ３）＝Ｗｋ＋１（＝５）として（ステップＳ６１５）、本処理を終了する。
【００７１】
次に、３日目の測定期間（ｋ＝３）となり、本処理を起動したとき、処理量カウンタＡｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間３日目が開始してから本処理実行時までの間に、イベント処理が１５００回行われており、ロギングデータ中に処理量カウンタＡ３（＝１５００）はあるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ３の値及び処理部スレッド数Ｗ３を取得する（ステップＳ６１３）。
【００７２】
その後、処理量カウンタＡｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、２日目にもイベント処理が行われており、ロギングデータ中に今回の処理量カウンタＡ３のみならず、前回の処理量カウンタＡ２も保管しているため（ステップＳ６１４でＹＥＳ）、前回の処理量カウンタＡ２及び前回の処理部スレッド数Ｗ２を取得する（ステップＳ６１６）。
【００７３】
その後、ステップＳ６１３で取得した処理量カウンタＡ３の値より処理量カウンタＡ２の値の方が大きいか否かを判別する（ステップＳ６１７）。ここで、Ａｋの値とは、測定期間ｋ日目が開始してから本処理実行時までの間に返却されたワークパスの数であり、本具体例においては、Ａ３≧Ａ２であるので（ステップＳ６１７でＹＥＳ）、ステップＳ６１９に進み、次に、Ｗ３が最大スレッド数Ｍ未満であるか否かを判別する。本具体例では、２日目のステップＳ６１５の処理により、Ｗ３は５に設定されている一方、最大スレッド数は１０であるため、Ｗ３＜Ｍとなり（ステップＳ６１９でＹＥＳ）、次回（４日目）の処理部スレッド数Ｗ４＝Ｗ３＋（Ｗ３−Ｗ２）＝６に設定する（ステップＳ６１１１）。
【００７４】
その後、Ｗｋ＋１とＷｋを比較すると（ステップＳ６１１２）、Ｗ４（＝６）＞Ｗ３（＝５）であるので、各処理部におけるスレッド数を一つずつ増加させて（ステップＳ６１１５）、本処理を終了する。
【００７５】
次に、４日目の測定期間（ｋ＝４）となり、本処理を起動したとき、処理量カウンタＡｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間４日目が開始してから本処理実行時までの間に、イベント処理が１２００回行われており、ロギングデータ中に処理量カウンタＡ４（＝１２００）があるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ４の値及び処理部スレッド数Ｗ４を取得する（ステップＳ６１３）。
【００７６】
その後、処理量カウンタＡｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、３日目にもイベント処理が行われており、ロギングデータ中に今回の処理量カウンタＡ４のみならず、前回の処理量カウンタＡ３も保管しているため（ステップＳ６１４でＹＥＳ）、前回の処理量カウンタＡ３及び前回の処理部スレッド数Ｗ３を取得する（ステップＳ６１６）。
【００７７】
その後、ステップＳ６１３で取得した処理量カウンタＡ４の値より処理量カウンタＡ３の値の方が大きいか否かを判別する（ステップＳ６１７）。本具体例においては、Ａ４＜Ａ３であるので（ステップＳ６１７でＮＯ）、次回の処理部スレッド数Ｗ５＝Ｗ４−１＝Ｗ３＝５として（ステップＳ６１８）、本処理を終了する。
【００７８】
次に、５日目の測定期間（ｋ＝５）となり、本処理を起動したとき、処理量カウンタＡｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間５日目が開始してから本処理実行時までの間に、イベント処理が１５００回行われており、ロギングデータ中に処理量カウンタＡ５（＝１５００）があるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ５の値及び処理部スレッド数Ｗ５を取得する（ステップＳ６１３）。
【００７９】
その後、処理量カウンタＡｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、４日目にもイベント処理が行われており、ロギングデータ中に今回の処理量カウンタＡ５のみならず、前回の処理量カウンタＡ４も保管しているため（ステップＳ６１４でＹＥＳ）、前回の処理量カウンタＡ４及び前回の処理部スレッド数Ｗ４を取得する（ステップＳ６１６）。
【００８０】
その後、ステップＳ６１３で取得した処理量カウンタＡ５の値より処理量カウンタＡ４の値の方が大きいか否かを判別する（ステップＳ６１７）。本具体例においては、Ａ５≧Ａ４であるので（ステップＳ６１７でＹＥＳ）、次に、Ｗ５が最大スレッド数Ｍ未満であるか否かを判別する（ステップＳ６１９）。本具体例では、４日目のステップＳ６１５の処理により、Ｗ５は５に設定されている一方、最大スレッド数は１０であるため、Ｗ５＜Ｍとなり（ステップＳ６１９でＹＥＳ）、次回（６日目）の処理部スレッド数Ｗ６＝Ｗ５＋（Ｗ５−Ｗ４）＝４に設定する（ステップＳ６１１１）。
【００８１】
その後、Ｗｋ＋１とＷｋを比較すると（ステップＳ６１１２）、Ｗ５（＝５）＜Ｗ４（＝６）であるので、各処理部におけるスレッド数を一つずつ削除させて（ステップＳ６１１６）、本処理を終了する。
【００８２】
次に、６日目の測定期間（ｋ＝６）となり、本処理を起動したとき、処理量カウンタＡｋがロギングデータ中に存在するか否か判別する（ステップＳ６１１）。本具体例では、測定期間６日目が開始してから本処理実行時までの間に、イベント処理が１０００回行われており、ロギングデータ中に処理量カウンタＡ６（＝１０００）があるため（ステップＳ６１１でＹＥＳ）、処理量カウンタＡ６の値及び処理部スレッド数Ｗ６を取得する（ステップＳ６１３）。
【００８３】
その後、処理量カウンタＡｋ−１がロギングデータ中に存在するか否かを判断する（ステップＳ６１４）。本具体例では、５日目にもイベント処理が行われており、ロギングデータ中に今回の処理量カウンタＡ６のみならず、前回の処理量カウンタＡ５も保管しているため（ステップＳ６１４でＹＥＳ）、前回の処理量カウンタＡ５及び前回の処理部スレッド数Ｗ５を取得する（ステップＳ６１６）。
【００８４】
その後、ステップＳ６１３で取得した処理量カウンタＡ６の値より処理量カウンタＡ５の値の方が大きいか否かを判別する（ステップＳ６１７）。本具体例においては、Ａ６＜Ａ５であるので（ステップＳ６１７でＮＯ）、次回の処理部スレッド数Ｗ７＝Ｗ５（＝５）とする（ステップＳ６１８）。
【００８５】
その後、Ｗｋ＋１とＷｋを比較すると（ステップＳ６１１２）、Ｗ７（＝５）＞Ｗ６（＝４）であるので、各処理部におけるスレッド数を一つずつ増加させて（ステップＳ６１１５）、本処理を終了する。
【００８６】
以降の７日目、８日目においても同様の処理がおこなわれ、処理部スレッド数は５をはさむ４から６の間で推移する。
【００８７】
尚、本具体例では、ステップＳ６１１２でＷｋ＋１とＷｋを比較した結果、両者が等しい値であるケースは存在しなかったが、図１１に示すように、この場合（Ｗｋ＋１＝Ｗｋ）、各処理部スレッドの数は維持してそのまま本処理を終了する。
【００８８】
引き続き、図１０のステップＳ５３５で最適化対象期間の終了後１日目になったときに起動する処理部スレッド数登録処理が上記具体例について行われた場合について説明する。
【００８９】
図１２は、図１０のステップＳ５３６の処理部スレッド数登録処理の手順を示すフローチャートである。
【００９０】
図１２において、まず、処理部スレッド数Ｗｋの値別に処理量カウンタＡｋの値の平均を算出し、その平均値が最大値となり、最高のパフォーマンスをえた処理部スレッド数Ｗｋを決定する（ステップＳ６２１）。本具体例では、（Ｗ２，Ａ２）＝（４，１０００）、（Ｗ３，Ａ３）＝（５，１５００）、（Ｗ４，Ａ４）＝（６，１２００）、（Ｗ５，Ａ５）＝（５，１５００）、（Ｗ６，Ａ６）＝（４，１０００）、（Ｗ７，Ａ７）＝（５，１５００）、（Ｗ８，Ａ８）＝（６，１２００）である。従って、Ｗｋ＝４のとき、処理量カウンタＡｋの値の平均値は１０００、Ｗｋ＝５のとき、処理量カウンタＡｋの値の平均値は１５００、Ｗｋ＝６のとき、処理量カウンタＡｋの値の平均値は１２００と計算され、平均値が最大値（＝１５００）となる処理部スレッド数Ｗｋ＝５が最高のパフォーマンスを得るものに決定される。次に、その決定された処理部スレッド数Ｗｋの値を最適値に設定し（ステップＳ６２２）、この最適値に設定された処理部スレッド数Ｗｋの値を最適化対象期間別に処理部スレッド数の値を保管する最適化テンプレートファイルに保管し（ステップＳ６２３）、本処理を終了する。
【００９１】
以上、図１１及び図１２の処理によれば、最適化テンプレート定義設定ファイル（図６（ａ））に予め設定された最適化対象期間中の測定時間となったとき、即ち、見直し処理の切り替わり時期であるときに（図１０のステップＳ５３１でＹＥＳ）、図１１の処理部スレッド数最適化処理を起動して、変化させた処理部スレッド数Ｗｋ別にＡｋの値を取得し（図１１のステップＳ６１３）、この取得した処理部スレッド数別Ａｋの平均値が最大となり、最高のパフォーマンスを得ることができるＷｋの値を処理部スレッド数に決定し（図１２のステップＳ６２１）、この処理部スレッド数Ｗｋの値を最適値として最適化テンプレートファイルに保管するので（ステップＳ６２３）、ジョブ発生量が予測可能である最適化対象期間中において、複数の優先順位付キュー１１３１，１１４１，１１５１を持ち、複数の処理部（帳票変換部１１３，帳票仕分け部１１４，帳票送信部１１５）による多段処理をする場合の負荷を平衡化することができ、スループットを向上することができる。
【００９２】
図１３は、図１０のステップＳ５３３の処理部別スレッド優先順位最適化処理の手順を示すフローチャートである。
【００９３】
本処理は、図１０に示すように、処理部スレッド数最適化処理（図１０のステップＳ５３２，図１１）が行われ次第、起動する。
【００９４】
以下説明を簡略化するため、図１１と同様に、具体例として、最適化テンプレート定義用設定ファイルの最適化実施スケジュールの実施日数として８日間が指定されている場合について説明する。
【００９５】
まず、１日目の測定期間（ｋ＝１）の処理部スレッド数最適化処理が終了して、本処理が起動すると、処理量カウンタＡｋがロギングデータ中に存在するか否かを判断する（ステップＳ７１１）。本処理実行時には、１日目のイベント処理が一度も行われなかったときは、ロギングデータ中にＡｋの値はないため（ステップＳ７１１でＮＯ）、全処理部のスレッド優先順位をシステムデフォルトとし（ステップＳ７１２）、本処理を終了する。
【００９６】
次に、２日目の測定期間（ｋ＝２）の処理部スレッド数最適化処理が終了して、本処理が起動すると、処理量カウンタＡｋがロギングデータ中に存在するか否か判別する（ステップＳ７１１）。本具体例では、測定期間が開始してから２日目が経過している本処理実行時までの間に、イベント処理が１回行われており、ロギングデータ中に処理量カウンタＡｋはあるため（ステップＳ７１１でＹＥＳ）、Ａｋの値を取得する（ステップＳ７１３）。
【００９７】
次に、図７のステップＳ４１５でロギングされている処理部毎の待ち時間により各処理部の平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋを算出し（ステップＳ７１４）、各処理部の優先度の組み合わせにおける測定順序を記述したシナリオＳｊが存在するか否かを判別する（ステップＳ７１５）。
【００９８】
上述したように、１日目の処理では、各処理部の優先度の組み合わせにおける測定順序を記述したシナリオの設定はなされていないため、設定されたシナリオは存在しないため（ステップＳ７１５でＮＯ）、電子帳票マネージャシステム１２のＤＢＭＳ１２１に予め保存されている複数のシナリオ（図１６）のうち、各処理部の平均待ち時間と一致するシナリオＳｊを選択する（ステップＳ７１６）。このシナリオＳｊの選択は具体的には、各処理部の平均待ち時間の比率を比べ、１つの処理部の平均待ち時間の比率が高く、この処理部に突出して高い負荷が掛かっているパターン１（図１６（ａ））、２つの処理部の平均待ち時間の比率が高く、この２つの処理部に突出して高い負荷が掛かっているパターン２（図１６（ｂ））、平均待ち時間の比率が中位である処理部の負荷が、その他２つの処理部の平均待ち時間の比率の中間程度であるパターン３（図１６（ｃ））、全ての処理部の平均待ち時間の比率がほぼ同じで、３つの処理部共に同程度の負荷が掛かっているパターン４（図１６（ｄ））のうち、一致するパターンを選択することにより行う。本具体例では、帳票変換部１１３と帳票仕分け部１１４が、帳票送信部１１５に比べて平均待ち時間の比率が高い場合について説明する。即ち、本具体例では、ステップＳ７１６では、パターン２のシナリオが選択される。
【００９９】
ステップＳ７１４で算出された各処理部の平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋは、各処理部の優先度の組み合わせが設定されていない状態、即ち、全ての優先度が０の状態で算出されているため、各処理部の優先度組み合わせが全て０に設定されているｊ＝１の履歴として保管する（ステップＳ７１８）。図１６に示すように、いずれのパターンのシナリオもｊ＝１優先度組み合わせＳ１は、各処理部の優先度を全て０としているため、ステップＳ７１６でいずれのパターンのシナリオが選択された場合であっても、初めて履歴として保管される各処理部の平均待ち時間はｊ＝１のシナリオによるものとする。
【０１００】
その後、jを１つインクリメントして２とし（ステップＳ７１１２）、各処理部の優先順位の組み合わせとして、シナリオＳ２を適用して（ステップＳ７１１３）、本処理を終了する。本具体例では、パターン２のシナリオＳ２が適用されるので、帳票変換部１１３と帳票仕分け部１１４の全処理スレッドの優先度をそれぞれデフォルト値よりも１つずつ上げる。
【０１０１】
その後、この２日目に適用されたパターン２のシナリオＳ２でイベント処理され、処理量カウンタＡｋがロギングデータ中に保管されていく。
【０１０２】
次に、３日目の測定期間（ｋ＝３）の処理部スレッド数最適化処理が終了して、本処理が起動すると、上述のようにロギングデータ中に保管されていった処理量カウンタＡｋの値を取得した後（ステップＳ７１１でＹＥＳ，ステップＳ７１４）、各処理部の平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋを算出し（ステップＳ７１４）、２日目に適用されたシナリオＳ２をキーに履歴として処理量カウンタＡｋ及び各処理部の平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋ保存し（ステップＳ７１７）、次に、ｊがその最大値未満であるか判別する（ステップＳ７１９）。
【０１０３】
本具体例では、現在のｊの値は２であり、また、図１６（ｂ）に示すようにｊの最大値は４であるため、ｊの値はその最大値未満であると判別し（ステップＳ７１９でＹＥＳ）、ｊの値を１つインクリメントして３とし（ステップＳ７１１０）、各処理部の優先順位の組み合わせとして、シナリオＳ３を適用して（ステップＳ７１１３）、本処理を終了する。本具体例では、パターン２のシナリオＳ３が適用されるので、帳票変換部１１３と帳票仕分け部１１４のいずれか一方の全処理スレッドの優先度のみを現在の優先度１から１つ上げる。
【０１０４】
その後、この３日目に適用されたパターン２のシナリオＳ３でイベント処理され、処理量カウンタＡｋがロギングデータ中に保管されていった後、４日目で同様の処理部別スレッド優先度順位最適化処理でパターン２のシナリオＳ４が適用され、イベント処理及び処理用カウンタＡｋの保管が行われる。
【０１０５】
次に、５日目の測定期間（ｋ＝５）の処理部スレッド数最適化処理が終了して、本処理が起動すると、上述のようにロギングデータ中に保管されていった処理量カウンタＡｋの値を取得した後（ステップＳ７１１でＹＥＳ，ステップＳ７１４）、各処理部の平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋを算出し（ステップＳ７１４）、４日目に適用されたシナリオＳ４をキーに履歴として処理量カウンタＡｋ及び各処理部の平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋ保存する（ステップＳ７１７）。
【０１０６】
次に、現在のｊの値「４」はその最大値であるので（ステップＳ７１９でＮＯ）、ｊの値を再度「１」とし（ステップＳ７１１１）、各処理部の優先順位の組み合わせとして、シナリオＳ０を適用して（ステップＳ７１１３）、本処理を終了する。
【０１０７】
その後、この５日目に適用されたパターン２のシナリオＳ１でイベント処理され、処理量カウンタＡｋがロギングデータ中に保管されていった後、６日目で同様の処理部別スレッド優先度順位最適化処理が行われて、パターン２のシナリオＳ２が適用され、イベント処理及び処理用カウンタＡｋの保管が行われる。さらに、７日目、８日目における本処理は、夫々３日目、４日目の処理と同様の処理となる。
【０１０８】
図１４は、図１０のステップＳ５３７の処理部別スレッド優先順位登録処理の手順を示すフローチャートである。
【０１０９】
本処理は、図１０のステップＳ５３５で最適化対象期間の終了後１日目になったときに起動する。
【０１１０】
図１４において、まず、測定期間中の最後の（８日目の）処理部別スレッド優先順位最適化処理で適用されたシナリオＳｊ（パターン２のシナリオＳ４）でイベント処理がされ、ロギングデータ中に保管されていた処理量カウンタＡｋの値、及びそのときの各処理部の平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋをシナリオＳｊをキーに履歴として保存した後（ステップＳ７２１）、履歴中の処理量カウンタＡｋに基づき、履歴中のシナリオＳｊ別に処理量Ａｋの値の平均を算出し、その平均値が最大値となり、最高のパフォーマンスをえたシナリオＳｊを決定する(ステップＳ７２２)。本具体例では、パターン２のシナリオＳ１〜Ｓ４が適用されたイベント処理を２日間ずつ実施しているので、シナリオＳｊ別に処理量カウンタＡｋに基づく２日間の処理量の平均が算出される。
【０１１１】
ステップＳ７２２で決定されたシナリオＳｊを最適値に設定する（ステップＳ７２３）、例えば、本具体例でパターン２のシナリオＳ２が最適値に設定された場合、図１６（ｂ）に示すように、帳票変換部１１３と帳票仕分け部１１４の全処理スレッドの優先度をそれぞれデフォルト値よりも１つずつ上げたものが各処理部の優先度として設定される。
【０１１２】
その後、ステップＳ７２３で最適値に設定されたシナリオＳｊを最適化対象期間別にシナリオを保管する最適化テンプレートファイルに保管し（ステップＳ７２４）、次の最適化対象期間における最適化処理のために、図１３のステップＳ７１１３で適用されたシナリオを取り消して（ステップＳ７２５）、本処理を終了する。
【０１１３】
図１３及び図１４の処理によれば、処理部スレッド数最適化処理が終了したときに（図１０のステップＳ５３２）、図１３の処理部別スレッド優先順位最適化処理を起動して、スレッド優先度の複数の組み合わせが設定されたシナリオＳｊに基づき処理部別スレッド優先度を変化させてＡｋの値を取得し（図１３のステップＳ７１３）、その後シナリオＳｊ別にＡｋの値を履歴として保存した後に（図１３のステップＳ７１８，図１４のステップＳ７２１）、Ｓｊ別Ａｋの値の平均値が最大となり、最高のパフォーマンスをえるシナリオＳｊを決定し（ステップＳ７２２）、このシナリオＳｊの値を最適値として最適化テンプレートファイルに保管するので（ステップＳ７２４）、ジョブ発生量が予測可能である最適化対象期間別にスループットが向上するスレッドの多重化の最適値を得ることができる。
【０１１４】
以下、図１３のステップＳ７１６における、各処理部の平均待ち時間よりパターンを決定する方法について説明する。以下、各処理部の平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋがそれぞれ５００秒、４５０秒、３００秒 とした場合について各種パターン決定方法の例を説明する。
【０１１５】
第１のパターン決定方法は、各処理部の平均待ち時間のうち、最大のもの（ＣＶＴｋ）と、最小もの（ＳＮＴｋ）の差（２００秒）を求め、この差の時間を３等分して平均待ち時間が中位のもの（ＳＯＴｋ）がどのレンジに存在するかによりパターンを決定する方法である。
【０１１６】
本具体例では、差の３等分の値は、２００秒／３≒６６．７秒であるから、３００〜３６６．７秒の間にあるときは下位レンジに、３６６．７〜４３３．４秒の間にあるときは中位レンジに、４３３．４〜５００秒の間にあるときは上位レンジに存在することとなる。中位の平均待ち時間ＳＯＴｋは４５０秒であるので上位レンジに属することなり、パターン２が選択される。
【０１１７】
しかしながら、このように平均待ち時間の差分からパターンを決定すると、どんなに小さくとも差は差分と解釈されるためパターン４を採る場合はありえない。
【０１１８】
第２のパターン決定方法は、３つの平均待ち時間を、予め設定されたしきい値より大きいときに上位レベル、しきい値以下のときに下位レベルとすることによりパターンを決定する方法である。
【０１１９】
例えば、３つの平均待ち時間のうち最小のものを基準値とし、この基準値の１．６倍の値を上記しきい値とすると、しきい値は、最小の平均待ち時間であるＳＮＴｋ（＝３００秒）に１．６を乗じた４８０秒となる。この場合、平均待ち時間ＣＶＴｋ（＝５００秒）はしきい値より大きいので上位レベル、平均待ち時間ＳＯＴｋ（＝４５０秒），ＳＮＴｋ（＝３００秒）はしきい値以下であるので下位レベルとなり、パターン１が選択される。
【０１２０】
また、上記しきい値を上記基準値の１．４倍の値とすると、しきい値は４２０秒となる。この場合、平均待ち時間ＣＶＴｋ，ＳＯＴｋは共にしきい値よりも大きいので上位レベル、平均待ち時間ＳＮＴｋはしきい値以下であるので下位レベルとなり、パターン２が選択される。
【０１２１】
更に、上記しきい値を上記基準値の１．８倍の値とすると、しきい値は５４０秒となる。この場合、平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋは全てしきい値以下であるので下位レベルとなり、パターン４が選択される。
【０１２２】
しかしながら、このようにしきい値からパターンを決定すると、平均待ち時間は上位レベルと下位レベルのいずれかになるので、パターン３を採る場合はありえない。
【０１２３】
第３のパターン決定方法は、３つの平均待ち時間を、予め設定された第１のしきい値と第２のしきい値で比較し（第１のしきい値＞第２のしきい値）、第１のしきい値より大きいときに上位レベル、第２のしきい値より大きいときに中位レベル、第２のしきい値以下であるときに下位レベルとすることによりパターンを決定する方法である。
【０１２４】
例えば、３つの平均待ち時間のうち最小のものを基準値とし、この基準値の１．６倍の値を上記第１のしきい値、この基準値の１．３倍の値を上記第２のしきい値とすると、第１のしきい値は、最小の平均待ち時間であるＳＮＴｋ（＝３００秒）に１．６を乗じた４８０秒、第２のしきい値は３９０秒となる。この場合、平均待ち時間ＣＶＴｋ（＝５００秒）は上位レベル、平均待ち時間ＳＯＴｋ（＝４５０秒）は中位レベル、平均待ち時間ＳＮＴｋ（＝３００秒）は下位レベルとなり、パターン３が選択される。
【０１２５】
また、上記しきい値を夫々上記基準値の１．８倍、１．５倍の値とすると、第１のしきい値は５４０秒、第２のしきい値は４５０秒となる。この場合、平均待ち時間ＣＶＴｋ、ＳＯＴｋは共に中位レベルとなり、パターン２が選択される。
【０１２６】
さらに、上記しきい値を夫々上記基準値の２．０倍、１．８倍とすると、第１のしきい値は６００秒、第２のしきい値は５４０秒となる。この場合、平均待ち時間ＣＶＴｋ，ＳＯＴｋ，ＳＮＴｋは全て下位レベルとなり、パターン４が選択される。
【０１２７】
以上、第１〜第３のパターン決定方法によれば、算出された複数の処理部別の平均処理待ち時間に基づき、上記複数の処理部の負荷の度合いを示すパターンを決定し、この決定されたパターン毎にスレッドの優先度の組み合わせが設定されたシナリオのうちの最適なものを選択して、複数の処理部別にスレッドの優先度を決定するので、最適化対象期間別にスループットが向上するスレッドの多重化の最適値を確実に得ることができる。
【０１２８】
図１５は、図２のステップＳ２１３のイベント優先順位設定処理の手順を示すフローチャートである。
【０１２９】
本処理は、図２〜図５で前述したイベント処理において行われる処理の一つであり、図２に示すように、帳票検出部１１２が入力ファイル検出ディレクトリ１１２１にある入力ファイルを検出し（図２のステップＳ２１１）、イベントを生成する（ステップＳ２１２）毎に起動し、その処理終了後は図２のステップＳ２１４以降の処理が行われる。
【０１３０】
以下説明を簡略化するため、図１１、図１３と同様に、具体例として、最適化テンプレート定義用設定ファイルの最適化実施スケジュールの実施日数として８日間が指定されている場合について説明する。
【０１３１】
まず、１日目の測定期間（ｋ＝１）に本処理が起動すると、イベントに格納されたファイル名をキーとして、電子帳票マネージャシステム１２に保管されている変換用データ、仕分けデータ、格納先データ、及び個別イベントの優先度を取得し、イベントに格納する（ステップＳ８１１）。
【０１３２】
その後、測定期間１日目は最適化実施中であるので（ステップＳ８１２でＹＥＳ）、本処理をそのまま終了する。
【０１３３】
同様の処理を２日目〜８日目の測定期間においても行った後、最適化対象期間終了後１日目に本処理が起動すると、イベントに格納されたファイル名をキーとして、電子帳票マネージャシステム１２に保管されている上述のデフォルトデータを取得し、イベントに格納した後（ステップＳ８１１）、現在は最適化実施中ではないので（ステップＳ８１２でＮＯ）、イベントに格納されたファイル名と、現在日付をキーとして、電子帳票マネージャシステム１２のＤＢＭＳ１２１から現在の最適化対象期間における優先実行マーク情報を取得する（ステップＳ８１３）。ここで、優先実行マーク情報とは、最適化対象期間及び入力ファイルの種別（ファイル名）毎にある情報であって、イベント処理を優先的に実行する場合にマークが立てられる。
【０１３４】
次に、現在の最適化対象期間においてイベントのファイル名についての現在の最適化対象期間における優先実行マーク情報にマークが立てられていない場合は直接、マークがたてられている場合は（ステップＳ８１４でＹＥＳ）、イベントの優先順位を一つインクリメントして（ステップＳ８１５）、本処理を終了する。
【０１３５】
図１７は、図１０のステップＳ５３８の個別イベント優先度最適化処理の手順を示すフローチャートである。
【０１３６】
本処理は、図１０に示すように、図９のステップＳ５２４で見直し処理の起動がスケジューリングされた期間（最適化対象期間終了後１日目）への切り替わり時期となり（ステップＳ５３５でＹＥＳ）、図１２の処理部スレッド数登録処理（ステップＳ５３６）及び図１３の処理部別スレッド優先度登録処理（ステップＳ５３７）が終了した時に起動する。
【０１３７】
以下説明を簡略化するため、最適化テンプレート定義用設定ファイルの最適化実施スケジュールの実施日数として８日間が指定されており、測定期間中において図１５のイベント優先順位設定処理が行われた後に、最適化対象期間終了後１日目となり、本処理が起動した場合を例として説明する。
【０１３８】
まず、図７のステップＳ４１３において、入力ファイル毎にロギングされたデータから全入力ファイル毎の全イベントの平均処理時間μと標準偏差σを算出し（ステップＳ８２１）、次に、入力ファイル毎にその入力ファイルの平均処理時間を算出する（ステップＳ８２３）。
【０１３９】
次に、上記入力ファイルの平均処理時間がμ-σの値未満であるか否かを判別する（ステップＳ８２４）。ここで、上記入力ファイルの平均処理時間がμ-σの値以上であるときは直接、μ-σの値未満であるときはその入力ファイルについて優先実行マークを電子帳票マネージャシステム１２のＤＢＭＳ１２１中に立てる（ステップＳ８２５）。
【０１４０】
全ての入力ファイル毎のロギングデータについて上記処理を施し、全ての入力ファイルについて処理が完了すると（ステップＳ８２２でＮＯ）、本処理を終了する。
【０１４１】
図１５及び図１７の処理によれば、測定期間がが終了したときに本処理を起動し、測定時間中に処理された全イベントについて算出された平均処理時間μ及び標準偏差σ（ステップＳ８２１）と、ロギングされている各入力ファイルの平均処理時間（ステップＳ８２３）とに基づき、優先実行マークを立て（ステップＳ８２５）、この優先実行マークが立てられているイベントの優先順位を一つインクリメントするので（図１５のステップＳ８１５）、ジョブ発生量が予測可能である最適化対象期間中において、処理の実施に要する時間が短いジョブについては、優先的に処理を実施することができ、システム全体に滞留するジョブ量を減らすことができる。
【０１４２】
次に、上記具体例で最適なＷｋ，Ｓｊが最適化テンプレートファイルに保管されると共に、電子帳票マネージャシステム１２のＤＢＭＳ１２１にファイル名別に最適な優先順位が格納された後、図２〜図５のイベント処理が行われた場合について説明する。
【０１４３】
まず、ステップＳ２１４で帳票検出部１１２により優先度１と共にこのイベントが優先順位付キュー１１１１にポストされる。その後、ステップＳ２２１で、イベント制御部により、優先度がデフォルト値（０）のイベントよりも優先してこのイベントがキュー１１１１から取得される。
【０１４４】
ステップＳ２２３でイベント制御部１１１により貸し付けられたワークパスがイベントにセットされ、ステップＳ２２５でその優先度１と共にイベントが優先順位付キュー１１３１にポストされる。その後、ステップＳ２３１で、帳票変換部１１３により、優先度がデフォルト値（０）のイベントよりも優先してこのイベントがキュー１１３１から取得される。
【０１４５】
帳票変換部１１３は、ステップＳ２３３において、図１４の処理により最適化テンプレートファイルに登録された自身のスレッドの優先順位にこのイベントの優先度である１を加えて、このイベントの処理を開始する。例えば、自身のスレッドの優先順位が５である場合、これにこのイベントの優先度である１を加えた６に、このイベントを実行するスレッドの優先順位を設定し、優先順位が５であるスレッドにおけるイベント処理よりも優先的に処理を進行する。
【０１４６】
同様のキューからのイベント取得及びスレッドによるイベント処理実行が、帳票仕分け部１１４、帳票送信部１１５において行われる。この結果、同じ純粋処理時間を要する処理をデフォルトの優先度で処理した場合と比べ、処理時間の短縮が図られる。このように処理時間の短いものを優先実行することにより、システムそれぞれのキューに滞留するイベントの低減がはかられ、全体のスループットの向上を見込むことができる。
【０１４７】
また、本発明の目的は、上記実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（又は記録媒体）を、システム又は装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【０１４８】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１４９】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(ＯＳ)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５０】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５１】
また、上記プログラムは、上述した実施の形態の機能をコンピュータで実現することができればよく、その形態は、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給されるスクリプトデータ等の形態を有するものでもよい。
【０１５２】
プログラムを供給する記録媒体としては、例えば、ＲＡＭ、ＮＶ−ＲＡＭ、フロッピー（登録商標）ディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＭＯ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ）、磁気テープ、不揮発性のメモリカード、他のＲＯＭ等の上記プログラムを記憶できるものであればよい。或いは、上記プログラムは、インターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続される不図示の他のコンピュータやデータベース等からダウンロードすることにより供給される。
【図面の簡単な説明】
【０１５３】
【図１】本発明の第１の実施の形態に係るファイル登録システムとしての電子帳票登録システムの構成を概略的に示すブロック図である。
【図２】図１のシステム１１により実行されるイベント処理の手順を示すフローチャートである。
【図３】図３のフローチャートの続きである。
【図４】図４のフローチャートの続きである。
【図５】図５のフローチャートの続きである。
【図６】図１のシステムにより実行される見直し処理に用いられる各種ファイルの記述例を説明する図であり，（ａ）は最適化テンプレート定義用設定ファイルを示し、（ｂ）はワークパス定義用設定ファイルを示し、（ｃ）は最適化テンプレートファイルを示す。
【図７】図２のステップＳ２２１２のロギング処理の手順を示すフローチャートである。
【図８】図１のシステムにより実行される最適化対象期間切り替えスケジュール処理の手順を示すフローチャートである。
【図９】システムにより実行される最適化対象期間切り替え処理の手順を示すフローチャートである。
【図１０】システムにより実行される見直し処理の手順を示すフローチャートである。
【図１１】図１０のステップＳ５３２の処理部スレッド数最適化処理の手順を示すフローチャートである。
【図１２】図１０のステップＳ５３６の処理部スレッド数登録処理の手順を示すフローチャートである。
【図１３】図１０のステップＳ５３３の処理部別スレッド優先順位最適化処理の手順を示すフローチャートである。
【図１４】図１０のステップＳ５３７の処理部別スレッド優先順位登録処理の手順を示すフローチャートである。
【図１５】図２のステップＳ２１３のイベント優先順位設定処理の手順を示すフローチャートである。
【図１６】図１の電子帳票マネージャシステムのＤＢＭＳに予め保存されている複数のシナリオを示す図であり、（ａ）はパターン１の場合、（ｂ）はパターン２の場合、（ｃ）はパターン３の場合、（ｄ）はパターン４の場合を示す。
【図１７】図１０のステップＳ５３８の個別イベント優先度最適化処理の手順を示すフローチャートである。
【符号の説明】
【０１５４】
１１  電子帳票登録システム
１５  ホストコンピュータ
１２１  ＤＢＭＳ
１２  電子帳票マネージャシステム
１３  電子帳票保管システム
１４  ＷＥＢサーバ
１１２１  入力ファイル検出ディレクトリ
１１２  帳票検出部
１１３  帳票変換部
１１４  帳票仕分け部
１１５  帳票送信部
１１１  イベント制御部
１１０  記録部
【図１】
2006189932.tif 000003
【図２】
2006189932.tif 000004
【図３】
2006189932.tif 000005
【図４】
2006189932.tif 000006
【図５】
2006189932.tif 000007
【図６】
2006189932.tif 000008
【図７】
2006189932.tif 000009
【図８】
2006189932.tif 000010
【図９】
2006189932.tif 000011
【図１０】
2006189932.tif 000012
【図１１】
2006189932.tif 000013
【図１２】
2006189932.tif 000014
【図１３】
2006189932.tif 000015
【図１４】
2006189932.tif 000016
【図１５】
2006189932.tif 000017
【図１６】
2006189932.tif 000018
【図１７】
2006189932.tif 000019