0

私は、ロード バランサとそれに続く 2 つの Web アプリケーション サーバーとデータベースのアーキテクチャを持っています。Jmeter 分散テスト環境からサーバーに数千の HTTP リクエストを送信しています。

レスポンスを返す際に、サーバーからレスポンスが返ってこないリクエストはほとんどありません。

データベース ログを確認したところ、100 % の要求が応答されました。Web Application サーバーのアクセスログを確認したところ、100% のリクエストが応答されました。

ロード バランサーは、それぞれのクライアントへのこれらの保留中の応答をトラバースして損傷を引き起こす可能性がありますか? 毎回異なるリクエストがスタックしています。

前もって感謝します！！

4

1 に答える 1

0

ロード バランサーが疑われる場合は、まず 3 つの一般的な原因を調べてください。

  1. ロード バランサーが待機しているよりもサーバーの応答に時間がかかる
  2. クライアントのタイムアウトは、サーバーが応答するよりも短いです。
  3. ロード バランサーのポート/スレッド/接続の枯渇、またはその他の LB 構成の問題

3 つのケースすべてで、ロード バランサのログを確認することをお勧めします。使用している LB を指定していないため、ログがどのように表示されるかを正確に言うことはできませんが、通常、LB ログには以下を表示するオプションがあります。

  1. 要求が Web サーバーに送信され、Web サーバーからの応答がロード バランサーに返されるまでにかかった時間。これらの数値を、ロード バランサーとクライアント用に構成されたタイムアウトと比較できます (問題 1 と 2)。
  2. クライアントからのリクエストが LB によって処理されるのにかかった時間と、LB がクライアントに応答するのにかかった時間。時間がかかる場合は、ロードバランサーに問題があります (問題 3)
  3. もちろん、ロード バランサーにエラーがある場合は、何が起こっているのかを説明するだけかもしれません。

ロード バランサーのログを確認できない場合は、JMeter テストを一時的に変更して、ロード バランサーの背後にあるサーバーを直接ターゲットにすることをお勧めします。すべてのサーバー間で負荷を均等に分散するようにスクリプトを構成することもできます (複数のスレッド グループを使用するなど)。これにより、問題を特定し、何が起こっているかについてより多くの情報を得ることができます。

于 2016-04-22T14:56:06.470 に答える