17. 助けて！上司から、アプリケーションの負荷テストを依頼されました。¶
これはかなり自由度の高い提案です。最初に尋ねるべき質問がいくつかあり、さらに多くのリソースが必要になります。ベンチマーク/負荷テストを実行するには、いくつかのハードウェアが必要です。多くのツールが役立つことがわかります。検討すべき製品は数多くあります。最後に、負荷テスト/ベンチマーク製品を実装するのに Java が適している理由を教えてください。
17.1 質問事項 ¶
予想される平均ユーザー数 (通常の負荷) は?
予想されるピーク時のユーザー数は?
1 つまたは複数のサーバーがクラッシュする可能性があることを念頭に置いて、アプリケーションの負荷テストを行うのに適した時間 (営業時間外または週末) はいつですか?
アプリケーションには状態がありますか? もしそうなら、私たちのアプリケーションはそれをどのように管理しますか (Cookie、セッション書き換え、またはその他の方法)?
テストの目的は何ですか?
17.2 リソース¶
次のリソースは非常に役立ちます。これらのリソースを見つけることができない場合は、これらのリソースになることに注意してください。あなたはすでに仕事を切り詰めているので、必要に応じて彼らに助けを求めることができるように、以下の人々が誰であるかを知っておくことは価値があります.
17.2.1 ネットワーク¶
ネットワークトポロジを知っているのは誰ですか? ファイアウォールやプロキシの問題が発生した場合、これは非常に重要になります。同様に、プライベート テスト ネットワーク (したがって、ネットワーク レイテンシが非常に低くなります) も非常に優れたものです。誰があなたのためにセットアップできるかを知ることは非常に便利です. アプリケーションが期待どおりにスケーリングしない場合、誰がハードウェアを追加できますか?
17.2.2 アプリケーション¶
私たちのアプリケーションがどのように機能するか誰が知っていますか? 通常のシーケンスは
- テスト (少量 - アプリケーションのベンチマークを実行できますか?)
- ベンチマーク（平均ユーザー数）
- load-test (最大ユーザー数)
- 破壊的にテストします (私たちのハードリミットは何ですか?)
17.3 ベンチマーク/負荷テストを実行するには、どのプラットフォームを使用すればよいですか? ¶
これは、標準 (つまりバニラ) ソフトウェアがインストールされた、広く使用されているハードウェアである必要があります。結果を公開する場合、クライアントが最初に行うことは、大学院生を雇って結果を検証することであることを忘れないでください。できる限り、この人にとって簡単にすることもできます。
Windows の場合、Windows XP Professional が最低限必要です (その他は 50 ～ 60 接続を超えてマルチスレッド化されず、おそらくそれ以上のユーザーが予想されます)。
優れたフリー プラットフォームには、Linux、BSD、Solaris Intel などがあります。もう少しお金があれば、商用 Linux があります。サポートが必要な場合、これは価値があるかもしれません。
Windows 以外のプラットフォームの場合は、ユーザー アカウントの起動スクリプト (テスト アカウント用の .bashrcまたは.cshrcスクリプト)に含めることを目的として、 「 ulimit -n unlimited 」を調査します。
また、一部の Linux/Unix エディションはサーバーでの使用を目的としていることにも注意してください。これらは通常、最小限の GUI サポートしかないか、まったくサポートしていません。このような OS は、JMeter を CLI モードで実行するのに問題ありませんが、最小限の GUI 環境をインストールしない限り、JMeter GUI モードはおそらく機能しません。
大規模なベンチマーク/負荷テストに進むにつれて、このプラットフォームが制限要因になります。そのため、利用可能な最高のハードウェアとソフトウェアを使用する価値があります。公開されたベンチマークにハードウェア/ソフトウェア構成を含めることを忘れないでください。
多数のマシンが必要な場合や、ネットワークの遅延をテストしたい場合は、クラウドが役立ちます。 JMeter は、クラウドで利用可能なほぼすべてのアーキテクチャで実行されるため、クラウド インスタンスに簡単にインストールできます。自分で管理したくない場合は、JMeter も Commercial Cloud PAAS 内でサポートされます。
JMeter バッチ (CLI) モードを忘れないでください。このモードは、多くの理由から負荷テスト中に使用する必要があります。
- Java をサポートする強力なサーバーを使用しているが、おそらく高速なグラフィックスの実装がない場合、またはリモートでログインする必要がある場合。
- バッチ (CLI) モードは、リモート ディスプレイまたはクライアント サーバー モードを使用する場合と比較して、ネットワーク トラフィックを削減できます。
- GUI モードに使用される Java AWT スレッドは、時々ブロックすることによってインジェクション動作を変更することができます
17.4 ツール¶
次のツールはすべて役に立ちます。それらに精通することは間違いなく価値があります。これには、それらを試してみること、および適切なドキュメント (マンページ、情報ファイル、アプリケーション --help メッセージ、および提供されたドキュメント) を読むことが含まれます。
17.4.1 ping ¶
これは、ターゲット サイトに到達できるかどうかを確認するために使用できます。' ping ' が ' traceroute 'と同じ種類のルート レポートを提供するように、オプションを指定できます。
17.4.2 nslookup/dig ¶
ユーザーは通常、人間が判読できるインターネット アドレスを使用し ますが、ベンチマークや負荷テストを実行するときは、DNS ルックアップのオーバーヘッドを避けたい場合があります。これらを使用して、ターゲット サイトの一意のアドレス (点線のクワッド) を特定できます。
17.4.3 トレースルート¶
ターゲット サイトに「 ping 」 できない場合は、これを使用して問題を特定できます (ファイアウォールまたはプロキシの可能性があります)。また、全体的なネットワーク遅延を推定するために使用することもできます (ローカルで実行すると、可能な限り低いネットワーク遅延が得られるはずです。ユーザーは混雑している可能性のあるインターネット上で実行されることに注意してください)。一般に、ホップ数が少ないほど優れています。
17.5 JMeter を拡張するにはどうすればよいですか? ¶
JMeter プラグインまたは JMeter で使用するその他のリソースを提供するオープンソースおよび商用プロバイダーが多数あります。これらのいくつかは、JMeter Wiki にリストされています。それらはいくつかのカテゴリにリストされています。
- JMeterPlugins - JMeter を拡張するためのプラグイン
- JMeterAddons - JMeter で使用するアドオン (ブラウザ、Maven、Jenkins 用のプラグインなど)。
- JMeterServices -クラウドベースの JMeter などのサードパーティ サービス
17.6 Java を使用する理由 ¶
Perl や C ではないのはなぜですか?
まあ、Perl は非常に良い選択かもしれませんが、Benchmark パッケージがかなりあいまいな結果をもたらすように見えることを除けば. また、Perl で複数のユーザーをシミュレートするのは難しい問題です (複数の接続は、シェル スクリプトから多くのプロセスを fork することでシミュレートできますが、これらはスレッドではなく、プロセスになります)。ただし、Perl コミュニティは非常に大規模です。誰かがすでに役に立ちそうなものを書いていることがわかった場合、これは非常に良い解決策になる可能性があります。
もちろん、C は非常に良い選択です (Apache abツールを調べてください)。ただし、アプリケーションのベンチマークに必要なすべてのカスタム ネットワーク、スレッド、および状態管理コードを記述する準備をしてください。
Java は、アプリケーションのベンチマークに必要なカスタム ネットワーキング、スレッド、および状態管理コードを (無料で) 提供します。Java は、RMI、IIOP、および JDBC だけでなく、HTTP、FTP、および HTTPS も認識します (Cookie、URL エンコード、および URL 書き換えは言うまでもありません)。さらに、Java は自動ガベージ コレクションとバイトコード レベルのセキュリティを提供します。