こんにちは。
キャスレーコンサルティングのSI(システム・インテグレーション)部の遠山です。

今回は負荷試験ツールGatlingの紹介をしたいと思います。

http://gatling.io/#/

ハイパフォーマンスで、ユーザーフレンドリーなDSLを持ち、ゴージャスなレポート作成をしてくれる事を謳っています。
以下の順番で見ていく事にします。

  1. とりあえず触ってみる
  2. シナリオを書いてみる
  3. 便利にカスタマイズする

1.とりあえず触ってみる

公式サイトにすぐ使えるzipファイルがありますのでダウンロードしてみましょう。

01

中身はこんな感じです。

02

とりあえずbinにgatling.shがあるので実行してみます。
どれどれ。

03

シナリオ選択ですね。1のAdvancedSimulationStep01を選択してみましょう。
実行が始まります。

04

実行完了され、結果が出力されたようです。
結果を開くと…

05

06

おお、jsフル活用な綺麗なレポートが出来上がっています。

さてこのサンプルシナリオではどこで何をやっているんでしょうか。見てみましょう。
シナリオファイルはここにあります。

07

開いてみると…

09

コードはScalaですね。難解では無いので単語で意味が把握出来ると思います。後半部分を読んでみましょう。

execでスタートして、①で具体的なアクセス先が指定されています。「.get(“/computers/new”))」ですから、getリクエストを送っています。
②.pause(1)が何かというと、メソッドチェーンでつながっている次のリクエストまでに1秒待ちますよ、という事です。
③では再びexecでスタートして「.post(“/computers”)」「formParam」が登場します。④はpost時のパラメータです。
このようにpostリクエストも送れます。
⑤はhttpヘッダーの設定です。
⑥でこのクラスに定義されている全てのシナリオをscnでまとめて実行しています。
atOnceUsers(1)というのは1ユーザのアクセスという事ですが、
数字を変えれば当然アクセスを増やして負荷を上げることも出来ます。
この部分のシナリオでは雰囲気としてウェブサイトを訪れたユーザのユースケースに沿ったように
実行されているようです。

実はこのようなユースケースに沿ったシナリオはレコーダー機能で自動作成する事が出来ます。
http://gatling.io/docs/2.2.1/quickstart.html

便利！

2.シナリオを書いてみる

自動作成機能を使っても良いのですが、自分で1からシナリオ作成しても当然OKです。
単純に一つのAPIの負荷性能がどのくらいか調べるなら自分でさっと書けた方が楽です。
サンプルを使ってこんな感じで作成してみました。

10

ちなみにシナリオの置き場はconf/gatling.conf内に、directory.simulationsという項目があるので指定出来ます。
このシナリオでは秒間アクセス数と時間を環境変数から取得して単純にgetリクエストを実行します。
標的はplayのサンプルアプリです。リクエストを受けたらカウンターを表示するようにしてあります。
では実行してみます。

11

シナリオ一覧に作ったシナリオクラスが現れました。では6を選択して発射です。

12

play側で確認してみるとちゃんと発射出来ているようですね。秒間10リクエスト×10秒です。

13
自作シナリオでも当然レポートは出ます。打ち始めがやや重い事が分かります。
ではここからはdocumentを見ながらシナリオをカスタマイズしてみます。

3.便利にカスタマイズする

3-1.Cookieをセットする

以下のようにします。

14

addCookieにCookieオブジェクトを渡して中に値を渡します。
expireやmax ageの指定等設定がある場合はCookieオブジェクトに続けて.with〜と関数が用意されているので利用します。

3-2.パラメータを変数にして色々なパターンを用意したい

パラメータを自分が用意した何通りかの物から貼り付けたい場合です。
ファイルから読み込ませたり、数が少ないならハードコーディング可能です。
以下のようにします。

csvファイルからランダムに使用する場合

15

下のSSがデータファイルの中身です。data.csvとしています。

16

そのファイルをコード内で指定した後(csv(…).randomの部分ですね)、置き換えしたいqueryParamで使っています。
${VALUE}というのはcsvのデータラベルが”VALUE”だからというわけです。
当然カンマ区切りで複数指定して複数の置き換えをする事も可能です。

コード内に書いてしまう場合

17

上記のようにMapで指定します。指定した後はファイルから読み込む場合と同じで、
データラベルの代わりにMapのKeyを使うだけです。

データ指定の最後に付けている.randomは、読んだ如く用意された値をランダムでどれか使ってくれます。
これを.circularにすればデータを順番に読んで最後まで読んだら先頭に戻ります。
ちなみに3-1で紹介したCookieの値にも上記の置き換えは使えます。

3-3.アクセス量をカスタマイズする

基本的にはconstantUsersPerSec(数値)で、これは秒間アクセス数を数値で指定します。
動的にアクセス数を変える事も可能で、よく使うのが以下のようなやり方です。

18

rampUsersPerSecは引数1のアクセス数から引数2のアクセス数に向かって設定時間かけて増加するという事です。
ちなみに増加と書いてありますが減らすように書く事も可能です。
ロングランテストで時間帯によるアクセス数変化をシミュレーションしたい時に使ったりします。
基本的にconstantUsersPerSecとrampUsersPerSecがあれば困る事は無いかと思います。

さて以上を含んだシナリオを最後に動かしてみます。

19
クエリパラメータとしてMapで4つデータを渡しています。.circularなので上から順番です。
それらのレスポンスが200である事をチェックする事を宣言しています(.check(status.is(200))の部分)。
injectionは複数渡す事が出来るので、山なりの負荷になるように、rampUsersPerSecでまず上がり、
次のrampUsersPerSecで最高値から1まで下がります。
環境変数で渡す秒数の半分をそれぞれの時間に当てています。
一方受ける側のplayでは渡ってきたパラメータを単純に標準出力するようにしてあります。
(サンプルコードを少し変えただけなので割愛します)。
結果以下のようになります。

20

21

うまく発射出来ています。playも捌けているようですね。

playのターミナルで出力を見ていると山なりの負荷が掛かっている事が分かるのでちょっと楽しいです(笑)。

さて今回はgatlingの紹介でしたが如何でしたでしょうか。
柔軟なシナリオと綺麗なレポートで良いテストをしてみて下さい。