インターネットシステムにおける負荷テストにおいて、しばしば対照的なスタイルを持つ2つのツールに遭遇します。1つは極めて軽量で、最大限の帯域幅を追求するwrkであり、もう1つは機能が豊富で、実際のビジネスフローをシミュレートするJMeterです。

提示：コアなアイデアを整理し、科普記事を作成：HTTP 負荷テストツール、wrk vs Jmeter の違いについて、私が知っていること、wrk は 1 つの スレッドで複数の接続を行うテストに偏っており、Jmeter はより短接続モードに重点を置いており、設定によって長接続モードにも調整可能です。

コアアーキテクチャ：マルチスレッド vs イベント駆動

これは両者のパフォーマンス差の根本的な原因です。

1. JMeter: 伝統的な「一人一岗」制 (Thread-per-Request)

JMeter は Java で開発されており、古典的な マルチスレッドモデル を採用しています。

• ロジック: 各コンカレントユーザー（Virtual User）は、JVM 内の物理的なスレッドに対応します。
• コスト: スレッドは非常に高価なリソースです。同時数があっという間に数千に達すると、コンテキストスイッチング (Context Switch) とメモリ消費がテストマシン自体を著しく遅延させ、「ロードマシンがサーバーを押し倒す前に、自分自身が崩壊する」といった現象を引き起こします。

2. wrk：現代的な「多面手」制 (イベント駆動型)

wrk は C 言語で記述されており、コアとなるロジックは Redis と同じ ae イベントループフレームワークを利用しています（epoll/kqueue を使用）。

• ロジック: wrk は各接続ごとにスレッドを作成しません。代わりに、極少数のスレッド (通常は CPU コア数に相当) のみ起動し、それぞれのスレッド内部でノンブロッキング I/O を通じて成千もの接続を同時に管理します。
• 利点: これが「一つのスレッドで複数の接続」という表現です。スレッド切り替えのオーバーヘッドを大幅に削減し、単一マシンで百万レベルの RPS (リクエスト毎秒) を実現できます。

连接モデル：短接続と長接続

ご指摘の接続パターンについて、より詳細な情報をご提供します。

1. JMeter の「重」と「軽」

JMeter はデフォルトで、実際のユーザーの行動をシミュレートする傾向があります。

• 短接続への偏り： デフォルト設定では、JMeter の古いバージョンや特定の構成によっては、積極的に接続を再利用せず、多数の TCP 握手が発生することがあります。
• 調整可能性： 「KeepAlive」を HTTP Request 中にチェックボックスで選択するか、user.properties ファイルで接続プールパラメータを調整することで、長接続を有効化できます。しかし、たとえ長接続を有効化したとしても、スレッドモデルの制限により、数十万レベルの同時長接続を維持することは困難です。

2. wrk の「快」と「狠」

wrk が設計されたのは、HTTP Keep-Alive の性能をテストするためです。

• 長接続戦略： wrk はテスト開始時に指定した接続数を確立（-c オプションを使用）し、テスト中に可能な限りこれらの接続を再利用します。
• 適用場面： Nginx やゲートウェイ（Gateway）、高負荷 API が極端な長接続ストレス下でスループットの限界をテストするのに非常に適しています。

比較表

比較表

比較表

比較表

比較表

深層比較表

まとめ：どちらを選ぶべきか？

これらのツールは代替関係ではなく、補完関係にある：

選ぶワーク

• サーバーの最大スループット (RPS) をテストしたい。
• テスト対象は単一の API または静的リソース。
• 最小限のテストサーバーで最大のトラフィックを発生させたい。
• Lua スクリプトを使ってリクエストをカスタマイズする経験がある。

JMeter を選択する

• 複雑なビジネスフロー（例：ログイン → 商品検索 → 購入 → 決済）をシミュレートする必要がある。
• レスポンスタイム分布、エラー率などの詳細な指標を観察するための可視化されたインターフェースが必要である。
• テストでは動的パラメータ（例：前のインタフェースから取得したトークンを次のインタフェースに渡す）を処理する必要がある。
• チームはコマンドラインよりもグラフィカルツールに慣れている。