静的ファイルを提供するために Apacheの背後でLighttpd を実行することは、確かに頭がおかしいように思えます。Apache は引き続き HTTP パケットをアンパックし、その解析ツリーを介してリクエストを解析し、プロキシ リクエストを送信する必要があります。その後、Lighttpd は再度アンパックし、ファイル システムにアクセスして、Apache 経由でファイルを送り返す必要があります。このようなセットアップを本番環境で使用している人は聞いたことがありません。
あなたが目にするのは、 Nginxのような軽量のWebサーバーをフロントエンドサーバーとして使用して、静的ファイルを提供し、動的URLをApacheにプロキシする人々です。または、 VarnishまたはSquidをキャッシング リバース プロキシ フロントエンドとして実行して、トラフィックの多い静的ファイル (つまり、画像、CSS など、およびキャッシュに適したヘッダーを送信する任意の動的ページ) をすべて提供することができます。メモリの。
Apache は、静的ファイルを提供するように最適化することもできます。そのため、人々が Apache について不平を言っているのを耳にするとき、彼らは本当に設定方法を知らないことがよくあります。彼らは prefork MPM (対スレッドまたはワーカー) のみを使用し、あらゆる種類のモジュールを有効にしています (通常、すべてをモジュールとしてビルドし、デフォルトで 10-20 を有効にする Linux ディストリビューションのキッチンシンク Apache パッケージから実行しています)。モジュール以上)。最初に .htaccess のサポートなどの不要なモジュール/愚かな機能をオフにして Apache を調整します (これにより、Apache は要求ごとにファイルシステムをスキャンします!)。(また、Apache の 2 つのインスタンスを実行することもできます。動的要求のために「重い」Apache にプロキシする「軽い」Apache をフロントエンドとして使用します ...
Re:
受信するすべてのリクエストに対して apache プロセスが生成されている場合、これは負荷にどのようなプラスの影響を与えるでしょうか? lighttpd を介してリクエストをプロキシする Apache プロセスのサイズは、ファイル自体を提供している場合と同じくらい大きいことがわかります。
すべてのリクエストでプロセスを生成している場合、それは prefork MPM を使用していることを意味します。OS がこれらの各プロセスのメモリ使用量を報告する場合、すべてのメモリが接続されているわけではなく、それらのプロセスの多くがアイドル状態であることに注意してください。また、速度について話しているときは、OS によって報告されるメモリ使用量よりも、特定の要求に対する要求の解析と内部コード ブランチ (サーバーがどの程度の処理を行っているか) に関心があります。
たとえば、mod_php のようなものを有効にすると、これらの各ワーカー プロセスは即座に約 20 ~ 40M 増加します (PHP インタープリターで何が有効になっているかによって異なります)。静的リクエスト。もちろん、サーバーを最適化して小さな静的ファイルで最大の同時実行性を実現している場合、mod_php を有効にすることは依然として非常に悪いことであり、多くの prefork プロセスを RAM に収めることはできません。
バックエンド Lighttpd にそれらのリクエストをプロキシするよりも、実際には静的ファイルの提供を遅くする Apache の「悪夢のような構成」を思い付くことができるかもしれませんが、Lighttpd では無効になっている .htaccess のような高価な機能を Apache で有効にする必要があるため、それは本当に公平ではないでしょう。