unknownplace.org

Link: CLON - 2006/02/23 - backend fastcgi プロセスが落ちている場合の挙動 | Typemiss.net

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での変更ではないでしょうか。

1.4.8 でした、テスト環境。あざっす。

fastcgi プロセスをスタンドアローンで動かしていて、Webサーバーからそれを使うという場合、apache であれば fastcgi プロセスが落ちていたら 502 Bad Gateway が出るらしいのだけど、lighty だとでないみたい。

lighty から fastcgi へつなぐ方法 2 種類試した。

1. socket ファイルで fastcgi へ
2. host:port で

1 の場合、対象 socket ファイルが有効になるまで待ち続ける(!)

fastcgi プロセス再起なんかなどでは起動したらそのまま実行されるため便利かもしれないけど、downtime が長いとクライアントを溜め込んでしまうことになりそう。

2 の場合、指定ポートへの接続が reject されると lighty もクライアントの接続を切る。えー。ここで 502 とか返せばいいのに。

どっちにしろあんまり行儀が良くなくて使いにくいという感じ。1 よりは 2 のほうがいいかな。

このサーバーで動いてるアプリはほとんど lighty+fastcgi で動いているけど、アクセス数的に余裕まくりなのですべて1プロセスで動かしていていままで意識していなかったのだけど、仕事で使うことになったので調べてみた。

まず、Catalyst 製アプリケーション MyApp をlighttpd.conf で以下のように設定。

fastcgi.server = (
    "" => (
        "myapp" => (
            "socket" => "/tmp/myapp.socket",
            "check-local" => "disable",
            "bin-path" => "/path/to/script/myapp_fastcgi.pl",
            "max-procs" => 5,
        ),
    ),
)

これは割りと一般的な方法。これでMyAppプロセスが5つ立ち上がる。うちもこんなようなのの max-procs を 1 にしたのを使っている。

でも lighttpd.conf で bin-path を指定すると lighty がプロセスを5つ立ち上げてる感じになり、メモリは共有されてないっぽい。pstree はこんな感じ。

|-lighttpd---5*[myapp_fastcgi.pl]

なんかテストしてるPCだとCatalystアプリを立ち上げるときにFile::Slurpのwarningがでまくりなんだけど、上記設定でlighttpd立ち上げるとプロセス数分warningが出ることからもuseまくってんだなぁということがわかる（適当だなオイ

これじゃー微妙なので、もう一つの方法を試す。

Catalyst の fastcgi.pl は FCGI::ProcManager での動作もサポートしていて、

./script/myapp_fastcgi.pl -l /tmp/myapp.socket -n 5

とすれば MyApp が FCGI::ProcManager 経由で fastcgi プロセスが 5 つ立ち上がる。これだと

|-myapp_fastcgi.pl---5*[myapp_fastcgi.pl]

こんな感じで賢い風味。File::Slurp の warning も1回しか出ない！（そこで判断かよ

これを lighty から使うにはさっきの設定から bin-path をはずせば OK。

fastcgi.server = (
    "" => (
        "myapp" => (
            "socket" => "/tmp/myapp.socket",
            "check-local" => "disable",
        ),
    ),
)

こんなんで。

で、結論としては複数プロセス立ち上げるときは FCGI::ProcManager 使わないと損ということですかね。

時間があるときに追試はしてみたい。

lighttpd のロードバランス機能って誰も試してないのかなぁ。

一応 fair, hash, round-robin と3種類あって、

• fair
  • 負荷によって振り分ける(デフォルト)
• hash
  • URLのhashで振り分ける(同じURLは必ず同じホストにわけられる)
  • Cache Array Routing Protocol ていうアルゴリズムを使ってるらしい。
• round-robin
  • リクエストごとに違うホストへ振り分ける

設定も非常に簡単。

$HTTP["host"] == "www.example.org" {
  proxy.balance = "fair"
  proxy.server  = ( ".pl" => ( ( "host" => "192.168.0.2", "port" => 8080 ),
                            ( "host" => "192.168.0.3" ),
                            ( "host" => "192.168.0.4" ),
                            ( "host" => "192.168.0.5", "port" => 81 ) ) )
}

みたいな。バックエンドホストでも普通に VirtualHost が使えるのも○

svn.unknownplace.org、dev.unknownplace.org でも

$HTTP["host"] =~ "^(dev|svn)\.|unknownplace\.org)$" {
    proxy.server = ( "/" =>
                      ((
                       "host" => "127.0.0.1",
                       "port" => 8080,
                      ))
    )
}

とかしてバックエンドの apache2 にそのままとばしてるけど、後ろでも VirtualHost 普通に使えてうまー。

まぁ、lighttpd の mod_proxy だと svn メソッドとばないので commit できねーのだけど（だめ

debian ディレクトリなくなったー。しょぼーん。

debian ディレクトリ更新されてないよ！！

はすごい。Host: ヘッダもちゃんとバックエンドに飛んでくからバックエンド側でもVirtualHost使用可能。

apacheでもできるらしいけどやりかたわからねー。