3. ベンチマークテスト結果の検討

まず単純な処理についての結果を示す前ページのNo1,No.3,No.4のグラフを見てください。

いずれもカーネル2.4が最高の性能で2.6SMPが最低の性能であることがわかります。これでは最新の安定版カーネル2.6を使う意味がありませんね。しかしそう結論付けることは尚早です。最初に触れた通りカーネル2.6の真髄はマルチプロセス,マルチCPUで発揮されるはずです。
ではその観点から前ページのグラフを描きなおしてみます。

まず各状況下でのApacheコンパイル時間の比較です。

グラフ-Apacheコンパイル時間の変化

いかがでしょう? Apache Benchという大きな負荷がかかった状況でのコンパイルでは、カーネル2.6SMPの性能が群を抜いていることがわかります。逆にカーネル2.4(SMP)の結果は最悪です。これらの差は実に3倍〜4倍にもなります。これはカーネル2.6SMPの良さも然ることながら、Hyper Threadingの効果が大きく発揮されていることを示すものです。

同様に各状況下でのMySQLのコンパイル時間の比較です。

グラフ-MySQLコンパイル時間の変化

これも同様の傾向を示しています。複数のプロセスを同時に処理するサーバではカーネル2.6SMPが大きな威力を発揮することを如実にものがたっています。逆に2.4と2.4SMPでは、高負荷状態においてはSMPの方が性能劣化が著しいことがわかります。これは少し悲しいことですね。

次は各状況下でのSQL Benchの比較です。

グラフ-SQL Bench値の変化

性能劣化は一様に起こっているように見えますが、直線の傾きを見るとやはり2.6SMPの劣化が最も少ないことがわかります。

次に示すグラフはApache Benchに注目したものです。コンパイルやSQL Benchによってどの程度の性能劣化が起こるかを示したものです。

グラフ-Apache Bench値の変化

このグラフは興味深いものです。2.6SMPではコンパイル,SQL Bench共に同レベルの性能劣化を示し、他のカーネルでは負荷に応じてほぼリニアに性能劣化が起こっています。詳細説明は省きますが、これはカーネル2.6で新たに導入されたプロセススケジューラの動作を裏付ける結果だと考えられます。カーネル2.6ではマルチCPU環境において、複数のプロセスに均等に効率よくCPUリソースを割り当てるスケジューラが導入されています。このためコンパイルやSQL Benchと平行して走るApache Benchに対して一定のリソースが割り当てられているのだと推測できます。

なおApache Benchが示す数値について簡単にコメントしておきます。
今回のテストでは同一ホスト内httpdに対してApache Benchを実施しているため、ネットワーク速度のボトルネックが存在しません。コンテンツのサイズが96,450バイトですから、例えば1,000RPSでは、96,450,000バイト/秒すなわち約92MB/秒のデータ転送が行われていることになります。このような転送速度はギガビットLANでさえも得られるものではありません。100Base-TXではこの10分の1が限界性能となります。つまりネットワーク速度がボトルネックになるということです。

また仮にユーザの1クリックで20個のHTTP GETリクエストが発生するとすれば、1000RPSでは50ページ/秒,18万ページ/時間,432万ページ/日の超大規模サイトに相当します(超単純計算ですが)。1台のサーバでまかなう規模ではありません。

つまりこのような状況が現実に起こることはまずあり得ないということです。今回のベンチマークでいかに大きな負荷をかけているのかをご理解ください。