携帯コンテンツ変換の選定基準：スループット
パフォーマンス（1アクセスの平均レスポンスタイム）と並んでユーザにとって重要な指標がスループット（1秒間あたりの処理数）です。「同時接続数はどれくらいですか？」などとよく聞かれます。スループットはサーバ台数に直接に影響を与える数字です。当然、サーバ台数が少なくて済むように、より高い性能であることが望ましいです。
１/スループット＝パフォーマンス
なのですが、両者には別の相関関係があって、アクセスがスカスカの状態ではパフォーマンスは非常に良く、アクセスが増えてくれば徐々にパフォーマンスは劣化し、アクセスが増えすぎると両方落ち込みます。コンテンツ変換製品でもスカスカの状態では、パフォーマンスの違いは、あまり出ないかもしれません。問題はアクセスが増えてきてからで、どこまでスループットを上げることができるかが重要です。スループットが最大のときのパフォーマンス比較ができれば、信頼できる製品性能比較になるでしょう。全エントリーのパフォーマンスUPの方法はスループット向上にも役立つので今回は設計の話ではなく、実際の２つの計測データを提示してスループットについて説明していきます。
ラウンドアバウトのパフォーマンスデータ
グラフはラウンドアバウトの性能試験時のグラフです。記述にあるように３つの条件で計測しています（縦軸の単位はmsec）。負荷を高めていくとレスポンスに影響を与えていくのが分かります。PHP自体はコードが入っていないせいか、このテストでは変化が出ていません。この時のスループットが次のグラフです。
ラウンドアバウトのスループット
アパッチのみの場合に6,000くらいのスループットが、ラウンドアバウトでは2,200くらいとなっています。コンテンツによって違いますが、この時は1ページに10画像とCSS、Flashが１つ載っているシンプルなコンテンツです。サーバスペックは、Pentium Dual CPU 1.8GHz・メモリ2Gb・CentOs5.2という環境でした。このグラフを見て頂ければ、ラウンドアバウトの性能レベルについて推察してもらえるのではないかと思います。
■プロキシーの特性
もう１つのデータはプロキシー方式は遅くないのか？という疑問対するテストデータです。環境は前述と同様です。このテストでは、Lan上に配置したApacheにダイレクトにアクセスした場合と1台のApacheProxyを経由した場合のデータを比較しています。２つのどちらのシステムにもラウンドアバウトなどの変換システムは入っていません。
WebサーバとProxyサーバ経由でのレスポンス比較
プロキシーではリソースを多く使うせいか、ダイレクトアクセスに比較して圧倒的にレスポンスの劣化が起きやすい事が推察できます。この時のダイレクトアクセスのWebサーバとプロキシアクセスのプロキシサーバのロードアベレージを示したものが次のグラフです。
WebサーバとProxyサーバのロードアベレージ比較
やはりシステム自体が相当の負荷になっていることが分かります。
スループットも様々な要因が絡んでくるので、常にどのシステムが一番速いと断言することは難しいですが、ラウンドアバウトのWebサーバ組込みというシステム構造であれば、一般的傾向としてプロキシー型よりも非常に高い性能を発揮できると言えるでしょう。