Railsサーバ性能比較とlighttpd - 元RX-7乗りの適当な日々

Rails Key

くまくまーさんトコで、Rails※サーバのベンチマーク結果が公開されています。
※Ruby on Rails。一応ね。

http://wota.jp/ac/?date=20070820#p01

結果としては、静的ファイルについても、Railsアプリに関してもlighttpdが最も良いパフォーマンスを出しています。
# 圧勝に近いですよね。

以下に、くまくまーさんの結論を引用。

・Swiftiply は機能も性能も魅力的だが不安定 (abの実行が時々終了しない)
・結局 Lighttpd だけでいい (バックの場合「ワーカ数≒コア数」ぐらい？)

この結果を見ているとやっぱり Mongrel より Lighttpd を選びたくなってしまう。
実運用レベルでは、DBとERbの負荷によってアプリケーション側の実行時間が増大し、当然ながらこれらのサーバ性能の差は縮まることにはなるが、フロントを用意せずに生 Mongrel で静的ファイルを捌いている環境であれば、結構な負荷になるだろう(※1)。
まさに現在のうちの環境(Pound + Mongrel Cluster)がそれだ！ということで、今まで散々 Mongrel を薦めてきたが、やっぱり Lighttpd がいいかも。みたいなねぇ。

(※ 1req当たりにJS,CSS,IMGと多くの静的ファイルへのアクセスがあるため)

lighttpdが凄いのは、自分で過去に性能比較した結果や、1年近く運用してきているのもあって、よく知っているつもりだけど、Mongrelのパフォーマンスがあまりというか全然出ていないのが若干気になります。

処理内容によっては、多少偏りがあるんじゃないだろうか。

Mongrelを使うにしても、生じゃなくてSwiftiply(Ruby製のHTTP Proxy Framework)などとの組合せが良いみたいね。

ちなみにくまくまーさんが過去にもRails運用サーバの速度比較をしているので、こちらも参考になります。

http://wota.jp/ac/?date=20060608

さて、社内で運用しているSNSでも、フロントのリバースプロキシ/ロードバランサにはApache2.2、バックエンドでlighttpdを使ってRailsアプリを運用していますが、この結果を踏まえて、lighttpdのmod_proxyを使って、リバースプロキシもlighttpdにしてしまうのもアリなのかなと思い始めました。
# アプリ共通の静的ファイルはリバースプロキシ自身で返すようにしているので。

ただ、今の最新バージョンのlighttpd + mod_proxyは、ロードバランシングしてくれる機能は持ち合わせていますが、バックエンドのフェイルオーバをハンドリングすることが出来ません。
(※このあたり、Apache2.2で半年弱運用しましたが、なかなか秀逸です。)

が、lighttpdの次期バージョンである1.5系(まだpre版ですが)では、mod_proxy_coreでフェイルオーバーをハンドリングできる機能が実装されているみたいなので、ちょっと期待をこめつつ。

まぁ、一番のネックは、lighttpdでのリバースプロキシは、ほとんど実績が見当たらないというところでしょうか。

# これからメジャーになっていくと思うけどなぁ。