今回は，SAPアプリケーションのサイジングだけでなく，一般的なOLTP能力の評価としても有用な指標であるSAP SDベンチマークについてもう少し詳しく見ていくこととしよう。
前回述べたように，SAP SDベンチマークは，SAP R/3の販売管理モジュールをそのまま稼働させ，典型的な処理パターン（受注の入力・照会・変更，送り状発行など）において平均応答時間2秒以下を維持できる同時並行ユーザー数と時間当たりのダイアログ数（トランザクション処理を伴う画面転換の回数）を測定するというものである。性能評価はSAPSと呼ばれる正規化された値で表現される。1SAPSは100明細行を１時間で処理できることを表す。
言うまでもないが，タイプの違うSAPベンチマーク，例えばSDとATOとの間でSAPS値を比較することには全く意味がない。
比較の際のもう1つの考慮点は，ベンチマークで使用したSAP R/3のバージョンである。少なくともメジャー・リリースが異なる環境の結果を比較する（例えば，4.6Cと3.1H）ことにあまり意味があるとはいえない。マイナー・リリースが異なる環境の結果（例えば，4.6Cと4.0B）は，さほど大きな差が出るわけではないが，きん差のプラットフォーム間の比較をする場合にはバージョン違いが考慮の対象となることがある（そもそも，実験室的な値であるベンチマーク性能のきん差を議論しても意味はないとも言えるが）。
◆2種類のベンチマーク
SAP SDには大きく2種類がある。2-Tier（2層）構成によるものと3-Tier（3層）構成によるものである。要するに前者は完全な集中型構成であり，後者はクラスタによる分散構成である。SAPアプリケーション（というよりも，一般にエンタープライズ・アプリケーション・パッケージ）においてデータベース・サーバーをクラスタで分散することで，性能を向上することが難しいのは前回述べたとおりである。つまり，2-Tierであっても3-Tierであっても結局データベース・サーバーの性能がベンチマークの数字の決定要因となる（ゆえに，3-Tierの結果でもデータベース・サーバーだけが紹介されることも多い）。
2-Tierは要するにすべてのアプリケーションとデータベース処理を1台のサーバで稼働することによるベンチマークなので，トランザクション処理のスケーラビリティの測定としては最も厳しいテストの1つであると言って良いだろう。（もちろん，実際にSAPアプリケーションを実業務で稼働する際には，最も価格性能比が高い構成を選択すべきであり，2-Tierに固執する必要はない）。
また，測定を行うベンダーの立場から言うと2-Tierの方が実施が容易であることから測定実績の件数も多い。例えば，3-Tierの最高記録であるIBM p690のケースでは，なんと最上位Unixサーバーであるp690を14台のクラスタ構成で使用している。100億円規模の構成であり，ハードウエア提供元のベンダーであっても，そう簡単には実施できないであろう。
◆ランキング上位は？
2-Tierの上位3位までを見てみよう（表1）。当然のことながら2-Tierでは，大規模なSMPが有利となる。128 CPUをサポートする富士通のPRIMEPOWER，104 CPUをサポートする米Sun MicrosystemsのStarcat（Sunfire 15K）などが上位の常連なのはうなずける。DBMSとしてはOracleのケースが多く，やはり超大規模構成ではOracleが優位性を維持しているということができるだろう。
表1 SAP SD 2-Tier上位3システム
| サーバー | SAPS | 並行ユーザー数 | DBMS | OS |
| 富士通 PRIMEPOWER モデル2500 |
394万2000 | 1万3000 | Oracle 9i | Solaris 8 |
| Sun Microsystems SunFire 15K |
243万9000 | 8000 | Oracle 9i | Solaris 9 |
| Fujitsu Siemens PRIMEPOWER Model 2000 |
234万5000 | 7800 | Oracle 9i | Solaris 8 |
3-Tierでは，2002年の3月にUnisysがハイエンドIntelサーバーであるES7000によるWintel構成でトップの座を獲得し業界に衝撃を与えた。しかし，今では，前述のようにIBM p690によりUnixサーバーが首位の座を奪回し，ES7000に約2倍の差を付けている（表2）。
表2 SAP SD 3-Tier上位3システム
| サーバー | SAPS | 並行ユーザー数 | DBMS | OS |
| IBM eServer pSeries 690 |
1439万8000 | 4万7528 | DB2 V8.1 | AIX 5.1 |
| IBM eServer pSeries 690 |
1413万9000 | 4万7008 | DB2 V7.2 | AIX 5.1 |
| Unisys ES7000 | 781万8000 | 2万6000 | MS SQL Server 2000 | Windows Datacenter Server Limited Edition |
第1回でも述べたように，TPC-CにおいてはWintelとUnix/RISCの最高水準性能での差がほとんどなくなった一方で，より厳しいベンチマークであるSAP SDでは，まだ両者の差はあるということだ。
ここで，期待できるのが現在TPC-Cにおけるトップ・ランカーであるHPのsuperdome（Itanium 2（“Madison”）搭載）＋Windows＋SQL Serverの構成による結果である。当然ながら，今，HPはベンチマークの結果出しに総力を結集していると思うが，もし，Unix/RISCと同等以上の結果を出せたならばそれは真にエポック・メーキングなこととなるだろう。
◆健闘するLinux
もう1つの興味深い結果はLinuxサーバである。表3にIBMの中規模Intelサーバー（1.6GHz XEONの8ウエイ）におけるLinuxとWindowsの3-Tierでの結果比較を示した（ハードウェア構成，DBMS，SAP R/3のバージョンともに同じ）。Linuxの結果はWindows 2000による結果をわずかに上回っている。少なくとも8ウエイまでの中規模構成であれば，LinuxはOLTPアプリケーションにおいても他OSに劣らない性能を発揮できる可能性が高いと言ってよいであろう。
表3 同等構成によるLinuxとWindowsサーバーの比較
| サーバー | SAPS | 並行ユーザー数 | DBMS | OS |
| IBM eServer xSeries 440 （1.6GHz Xeon, 1MB L3キャッシュ） |
2900 | 575 | DB2 UDB 7.2 | SuSe Linux 8.0 （Linux Kernel 2.4.18） |
| IBM eServer xSeries 440 （1.6GHz Xeon, 1MB L3キャッシュ） |
2630 | 520 | DB2 UDB 7.2 | Windows 2000 |
SAP R/3にせよ一般のOLTPアプリケーションにせよ，性能を決定する最も重要な要素はDBMSの性能であり，OSそのものの性能が問題となることはほとんどない（OSのマルチタスク機能が相当に貧弱であれば話は別だが）。さらに，DBMSとアプリケーションに合わせてカーネルのチューニングを行いやすいLinuxは有利である。
過去においては，SAPベンチマークの結果の情報は各システム・ベンダーからのプレス発表を見るしかなかったので比較検討という点では不便であったが，今では，SAP Standard Application Benchmarksのサイトで一括して公表されるようになってきたので便利になっている。SAPのアプリケーションの導入を検討していなくても，たまにのぞいてみると各システム・ベンダーの一進一退のパフォーマンス競争が垣間見れて興味深いのではないだろうか？
