ほとんどの回答は、このような静的ファイルを提供するためにメモリフットプリントが高くなるため、mod_php の効率が悪いと考えています。
しかし、私は次のように異なる意見を持っています。
実際のところ、コード セクションはfork()ed プロセス間で共有されるため、メモリ フットプリントの述語は保持されません。
私が考えることができる唯一の理由はmod_php、Webサーバーが各リクエストに対してサブプロセスしか作成できないように、非スレッドセーフであることです。
fastcgi モードでは、Web サーバーはトリックを多重化することでパフォーマンスを向上させ、fork()オーバーヘッドを削減できます。
一言で言えば、mod_php の欠点はメモリ フット プリントではなく、オーバーヘッドですが、 thread_safe であるfork()場合は不要であり、これがリクエストを処理する最も効率的なソリューションになります。mod_phpfork()
上記は私の意見ですが、100％確実ではありません。
そうですか？
フォークは非常に高速で、デフォルトの apache + mod_php インストールもフォークします。(worker mpm を使用しない場合)。
本当の理由は（一種の）次のとおりです。
標準の mod_php には、プロセスに php と他のすべての apache モジュールなどが含まれているため、かなり大きなプロセスがあります。phpが別のプロセスにある場合、php プロセスの有効期間は短くなり、次の場合にすぐに結果を apache に返すことができます。 PHPができました。
もう 1 つの理由 (前述のとおり) は、PHP 以外のリクエストに対して PHP が変更されていないことです。
FastCGI を使用しているときに worker mpm に切り替えることができるという事実は、おまけです。しかし、効率が上がります。
一般に、これらのタイプの設計では、apache プロセスと php プロセスの両方を可能な限り短時間で実行するように常に試みたいと考えており、それらを分割すると役立ちます。
しかし、そうです..フォークは非常に高速であり、特定の設計では、Linuxのスレッドよりも実際にうまく動作します（ソースはありません。これを読んだことを覚えています）。Web サーバー タイプのシステムの場合、Reactor パターン ベースのシステムの方がうまく機能すると思います。NGinx と Varnish は、この代表的な例です。