web-dev-qa-db-ja.com

負荷分散にnginxを使用すると、1秒あたりのリクエスト数が遅くなります

2つのApacheサーバーへのリクエストをリバースプロキシするロードバランサーとしてnginxを設定しました。私はabでセットアップのベンチマークを行い、2つのバックエンドサーバー間で分散されたリクエストで1秒あたり約35のリクエストを取得しています（ip_hashを使用していません）。私を混乱させているのは、abを介してバックエンドサーバーのいずれかに直接クエリを実行すると、1秒あたり約50のリクエストが発生することです。

私はabでいくつかの異なる値を試しましたが、最も一般的なのは100の同時接続で1000のリクエストです。

2つのサーバーにトラフィックが分散されると、どちらかを直接ヒットするよりも1秒あたりのリクエスト数が少なくなる理由はありますか？

追加情報：

私はworker_processesの値を1から8の間で実験し、worker_connectionsを1024から8092の間で実験し、キープアライブ0から65も試しました。

私のメインの会議は現在次のようになっています：

user www-data;
worker_processes 1;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

worker_rlimit_nofile 8192;

events {
    worker_connections  2048;
    use epoll;
}

http {
    include       /etc/nginx/mime.types;

    sendfile        on;

    keepalive_timeout  0;
    tcp_nodelay        on;

    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

ローカルネットワーク全体で2つのバックエンドの下/にすべてをリダイレクトする1つの仮想ホスト（利用可能なサイト内）があります。

apache-2.2nginxload-balancingreverse-proxy
4
Ed Eliot

Abのデフォルトの同時実行性は1であり、ロードバランサーを追加すると常にリクエストのレイテンシーが増加するため、同時実行性が最初に考えられましたが、同時実行性を100に設定しているため、これが原因ではないはずです。

リバースプロキシは、各リクエストにヘッダーを追加する可能性があります。これにより、nginxを使用した場合の応答が使用しない場合よりもわずかに大きくなります。ギガビット内部ネットワークを介してこれを実行している場合、おそらく気付かないほどの変更ですが、オフィスまたは自宅からこれを実行している場合、特にこのテストを実行するために小さなファイルを使用している場合、余分なデータが測定可能な違いを引き起こす可能性があります。もちろん、小さなファイルはWeb上ではごく普通のことなので、小さなファイルはより現実的なベンチマークになる可能性があります。

キャッシングは、ベンチマークの実行方法によっては、後続の実行にも違いをもたらす可能性があります。これにより、最初の実行がその後のすべての実行よりも遅くなります。ウォームアップするキャッシュの数が2倍になるため、負荷分散時にこれはさらに複雑になります。最初にnginxをテストした場合、それが違いを引き起こした可能性があります。これを軽減するには、すべてのキャッシュをオフにするか、最初の実行を無視します。すべてのキャッシュを取得することは非常に困難であり、一部は制御できない場合もあります。最初に実行を無視する方法をお勧めします。異なる値で複数の実行を行ったとおっしゃいましたが、キャッシュベースの不正確さを回避するために必要なことは、まったく同じベンチマークを2回以上続けて実行し、最初の実行を無視することです。

この種の動作を引き起こす可能性のあるもう1つのことは、システム内の別の場所でのロックです。 「ロック」とは、一度に1つのWebサーバーのみが使用できるリソースを意味します。この例としては、データベースのMyISAMテーブルにPHPセッションを格納する場合があります。PHPページへのすべてのリクエストは、で読み取りリクエストを実行します。このテーブルは、セッションを検索するため、または書き込み要求を使用して新しいセッションを作成します。MyISAMテーブルにはテーブルレベルのロックがあるため、常に1つのWebサーバーのみがこのテーブルを使用でき、すべてのページでこれを使用する必要があります。テーブルの場合、これは2つのWebサーバーを持つ利点を完全に打ち消す可能性があります。システムの残りの部分が高速であるほど、ロックの相対的な効果が大きくなります。データベースである必要はなく、上の共有Webルートである可能性もあります。 SANまたはNASなので、静的ファイルでもこの​​種の問題の影響を受けません。元の質問で他のシステムについて言及していませんが、この問題はシステムとして現れる可能性が非常に高いです。成長します。

最後に、ベンチマークに関する一般的なアドバイスが少し（かなり多くなりました）。特定の速度（またはこの種のベンチマークの1秒あたりのリクエスト数）が得られる理由は、常に単一のボトルネックが原因です。 Apacheベンチマークは、一部のリソースが100％使用されるまで、できるだけ速くリクエストを続けます。このリソースは、WebサーバーのCPUである場合もあれば、リバースプロキシサーバーのCPUである場合もあります。ただし、これはありそうにありません。通常、ディスクアクセスとネットワーク帯域幅（内部および外部）は、CPU速度が問題になるずっと前に、最初に遭遇するボトルネックです。リソースが90％使用されている場合でも、これはボトルネックではありません。 100％のどこかに、これが90％を超えないようにする別の1つがあります。 100％のものは別のシステム上にある可能性があり、所有しているシステムではない可能性があります。それはネットワークである可能性があり、これは特定のデバイススイッチやa NIC、またはネットワークの一部であるケーブルなど）を意味します。

真のボトルネックを見つけるには、測定可能な値（たとえば、現在アクティブなnginxワーカーの数）から始めて、「なぜこれ以上高くならないのですか？」と尋ねる必要があります。最大値に達した場合は、ボトルネックが見つかりました。そうでない場合は、次に確認する必要があるのは接続されたリクエストです。上流に行くか下流に行くかは、本能の問題です。ダウンストリームでは、nginxはApacheにリクエストを渡すためのネットワークスロットを要求します。開いているネットワーク接続の数が最大かどうかを自問してください。次に、NICの帯域幅。次に、ネットワークの帯域幅。次に、ApacheマシンのNICの帯域幅。答えが明らかな場合は、これらの手順の一部をスキップできますが、システムをランダムに推測するだけではいけません。クエストを順序付けて論理的にします。

時々、あなたが遭遇するボトルネックはあなたがabを実行しているマシンにあるでしょう。これが発生した場合、ベンチマークは無意味です。テストしたのは、実行しているマシンまたはネットワークの速度だけです。あなたはあなたのサイトと同じようにグーグルをベンチマークする同じ結果を得るでしょう。意味のあるベンチマークを確実に取得するには、ベンチマークの実行中にボトルネックを見つける必要があります。 （または、少なくともテストマシン上にないことを確認してください。）サイトのベンチマークを改善するには、システムのボトルネックを見つけて拡大する必要があります。これは、ベンチマークの実行中に行うのが最も簡単です。

あなたのような大規模なシステムをテストするということは、ボトルネックが隠れることができる場所の数が非常に多いことを意味します。ベンチマークをシステムのほんの一部に絞り込むと役立つ場合があります。 nginxを切り取ってApacheにアクセスすることは、この一例であり、Webサーバーと同じネットワークでベンチマークを実行することも別の例です。ただし、さらに進んで、ディスク、ネットワーク、RAMレイテンシとスループットなどの個々のコンポーネントのベンチマークを行うことができます。

残念ながら、すべてのリソースがCPUとRAMの使用量のように報告された簡単なパーセンテージを持っているわけではありません。たとえば、大きなファイルをディスクに書き込むと40MB /秒になる場合がありますが、小さなファイルをたくさん書き込む場合同時にそれらを読み戻す（ディスクに保存されているPHPセッションなど））10MB /秒になる場合があります。リソースの実際のサイズを見つけるには、の各部分でベンチマークを実行する必要があります。システムを個別に使用します。ギガビットスイッチがあるという理由だけで、内部ネットワークを介して1000Mb/sを取得するとは限りません。IP、TCP、NFSヘッダーなどのアプリケーションレベルのヘッダーはすべてNICやケーブルの速度が低下する可能性があるため、このベンチマークを減らします。ハードウェアエラーは、ハードウェアが機能しているにもかかわらず、製造元の仕様よりも少ない場合でも、あらゆる種類のベンチマークに影響を与える可能性があります。

ボトルネックはnginxマシンにある可能性があります。その場合、負荷分散ソリューションが直接単一サーバーよりも遅い理由は明らかです。この時点で、rmalayterの提案のいくつかに従うのがよいでしょう。ボトルネックがどこにあるかがわかるまでは、推測しているだけであり、私たちもそうです。ボトルネックが他の場所にある場合は、おそらくそれを見つけてからここに戻って、より具体的な質問を探すか、質問する必要があります。

5
Ladadadada

テストしているファイルコンテンツの大きさはどれくらいですか？

Nginxの ログレベル を「警告」に切り替え、error.logを確認します。プロキシされたコンテンツをディスクの一時ファイルに書き込むことに関する警告が表示される可能性があります。 proxy_buffers 数/サイズを増やす必要があると思います。または、プロキシバッファリングを完全にオフにします。 nginxのデフォルトは低すぎて、合理的な最新のコンテンツには役立ちません。

同様の構成で、2つのバックエンドIISボックスからの静的57kBhtmlファイルに対して毎秒3700リクエストが表示されます。すべてが2GBのRAMを備えたシングルCPU仮想マシンです。 proxy_buffersは "proxy_buffers 32 16k;"として設定されています。明らかに、Apacheで1秒あたり50リクエストしか表示されない場合は、動的ページをテストしていますよね？

1
rmalayter