http_loadを利用した試験結果

http_loadを利用した試験結果

　http_loadの試験では、abを使った検証にてファイルサイズが大きくなった場合は、ネットワーク帯域がボトルネックになって評価すべき結果が得られないということがわかったため、試験項目の1～3の3KBのファイルを使った試験のみを実施しました。ツールが異なる以外の検証条件は同じで、結果は図3のようになりました。

　http_loadを使用した検証では、1秒間で処理したリクエスト数（Requests per second）で、lighttpdとApache（prefork）を比較すると、図3の上に示す通り、同時接続数が10の場合で約1.36倍、同時接続数100の場合で約1.32倍、同時接続数1000の場合で約1.2倍、lighttpdの処理量が優れていました。

　abを利用した場合と比べ、全体的に1秒間で処理したリクエスト数に異なりが見られますが、「http_load」および「ab」のどちらのベンチマークツールを使用した場合でも、同時接続数にかかわらず、lighttpdの処理量がApacheと比べて大きいという結果になりました。

　なお、Apache（prefork）とApache（worker）では、どの同時接続数の場合でも、Apache（worker）を使用した方が、若干リクエスト処理量は優れていますが、こちらもabを利用した場合と同様に大きな違いは無いと言えます。

検証結果のまとめ

　では、abの検証データを使って、3KBのファイルで同時接続数1000のケースにおける、Apacheとlighttpdの接続時間（Connect）、処理時間（Processing）、待ち時間（Waiting）の内訳を見てみることにします。

　図3の下は、接続時間（Connect）、処理時間（Processing）、待ち時間（Waiting）の全リクエスト数（10000）の平均値（msec）を示したものですが、このグラフから接続に要した時間、処理した時間、待ち時間のどれを取っても、Apache比べてlighttpdが短いことがわかります。

　lighttpdはリクエストを受け付けてから処理開始までの時間が短く、このあたりが軽量Webサーバーと言われるゆえんではないでしょうか。

　また、Apacheのpreforkとworkerを比較しても、workerがpreforkに比べ、接続時間や処理時間が短いことが確認できました。マルチプロセスで処理するpreforkに比べ、マルチスレッドで処理するworkerの方が身軽という結果となっています。

　今回は、Apacheとlighttpdのパフォーマンス面について、簡単ではありますが、配信ファイルサイズや、同時接続数を変更させながら、2種類のベンチマークツールを利用して検証を実施しました。

　今回は配信ファイルサイズの小さな場合のみ有効な検証結果として評価しましたが、その結果からApacheよりlighttpdの方が、単一時間あたりのリクエストに対する処理量は最大で1.78倍上回っていることがわかりました。

　また、どの試験項目でも、リクエスト処理量でlighttpdがApacheを下回ることは無く、パフォーマンス面ではApacheと比較してlighttpdの方が優れているということができます。

　なお、今回実施した検証結果については、Webサーバーの設定内容や検証環境によって結果が変化することに注意してください。

　次回は、Apacheとlighttpdの安定性についての検証を実施します。