(57)【要約】      （修正有）【課題】ソフトウェアのデータ／プロセス分離によって発生する性能影響を更に精度よく評価する性能影響評価装置を提供する。【解決手段】性能影響評価装置１は、ログ記憶部１１及び評価式記憶部１２を有する記憶装置１０と、ログ取得部２１及び評価部２２を有する処理装置２０とを備える。ログ記憶部は、ログ取得部によって取得されたログを記憶する。評価式記憶部は、性能影響の評価に用いる評価式を記憶する。シングル部分評価式１２Ａは、ソフトウェアがシーケンシャルに処理する構造である部分の評価に用いる評価式であり、マルチ部分評価式１２Ｂは、並列に処理する構造である部分の評価に用いる評価式である。ログ取得部は、外部ＤＢへのアクセスを記録するためのログを取得する。シングル部分評価部２２Ａは、シングル部分評価式を用いてシーケンシャル部分を評価し、マルチ部分評価部２２Ｂは、マルチ部分評価式を用いて並列部分を評価する。【選択図】図３
2019175067.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアで用いるデータを外部ＤＢに分離することによって発生する性能影響を評価する性能影響評価装置であって、
前記外部ＤＢへのアクセスを記録するためのログを取得するログ取得部と、
前記ログ取得部によって取得されたログに基づいて、データの特徴だけでなくソフトウェアの構造を考慮した評価式を用いて前記性能影響を評価する評価部と
を備えることを特徴とする性能影響評価装置。
【請求項２】
前記評価部は、前記ソフトウェアの構造がシーケンシャルに処理する構造である部分と並列処理する構造である部分とで異なる評価式を用いて前記性能影響を評価することを特徴とする請求項１に記載の性能影響評価装置。
【請求項３】
前記評価部は、前記ソフトウェアの構造がシーケンシャルに処理する構造である部分については、遅延影響がアクセス回数倍される評価式を用いて前記性能影響を評価することを特徴とする請求項２に記載の性能影響評価装置。
【請求項４】
前記評価部は、前記ソフトウェアの構造がシーケンシャルに処理する構造である部分については、下記評価式を用いて前記性能影響を評価することを特徴とする請求項３に記載の性能影響評価装置。
【数３】
2019175067.tif 000011
【請求項５】
前記評価部は、前記ソフトウェアの構造が並列処理する構造である部分については、遅延影響が累積しない評価式を用いて前記性能影響を評価することを特徴とする請求項２に記載の性能影響評価装置。
【請求項６】
前記評価部は、前記ソフトウェアの構造が並列処理する構造である部分については、下記評価式を用いて前記性能影響を評価することを特徴とする請求項５に記載の性能影響評価装置。
【数４】
2019175067.tif 000012
【請求項７】
前記評価部は、前記外部ＤＢへのアクセス回数分だけサイズが影響を与える評価式を用いて前記性能影響を評価することを特徴とする請求項１から６のいずれか１項に記載の性能影響評価装置。
【請求項８】
ソフトウェアで用いるデータを外部ＤＢに分離することによって発生する性能影響を評価する性能影響評価方法であって、
性能影響評価装置が、
前記外部ＤＢへのアクセスを記録するためのログを取得するログ取得ステップと、
前記ログ取得ステップで取得されたログに基づいて、データの特徴だけでなくソフトウェアの構造を考慮した評価式を用いて前記性能影響を評価する評価ステップと
を実行することを特徴とする性能影響評価方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアのデータ／プロセス分離によって発生する性能影響を評価する性能影響評価装置及び性能影響評価方法に関する。
【背景技術】
【０００２】
従来、システムのスケーラビリティ向上などの運用効率化やコンピューターリソース使用の効率化のため、クラウド環境などへの移行が各分野で広く取り組まれている。処理サーバに大きなリソース（ＣＰＵ、メモリ）を要求する通信システムにおいても同様の傾向にあるが、従来型の通信システムをそのまま新しい実行環境に移行しただけではメリットを享受することはできない。
【０００３】
従来型の通信システムの多くにおいては、それぞれの処理サーバが個々に処理する内容が定義されているなど、各処理サーバに個性が存在する。この個性が新しい実行環境においても残存すると、運用の効率化やリソースの有効活用などのメリットを享受することが難しい。
【０００４】
一つの解決スタイルとして、データを外部ＤＢに分離させて処理サーバ間で共有させ、個性をもたらしているデータを処理サーバから排除し、処理サーバの個性を無くす方法がある（例えば、特許文献１）。個性の無い処理サーバとすることでクラウド環境などでも処理サーバをより単純な位置づけにすることができ、スケーラビリティの向上や、効率的なロードバランシングによるリソース効率化を実現できると考えられている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１８-０２５８６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、データ分離型システムへ移行するにあたり、外部ＤＢへのアクセスが新たに追加となる。このアクセスが呼処理ＴＡＴ（Turn Around Time）延伸につながり、性能などに影響する。この影響評価を開発判断の前にする必要があるが、長年開発を積み重ね複雑化したＮＴＴやＯＳＳのソフトウェアの性能見積もりを開発前に行うのは困難である。そのため、外部ＤＢへのアクセス追加がもたらす性能影響を解決する必要がある。特許文献１には、アプリケーションで用いられるデータの適切な分離を支援するデータ分離評価装置が開示されているが、更に精度よく性能影響を評価することが望まれている。
【０００７】
本発明は、上述した従来の技術に鑑み、ソフトウェアのデータ／プロセス分離によって発生する性能影響を更に精度よく評価することができる性能影響評価装置及び性能影響評価方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、第１の態様に係る発明は、ソフトウェアで用いるデータを外部ＤＢに分離することによって発生する性能影響を評価する性能影響評価装置であって、前記外部ＤＢへのアクセスを記録するためのログを取得するログ取得部と、前記ログ取得部によって取得されたログに基づいて、データの特徴だけでなくソフトウェアの構造を考慮した評価式を用いて前記性能影響を評価する評価部とを備えることを要旨とする。
【０００９】
第２の態様に係る発明は、第１の態様に係る発明において、前記評価部が、前記ソフトウェアの構造がシーケンシャルに処理する構造である部分と並列処理する構造である部分とで異なる評価式を用いて前記性能影響を評価することを要旨とする。
【００１０】
第３の態様に係る発明は、第２の態様に係る発明において、前記評価部が、前記ソフトウェアの構造がシーケンシャルに処理する構造である部分については、遅延影響がアクセス回数倍される評価式を用いて前記性能影響を評価することを要旨とする。
【００１１】
第４の態様に係る発明は、第３の態様に係る発明において、前記評価部が、前記ソフトウェアの構造がシーケンシャルに処理する構造である部分については、下記評価式を用いて前記性能影響を評価することを要旨とする。
【００１２】
【数３】
2019175067.tif 000003
【００１３】
第５の態様に係る発明は、第２の態様に係る発明において、前記評価部が、前記ソフトウェアの構造が並列処理する構造である部分については、遅延影響が累積しない評価式を用いて前記性能影響を評価することを要旨とする。
【００１４】
第６の態様に係る発明は、第５の態様に係る発明において、前記評価部が、前記ソフトウェアの構造が並列処理する構造である部分については、下記評価式を用いて前記性能影響を評価することを要旨とする。
【００１５】
【数４】
2019175067.tif 000004
【００１６】
第７の態様に係る発明は、第１から第６のいずれか１つの態様に係る発明において、前記評価部が、前記外部ＤＢへのアクセス回数分だけサイズが影響を与える評価式を用いて前記性能影響を評価することを要旨とする。
【００１７】
第８の態様に係る発明は、ソフトウェアで用いるデータを外部ＤＢに分離することによって発生する性能影響を評価する性能影響評価方法であって、性能影響評価装置が、前記外部ＤＢへのアクセスを記録するためのログを取得するログ取得ステップと、前記ログ取得ステップで取得されたログに基づいて、データの特徴だけでなくソフトウェアの構造を考慮した評価式を用いて前記性能影響を評価する評価ステップとを実行することを要旨とする。
【発明の効果】
【００１８】
本発明によれば、ソフトウェアのデータ／プロセス分離によって発生する性能影響を更に精度よく評価することができる性能影響評価装置及び性能影響評価方法を提供することが可能である。
【図面の簡単な説明】
【００１９】
【図１】背景技術を説明するための概念図である。
【図２】背景技術の課題を説明するための概念図である。
【図３】本発明の実施の形態における性能影響評価装置の機能ブロック図である。
【図４】本発明の実施の形態における性能影響評価装置の動作を示すフローチャートである。
【図５】比較例を説明するための概念図である。
【図６】比較例の課題１を説明するための概念図である。
【図７】比較例の課題２を説明するための概念図である。
【図８】実施例２（シングル部分）を説明するための概念図である。
【図９】実施例２（マルチ部分）を説明するための概念図である。
【図１０】実施例２の効果を説明するための概念図である。
【発明を実施するための形態】
【００２０】
以下、図面を用いて本発明の実施の形態を説明する。以下の図面の記載において、同一または類似の部分には同一または類似の符号を付している。
【００２１】
＜背景＞
既に説明したように、従来型の通信システムをそのまま新しい実行環境に移行しただけではメリットを享受することはできない。例えば、図１（ａ）から図１（ｂ）のように、実行環境を仮想環境へ移行しても、各処理サーバ（各アプリケーション）３の個性が新しい実行環境においても残存すると、ロードバランシングやスケーラビリティなどの面でメリットを享受できない。一方、図１（ｂ）から図１（ｃ）のように、個性を生むデータ２を共有（ここではデータ分離）し、処理サーバ３を無個性化すると、ロードバランシングやスケーラビリティなどの面でメリットを享受できる。
【００２２】
しかしながら、図１（ｂ）から図１（ｃ）のように、データ分離型システムへ移行するにあたり、外部ＤＢ４へのアクセスが新たに追加となる。そのため、図２に示すように、外部ＤＢ４へのアクセスが呼処理ＴＡＴ延伸につながり、「開発後の性能が分からない」「費用対効果が分からない」「開発判断できない」等の問題があるため、外部ＤＢ４へのアクセス追加がもたらす性能影響を解決する必要がある。
【００２３】
＜性能影響評価装置＞
図３は、本発明の実施の形態における性能影響評価装置１の機能ブロック図である。この性能影響評価装置１は、ソフトウェアのデータ／プロセス分離によって発生する性能影響を評価する装置である。すなわち、データ２を外部ＤＢ４に分離させて、処理サーバ３間で共有させ、処理量に影響をもたらしているデータ２を処理サーバ３から排除し、処理サーバ３の個性を無くすことにより、処理サーバ３の処理の偏りを防止する技術を前提としている。このようなデータ／プロセス分離によって発生する性能影響を評価するにあたり、データ２の特徴だけでなくソフトウェアの構造を考慮した評価式を用いることとしている。
【００２４】
記憶装置１０は、各種データを記憶するハードディスク等であって、ログ記憶部１１と、評価式記憶部１２とを有する。ログ記憶部１１は、ログ取得部２１によって取得されたログを記憶する。評価式記憶部１２は、性能影響を評価する際に用いられる評価式を記憶する。シングル部分評価式１２Ａは、シングル部分を評価する際に用いられる評価式である。シングル部分とは、ソフトウェアの構造がシーケンシャルに処理する構造である部分を意味する。マルチ部分評価式１２Ｂは、マルチ部分を評価する際に用いられる評価式である。マルチ部分とは、ソフトウェアの構造が並列処理する構造である部分を意味する。もちろん、データ２の特徴を考慮した評価を行う場合は、そのような評価式も記憶されている。
【００２５】
処理装置２０は、各種処理を実行するＣＰＵ等であって、ログ取得部２１と、評価部２２とを有する。ログ取得部２１は、外部ＤＢ４へのアクセスを記録するためのログを取得する。評価部２２は、ログ取得部２１によって取得されたログに基づいて、データ２の特徴だけでなくソフトウェアの構造を考慮した評価式を用いて性能影響を評価する。シングル部分評価部２２Ａは、シングル部分評価式１２Ａを用いてシングル部分を評価する。マルチ部分評価部２２Ｂは、マルチ部分評価式１２Ｂを用いてマルチ部分を評価する。もちろん、データ２の特徴を考慮した評価を行う場合は、そのような評価部も有している。
【００２６】
なお、“ソフトウェアのデータ／プロセス分離”とは、処理サーバ（アプリケーション）３で用いるデータ２を処理サーバ３上のプロセスＰから分離することである（図２参照）。アプリケーション３は、特定の目的を達成するために設計されたソフトウェアである。プロセスＰは、アプリケーション３の制御ロジックである。
【００２７】
また、“ソフトウェアのデータ／プロセス分離”は、“ソフトウェアで用いるデータ２を外部ＤＢ４に分離すること”と言い換えることもできる。外部ＤＢ４は、処理サーバ３と通信ネットワークを介して接続された外部装置上のデータベースであり、典型的にはクラウドコンピュータである。
【００２８】
＜動作＞
図４は、本発明の実施の形態における性能影響評価装置１の動作を示すフローチャートである。以下、図４を用いて、性能影響評価装置１の構成をその動作とともに説明する。ここでは、ソフトウェアの構造を考慮して性能影響を評価する点だけに着目して説明することとし、データ２の特徴を考慮して性能影響を評価する点については詳しい説明を省略する。
【００２９】
まず、ログ取得部２１は、外部ＤＢ４へのアクセスを記録するためのログを取得する（ステップＳ１）。例えば、ログには、１呼あたりのアクセス頻度と各データ２のサイズを記録する。以下の説明では、データ２のサイズを単に「サイズ」という場合がある。
【００３０】
次いで、評価部２２は、ソフトウェアの構造がシーケンシャルに処理する構造である部分であるか、並列処理する構造である部分であるかを判定する（ステップＳ２）。ここで、ソフトウェアの構造がシーケンシャルに処理する構造である部分である場合、シングル部分評価部２２Ａがシングル部分評価式１２Ａを用いてシングル部分を評価する（ステップＳ３）。一方、ソフトウェアの構造が並列処理する構造である部分である場合、マルチ部分評価部２２Ｂがマルチ部分評価式１２Ｂを用いてマルチ部分を評価する（ステップＳ４）。
【００３１】
以上の処理をソフトウェアの全ての部分について繰り返す（ステップＳ２→Ｓ３→Ｓ２→…，Ｓ２→Ｓ４→Ｓ２→…）。最後に評価値を出力し（ステップＳ５）、処理を終了する。
【００３２】
なお、データ２の特徴を考慮して性能影響を評価する手法としては、公知の手法を用いることができる。例えば、特許文献１に記載されているように、（１）複数の装置からアクセスされるデータは分離する方がよく、特定の装置のみからアクセスされるデータは分離しない方がよい、（２）アクセスが頻繁である場合またはデータ容量が大きい場合は分離しない方がよい、（３）リアルタイムな応答で用いるデータは分離しない方がよい、（４）重要なデータで冗長化が必要なデータは分離する方がよい、等の基準で評価することが可能である。
【００３３】
これにより、ユーザは、性能影響評価装置１から出力される評価値に基づいて、分離するデータと分離しないデータとを振り分ける指標を得ることができる。また、データを分離してアプリケーション３を設計した際の分離効果を把握することができる。その結果、分散効果が高い場合にはデータ分離型システムを採用し、逆に分離効果が低い場合にはデータ分離型システムを採用しない等、データ分離型システムの採用要否の指標を得ることが可能となる。
【００３４】
＜比較例＞
次に、比較例について説明する。比較例は、特許文献１に開示される技術に相当するが、特許文献１に開示されていない内容も含まれる。
【００３５】
比較例では、各データ２の特徴（サイズ、アクセス頻度、ライフタイムなど）を踏まえ、それぞれの特徴の度合いを把握し、それぞれの度合いからデータ分離による影響を評価する。例えば、図５に示すように、データ２Ａと２Ｂのサイズの違いが与える影響や、アプリケーション３から外部ＤＢ４へのアクセス頻度が与える影響を評価する。その他に、ライフタイム、データ種別（状態、コンフィグ等）などデータ操作の特徴別に適正評価する。この手法に照らし合わせると、性能影響評価は、“［遅延］＝［サイズ評価］＋［アクセス頻度評価］＋・・・”のように表すことができる。それぞれの特徴が独立して遅延に影響するものとしている。
【００３６】
＜比較例の課題１＞
次に、比較例の課題１について説明する。比較例を検証により確かめたところ、性能に影響する特徴はサイズとアクセス頻度であった。また、評価計算上、サイズが与える性能影響はアクセス頻度に関わらず独立したものとしていたが、性能影響に対してサイズはアクセス回数分だけ影響を与えることを確認した。このことから、評価式上のサイズとアクセス頻度に関しては、独立関係ではなく従属関係にあることが分かった。
【００３７】
比較例で評価できるのは、図６（ａ）に示すように、アプリケーション３から外部ＤＢ４へ１回アクセスする時のみである。すなわち、図６（ｂ）に示すように、アプリケーション３から外部ＤＢ４へ２回アクセスする時や、図６（ｃ）に示すように、アプリケーション３から外部ＤＢ４へｎ回（ｎは３以上の整数）アクセスする時は、比較例で評価できない。一般的に、ごく短い期間内に複数のデータアクセスが想定される通信システムにおいて、データ分離時の遅延評価をするためには、アクセス頻度とサイズの従属関係を評価式に反映する必要がある。
【００３８】
＜実施例１＞
次に、実施例１について説明する。実施例１は、本発明の実施の形態の一例であり、比較例の課題１を解決するためのものである。上記したように、サイズとアクセス頻度に関しては従属関係にあるため、実施例１では下記［数１］の評価式を用いる。
【００３９】
【数１】
2019175067.tif 000005
【００４０】
データアクセス頻度は呼量に比例して増減する。アクセス頻度とサイズの従属関係を反映した上記の評価式により、評価対象の通信システムの呼量に応じた評価ができる。
【００４１】
＜比較例の課題２＞
データ２の特徴に閉じた観点では［数１］の評価式となるが、ソフトウェアの構造（並列処理）も性能に影響する。すなわち、シーケンシャルに処理する構造と並列処理する構造とで性能影響が異なる。例えば、図７（ａ）に示すように、シーケンシャルに処理する構造では、スレッドＴ１が外部ＤＢ４にシーケンシャルにアクセスするため、遅延影響がアクセス回数倍される。一方、図７（ｂ）に示すように、並列処理する構造では、スレッドＴ１，Ｔ２，Ｔ３がそれぞれ外部ＤＢ４に並列にアクセスするため、遅延影響が累積しない。比較例では、このようなソフトウェア構造まで考慮した性能影響評価ができない。
【００４２】
＜実施例２＞
次に、実施例２について説明する。実施例２は、本発明の実施の形態の一例であり、比較例の課題２を解決するためのものである。実施例２では、ソフトウェア構造を考慮した性能影響評価を実現するため、シングル部分とマルチ部分とで性能影響を以下の通りとする。
【００４３】
まず、シングル部分では、性能影響は全呼のアクセス回数倍とする。具体的には、図８に示すように、各呼Ａ，Ｂ，Ｃ，…ごとに同じような処理サイクルがあり、各呼Ａ，Ｂ，Ｃ，…ごとの処理で外部ＤＢ４にアクセスするものと仮定する。この場合、シングル部分では、スレッドＴ１において、先発の呼（例えば、呼Ａ，呼Ｂ，…）のデータアクセスの後に後続の呼（例えば、呼Ｂ，呼Ｃ，…）のデータアクセスが発生するため、各呼のアクセスの遅延が後続に蓄積する（待たされる）。なお、ソフトウェアの再送タイマの期間で生じる遅延がタイマ値の範囲内であれば許容範囲内である（遅延影響が再送タイマの期間より小さい必要がある）。
【００４４】
一方、マルチ部分では、１呼分のアクセス回数倍とする。具体的には、図９に示すように、各呼Ａ，Ｂ，Ｃ，…ごとに同じような処理サイクルがあり、各呼Ａ，Ｂ，Ｃ，…ごとの処理で外部ＤＢ４にアクセスするものと仮定する。この場合、マルチ部分では、それぞれのスレッドＴ１，Ｔ２，Ｔ３において、個別に各呼Ａ，Ｂ，Ｃのデータアクセスが発生するため、呼毎に発生するアクセス回数が各呼に影響する。
【００４５】
以下、各ソフトウェア構造の評価式について具体的に説明する。ここでは、実施例２の評価式の特徴を明確にするため、比較例の評価式と対比しながら説明する。
【００４６】
まず、比較例の評価式は、下記［数２］の評価式であると仮定する。アクセス頻度［回／秒］は、アプリケーション３から外部ＤＢ４へのアクセス頻度であり、サイズ［Ｂｙｔｅ］は、アクセスされるデータ２Ａ，２Ｂのサイズである（図５参照）。アクセス頻度［回／秒］は、頻度［回／呼］×呼量［呼／秒］と言い換えることができ、頻度［回／呼］は、１呼あたりのアクセス回数と言い換えることができる。
【００４７】
【数２】
2019175067.tif 000006
【００４８】
それに対して、実施例２においては、下記［数３］に示すように、シングル部分では、性能影響は全呼のアクセス回数倍とする（図８参照）。タイマ値［秒］は、ソフトウェアの再送タイマの期間である。呼量［呼／秒］×タイマ値［秒］により、一番最後の信号がその前段でどれだけの処理を受けた後に処理をしなければいけないかを求めている。
【００４９】
【数３】
2019175067.tif 000007
【００５０】
また、実施例２においては、下記［数４］に示すように、マルチ部分では、性能影響は１呼分のアクセス回数倍とする（図９参照）。すなわち、個別に各呼Ａ，Ｂ，Ｃのデータアクセスが発生するため、１呼あたりのアクセス回数とサイズで求めることができる。そのため、［数４］は、［数２］の評価式から“×呼量［呼／秒］”を消した内容になっている。
【００５１】
【数４】
2019175067.tif 000008
【００５２】
以上のように、実施例２によれば、ソフトウェアの構造を考慮して性能影響を評価することができる。データ２の特徴だけを考慮しただけでは評価が実態と合わない場合があるが、ソフトウェアの構造を考慮して評価することで、より正確に評価をすることが可能となる。具体的には、図１０に示すように、シーケンシャルに処理する部分で問題ないか区別して評価できるとともに、並列に処理する部分で問題ないか区別して評価できるようになる。
【００５３】
＜まとめ＞
以上説明したように、本発明の実施の形態における性能影響評価装置１は、ソフトウェアで用いるデータ２を外部ＤＢ４に分離することによって発生する性能影響を評価する装置であって、外部ＤＢ４へのアクセスを記録するためのログを取得するログ取得部２１と、ログ取得部２１によって取得されたログに基づいて、データ２の特徴だけでなくソフトウェアの構造を考慮した評価式を用いて性能影響を評価する評価部２２とを備える。これにより、ソフトウェアのデータ／プロセス分離によって発生する性能影響を更に精度よく評価することができる性能影響評価装置１を提供することが可能である。
【００５４】
具体的には、評価部２２は、ソフトウェアの構造がシーケンシャルに処理する構造である部分と並列処理する構造である部分とで異なる評価式を用いて性能影響を評価してもよい。シーケンシャルに処理する構造と並列処理する構造とで性能影響が異なるためである。
【００５５】
また、評価部２２は、ソフトウェアの構造がシーケンシャルに処理する構造である部分については、遅延影響がアクセス回数倍される評価式を用いて性能影響を評価してもよい。これにより、外部ＤＢ４にシーケンシャルにアクセスする場合に、その実態に合った評価を行うことが可能である。
【００５６】
また、評価部２２は、ソフトウェアの構造がシーケンシャルに処理する構造である部分については、下記評価式を用いて性能影響を評価してもよい。これにより、性能影響は全呼のアクセス回数倍とすることが可能である。
【００５７】
【数３】
2019175067.tif 000009
【００５８】
また、評価部２２は、ソフトウェアの構造が並列処理する構造である部分については、遅延影響が累積しない評価式を用いて性能影響を評価してもよい。これにより、外部ＤＢ４に並列にアクセスする場合に、その実態に合った評価を行うことが可能である。
【００５９】
また、評価部２２は、ソフトウェアの構造が並列処理する構造である部分については、下記評価式を用いて性能影響を評価してもよい。これにより、性能影響は１呼分のアクセス回数倍とすることが可能である。
【００６０】
【数４】
2019175067.tif 000010
【００６１】
また、評価部２２は、外部ＤＢ４へのアクセス回数分だけサイズが影響を与える評価式を用いて性能影響を評価してもよい。これにより、アクセス頻度とサイズの従属関係を評価式に反映することが可能である。
【００６２】
また、本発明の実施の形態における性能影響評価方法は、ソフトウェアで用いるデータ２を外部ＤＢに分離することによって発生する性能影響を評価する方法であって、性能影響評価装置１が、外部ＤＢ４へのアクセスを記録するためのログを取得するログ取得ステップと、ログ取得ステップで取得されたログに基づいて、データ２の特徴だけでなくソフトウェアの構造を考慮した評価式を用いて性能影響を評価する評価ステップとを実行する。これにより、ソフトウェアのデータ／プロセス分離によって発生する性能影響を更に精度よく評価することができる性能影響評価方法を提供することが可能である。
【００６３】
＜その他の実施の形態＞
上記のように、本発明の実施の形態によって記載したが、この開示の一部をなす論述および図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例および運用技術が明らかとなる。
【００６４】
例えば、本発明の実施の形態における性能影響評価装置１は、図３に示すように一つのハードウエア上に構成されてもよいし、その機能や処理数に応じて複数のハードウエア上に構成されてもよい。また、既存の情報処理システム上に実現されてもよい。
【００６５】
また、本発明の実施の形態における性能影響評価装置１でも、特許文献１に開示される技術を採用してもよい。例えば、特許文献１に開示される技術と同様の手法によりスコアを生成して性能影響を評価することも可能である。
【００６６】
本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。従って、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【符号の説明】
【００６７】
１…性能影響評価装置
２…データ
３…処理サーバ（アプリケーション）
４…外部ＤＢ
１０…記憶装置
１１…ログ記憶部
１２…評価式記憶部
２０…処理装置
２１…ログ取得部
２２…評価部
【図１】
2019175067.tif 000013
【図２】
2019175067.tif 000014
【図３】
2019175067.tif 000015
【図４】
2019175067.tif 000016
【図５】
2019175067.tif 000017
【図６】
2019175067.tif 000018
【図７】
2019175067.tif 000019
【図８】
2019175067.tif 000020
【図９】
2019175067.tif 000021
【図１０】
2019175067.tif 000022