まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:load

IBM Bluemix のサードパーティサービスの1つである Load Impact を紹介します:
2015092400


このサービスは単純にウェブサイト/ウェブサービスに負荷をかけて、その時のパフォーマンスを測定するサービスです。負荷をかける対象は Bluemix 上のランタイムでも、そうでなくても構いません。


Load Impact サービスは Bluemix 上では "DevOps" カテゴリに分類されています。このサービスは特定のランタイムにバインドして利用するものではないので、カタログページから直接選択して追加することで利用可能になります:
2015092401


Load Impact サービスの説明ページです。"Free"(無料)利用の条件が表示されているので確認して追加してください:
2015092402


Load Impact サービスを追加した後、ダッシュボード画面から追加した Load Impact サービスを選択すると、このような画面が表示されます。"OPEN LOAD IMPACT DASHBOAD" と書かれた箇所をクリックして、Load Impact のダッシュボード画面に移行します:
2015092403


サービスを利用するには最初にログインする必要があります。ここでは新規にアカウントを作成することもできますし、既にアカウントをお持ちであればそれを指定することもできますし、また Google や Github といったソーシャルサイトのアカウントをお持ちであればそれらとの OAuth を使ってログインすることもできます。お好きな方法でログインしてください:
2015092404


ログイン直後にこのような画面が表示されるはずです。この画面をスキップして詳細なテスト設定を行うこともできますが、まずはこの簡易機能を使ってテストしてみましょう:
2015092405


今回、テストする対象はこちらのサイトとします(皆さんがお作りになったサービスを指定しても構いませんが、他の方が作ったウェブサイトの URL を勝手に指定することはご迷惑をかけることになりかねないので控えてください):
http://fx.mybluemix.net/
2015092406


このサービスは先日、私が作って紹介したリアルタイム為替情報の REST API サービスです。IBM Bluemix 上で動いています。一般的には「ウェブサイト/サービスはリクエストからレスポンスまで2秒待つと、ユーザーは長く感じる」と言われているので、レスポンスタイムが2秒を確保できているかどうかをテストしてみたいと思います。また最大同時接続ユーザー数は30を想定します(つまり30ユーザーが同時にアクセスしてきても、このサービスは2秒以内にレスポンスを返せるか?をテストで計測する指標とします)。

では、このサービスの URL(http://fx.mybluemix.net/) を URL フィールドに入力します。同時に最大接続ユーザー数(Max VUs)を "30" に、Duration(mins) を "3" にします(つまり3分間で30ユーザーのテストをする、という指定をします)。最後に "Run test" と書かれたボタンをクリックして、テストを開始します。作業はこれだけ、簡単ですね:
2015092407


しばらくするとテストが始まります。最初に同時接続(仮想)ユーザーの準備を行います:
2015092401


テストが始まると、このサービスを提供している場所(バージニア州 Ashburn)から、目的のサーバー(下図ではテキサス州 Dallas)までの地図が表示されます。このレイテンシーがテスト結果に影響することを考慮してください:
2015092402


またテスト途中までの結果も順次表示されていきます。少しずつ接続ユーザー(青)を増やしながら、それぞれの回でどれくらいのレスポンスを実現できたのか(緑)が分かります:
2015092403


今回の設定ではテスト開始から3分後に最大接続ユーザーのテストが行われ、その後少しずつユーザーを減らしてテストが終了します。終了すると左上に "Finished" と表示されます:
2015092404


画面を下にスクロールすると、最終テスト結果がグラフ表示されています。一瞬危ういテスト回もありましたが、どうやらこのサービスは30ユーザー程度であれば、2秒どころか1秒以内にレスポンスを返せることがわかりました。リアルタイム性を重視するサービスなので、これは一応合格だと思います。さすが Bluemix 、という所?
2015092405


更に下にスクロールすると、更に細かなテスト結果も表示されています。ほぼ何の準備もせずに、URL と最大接続ユーザー数の指定をしただけで、このレベルの負荷テストが実現できた、ということがわかります:
2015092406


Load Impact はもっと細かなテスト項目の指定などもできますが、そこまでしなくてもある程度の負荷テストが実現できるツールです。Bluemix のようにアジャイルに機能を追加してアプリケーションを開発できる環境ですと、ついつい変更による負荷の影響を忘れがちになってしまいますが、そのようなことがないように Load Impact サービスを1つアクティブにしておくといいかもしれません。


Apache jMeter を使ったウェブサイトの負荷テストの手順を一通り紹介します。


今回の紹介するシナリオでは、以下の目的および前提でテストを行います:
(1) ウェブサイトは(一応)完成している
(2) ユーザーの想定挙動(「トップページを見て、検索をして、検索結果ページをいくつか閲覧して、・・」という導線)は決まっている
(3) 1つのページあたりのユーザーレスポンスタイム(ユーザーがそのページを開き始めてから反応が返り切るまでの時間)を3秒以内にしたい
(4) この条件で、1秒あたりに何ユーザーのアクセスまで耐えられるシステムなのかを測定したい

アプリケーションのテストには色々な種類がありますが、今回は上記のように「どれだけのユーザーアクセスにまでは耐えうるシステムなのか」を検証するテストを行います。そしてそのようなテストではこの Apache jMeter は便利です。


まずは Apache jMeter をインストールします。jMeter は Pure Java アプリケーションのため、前提として Java の実行環境が必要になります。JRE または JDK を導入して、実行可能な状態にしておいてください。その上で公式サイトから Apache jMeter の最新版バイナリをダウンロードし、展開します。展開後、jMeter の起動ファイル(Windows であれば bin/jmeter.bat)を実行して、jMeter を起動します:
2014102701


次に、このテスト計画にスレッドグループを追加するのですが、その前に今回のテスト目的をおさらいします。一覧のページビューにおいて、そのユーザーレスポンスタイムを3秒(この数字は変更しても構いません)以内にする前提で、1秒あたりに何ユーザーのアクセスまで耐えられるシステムなのかを測定したい、というものでした。 

というわけで、今回のテストでは、あるユーザーシナリオを元に、最初は1ユーザーで実行、次に2ユーザー同時に実行、その次は3ユーザー同時に、、、、と少しずつユーザー数を増やしていきながら、(例えば)20ユーザー同時にアクセスするところまでを実行して、それぞれのページビューアクションでのレスポンスタイムを計測する、という流れになります。そして(今回の場合であれば)3秒以内のレスポンスを期待できるのは何ユーザー程度の同時アクセスまでか、を調べることになります。

つまり今回のテストでは最初は1ユーザーでアクセスし、1分後に1ユーザー増やして2ユーザーでアクセス、更に1分後に1ユーザー増やして3ユーザーでアクセス、、、といった具合に1分ごとにユーザー数(ユーザースレッド)を増やして負荷を加えていきます。そして開始から19分後に20ユーザーでの同時アクセスとなり、ここでのレスポンスタイムを計測して終了、というテストを行います。 なお、1ユーザー増やすタイミングを1分後にする必要はありませんが、後から結果を確認しやすい(開始から何分経過したかで何ユーザーでのアクセスかを推測できる)のでこのようなテストシナリオにしています。

ではこのテストシナリオに従ってスレッドグループを定義します。jMeter の「テスト計画」と書かれた箇所を右クリックして、 追加 > Threads(Users) > スレッドグループ を選択します:
2014102702


テスト契約の下にスレッドグループが追加されます。これをクリックして選択し、以下の内容を入力します:
 スレッド数: 20
 Ramp-Up期間(秒): 1200
 ループ回数: 無限ループ
2014102703


スレッド数はユーザー数です、なので20。Ramp-Up はこの20スレッドをどれだけの時間かけて生成するか、という期間の数字です。今回は1分毎に1スレッドずつ、20スレッドまで増やしていくので 60 x 20 = 1200(秒)を指定します。そして各スレッドは無限に処理を繰り返し実行してほしいので、ループ回数は「無限ループ」を指定しています。

次に、各ユーザースレッドで実行する内容を定義します。「スレッドグループ」を右クリックして、 追加 > サンプラー > HTTPリクエスト を選択します。
2014102704


HTTP リクエストが追加されたら、その中身を実際のテストシナリオに合わせて変更します:
 名前: 何のアクションが分かる名前に変更(どのアクションに時間がかかっているのかを区別できるように)
 サーバー名: テスト先アプリケーションサーバー
 ポート番号: テスト先アプリケーションサーバーのポート番号(80の場合は省略可)
 パス: アクセスする URL のサーバー名以降の部分
2014102705


HTTP リクエスト1つがユーザーの1回のアクセスを定義します。「このページを見て、次にこのページを見て、その次にこのページを見て、・・」のように複数のページを巡回するシナリオで計測する場合は、必要なだけこの HTTP リクエストをスレッドグループに追加していきます。この例では4つのページを巡回するシナリオを定義しています:
2014102706


テストシナリオの定義はこれで終わりです。最後に結果を一覧表で確認できるようにします。スレッドグループを右クリックして 追加 > リスナー > 結果を表で表示 を選択します:
2014102708


これで最小限必要な設定ができたので、メニューから ファイル > テスト計画を保存 を選択して、このテスト計画を保存します。

テストの実行はメニューから 実行 > 開始 を選択するだけです。実行中に「結果を表で表示」をクリックすると、次々に実行されるテストの結果を参照することができます:
2014102707

この "Sample Time(ms)" 列が各アクションのレスポンスタイムになります。スレッドが増えていった時にこの数値がどのように増えていくのかを参照することで(今回の例であれば3秒以内に収まっているかどうかを確認することで「どの程度の同時アクセス数までは期待通りのパフォーマンスを維持できているか」を調査していくことになります。












 

このページのトップヘ