2009年5月28日木曜日

jmeterで繰り返し作業

検索キーワードでjmeterからこのブログに来る人もあったので、間違いを修正。

WinRunnerで実施していた作業を訳あって、他のツールに乗り換える必要が発生しました。
その候補にJmeterがあったので調査したネタです。

ストーリー
  • 繰り返し実施する作業のパラメータをCSVで保持
  • 実施した結果画面の内容を一覧として別ファイル(CSV)に出力すること。
採用したネタ
  • CSV Data Set Config(パラーメータ読み込み)
  • 正規表現抽出
  • BeanShell(結果ファイル出力)
CSV Data Set ConfigはJmeterを負荷テストで利用する際にもよく利用されていると思います。

CVSRead:一行ごとにスレッドを割り当てる。ループ処理では同じスレッドは同一データのまま。
CSV Data Set Config:一行ごとにスレッドはデータを読み込む
という違いがあるようです。

ファイル内のデータをランダムに読み込んで実行することが出来るようですが、今回は先頭からEOFまで
実施すれば良かったので素直にCVS Data Set Configの機能を使います。

正規表現抽出は通常のアサーションでも設定する内容だと思うのでパス。

結構ハマったのがBeanShell。まず、jmeterには付属していないので別途ダウンロードします。
私はJMETER_HOME/lib/extに入れておきました。

通常のアサーション検証後にBeanShell Listenerとして登録したのですが、
これがjavaの構文そのままでscriptとして動くので起動方法さえ分かれば楽チンでした。
アサーションや、正規表現抽出で取得した値もvarsという変数からアクセス出来るようになってます。

例えば、正規表現で取得した${name}を扱う場合には
System.out.println("val is " + vars.get("name"));
こんな感じで出力が可能です。

scriptを確認したい場合には

java -cp bsh-X.X.jar bsh.Interpreter で
bsh% のプロンプトが出現、そのまま
java -jar bsh-X.X.jarで起動すればterminalが出現するので簡単に確認可能です。

ちなみに対象WEBアプリがShift_JISだったのですが、マルチバイト文字をリクエストする際のエンコードが
うまく行っていなかった
のでここもBeanShellを利用して

パーセントエンコーディングは HTTPリクエストのContent encodingを指定することと、Encode?のチェックボックス
をチェックすることで問題なく対応できました。(追記)
${__BeanShell(new org.apache.commons.codec.net.URLCodec("Shift_JIS").encode("${name}"))}


こんな感じで解決できました。
(jmeterにcommons-codecが付属しているのでダウンロードは不要です)

2009年5月15日金曜日

hudsonに乗り換えました。

継続的統合にmavenとの相性からcontinuumが良いと思っていたのですが、操作感の重さと日本語環境の貧弱さが
如何ともしがたくて、hudsonを試してみました。で、ソッコーで乗り換えました。

  1. 日本語環境で困る事なし。
  2. アプリ環境設定が楽チン。
  3. Ajaxで処理中のログの閲覧が快適。
既にjetty + continuumの環境があるのでwebapp-plusディレクトリにhudson.warを置いてjetty再起動するだけで
簡単に使えました。

以前はjettyのプロセスのためにjettyユーザーを作成していたのですが、continuum起動時に例外が発生するため
やむなく、root権限で起動させていたのですが、hudsonでは問題なくjettyユーザーで起動できたので、権限問題も
クリア出来ました。

定期的なビルドと共にリポジトリに更新があった場合にもビルドしてほしい訳ですが、hudsonでは提供されるREST API
を利用するようです。

apacheのリポジトリの構成をまねっこしている自分のリポジトリでは post-commit スクリプトで以下のように
ディレクトリ構成からプロジェクト名、ブランチを取得してREST APIにアクセスしています。

最後の「delay=30sec」はcommitするサイズが大きいとdelayが十分でなくなって2重でビルドが起動してしまうことが
あったので適当に30秒としています。

selinuxを適応している場合は chcon -t httpd_sys_script_exec_t post-commit でコンテキストの変更を忘れずに。


for ELEMENT in $(svnlook dirs-changed -r $REV /foo/var/repos); do
if [ "$PROJECT" = "" ]; then
PROJECT=$(echo $ELEMENT | cut -d/ -f1)
if [ $PROJECT = incubator ]; then
PROJECT=$(echo $ELEMENT | cut -d/ -f2)
fi
fi
if [ ! -z $(echo $ELEMENT | grep "branches") ]; then
BRANCH=$(echo $ELEMENT | cut -d/ -f3)
break;
fi
done

if [ "$PROJECT" = incubator ]; then
exit
fi
if [ "$BRANCH" != "" ]; then
TARGET="$PROJECT-$BRANCH"
else
TARGET="$PROJECT"
fi

wget -O /dev/null http://domain.jp/hudson/job/$TARGET/build?delay=30sec

2009年5月6日水曜日

abdera 1.0 release

abderaが0.4をリリースした後、ダンマリだったので心配になっていたのですが、そろそろ1.0としてリリースされるようです。
この開発者用のメーリングリストでは次の計画も議題にされていて

  1. Axiomいいんだけど、SOAP関連の依存ライブラリが付いてくるのでAxiom依存をやめよう。
  2. i18n(internationalization)のライブラリをAbdera配下のサブプロジェクトとして独立させよう。
  3. RSS機能を統合しよう。
  4. APIをもっと簡素化しよう。

まだ、決定ではないみたいですが、大体こんな事みたいです。

1番は自前で用意したくなるのはなんとなく理解できますね。

i18nのライブラリは確かに独立しているし、自分でもAbderaを利用したアプリを作ろうとした時にIRIをそのまま
取得して扱うとAbdera依存がすべてといっていいほどに発生してしまうので、取得時にURIに変換してました…
独立してくれるのは喜ばしいことだと思います。

RSS機能の統合も利用者としてはrome以外の選択肢、対抗として考えたときには有効ですよね。
基本的に要素は結構似てる部分があると思うのでAPIを簡素化とうまく協調して実現されることを期待したいです。