fastcgiに関するいくつかの抜粋
元の討論スレッド:http://www.iteye.com/topic/267429
dangoのfastcgiパターンには以下のような重要なパラメータがあります。
djangoでは、lighttpdはfcgiプロセスの発生または消滅を制御することができません。これらの仕事は全部flupです。python manager.py funfcgiという命令で父プロセスを生成します。そして、要求によって父プロセスから動的なspawn子プロセスを作ります。最大のアイドルプロセス数は50で、最小のアイドルプロセス数も50である。これで親プロセスは絶えず破壊し、子プロセスを作成することができなくなる。このように実は同じく動的なspawnを免れましたと言えます。
プロセスには軽い量と軽い量の違いはありません。あなたがforkする時はお金がかかります。親子プロセス共有データというのはただのcopy-on-writeにすぎません。これは物理メモリを節約できるだけで、他の利点は大きくありません。mod_私はこのようなやり方をしていますが、このような欠点は前に述べました。私の観察によると、FastCGIプロセスのメモリオーバヘッドの一番の部分はまだメモリスタックで、ややもすれば100-200 MBで、さらに多く、あなたのcopy-on-write節約の共有コードセグメントメモリは非常に限られています。10-20 MBのようです。
ライト級プロセスは親子が常にカーネル中のデータ構造を共有することができます。これらのデータ構造が占める空間は限られています。10-20 mはないはずです。だから一つはcowプロセスです。親子プロセスは同じ物理ページを読みます。これらのfastcgiプロセスの物理ページは10 mぐらいです。
1、ダイナミックspawnプロセスの欠陥は、ウォーカープロセスが死ぬまで耐えられないことではなく、ハッカーが大量の要求を瞬間的に開始してクリーンなCPUリソースを消費し、サーバに応答を失わせ、重大なものはリモートsshに上がることができないことである。ある程度のspareプロセスがあるかもしれませんが、これはハッカーの大量要求の前では効果がありません。静的なspawnの利点は、このような状況に遭遇すると、最も多くのサイトの動的要求に応答できなくなります。他のすべての場合、lighttpdの同時接続状況を確認する十分な時間があります。実はlistpeedもlsapiを通してRubyプロセスのダイナミックspawnをサポートすることができますが、私がテストした結果、上記の問題があります。もちろんApacheのmod_ライズにも上記の問題があります。特にラーズアプリケーションのように、初期化のプロセスが非常に長いです。初期化のためにロードされたデータが多く、起動時にCPU消費が非常に大きいです。2、ダイナミックspawnは要求数を超えたら自動的に廃棄してしまうので、意味がないと思います。このような自動再起動メカニズムはメモリ漏れによる苦痛をある程度軽減できますが、もし私のプロセスにメモリ漏れがなかったら、ちゃんと走ってください。なぜ定期的にリセットしなければならないですか？だから、このような計数のメカニズムによって定期的に再起動してもいいです。資源の監視状況によって釈放を決めます。もしあなたのプロセスのメモリがある程度漏れたら、私はあなたをやり直します。もし漏れないなら、私は自然にあなたを重ならないです。このような仕組みはもっと合理的です。
dangoのfastcgiパターンには以下のような重要なパラメータがあります。
# protocol=PROTOCOL fcgi, scgi, ajp, ... (default fcgi)
# host=HOSTNAME hostname to listen on..
# port=PORTNUM port to listen on.
# socket=FILE UNIX socket to listen on.
# method=IMPL prefork or threaded (default prefork)
# maxrequests=NUMBER number of requests a child handles before it is
# killed and a new child is forked (0 = no limit).
# maxspare=NUMBER max number of spare processes / threads
# minspare=NUMBER min number of spare processes / threads.
# maxchildren=NUMBER hard limit number of processes / threads
# daemonize=BOOL whether to detach from terminal.
# pidfile=FILE write the spawned process-id to this file.
# workdir=DIRECTORY change to this directory when daemonizing.
# outlog=FILE write stdout to this file.
# errlog=FILE write stderr to this file.
# umask=UMASK umask to use when daemonizing (default 022). protocol=PROTOCOL fcgi, scgi, ajp, ... (default fcgi)
host=HOSTNAME hostname to listen on..
port=PORTNUM port to listen on.
socket=FILE UNIX socket to listen on.
method=IMPL prefork or threaded (default prefork)
maxrequests=NUMBER number of requests a child handles before it is
killed and a new child is forked (0 = no limit).
maxspare=NUMBER max number of spare processes / threads
minspare=NUMBER min number of spare processes / threads.
maxchildren=NUMBER hard limit number of processes / threads
daemonize=BOOL whether to detach from terminal.
pidfile=FILE write the spawned process-id to this file.
workdir=DIRECTORY change to this directory when daemonizing.
outlog=FILE write stdout to this file.
errlog=FILE write stderr to this file.
umask=UMASK umask to use when daemonizing (default 022).djangoでは、lighttpdはfcgiプロセスの発生または消滅を制御することができません。これらの仕事は全部flupです。python manager.py funfcgiという命令で父プロセスを生成します。そして、要求によって父プロセスから動的なspawn子プロセスを作ります。最大のアイドルプロセス数は50で、最小のアイドルプロセス数も50である。これで親プロセスは絶えず破壊し、子プロセスを作成することができなくなる。このように実は同じく動的なspawnを免れましたと言えます。
プロセスには軽い量と軽い量の違いはありません。あなたがforkする時はお金がかかります。親子プロセス共有データというのはただのcopy-on-writeにすぎません。これは物理メモリを節約できるだけで、他の利点は大きくありません。mod_私はこのようなやり方をしていますが、このような欠点は前に述べました。私の観察によると、FastCGIプロセスのメモリオーバヘッドの一番の部分はまだメモリスタックで、ややもすれば100-200 MBで、さらに多く、あなたのcopy-on-write節約の共有コードセグメントメモリは非常に限られています。10-20 MBのようです。
ライト級プロセスは親子が常にカーネル中のデータ構造を共有することができます。これらのデータ構造が占める空間は限られています。10-20 mはないはずです。だから一つはcowプロセスです。親子プロセスは同じ物理ページを読みます。これらのfastcgiプロセスの物理ページは10 mぐらいです。
1、ダイナミックspawnプロセスの欠陥は、ウォーカープロセスが死ぬまで耐えられないことではなく、ハッカーが大量の要求を瞬間的に開始してクリーンなCPUリソースを消費し、サーバに応答を失わせ、重大なものはリモートsshに上がることができないことである。ある程度のspareプロセスがあるかもしれませんが、これはハッカーの大量要求の前では効果がありません。静的なspawnの利点は、このような状況に遭遇すると、最も多くのサイトの動的要求に応答できなくなります。他のすべての場合、lighttpdの同時接続状況を確認する十分な時間があります。実はlistpeedもlsapiを通してRubyプロセスのダイナミックspawnをサポートすることができますが、私がテストした結果、上記の問題があります。もちろんApacheのmod_ライズにも上記の問題があります。特にラーズアプリケーションのように、初期化のプロセスが非常に長いです。初期化のためにロードされたデータが多く、起動時にCPU消費が非常に大きいです。2、ダイナミックspawnは要求数を超えたら自動的に廃棄してしまうので、意味がないと思います。このような自動再起動メカニズムはメモリ漏れによる苦痛をある程度軽減できますが、もし私のプロセスにメモリ漏れがなかったら、ちゃんと走ってください。なぜ定期的にリセットしなければならないですか？だから、このような計数のメカニズムによって定期的に再起動してもいいです。資源の監視状況によって釈放を決めます。もしあなたのプロセスのメモリがある程度漏れたら、私はあなたをやり直します。もし漏れないなら、私は自然にあなたを重ならないです。このような仕組みはもっと合理的です。