一筋縄ではいかなかった Microsoft WCat(Web Capacity Analysis Tool) 6.3(x86)

とある事情で、とある Web アプリケーションに、同時にたくさんのリクエストを仕掛けて、クラッシュしたりしないかどうか、実験してみることになった。

ということで思い出したのが、Microsoft がリリースしている無償利用可能な負荷ツール「Web Capacity Analysis Tool」、略して WCat。
設定ファイルやシナリオスクリプトをテキストエディタで記述し、それを読み込ませて動作する、コマンドラインから使うコンソールアプリとなっている。

このへんとかが参考になる。

[HOW TO] 無償の簡易 Web 負荷ツール WCATの使い方
http://bit.ly/9CXTec
（@hirookun さんの IIS フォーラムの投稿）

そこで、早速、WCat を利用して実験してみることにした。

しかしながら、なかなか一筋縄ではいかなかったので、その顛末を以下に記しておく。

WCat の最新バージョンは2010年9月6日現在、6.3 っぽい。
32bit 版は下記からダウンロードできる。
http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1466
もちろん、64bit 版もある。
http://www.iis.net/downloads/default.aspx?tabid=34&i=1467&g=6

今回は諸事情で 32bit 版を使用することに。

WCat は「簡易 Web 負荷ツール」とはいえ、なかなかどうして多機能。
単に負荷をかけるっていうんじゃなくて、パフォーマンスモニタも含めて監視、ロギングしたりできるらしい。
おまけに、ボット的に、中央制御の PC からたくさんの PC にチャイルドプロセスを配布し、こいつらをリモートで起動して、Web サーバーに負荷をかけることができるようになっている。

今回はそこまで凝った使い方はせず、単一のクライアント機だけで、ほどほどのリクエストを送信するようにした。

さてこの WCat だが、Web サーバーと WCat の間に HTTP プロキシがあると使えないっぽい。
付属の Word 文書によるマニュアルを読んでも、settings.ubr にてプロキシの設定を行う設定構文はなさそう。
無理を承知で色々試してみたが、ついにプロキシを超えての実行はできなかった。

まぁ、ストレステストの性質上、間にプロキシが挟まっていると、Web サーバーの負荷テストをしているのか、プロキシの負荷テストをしているのかわからなくなってしまう。
それに、パフォーマンスモニタの監視なども同時に行える WCat の特徴を考えると、妥当な制限かもしれない。

次に、対応しているプラットフォームだが、上記ダウンロードサイトでは、Windows Vista までとの記述になっている。
だが、まぁ、Vista で動くのだから当然と言えば当然だが、Windows 7 Pro(x86) で動作することを確認。

SSL でも問題なし。
home.ubr 側でシナリオを記述するところで、 request { ... } のブロック内に secure = true; の行を書き足しておけばOK。

ところが、どういうわけかはわからないのだが、Hyper-V2.0 上に新規インストールした Windows 7 Pro(x86) 仮想マシンで実行すると、アプリケーションエラーが発生してしまう。
ネットワークアダプタをレガシーにしてみるとか、いろいろ試行錯誤したのだが、どうやってもうまくいかない。

仮想マシンではなく、実機では動作しているので（しかも、まったく構成の異なる2台で成功）、仮想化となにか関係があるのだろうか?
しかしほかの原因が皆無とは言えないので、断言はできない。

さて、同じ Hyper-V2.0 サーバーに、今度は Windows XP Pro SP3(x86) を新規インストールし、統合サービスもセットアップした上で、WCat を試してみた。
するとこちらは成功。
うーん、何なんでしょう。


ところで、実は、Windows XP Pro(x86) 上で WCat をインストール & 動作させるにはコツが要った。

まず、インストーラによるセットアップ作業そのものは問題ない。
問題はそのあと。

WCat では、インストールされた wcat.wsf にパラメータをつけて実行することで、チャイルドプロセスをたくさんの PC にコピーし、いよいよ実行のときにそれら PC 上のチャイルドプロセス群を起動するのに備える（ボットのように）。
今回はクライアントは中央制御機と同じ1機しかないので、この作業を readme.txt に従って次の構文で試してみた。

cscript wcat.wsf -terminate -update -clients localhost

ところが、「パス \\localhost\admin$ が見つからない」的なエラーとなってしまう。

なるほど、たしかに、この WindowsXP 環境では、エクスプローラのアドレスバーに「\\localhost\admin$」と入力しても、その PC 自身は参照されず、"見つからない" エラーとなる。
この WindowsXP 仮想マシンのコンピュータ名が "MyPC1" だとすると、「\\MyPC1\admin$」ならば、ちゃんと成功するので、ネットワーク構成がおかしいわけではなさそう。当然、書き込みもできるので、共有のアクセス権が足りないとかそういう問題でもなさそうである。
ちなみに Windows 7 では、「\\localhost」でちゃんと自身が参照される。

ということで、-clients スイッチに、"localhost" ではなく、きちんと自身のホスト名を書いてやってみた。

cscript wcat.wsf -terminate -update -clients MyPC1

これなら成功。

さて次は、settings.ubr や home.ubr を用意したら、いよいよ実行だ。
というわけで、次のコマンドラインを実行。

cscript wcat.wsf -terminate -run -clients MyPC1 -t home.ubr -f setting.ubr

しかししかし、またしても「パス \\localhost\admin$ が見つからない」的エラーとなる。
えぇ、なぜ?
ちゃんと -clients スイッチに、ホスト名で指定しているのに。

途方に暮れたので、wcat.wsf をテキストエディタで開いてみた。

するとなにやら匂う記述を発見。
wcat.wsf に次の一行が。

var CLIENT_COMMAND_LINE = "\\\\localhost" + TARGET_SHARE + "wcclient.exe";

ロジックをよく見たわけではないが、"localhost" で検索すると、どうにもここが怪しくてしようがない。
変数名も、ズバリ CLIENT_COMMAND_LINE だし。

ということで、ここをズバリ "MyPC1" と書き換えて保存。

var CLIENT_COMMAND_LINE = "\\\\MyPC1" + TARGET_SHARE + "wcclient.exe";

これで実行してみると、ようやく成功した。

　　◇　　◇　　◇　　◇

さて、ちょっと話しは変わって。

WCat は無償利用ながら、先に述べたとおりかなり秀逸なツールである。
（GUIがないので、ある程度理解するまで扱いづらいが）

ただ、パフォーマンスモニタの監視とか、ボット的に多数のクライアント機を中央から起動とか、そこまで凝った使い方ではなく、単にちょっとかるーく負荷をかけてみたい、というときに、WCat は Windows 用のコンソールアプリなので、Windows のライセンスが必要になるのが今回はちょっと厄介だった。
幸い今回は、社内で未使用だったライセンスがあったのでそれを一時借りてしのぐことができたが。

今回の程度の実験なら、Linux 上でも動作する、Apache に付属の "ab" ( Apache Bench ) というツールがあるとのこと。
Linux の適当なディストリビューションを利用して ab を使うのも一案かもしれない。
自分は ab は使ったことがないので、今後の宿題。