5. SOHO向けサーバに必要なCPUの性能とは

まずは前回の実験の結果から、コンパイル時間だけを抜き出して下のグラフにまとめます。

CPU別コンパイル時間比較

おさらいしますと、上のグラフはLinuxカーネルを5回連続でコンパイルするのに要した時間を表したものです。 さすがにPentium4は速いですね。 1回当たりわずか3分です。 思えば私がLinuxカーネルを最初にコンパイルしたのは10年前も前のことですが、カーネルの規模は今と比較にならない位小さいにもかかわらず、1時間以上を要した記憶があります。 CPUが386SX/16MHzでメモリは4MBというパソコンでした。 しばし回想に浸らせて下さい ・・・・。

さて、気を取り直して続けます。
プログラム開発用マシンとしては速ければ速いほど良いのはわかりますが、サーバ用としてはどうでしょう? さらに実際的な状況としてWebサーバとしての性能を考えてみましょう。
Webサーバの性能を左右する大きな要素はネットワークです。 Webサーバを公開する場合は、当然ですが、ADSLやFTTHなどでインターネットに接続します。 また会社内のイントラネットで公開する場合は10Base-Tや100Base-TのLANによる構内ネットワークに接続します。

インターネット接続で注意したいのは、サーバを公開する上で重要なのは下り速度ではなく、上り速度であるということです。 Webコンテンツはサーバからインターネット上のユーザの方向に送られるため、サーバ→インターネットの方向、すなわち上り方向のデータ転送量が圧倒的に多いからです。
ADSLは上りと下りの速度が非対称で、宣伝で強調される12M や24M という数字は下りのスピードであり、上りは通常1Mbpsしかありませんから、サーバ公開には向きません。 これに対してFTTHは上り・下り対称スピードで、最大100Mbpsであり、サーバ公開に適しています。
というわけで、性能を比較する実験は次の3種類の環境で行いました。

  1. FTTH経由 ・・・ インターネット接続を想定
  2. 100Base-T LAN経由 ・・・ 社内イントラネット接続を想定
  3. 同一サーバ内 ・・・ ネットワークを経由しない裸の性能 (参考用)

Webサーバの性能を測定する方法としてはApacheに付属するabコマンド(ApacheBench)のバージョン2.0.40-devを用いました。条件は次の通りです。

  • HTTP同時リクエスト数: 10個
  • 総リクエスト数: 1万個
  • コンテンツ: HTMLテキストファイル サイズ17kB

つまり10個のリクエスト (HTTP GET) を同時に発生させ続け、10,000個のリクエストが終了するまでの時間を計り、1秒当りのリクエスト処理数rps(Reqests per second)を見るものです。 通常、Webページは図などの複数のオブジェクトで構成されていますから、1クリックで10個程度のリクエストが発生することは普通です。ですから単純に言えば、100rpsの性能を持つサーバは、1秒間に10人程度の同時アクセスに対応できるというように考えることができます。 SOHOをやっていて10人もの人が同時にアクセスしてくれる状況はまさに夢のようですね。実際は50rps程度の性能が出ていれば十分です。
では結果を見てみましょう。

Webサーバ性能比較-ネットワーク・CPU別データ

同一サーバ内・・・つまり裸の性能をみると圧倒的にPentium4の勝ちですが、ネットワークを経由したとたんに差は無くなってしまいます。FTTH経由となるとCPUなんて無関係ですね。 理由は単純です。 ネットワークの帯域幅がボトルネックになっているわけです。

データ転送レートはリクエスト処理数にコンテンツのサイズ17KBを掛けることで算出できます。 例えば100Base-Tの場合はCPUによらず約600rpsですから、600['rps']×17['KB']=10200[KB/秒]で、100Base-Tの帯域幅である100Mbps(bit per second)をほぼ使い切っていることがわかります。 同様にFTTHの帯域幅は110['rps']×17['KB']=1870[KB/秒]となり、およそ20Mbpsであったことがわかります。ご自分の会社のLANが未だに10Base-Tだと10Mbpsですから、実験のFTTHの半分程度の性能しか出ないことになりますね。

なおFTTH経由で実験している最中のCPUアイドル率をモニタすると、いずれのCPUの場合も80%程度をキープしています。 つまり80%は遊んでいるわけです。これでは高性能のPentium4はかわいそうですね。フェラーリで路地裏を走行しているようなものです。

では次に単純なコンテンツではなく、データベースへのアクセスを伴うようなダイナミックなコンテンツのケースも調べてみます。 次のグラフはPHPからMySQLデータベースへのアクセスを伴うコンテンツ(ダイナミックコンテンツ)を使った場合と、上の実験の単純なコンテンツ(静的コンテンツ)の場合とを比較したものです。CPUはCeleronの2.2GHzです。

Webサーバ性能比較-コンテンツ別

ダイナミックコンテンツは、静的コンテンツに対して1000件の顧客テーブル相当への全件検索1回とその結果を表示するPHPプログラムを追加したものです。

結果を見ると、サーバ内と100Base-Tの場合はダイナミックコンテンツでの性能劣化が著しいことから、処理の複雑さによるシステム性能の限界が支配的であると言えます。
静的コンテンツでは、HTTPサーバプロセスが単にファイルの内容を送信しているのに対し、ダイナミックコンテンツではPHPプログラム実行とデータベース検索という比較的重い処理を伴うため、システム性能の限界が先に見えるのです。 しかしながらFTTHの結果を見ると、依然としてネットワークの帯域幅がボトルネックになっていることがわかります。 ダイナミックコンテンツでの実験中のCPUアイドル率は、サーバ内と100Base-Tの場合は0%,FTTH経由の場合は40%であったことからも、この推測は正しいことがわかります。
ちなみに部門内ファイルサーバなどの用途を考えた場合、上の静的コンテンツの性能が参考になります。つまりいくら高性能なサーバを導入しても、ネットワークの帯域幅が十分でないと意味がないというわけです。

さて今回の実験からわかったことを以下にまとめます。

  1. SOHO用Webサーバに必要な50rps程度の性能はCeleron2GHzクラスのCPUで事足りる。
  2. CPUの性能よりもネットワークの帯域幅に注意を払う必要がある。コンテンツにもよるが、50rps以上を確保するためには、FTTHでのインターネット接続が必須となる。
  3. 特に10Base-TのLANを用いている場合のWebサーバやファイルサーバの性能改善は、サーバ自体の高性能化よりも、LANを100Base-Tにするなど、ネットワークの帯域幅改善を行うべきである。

いかがでしたか? いくらスピード狂でも、路地裏を爆走するのはやめてくださいね :-)
次回はまたサーバの冷却の話に戻ります。 ご期待ください。

(石)