Skip to content

MS_JMeter3TierLoadTest

Jump to bottom
nishi_74322014 edited this page Aug 18, 2026 · 1 revision

Jmeterによる3層C/Sの負荷テスト

概要

HTTPプロトコルの場合

テキスト・フォーマット

XML、JSONなどのテキスト・フォーマットの場合、
JmeterによるWebアプリの負荷テストと
同じ方法で負荷テストが可能。

バイナリ・フォーマット

  • HTTP 内部に base64 等のバイナリ・フォーマットが存在する場合、
    JmeterによるWebアプリの負荷テストの手順と異なり、
    スクリプト修正は不可能
    （電文再送で再現可能な負荷に限りテスト可能）。

  • 生バイナリ電文の場合は更に考慮が必要。

補足（なぜバイナリだと難しいのか）: 負荷テストの本質は
記録したリクエストを、可変値だけ差し替えて再生することにある
（Jmeterによる可変値の追跡）。

電文の形式 可変値の差し替え
テキスト（XML / JSON / フォーム） 可能。正規表現や JSON Extractor で置換できる
Base64 等でエンコード デコード → 編集 → 再エンコードが必要。実質困難
生バイナリ（独自シリアライズ） 不可能に近い。長さフィールドやチェックサムも壊れる

このため、バイナリ電文では
「記録したものをそのまま投げ返す」ことしかできない。
セッション ID やトークンが電文中にあると、
全スレッドが同じ値を送って失敗する（＝負荷にならない）。
本ページが「電文再送で再現可能な負荷に限りテスト可能」と
断っているのはこのためである。

その他のプロトコルの場合

サンプラー

適切なプロトコル系のサンプラー（Jmeter用語）を使用して
負荷テストを実施（ワークロードの記録はできない）

  • FTP
  • LDAP
  • JDBC
  • MongoDB
  • SMTP
  • POP3（S）/IMAP（S）
  • JMS（Java Message Service）
  • OS コマンド

補足（.NET 系の 3 層 C/S を測る場合）: 上記のサンプラーには
.NET Remoting や WCFのバイナリ バインディングに
対応するものが無い。
このため、選択肢は以下になる。

方式 可否
WCF の basicHttpBundling / SOAP（テキスト） HTTP サンプラーで可能
WCF の netTcpBinding（バイナリ） 不可。後述の pcap 再生などを検討
gRPC JMeter の gRPC プラグイン、または k6 / ghz
WebAPI（REST / JSON） HTTP サンプラーで可能。最も扱いやすい

「負荷テストのしやすさ」は
プロトコル選定の段階で決まってしまうという点は、
設計時に意識しておく価値がある
（負荷テストのポイント）。

テンプレート

テンプレート（Jmeter用語）を使用して
テスト計画を作成すると良い。

生バイナリ電文対応

Jmeter

proxy.binary.types=application/x-amf,application/x-java-serialized-object,application/octet-stream
  • コードは以下のように修正する（VB で WebRequest を使用する際の例）。
' HttpWebRequest作成
request = DirectCast(WebRequest.Create(server), HttpWebRequest)
request.Proxy = New WebProxy("127.0.0.1", 8888)
request.ContentType = "application/octet-stream"
  • 生バイナリ電文でも、キャプチャ・リプレイが可能になる。
    ※ 以下のようにバイナリのボディがファイルに保存されるようになる。

バイナリ電文ファイル

補足: proxy.binary.types に指定した Content-Type の
リクエスト ボディは、テキストとして扱わず
.binary ファイルに退避され、HTTP リクエスト サンプラーから参照される
（「本文データ」ではなく「ファイルのアップロード」として記録される）。
前述のとおり、ファイルの中身は編集できないため
そのまま再生することになる。

なお、jmeter.properties を直接編集せず
user.properties に書くのが望ましい
（Jmeterのインストールの補足参照）。

また、コード側にプロキシ設定を埋め込む例が挙がっているが、
.NET なら app.config / web.config の
<system.net><defaultProxy> で外部化するほうが
テスト用の改変をコードに残さずに済む。

Fiddler and Test Studio

Fiddler（電文を確認する方法（パケット・キャプチャ））を
使用すれば、キャプチャ電文をそのままリプレイできる。

  • しかし、*.saz ファイルのログを

    • シーケンシャル実行したり
    • 多重度を上げて実行したり

    できない。

  • Test Studio（MS_TestStudio.md）を使用すればできるようにも見えたが、
    ログをシーケンシャル実行する機能テストは可能だったが、
    多重度を上げるような負荷テストができなかった。

補足（最新化）: Fiddler Classic は開発が終了しており、
後継は Fiddler Everywhere（クロスプラットフォーム・商用）である。
同様の用途では mitmproxy（OSS）も選択肢になる。
mitmproxy は Python でスクリプトを書けるため、
記録した電文を加工して再生する処理を自作しやすい。

pcap再生ツール

TCP/IP の電文再送でテスト可能なら pcap 再生ツールが使える。
（ただし、一通り調べたところ、多重実行できるまでのツールは発見できなかった）

補足（pcap 再生の根本的な限界）: 調査結果が
どれも「多重実行できない」で終わっているのには理由がある。

pcap の再生はパケットをそのまま送出するだけなので、

  • TCP のシーケンス番号・ACK が相手と噛み合わない
  • 送信元ポートが記録時のまま（多重化すると衝突する）
  • 相手からの応答に応じた挙動ができない

つまり、pcap 再生は本来
ネットワーク機器（スイッチ・ファイアウォール）の試験用であり、
アプリケーションの負荷試験には原理的に向いていない。

生バイナリ電文の負荷試験を行うなら、現実的には

  • クライアント側のライブラリを使った負荷ツールを自作する
    （実際のクライアント コードを多重で回す）
  • プロトコルをテキスト（WebAPI / gRPC）に寄せる

のいずれかになる。

Bit-Twist

元々は Unix 系 OS 向けのツールだが、Windows 版のバイナリもある。

  • Bit-Twist: Libpcap-based Ethernet packet generator
    http://bittwist.sourceforge.net/index.html

  • コマンドは 2 種類あり、

    • bittwiste.exe
      PCAP ファイルを編集するコマンドでパケットに含まれる
      IP アドレスやポート番号を編集できる。
    • bittwist.exe
      PCAP ファイルを送信するコマンドでパケットの送信速度等を設定できる。

  • Cygwin1.dll
    Windows 版では Cygwin1.dll が必要

    • Bit-Twist サイトからダウンロードできる
    • Windows 8.1 以降では新しいバージョンの Cygwin1.dll が必要

PReplay

非常に単純なツール。また、2 パケット間の時間差を保持する。

  • PReplay – A pcap Network Traffic Replay Tool for Windows
    https://www.darknet.org.uk/2007/03/preplay-a-pcap-network-traffic-replay-tool-for-windows/

  • 評価
    使えるが、ポート番号が同じになるので多重実行ができない。
    そもそも多重起動に対応していなそう（→ 下記設定でファイルを複数設定する仕様）。

    • 設定
      追跡 -> TCP/IP で全選択した後にエクスポートした selected.pcap を指定。
      ※ ここに、1, 2, 3 ... と指定して行くと、シーケンシャルではなく多重実行に見える。
[SendingDetails]
SendingFilePath=C:\
GatewayOldMac=00-0F-A3-35-C4-15
GatewayNewMac=00-0D-56-69-14-6D
ClientOldMac=00-02-44-8E-98-7B
ClientNewMac=00-15-F2-33-6A-D5
GatewayOldIP=192.168.1.1
GatewayNewIP=192.168.8.3
ClientOldIP=192.168.1.2
ClientNewIP=192.168.8.8
[SendingFileName]
1=PReplay\selected.pcap
;1=pcap1.cap
;2=pcap2.cap
  • 実行
    PReplay で pcap ファイルを再生する。

PReplayでpcap再生

  • 結果
    実行したパケットをキャプチャして実際に実行できたかを確認する。

PReplayでのpcap再生結果

  • bat 化
    bat 化する場合、Echo コマンドで使用する NIC の番号を指定可能。
echo 3 | PacketSendingUtility.exe

補足: pcap の取得・確認方法は
監視・パケット解析編、
Wiresharkの操作方法（MS_WiresharkUsage.md）を参照。

tcpreplay

Windows 用のサポートやバイナリがない。

  • tcpreplay man page
    http://otsuka752.github.io/wiki/tcpreplay-man.html

    tcpreplay の基本的な使い方は、\

    • 指定されたファイル群をキャプチャされた時と同じ速度で再送信したり、
    • ハードウェアが許す限りの速度の範囲内であれば、指定したデータ速度で再送信する。

  • Download and Installation > Special Instructions for Windows
    https://tcpreplay.appneta.com/wiki/installation.html

    実験的なベータ版の品質です。（beta quality if you will.）

補足: 現在は WSL2（WSL）を使えば、
Windows 上でも Linux 版の tcpreplay をそのまま利用できる。

Ostinato

昔はフリーだったのかもしれないが、今は有償化されている。

XenaManager-2G

UI が複雑すぎるうえ、Replay File メニュー・アイテムを Enable にする方法が不明で
利用を断念。

移行メモ（体裁）: 元ページの「UI が複雑すぎるとの、Replay File メニュー…」は
文意が通らないため、「複雑すぎるうえ」と補って掲載した。

参考

Tags: 移行, テスト, ツール類

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally