5

Apache の負荷を軽減するために、lighttpd を使用して静的コンテンツを提供することを提案する人がよくいます。

http://www.linux.com/feature/51673

このセットアップでは、Apache は静的コンテンツのリクエストを mod_proxy 経由で lighttpd に戻し、動的リクエスト自体を処理します。

私の質問は次のとおりです。これにより、サーバーの負荷がどのように軽減されますか? 受信するすべてのリクエストに対して apache プロセスが生成されている場合、これは負荷にどのようなプラスの影響を与えるでしょうか? lighttpd を介してリクエストをプロキシする Apache プロセスのサイズは、ファイル自体を提供している場合と同じくらい大きいことがわかります。

4

5 に答える 5

9

静的ファイルを提供するために 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 で有効にする必要があるため、それは本当に公平ではないでしょう。

于 2008-10-09T01:48:01.197 に答える
2
  1. 同じマシンから静的コンテンツと動的コンテンツを提供する能力がまだある場合(参照記事にあるように)、その設定には何の意味もありません。
  2. ディスクへの IO を実行する必要がないため、Apache の負荷が軽減される可能性がありますが、同じマシンで Lighttpd の負荷が増加し、 Apache への利用可能な負荷が減少します...
  3. Lighttpd の IO アクセスは Apache 1.3 より軽いかもしれませんが、Apache 2 または Lighttpd に完全に切り替えてみませんか? そして、パフォーマンスが本当に低下し始めた場合は、別のマシン (media.yourdomain.com) で静的ファイルをホストしてください。

パフォーマンスの高いセットアップを作成する方法の簡単な紹介は、ここにあります: Django のデプロイScaling->終了前にいくつかのページにスクロール

于 2008-10-08T09:40:31.803 に答える
0

Apache MPM Worker fastcgi を使用すると、サーバーのメモリ使用量が減少します。MPM ワーカーは Prefork よりも優れた静的コンテンツを提供し、静的コンテンツに関しては lighttpd とほぼ同等です。

于 2008-11-17T01:19:07.480 に答える
0

リクエストごとに Apache プロセスを生成する必要はありません。静的ファイル (画像など) は lighttpd によって直接取得されます。

于 2008-10-08T09:17:45.470 に答える
0

私は Apache の内部動作についてあまり知りませんが、私が見た 1 つの説明は、メモリ プレッシャに関するものです。つまり、Apache はキャッシュと動的ページに使用するメモリのバランスを取ろうとします。しかし、通常はキャッシュが多すぎて、アプリには少なすぎます。それらを異なるプロセスに分けると、それぞれが負荷の種類に合わせて最適化されます。

現在、私が行っているのは、nginxをフロント エンドとして使用することです。これは非常に高速で軽量で、特にフロントエンド プロキシとして設計されています。静的ファイルも提供します。実際、FastCGI プロセスを呼び出すこともできるため、Apache をなくしても、分割ファイル/アプリ プロセスのメリットを享受できます。(そして、絶対に天才に見える追加のmemcached マジックがいくつかあります)

(はい、lighttpd は Apache や FastCGI のフロントエンドとしても使用できます)

于 2008-10-08T10:08:58.783 に答える