モードの違い
- mod_fastcgiを使ったfastcgi動作には、動的(dynamic)、静的(static)、外部(external)の三種類がある。
- dynamicは、始めてアクセスがあった段階でプロセスを起動し、以後は常駐する。
- staticは、httpdが起動した段階でプロセスを起動し、そのまま常駐。
- externalは、httpd側はプロセス起動を行わなずに、既に起動されているfastcgiプロセスと通信を行って、レスポンスをえる
- FastCgiServer - Static mode
- By default, the Process Manager will start one instance of the application with the default configuration specified (in parentheses) below. Should a static application instance die for any reason mod_fastcgi will spawn another to replace it and log the event (at the warn LogLevel).
- FastCgiConfig - Dynamic mode
- By default, the Process Manager will start one instance of the application with the default configuration specified (in parentheses) below. Should a static application instance die for any reason mod_fastcgi will spawn another to replace it and log the event
- FastCgiExternal 外部
それぞれの設定は排他的。それらのプロセスは親がApacheになるためCoWでのメモリ共有はされない。(Externalは違うか）。従って、forkさせてCoWでメモリ共有するためには、自前でプロセスを管理して、そこでプロセスをforkさせる必要がある。それらを実装するためのライブラリとして、FCGI::ProcManagerが存在する。
Catalyst::Engine::FCGIもこの実装を用いている。
プロセス管理
- Apache, lightyが面倒をみてくれるわけではない。プロセス管理は自前でやる必要あり(.fcgiで）
- それをやるための実装として、FCGI::ProcManagerが存在する。
- MaxRequestsPerChild的なものはFCGI::ProcManagerを使って自前で実装する
所感
大規模運用では結局のところmod_perl2という選択肢のほうがいいんじゃないかということ。理由は、以下の2点。
- 自前でプロセス管理をする必要がない点
- Apacheが面倒をみてくれる点で楽なのと、FCGI::ProcManagerのようにPure Perlライブラリで実現する必要がないので高速という2点でメリットがある
- MaxRequestPerChildのようなメモリー対策を自前で実装する必要がない点
一方、プロセスを独立で管理させたいときにはFastCGIでのメリットがあり、プロセス管理を簡単に実現できかつ高速な実装を用意できれば、FastCGIも使える可能性があるかもしれない。
疑問点
- 毎回新規プロセス作って運用して、killIntervalでプロセス殺すみたいな運用。親はApacheになるので、CoWによるメモリ共有はできないが、それでも安定性からApacheに頼るというFastCGIの使い方はあるかもしれない。
- ただ、大きなところでは自前でprocess managerを書いているのかも？(SODの中の人に聞いてみたい）
See also
