パフォーマンス テストを行う場合、どのようなテスト ツールを選択しますか? ワークを選びますか？jメーター？イナゴ？またはロードランナーはどうですか？今日は、jmeter、locust、wrk、loadrunner で一般的に使用されているパフォーマンス テスト ツールについて、著者自身の経験に基づいて簡単に紹介し、比較します。
まず、4つの基本的な比較チャート：
loadrunner は商用の課金モデルであるため、企業レベルのテスト使用には承認の問題が伴うため、この記事では loadrunner について詳しく説明しません。
01週
wrk は軽量の http パフォーマンス テスト ツールです. スレッド + ネットワーク非同期 IO モデルを採用しています. ネットワーク非同期 IO により、システムは少数のスレッドを使用して多数のネットワーク接続をシミュレートし、同時実行性と圧力を高めることができます.
長所：
シンプルな操作、使いやすい
使用方式例如：
./wrk -c 1000 -t 8 -d 10s http://www.baidu.com
主要包括以下参数：
-t（--thread） 需要模拟的线程数
-c（connection） 需要模拟的连接数
--timeout 超时的时间
-d（--duration） 测试的持续时间
欠点:
wrk は http プロトコル タイプのリクエスト (get、post など) のみをサポートしますが、get 以外の http タイプのリクエストを実行する必要がある場合は、ユーザーが自分で lua スクリプトを作成する必要があります。
単一マシンのテストのみが許可され、複数マシンの分散ストレス テストはサポートされていないため、wrk はパフォーマンス ベンチマーク テストに適しており、数万ユーザーの同時テストをシミュレートするには少し無力に思えます。
テスト結果は単純で、詳細なチャート分析はありません。例は次のとおりです。
wrk テスト結果の出力:
02 メートル
Jmeter もスレッド同時実行メカニズムを採用していますが、主にスレッド数を増やして同時実行数を増やしているため、1 台のマシンで数千人の同時ユーザーをシミュレートすると、CPU とメモリの消費量が比較的大きくなります。上記のwrkと比較すると、jmeter自体には次のような長所と短所があります—
アドバンテージ：
インターフェイスの視覚化操作。記録スクリプトを使用して、より複雑なユーザー フローをモデル化できます。また、アサーションを作成して、テスト動作が合格したかどうかを確認することもできます。
表、グラフ、結果ツリーなど、さまざまな種類の視覚的なデータ分析とレポート出力の例を以下に示します。
jmeter 集計レポートとテーブル ビューの結果:
http、ftp、tcp、およびその他のプロトコル タイプのテストをサポートします。
分散ストレス テストはサポートされていますが、数万人のユーザーを同時にテストするには、複数のテスト マシンをサポートする必要があり、比較的大きなリソースが必要です。
システム応答時間や 100QPS (QPS: 1 秒あたりのクエリ レート) 未満のリソース消費など、一定のスループットでシステム パフォーマンスをテストするために使用できます。
欠点:
jmeter の GUI モードは多くのリソースを消費します. 高負荷をテストする必要がある場合は、まず GUI ツールを使用して XML テスト計画を生成し、次にテスト計画をインポートして非 GUI モードでテストを実行する必要があります.不要なリスナーを閉じます (測定値を表示するデータ コンポーネントを収集します)。これは、リスナーが負荷を生成するために使用されるはずのかなりのリソースも消費するためです。テストが終了したら、生の結果データを GUI にインポートして結果を表示する必要があります。
03 イナゴ
locust はシンプルで使いやすい分散負荷テスト ツールで、主に Web サイトの負荷ストレス テストに使用されます。Locust は Python 言語で開発されており、テスト リソースの消費は Java 言語で開発された jmeter よりもはるかに少なくなります。また、何百万ものユーザーの同時テストを簡単にシミュレートできる分散展開テストをサポートしています。jmeter や wrk と比較すると、locust には次の長所と短所があります。
利点:
同時実行性を高めるためにスレッド数を使用する wrk や jmeter とは異なり、locust はコルーチンを使用してユーザーをシミュレートします. 同じ物理リソース (マシンの CPU、メモリなど) 構成の下で、locust がサポートできる同時ユーザーの数は、 jmeter Magnitude と比較して 1 増加します。
複雑なシナリオをテストするための wrk の限られた機能や、複雑なシナリオを記録するためにインターフェイスをクリックする必要がある jmeter と比較すると、locust では、ユーザーが python を使用してユーザー シナリオを記述し、テストを完了するだけで済みます。
jmeter の複雑なユーザー インターフェイスとは異なり、locust のインターフェイスはすっきりと整理されており、テストに関連する詳細 (送信された要求の数、失敗の数、現在の要求の送信速度など) をリアルタイムで表示できます。
locust は Web アプリケーションのテストを対象としていますが、ほぼすべてのシステムのテストに使用できます。すべてのテスト要件を満たすイナゴのクライアントを作成します。
欠点:
wrk と同様に、イナゴ テスト結果の出力は、jmeter ほど多様ではありません。
イナゴ試験結果:
04 まとめ
この記事では、wrk、jmeter、および locust の 3 つのパフォーマンス テスト ツールを簡単に紹介して比較し、基本的な理解を深めてもらいたいと考えています。さらに、最後に、次のテスト要件に直面して、3 つからどのように選択する必要があるかを見てみましょう。
1. インターフェース操作の形式を使用してシステムのパフォーマンスをテストしたいのですが、テスト データを視覚的に適切に表示したいと考えています。
jmeter ツールの使用をお勧めします
2. システムの http rest インターフェイスのパフォーマンスをテストしたいのですが、これまでテストを行ったことがなく、システムの QPS がどのレベルなのかわかりません。
wrk ツールの使用をお勧めします
3. 複雑なシナリオでシステム上のユーザー操作のパフォーマンスをシミュレートしたい。
イナゴツールの使用をお勧めします
4. 特定の QPS 条件下で、システムのパフォーマンス インジケータ (CPU 消費、メモリ消費など) を一定期間テストしたいと考えています。
jmeter ツールの使用をお勧めします
5. システムのパフォーマンスをテストするために等速要求の方法を使用したい。
jmeter または locust ツールを使用することをお勧めします
6. プログラミングの楽しさを体験し、パフォーマンス テスト用のスクリプトを書きたい。
http リクエスト: wrk、lua 言語を使用してスクリプトを記述します。
イナゴ、python 言語を使用してスクリプトを記述します。
または、自分で行って、選択したプログラミング言語でパフォーマンス テスト スクリプトを記述します。
05 付録
wrk はパラメーターの説明を使用します。
1. パラメータ -c (接続、回線リンクの数) は、オペレーティング システムのファイル ハンドルの数に関連しています. -c は、設定されたファイル ハンドルの数を超えることはできません. テストを開始する前に、使用可能なシステムのポートが -c 設定より大きい。
2. パラメータ -t (–thread, スレッドの数) は、オペレーティング システムの CPU コアの数に関連しています. -t を大きく設定しすぎることは適切ではありません.スレッドのスケジューリングにより、パフォーマンスが低下します。下の図に示すように、オペレーティング システムは 8 コア CPU です: 同じ接続数とテスト期間の下で、異なる数のスレッドを使用して同じシステムの REST インターフェイスをテストします. テスト結果から、 thread=8 の場合 (CPU コアの数と一致)、システム パフォーマンス テストの結果が最高であり、パフォーマンスの変動が最小であることがわかります。
8 コア CPU: 接続数とテスト期間が同じ場合、スレッド数が異なる同じシステムの REST インターフェイスのテスト結果の比較チャート
最後に, 私の記事を注意深く読んでくれたすべての人に感謝したいと思います. 相互主義は常に必要です. それは非常に価値のあるものではありませんが, 必要に応じて取り除くことができます:
これらの資料は、[ソフトウェア テスト] の友人にとって最も包括的で完全な準備倉庫である必要があります. この倉庫はまた、最も困難な旅を通して何万人ものテスト エンジニアに同行してきました.パートナーは下の小さなカードをクリックできます.受け取る