kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Visual Studio Team Servicesの負荷テストをCI/CD時に実施する-JMeter編(19日目)

今日は追い込まれたので手抜きです(でも予定通りです)。

はじめに

VSTSの負荷テスト機能はVisual Studioだけではなく、Apache JMeterも対応しています。以前も少し紹介しましたが、多少強化されています。

kkamegawa.hatenablog.jp

制限事項

www.visualstudio.com

  • JMeter 3.1をサポートしているという記述を見つけられません。一応試してみたのですが、Cookie Managerでエラーが出てしまいます。
  • HTTPリクエストのみサポートです。
  • 要素名に日本語を使わないほうがいいです。
  • Graphなどのビジュアルを持つリスナーは使わないでください。

設定

Jmeter 2.13で設定します。

f:id:kkamegawa:20161219220916p:plain

グラフィカルなリスナーを除外します。ちょっと色々試行錯誤しているのですが、最後の結果表示がうまくいっていません…。

f:id:kkamegawa:20161221055537p:plain

(2016/12/20追記)
JMeterのThreadGroupの設定で、ループ回数を指定していると思いますが、「無限ループ」にチェックしてください。これを設定しないと、VSTSの負荷テストが指定回数で打ち切ってしまうので、正しくグラフが出るほど回数が実施されません。

f:id:kkamegawa:20161219220914p:plain

Load TestからApache JMeter testをクリックします。

f:id:kkamegawa:20161219220917p:plain

jmxファイルを指定します。

  • Supporting files:動的に変更するパラメータファイルを指定します。
  • Number of agents:同時に負荷をかけるエージェント数です。1エージェントで最大25userが同時にアクセスできるそうです
  • Load duration:アクセスする時間です。
  • Load location:実行するAzureデータセンターです。

ライセンスの計算は公開されていますが、1分であったとしても、最低250vuserが消費されるようです。

CI/CD時に実施する

f:id:kkamegawa:20161219220913p:plain

ビルドタスクにJMeterがあるので、追加します。

f:id:kkamegawa:20161219220915p:plain

  • VS Team Service Endpoint:昨日紹介した方法でVSTSへのアクセスエンドポイントを指定します。
  • Apache JMeter test files folder:jmxファイルが入っているリポジトリのフォルダ名を指定します。
  • Apache JMeter file:jmxファイルをパスなしで指定します。
  • Agent count:同時に使用するagent数です。
  • Run Duration:実行時間です。なぜかここでは2分という設定ができます。

結果

f:id:kkamegawa:20161219220912p:plain

結果ファイルはDownload ResultsでCSVとしてダウンロードできます。本当はVSTSでも見えるはずなのですが、なぜかうまくいっていません…もうちょっと調べます。

(2016/12/20追記)前述のとおりうまくいきました。 f:id:kkamegawa:20161220214937p:plain

指定した分数の負荷がかかっています。JMeterのThread数がVSTSではUSER LOADに相当しています。

f:id:kkamegawa:20161220214938p:plain

chartでもちゃんと出ています。

f:id:kkamegawa:20161219220918p:plain

Azureの方でも負荷はかかっています(Application Insights設定忘れ…)。

f:id:kkamegawa:20161218204630p:plain

ビルドもこんな風に成功しています。SSL関係でエラーが出ているようですが…。

まとめ

超手抜きですが、一応AzureデータセンターからJMeterでも負荷テストがかけられます。3.1に本当に対応しているのかとか、FTPもサポートして欲しいとか、色々要求はありますが、どうなっているのか、少し確認してみます。

(12/21追記)
やはりまだJMeter 3.xには対応していないようです。UserVoiceでも要求が出ているので、voteしてみてください。2.13で作ったjmxを編集してもうまく動くことは動くようですが、保証はできません。

How can we improve Team Services?
  • 11 votes
  • 1 comment

Support jMeter 3.0

Please upgrade support for jMeter load tests to support the latest version.

Right now, the supported version for jMeter test scripts in Visual Studio Online is v2.13 (c.f. https://www.visualstudio.com/en-us/docs/test/performance-testing/getting-started/get-started-jmeter-test#jmeter-tests).

...

visualstudio.uservoice.com

Visual Studio Team Servicesの負荷テストをCI/CD時に実施する(18日目)

はじめに

昨日は単体で実施する負荷テストを紹介しました。たまにやる分にはGUIでちまちま実施しても構いませんが、どうせなら継続的インテグレーション(CI)や継続的デプロイ(CD)に組み込みたいものです。

VSTSのビルドタスクにはVSTSのLoad Testを呼び出す機能があります。今日はそれを紹介します。

負荷テストプロジェクトを登録する

負荷テストのひな型を入手する

f:id:kkamegawa:20161218203954p:plain

VSTSのCI/CDで負荷テストを実施するにはまずロードテストソリューションを登録します。最初から作ってもいいのですが、せっかくなので、GUIで作ったテストをそのまま使いましょう。

Load Testの結果から"Export test to Visual Studio"をクリックすると、負荷テストのソリューションがzipファイルで入手できます。いつも通り右クリックから「ブロックを解除」(もしくはPowerShellでunblock-fileコマンドレット)してから開きます。

f:id:kkamegawa:20161218203956p:plain

ソリューションを開くとこんな感じで負荷テストの設定が一式入っています。

f:id:kkamegawa:20161218203957p:plain

LoadTestProjectを開くとこんな感じでシナリオやWebテスト、負荷をかけるデータセンターの設定が入っています。特に事情がない限り、変更する必要はありません。

Visual Studioで負荷テスト結果を参照する

ちょっと話がずれますが、負荷テストソリューションを開くと、Visual Studio内にロードテストという項目ができます。

f:id:kkamegawa:20161218203958p:plain

ロードテストメニューの「ロードテストマネージャー」を開くと、VSTSで実施したロードテストの結果が見えます。

f:id:kkamegawa:20161218203959p:plain

調べたい結果をクリックするとVisual Studio内で結果が確認できます。Performance,Throughput, Applicationのログが確認できます。

f:id:kkamegawa:20161218204000p:plain

Throughputもこのように確認できます。Applicationを調べるにはMonitoring Agentが必要なので、App Serviceそのままでは確認できません。

ソリューションを追加する

f:id:kkamegawa:20161218204001p:plain

開いた負荷テストソリューションはもちろんソース管理の対象にできます。ここではチームプロジェクトのGitリポジトリに登録します。

f:id:kkamegawa:20161218204002p:plain

こんな風にWebサイトのプロジェクトと同じリポジトリで管理してみました。負荷テストを設定する都合上、同じチームプロジェクトであれば、異なるリポジトリでもOKです。

VSTS負荷テストをCI/CDで呼び出せるように設定する

f:id:kkamegawa:20161218204003p:plain

VSTSのビルドパイプラインで負荷テストを呼び出せるようにするには、サービスのエンドポイントに登録しなくてはなりません。まずはPersonal Access Tokenを設定します。All scopeで構いません。APIKEYはなくさないようにしましょう。

f:id:kkamegawa:20161218204004p:plain

ServicesからNew Service Endpointをクリックします。Genericをクリックして、以下の指定をします。

  • わかりやすい名前
  • Server URL:自分のVSTSのホスト名
  • User Nameには管理者のアカウント名
  • Token Keyには先ほど作ったAPI KEY。

ビルド定義に追加する

簡単なURLテスト

f:id:kkamegawa:20161218204006p:plain

ビルドもしくはReleaseのタスクにCloud-based Web Performance Testを追加するとCI/CDでURLへのアクセステストができます。例えば、デプロイして特定のURLに一定数のユーザーがアクセスしても例外が起きているかどうか、という用途に使えます。

  • VS Team Services Connection : Servicesで追加したエンドポインt
  • Website Url : アクセスするURL
  • Test Name : テスト名
  • User Load : ユーザー数
  • Run Duration : 実行時間
  • Load Location : アクセス元データセンター
  • Run load test using : 負荷テストをかけるのを自動管理か自前管理か

f:id:kkamegawa:20161218204007p:plain

ビルドをキューに入れるとこんな感じで結果が出ます。アクセス例外が出なかったので、ビルドが成功したことになっています。

VSTSの負荷テストをビルド時に実施する

次はVSTSの負荷テストと同等のテストを実施します。毎回ビルド時に実施すると時間がかかりすぎるので、工夫が必要になります。

例えば、特定のスケジュールでリリースする前に実施するとか、不定期にブランチを作って、そのブランチを検証用の環境にデプロイしてやってみるとか、といった感じでしょうか。

f:id:kkamegawa:20161218204632p:plain

ビルドタスクを作ってみました。負荷テストソリューションをビルドして、publishしてから、Cloud Load Test タスクを実行します。

  • Test settings file:ソリューション内にある拡張子testsettingファイルです。VSTSが作ったものであればCloud.testsettingというファイルです。
  • Load test files folder:負荷テストソリューションがあるフォルダ名です。
  • Load test file : 負荷テストシナリオを登録しているWeb Performance Testプロジェクトです。VSTSが作ったものであれば「テスト名+WebTest.loadtest」となっています。
  • Number of permissible threshold violations : 何回以内の例外であればOKとみなすかという判定です。

f:id:kkamegawa:20161218204630p:plain

ビルドログでは例外が3回だったので、問題ないと判定されます。

f:id:kkamegawa:20161218204631p:plain

ということでビルドも成功しました!

まとめとRelease Managementでの補足

VSTSの負荷テストをCI/CDで実施できるのは定期的に負荷テストをかけたいというシナリオにおいてとても便利です。特に大きな改造をした場合は、ビルドやリリースタスクに追加しておくといいでしょう。

今回リリースでの組み込みは(時間の関係でw)実施しませんでしたが、コツとしては変わりありません。

必ずビルド時のartifactsに負荷テストソリューションを追加しておかないと、Release Managementで負荷テスト実施のシナリオが参照できないという点に注意してください。

Visual Studio Team Servicesを使ってWebサイトの負荷を簡単に計測する(17日目)

はじめに

Webサイトをリリースして、著名なメディアに取り上げられるなどの何らかの事情で、突発的にアクセスが増えてダウンした、ということはよくあります。そういうことがなくても、導入の要件で最低アクセス人数を指定されているということもよくあります。

Visual Studioの負荷テスト機能をはじめ、Load Runnerなどの商用製品やjmeterのオープンソースのツールを使うこともあるでしょう。VSTSはクラウドサービスらしく、Azureのデータセンターから負荷をかけるという機能があります。

何度か@ITなどで紹介したこともありますが、さらに進化を遂げています。今日は簡単なURLを指定して負荷をかける機能を紹介します。

URLベースのシナリオを作成する

f:id:kkamegawa:20161216202634p:plain

Load Testをクリックすると、初期画面が表示されます。今日紹介するのはURLとhttp archiveです。

f:id:kkamegawa:20161216202633p:plain

右から二番目にあるURLの下にあるCreate testをクリックすると、シナリオ作成画面になります。

アクセスをかけるURLおよび、httpヘッダ、クエリパラメータを指定します。

f:id:kkamegawa:20161216202636p:plain

こんな風にトップページ、About, ContactのURLを順番にアクセスするというシナリオを作りました。

f:id:kkamegawa:20161216202637p:plain

Settingsで負荷の設定を行います。

  • Run duration:負荷をかける時間です
  • Load pattern:均等にかける(Constant)、徐々に上げる(step)
  • Max vusers:シナリオにおける最大ユーザーです。20000ユーザー/月まで無償で実行できます。ただし、負荷の時間によって、25×実行時間でユーザー数を消費します。ちなみにこのパターンでは250ユーザーを消費します。
  • warmup duration:負荷をかけるまでの待機秒数です
  • Browser Mix:ChromeとIEのアクセス比率を指定します。
  • Load location:どのデータセンターから負荷をかけるかという指定です。東京と大阪も指定できます。

f:id:kkamegawa:20161216202638p:plain

負荷をかけるとこのような結果が表示されます。chartをクリックすると、グラフで表示されます。

f:id:kkamegawa:20161216202639p:plain

性能、スループット、エラー数が表示されます。

f:id:kkamegawa:20161216202640p:plain

Diagnosticsでは発生した例外、情報が表示されます。これはAzure App ServiceのBasic B1で動いているので、CPUが1つです。Basic B2の2CPUに変更して同じ負荷をかけてみます。

f:id:kkamegawa:20161216202641p:plain

f:id:kkamegawa:20161216202642p:plain

数値とグラフも変わっています。

f:id:kkamegawa:20161216221257p:plain

しかし、このような数値だけではわかりづらいですね。そういうときのために設定前後の実行結果を選択して、"Compare two runs"をクリックすると、チューニング前後で比較できます。

f:id:kkamegawa:20161216202643p:plain

baseline(最初に取得したデータ)と現在のデータで比較して、どのくらい負荷が減ったか一目でわかります。

…減ったと言いたいところですが、App Serviceのスケールを変えた後の再起動後の初回起動で性能が悪化してますね(^^;。負荷テストのときはこういうことがあるので、気を付けてください。

ブラウザのリクエストをそのまま使用する

har(HTTP archive)を取得する

負荷テストのリクエストの作成はいつも結構苦労します。fidderでキャプチャして、リクエストを見ながらということが多いのではないでしょうか。

VSTSの負荷テストではブラウザが発行したリクエストを保存して転用する機能があります。

f:id:kkamegawa:20161216202635p:plain

Chromeのf12ツールのネットワークタブでリクエストを右クリックして、「生を付けて保存」すると、該当リクエストをharファイルとして保存できます。

f:id:kkamegawa:20161216202644p:plain

Edgeでも同様にf12開発者ツールで保存できます。

HTTP Archive based testを作成

f:id:kkamegawa:20161216202645p:plain

Newから"HTTP Arvhice based test"をクリックします。 f:id:kkamegawa:20161216202647p:plain

ダイアログが表示されるので、保存したharファイルを指定します。 f:id:kkamegawa:20161216202649p:plain

リクエストが追加されます。追加されるリクエストは外部のCDNなども入っているので、不要なリクエストは消してください。

f:id:kkamegawa:20161216202648p:plain

こんな風に同じリクエストが作れました。http headerとかQueryStringも入るので、便利です。ただし、リクエストごとに保存して追加という手順を踏まないといけないんですかね?この辺は拡張機能か何かあってもよさそうに思いますが…。

自動的にリダイレクトするようなサイトだと難しいかもしれませんが、自分でヘッダやQueryString設定しなくてもいいのは便利だと思いますので、使ってみてください。

Visual Studio Team Servicesで顧客に手軽にフィードバックを入力してもらう(16日目)

はじめに

フィードバックがほしい、とお願いしても、VSTSのWeb UIに不慣れな人ではなかなかチケットを作ってもらうことは難しいです。もう少し気軽にフィードバックするための仕組みとして、VSTS/TFSには専用のフィードバッククライアントが用意されています。

フィードバッククライアントそのものは無償で使えるので(VSTSの接続ユーザーにも入りません)、気軽に試してもらう場合有効です。

フィードバックをお願いする

ダッシュボードの設定

f:id:kkamegawa:20161216012214p:plain

ダッシュボードにあるRequest feedbackというリンクをクリックすればいい…のですが、ダッシュボードに存在しないことがあります。

このような場合、ダッシュボードを編集して、Other Linksというボックスを選択して、Addで追加します。

f:id:kkamegawa:20161216012215p:plain

Other Linksが追加されたので、Request feedbackをクリックして、フィードバックのお願いを開始します。

フィードバック依頼

f:id:kkamegawa:20161216012216p:plain

まず、フィードバックがほしいStakeholder(利害関係者)をSelect Stakeholderで選択します。

f:id:kkamegawa:20161216012217p:plain

次に、試したいアプリケーションの種類を選択します。ここではWeb Applicationを選び、URLを指定します。Stakeholderではクリックすればそのまま開くので、手間がかかりません。

注意してほしいことなどがあれば下に捕捉します。

f:id:kkamegawa:20161216012218p:plain

フィードバックがほしい項目について一つずつ記載します。Add Itemをクリックすると、要求項目が増えます。ここでは2件のフィードバックを依頼しました。

f:id:kkamegawa:20161216012219p:plain

選択した人のところにはこのようなメールが届きます。フィードバッククライアントをインストールしている場合、Start for feedback sessionをクリックすれば始まります。

そうでない場合は、install the feedback toolをクリックします。

f:id:kkamegawa:20161216012220p:plain

こんな風にクライアントが起動するので、インストールしてください。

フィードバック開始

f:id:kkamegawa:20161216012222p:plain

指示内容とURLを確認して、「次へ」をクリックします。

f:id:kkamegawa:20161216012223p:plain

フィードバック依頼項目が二つあるので、1と2を確認します。

f:id:kkamegawa:20161216012225p:plain

項目1のUIについては悪くないので、そのまま「悪くないね」というコメントと、評価(問題なかったので★5)を記載しています。

フィードバックのとき、基本的に問題なければ一番いいレートにしておくと、受け取る側のモチベーションにもつながります。ダメだったらダメでいいのですが、どこがどういう風にダメだったか、あるいは改善してほしいか、ちゃんと書きましょう。

f:id:kkamegawa:20161216012224p:plain

フィードバック項目2ではAbout画面がデフォルトのままだったので、スクリーンショットの添付と、コメント、ダメだったので、★1を付けています。

★1は致命的で、業務上どうしようもないところとかにつけるといいでしょう。

f:id:kkamegawa:20161216012226p:plain

フィードバックの結果が問題なければ、「送信して閉じる」をクリックします。

開発側

f:id:kkamegawa:20161216012221p:plain

フィードバックはWorkのQueriesから確認できます。自分が送ったフィードバックはAssign to meで見えますし、チーム全体のフィードバック項目をみたければ、Shared Queriesにある、feedbackを選べばチーム全体に送られてきたフィードバック項目が全部確認できます。

まとめ

フィードバッククライアントは無償で使えるし、簡単に画面上のここというところを指示できるし、開発側もフィードバックというカテゴリーで一元管理できるのでとても便利だと思います。

ぜひ使ってみてください。