さて。もう一つ別のWebサーバでのFastCGI設定を晒しておきましょう。nginxというWebサーバです。かなりマイナーですが，以下のような特長があります。

• 高速：条件にもよるがlighttpdよりも速い
• FastCGI対応：ただし，FastCGIプロセス管理をきっぱり切り捨て，external-server専用と割り切っています
• FastCGIに渡すパラメータを自分で設定：分かりやすいですし，変なこともできそうです
• なんか最近開発が盛んっぽい：２月だけで10回バージョンアップしてます
• 日本ではほとんど知られていない：Gentooのportageにあったから知りました
• そもそも英語の情報すらもない：オフィシャルはロシア語。露英翻訳をかければ何となく分かります
• 実はlighttpdよりメジャー？：Netcraft Web Server Surveyではlighttpdよりも上にいる！（.comでの比較だと逆転するあたり，「国産だから」とロシア人が使っているのでしょうか。

色々試した結果，ようやく良い感じのlighttpdのFastCGI設定が書けたので公開しておきます。環境はCatalyst-5.64 + lighttpd-1.4.10で，他のバージョンではテストしていません。

• 複数アプリ対応
• local-server, external-server両方の例
• $c->baseや$c->uri_forも正しく動く
• app/root/static以下のファイルはlighttpdが処理する

CLON - 2006/02/23 - backend fastcgi プロセスが落ちている場合の挙動 lighttpd-1.4.10ではsocket, host:portともに500 Internal Server Errorで返ってきています。lighttpd-1.4.9のNEWSで「fixed endless loops in mod_fastcgi if backend is dead」とあるので1.4.9での変更ではないでしょうか。

CLON - 2006/02/20 - lighttpd+fastcgi時のメモリ共有 このパターンで実行すると親プロセスがlighttpdになっている以上，forkする元がlighttpdなので，共有されるはずがありません。WebプログラマのためのCopy On Write解説：mod_perl/FastCGIでメモリを節約する方法 | Typemiss.netに書いたとおりです。もうちょっとしっかり実験しておきましょう。

CoWでテンプレートキャッシュを共有！（C::V::H::T編） | Typemiss.netではHTML::Templateのテンプレートキャッシュを共有させてメモリを節約する話を書きましたが，同じことをCatalyst::View::TTでやろうとするとどうなるか，です。 TT2はH::Tに比べて内部が複雑で，普通に読み込ませておくだけではうまく共有することができませんでした。色々小細工をしてみたものの，copy on writeの発生を防ぐことができず，どうやっても子プロセスごとにメモリを用意する必要があるようです。

Perl：forkしたプロセス間でのメモリ領域の共有　（Link: 遅レス。 - Apache + mod_perl - MaxClients の値に注意） | Typemiss.netの後，LinuxのCopy On Writeについて調べてみました。 このエントリではLinuxのCopy On Writeの挙動を簡単に説明し，mod_perlやFastCGI環境の場合に，どういうことがおこっているのか，どうすればそのような環境でメモリを節約できるのかについて説明してみます。・・・あまり分かりやすくなっていないかもしれませんが。

ざっと試してみた。 ab2 -k -c 10 -n 10000 http://localhost/fcgi/tiny-cgi2.fcgiとして比較。 結果としてはデフォルトオプションならmod_fcgidが50%ほど速いということで。 それ以上にlighttpdとかは速いんだけど。 Webサーバ側でFastCGIのプロセス管理やるより外部でspawn-fcgiなどを使って管理した方が速いようだ。

The mod_fcgid Home Page, mod_fcgid is an Apache2 module for FastCGI protcol ふむ。mod_fastcgiとどう違うのやら・・・ あれ？　「マルチスレッドなApacheとPHPを一緒に動かすのは推奨されない。だから，これ使うと良いよん。」ってそうだったのか？

そうだ。FastCGIのCで書いた最小版のab2も載せておこう。 同じ条件で2.652218秒しかかかっていない。FCGI.pmでのオーバーヘッドも結構あるのかな。 FCGI.pmのシンプルな奴も試してみよう。・・・うん。FCGI.pm自体は大して悪くない。

Catalystのオーバーヘッド～Catalyst::Engine::FastCGIの続き。 handlerの準備段階であるprepare_*の詳細を見てみよう。