性能評価

トワークに接続し、実験を行った。計測データの誤差や、ばらつきを減らすため、このプライ ベートネットワーク上には、他のPCを接続していない。

6.3.4 実験結果

以上のような環境において実際に評価実験を行った結果を、以下の図6.5に示す。

!#"$%

&

' ()

* +, -./0

1

2345

&

/0

1

6 7

89

*+:(3;1

<5

=?>?@BADCDEFHGBI !

I D JKLM

ADC?N>

図6.5: データベースのエントリー数に応じたEPCADSの性能変化

データベースのエントリー数が50件の時には1分間に約1400個のクエリを処理できている。

しかし、データベースのエントリー数が増えるにつれて、処理できるクエリ数が減少していき、

エントリー数が6500件の時にはおよそ半数の700個になっている。1クエリあたりの処理時間 を見てみると、データベースのエントリー数が50件の時にはおよそ80msecであった処理時間 が、エントリー数が6500件の時には160msec以上かかってしまっている。

6.3.5 まとめ

実験結果から、本システムはデータベースのエントリー数が増加するのに応じて、EPCADS の性能が低下することが確認された。これは、データベースのエントリー数が増加することによ り、データの検索にかかる時間が長くなることが原因である。このことから、本システムの今後 の課題として、データベースの応答性能の向上が挙げられる。今回の評価では、データベース内 のエントリ数の増加に伴い、応答性能の低下が確認された。この応答性能の低下はPostgreSQL 特有の現象であるのか、また、他のデータベースを用いた場合にはどのような結果が出るのか について、調査する必要がある。

また、データベースの応答性能を除外して考えた際にも、性能面で大きな課題が残る。実際 の運用を考えた際には多数クライアントから、同時に多くのクエリが集中することが考えられ る。データベースのエントリー数を最小にして計測した場合でも、1分間に処理できるクエリ

の数が1500個程度であるため、世界中のオブジェクトにタグを貼付し、本システムでプライ バシを保護することは不可能である。さらに、復号化にかかる時間も今後の課題としてあげら れる。今回の評価では暗号強度は評価対象外であったため、非常に短時間で計算できる暗号化 しかしていないが、実際の運用を考えた際には暗号強度を十分に確保する必要がある。このよ うな場合には、復号化のための計算にかかる時間は飛躍的に増加するため、同一時間内に処理 できるクエリの数はさらに減少することが予想される。

以上のことをまとめると、本システムを実際に運用する際には、データベースの応答性能と、

復号化処理にかかる時間が問題点となり、規模性を確保できないと思われる。