この質問のタイトルは私の主な懸念を表していますが、質問セクションでは、私たちのセットアップに関する背景情報がいくつか記載されていますが、関連性や有用性があるかどうかはわかりません。
質問
私たちはアプリケーションのストレステストをガトリング、そしてガトリングシナリオを実行しているシングルマシン。アプリケーションは、ストレス ツールによって生成される高負荷には対応できますが、実際のユーザーからの比較的低い負荷には対応できないことがわかりました。
私の質問は、単一のマシン/OS からアプリケーションへの同時リクエストと、複数のマシン (つまり、Web ブラウザーを使用する一般ユーザー) からの同時リクエストでは、どのような OS/ネットワーク レベルの最適化または合理化が行われるかということです。
背景
AJP 経由で Apache の背後に Tomcat アプリケーションがあり、Apache 自体はポート 80 経由で Citrix Netscaler の背後にあります (Apache を除外することも計画していますが、それは別の問題です)。
私たちのアプリは、比較的低い負荷 (Apache と Tomcat の間に CLOSE_WAIT 接続が構築されている) で停止してしまい、問題を解決するために負荷テストを行っています。SQLServer インスタンスでデッドロックが頻繁に発生していたため、そこから始めることにしました。問題を再現し、その後修正をテストするために、Gatling を使用して負荷を生成する単一のマシンを使用しています。
最初は、このツールを使ってデッドロックを確実に再現できました。最適化をいくつか行った後、デッドロックはなくなり、CLOSE_WAIT 接続も解消されました。その後、アプリケーションを満足のいく負荷までプッシュしたところ、大きな問題もなく実行されました。
残念ながら、修正が本番システムに適用された後も、元の動作と同じ状態が見られました。ストレスツールによって生成された負荷は、現実世界で実際に起こっていることを正確に表していないのではないかと思います。インターネット上に広がる多くの異なるクライアントではなく、単一のソースから発信されるため。
答え1
単一の負荷ジェネレーターは、異なるクライアントよりも接続プールの処理が優れている可能性が高く、たとえば、Keepalives をより有効に活用できます。これにより、より少ない接続でより多くのリクエストが可能になります。
ラウンドロビン DNS が関係する場合、負荷をすべての DNS 宛先に分散するのではなく、DNS 宛先の 1 つだけにアクセスする傾向があります。一部のロード バランサーは、クライアント IP に基づいてスティッキー性の決定を行いますが、この場合は静的になります。
負荷ジェネレーターには制約された実行プール (たとえば、200 人の「ユーザー」) があり、応答の遅延によってユーザーの速度が低下する可能性があります。これは、他のユーザーの終了を辛抱強く待つことのない、はるかに多くのユーザーが存在する現実の世界とは対照的です。
答え2
ガトリングテストのシナリオを見ずに何かを維持するのは難しい。単なる「ブラインドショット」：ガトリングテストは実際のユーザーを正確に表していない、つまり
- 実際のブラウザは、ページに埋め込まれた外部リソース（画像、スクリプト、スタイルなど）をダウンロードし、同時スレッドプールを使用してこれを実行します。Gatlingテストが見つからない場合HTMLリソースの推論方法によっては、ガトリングからの負荷は、実際のブラウザの背後に座っている実際のユーザーによって実行される負荷よりもはるかに少ない可能性があります。
DNSキャッシュ。JVMレベルでDNS名キャッシュの背後にあるIPアドレスのため、Gatlingは1つのIPアドレスのみにヒットする場合があります。ガトリングに関するよくある質問:
基本的に、Gatling/JVM の DNS キャッシュを調整する必要があります。解決策は、
-Dsun.net.inetaddr.ttl=0コマンド ラインに追加することです。AJAX リクエスト。Gatling はクライアント側の JavaScript を実行しないため、アプリケーションが XMLHTTP リクエストに基づいて構築されている場合、Gatling がページにアクセスしたときにリクエストは実行されません。アプリケーションが何らかの形式の AJAX を使用している場合は、手動で処理する必要があります。
そこで、JMeter を実際のブラウザのように動作させる方法負荷テストが実際の負荷を反映していない場合、そのようなテストを実行してもあまり意味がないので、同等の Gatling セットアップを実装します。