実務で使ったので、メモの意味も含めて。

使用したバージョン：5.1.1

実際に使ってみる

nodejsで以下のようなAPIを作成してみました。

// ライブラリ読み込み
var express    = require('express');
var app        = express();

var port = process.env.PORT || 8080; // port番号を指定


// GET http://localhost:3000/api/v1/
app.get('/api/test/',function(req,res){
    res.json({
        message:"Hello,world"
    });
});

app.listen(port);

このAPIについて試したい目的は、「同時リクエストの負荷が高まるとどうなるのか」とします。

jmxファイルを作成

以下のようなテストを作成します。HTTPのgetを上記で作成したサーバに投げるのみです。
※「各スレッドグループを別々に実行」にチェックを入れないと、4つのテストが同時に走ってしまうので注意

今回はスレッドを４つ用意しました。赤枠で囲った部分が異なるだけです。

スレッド数: 60
Ramp-Up期間(秒): 60
「60秒の時間をかけて処理開始し、スレッド毎にシナリオを一回だけ実行する」
= 「秒間1リクエストのテスト」
となります。
※画像で設定した4つ目のテスト(秒間1000リクエスト)は java.net.BindException発生するので無効にしてありますorz
※windowsによる制限なんだろうか・・・

実行

※GUIは本番の負荷試験では使うべきではない

参考
Don't run load test using GUI mode !
GUIはテストを作成する上では非常に便利なんですが、自分の体験としては
高い負荷のテストを実行しようとすると途中で止まってしまう。(JMeterのGUI自体がボトルネックになっているようだ)
のでかなり不便です

CUIならば、オプション指定で結果をまとめてくれます。

と非常に便利です。

CUIで実行

jmeterフォルダ/bin以下で
(Linux)./jmeter.sh -n -t <上記で作成したファイル名>　-l <結果ファイル> -e -o report で実行
テスト結果がreportフォルダ内に出力されます。

結果

report/index.htmlを参照するといろいろな角度からテスト結果を見ることができます。
意味ありそうなやつを。Time Vs Threadsを見ると、
同時アクセスのスレッドが増えたら平均レスポンスタイムは増えていることがわかります。
上記実装はシングルスレッドなのでこんなもんなのかな、という感じです。