FastCGI (fcgi-2.4.0) のソースを調べたところ、実際にはフォークの兆候はありません。私が正しければ、WebサーバーはFastCGIモジュールのプロセスを生成し(コンパイルまたはSO / DLLとしてロード)、メインソケット(通常はポートTCP:80)の制御を処理します。
*nix では、FastCGI モジュールはファイル記述子全体 (確かにリッスン ソケット) でファイル書き込みロック (libfcgi/os_unix.c:989) を使用してそのソケットを「ロック」します。この方法では、新しい接続が発生したときに、FastCGI モジュールのみがこれらを処理できます。HTTP req 処理に引き渡す直前に、着信ソケット ロックが解放されます。
FastCGI モジュールがマルチ プロセス/スレッドではない (fork/pthread_create の内部使用がない) ように、複数の同時接続の同時処理は、n 個の FastCGI モジュール プロセスの Web サーバーからの spwaning (OS_SpawnChild 経由) によって取得されると想定しています。例として、3 つの FastCGI プロセス (Apache が 3 x OS_SpawnChild を呼び出す) を生成した場合、最大 3 つのリクエストしか同時に処理できないということですか?
A) FastCGI の動作方法に対する私のビジョンは正しいですか?
B) OS が新しいプロセスを生成したり、ローカル DB への接続を作成したりするためのコストが無視できると考えられる場合、旧式の実行可能アプローチに対する FastCGI の利点は何ですか?
ありがとう、エマ!:-)