前回,TPC-Cでは非現実的なチューニングが可能である点が問題であると述べた。今回は,この点をもう少し追及してみよう。

◆ベンチマークの本質的な問題

 TPCに限らず,標準パフォーマンス・ベンチマークが抱えている本質的な問題とは,各ベンダーが自社の製品の数値をよく見せるために現実のアプリケーションの性能アップとはほとんど関係がないようなチューニングをしてしまうことである。自動車の例でいえば,燃費テストの結果を良くするために,トップギアだけを異常にハイギアにして,運転しにくいセッティングにしてしまうことに相当するだろうか。

 要は真の実力がなくてもテストの点だけを良く見せるような細工が可能であるような単純すぎるテストは良くないテストだということである。

 オンライン・トランザクション処理という比較的複雑性が高いアプリケーションにおける性能を適切に表現しようとするならば,パフォーマンス・ベンチマークにもある程度の複雑性が必要である。

◆単純すぎるTPC-C

 TPC-Cは,それ以前にあったTPC-AとTPC-Bという単純すぎるベンチマークの問題を解決すべく1992年に開発された。現実世界の受注処理アプリケーションを模したものであり,複数のトランザクション・タイプを使用し,ログの書き込みも強制するなど,当時のベンチマークとしてはかなり現実のアプリケーションに近いとされていた。

 しかし,今日では,TPC-Cは現実のアプリケーションと比較するとやはり複雑性が足りないということが明らかになっている。たとえば,TPC-Cで使用するデータベースのテーブル数は9個にすぎない。

 また,データベースに対するアクセスの競合も少なすぎる。現実のアプリケーションでは,たとえば,制御テーブルへの書き込み,品番の採番のためのカウンタへのアクセス,など複数のプロセスからのアクセスが集中するデータ,いわゆる,ホット・スポットが性能のボトルネックとなることが多い。このあたりの条件がTPC-Cではほとんど再現できていない。

 その結果,TPC-Cでは,DBMSのロッキング処理の効率性,I/Oドライバの並列性などの現実のアプリケーションの性能向上には重要な要素がほとんど影響せず,プロセサが速ければ単純に数値が向上してしまう傾向が見られる。

 最近,米Sun Microsystemsが自社製品のTPC-C値の発表を控える傾向があるが,これは,同社のサーバーの設計思想が,必ずしも業界最速ではないプロセサを使いつつ,Solarisというスケーラビリティが高いOSと余裕のあるメモリー・インターコネクトで性能を稼ぐことにある点が大きいと思われる。つまり,Sun社の設計思想では,TPC-Cで現実のアプリケーションにおける真の実力が表現できないわけである。

◆クラスタ構成によるTPC-Cベンチマークは,ほぼ無意味

 そして,TPC-Cのデータ設計に起因するさらに大きな問題がある。TPC-Cのデータベースのテーブルのほとんどが倉庫IDを主キーとしている。そして多くのデータベース・アクセスが倉庫IDのみをキーとしたものとなっている。これにより,テーブルを倉庫IDのキー範囲により分割して複数のサーバから並行アクセスさせることが容易になる。つまり,クラスタ構成でノード間の競合をほとんど発生させないようにすることができるのである。これは,現実のアプリケーション環境ではほとんどあり得ない状況である。

 要するに,TPC-Cでは,サーバーを多数そろえて,データベースを分割していけば,好きなだけ見かけ上の性能を上げられるということである。一時期,PCサーバーのクラスタ構成によるTPC-Cの新記録が続けざまに発表されたことがあった。これは,まったく現実のアプリケーション環境での性能を表現したものとはいえない。

 さすがに,TPCもこれではまずいと感じたのであろう。最近はWebサイトでのTPC-Cのランキングはクラスタ構成のものと非クラスタ構成を分けて掲載するようになっている。これは当然のことだろう。

◆もっと良いベンチマークはないのか?

 では,もう少し現実のアプリケーション環境の性能を適切に表現できるベンチマーク・テストはないのだろうか? ベンチマークである以上,完璧ということはないが,TPC-Cよりは忠実に現実世界のアプリケーションの性能を測定できるベンチマークがある。それが,SAP R/3 SD(販売管理)ベンチマークに代表されるアプリケーション・パッケージをそのまま稼働することによるベンチマークである。これらのアプリケーション・ベンチマークについて,次回に詳しく見ていくこととしよう。