Overview
ApacheBench、Tsung等といったら通常、Webサーバのパフォーマンスチューニングや測定する事が多い。
だが、今回はWebサーバよりも経路上に設置したFireWallがどの程度、トラフィックを裁けるかを測るために環境を作ってみた。
とはいえ、HTTPの性能試験なので環境作り自体はWebサーバのパフォーマンス試験とほぼ変わらない。
試験環境
Web Server
- CentOS 6 on VMwareESXi 6.0 x 10
Tsung Master
- CentOS 6 on VMwareESXi 6.0
Tsung Slave
- CentOS 6 on VMwareESXi 6.0 x 10
パフォーマンス試験を行う上で、試験環境がESXi上というのは少々情けないが、
大量のコネクションを発生させる事が目的なので帯域という点におけるNICの性能は殆ど必要としない。
故にこれでやってみた。
How to Install
これについては特筆すべき事はない。
CentOSはepelパッケージを追加すればtsungもそのままyum install でインストール可能だからだ。
# yum install -y epel-release
# yum install -y tsung
Config files
こんな感じで列挙する。
<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd">
<tsung loglevel="notice" version="1.0">
<clients><client host="clients-0013" use_controller_vm="true" maxusers="65000"></client>
<client host="clients-0012" use_controller_vm="true" maxusers="65000"></client>
<client host="clients-0016" use_controller_vm="true" maxusers="65000"></client>
<client host="clients-0015" use_controller_vm="true" maxusers="65000"></client>
<client host="clients-0014" use_controller_vm="true" maxusers="65000"></client>
</clients>
<servers>
<server host="10.0.0.15" port="80" type="tcp"></server>
<server host="10.0.0.17" port="80" type="tcp"></server>
<server host="10.0.0.16" port="80" type="tcp"></server>
<server host="10.0.0.12" port="80" type="tcp"></server>
<server host="10.0.0.20" port="80" type="tcp"></server>
<server host="10.0.0.40" port="80" type="tcp"></server>
<server host="10.0.0.73" port="80" type="tcp"></server>
<server host="10.0.0.18" port="80" type="tcp"></server>
<server host="10.0.0.21" port="80" type="tcp"></server>
<server host="10.0.0.38" port="80" type="tcp"></server>
<server host="10.0.0.37" port="80" type="tcp"></server>
<server host="10.0.0.36" port="80" type="tcp"></server>
<server host="10.0.0.35" port="80" type="tcp"></server>
<server host="10.0.0.34" port="80" type="tcp"></server>
</servers>
<load>
<arrivalphase phase="1" duration="5" unit="minute">
<users arrivalrate="1" unit="second"></users>
</arrivalphase>
</load>
<options>
<option type="ts_http" name="user_agent">
<user_agent probability="100">Tsung traffic checker</user_agent>
</option>
<option name="connect_timeout" value="15000" />
<option name="max_retries" value="0" />
</options>
<sessions>
<session name="http-example" probability="100" type="ts_http">
<for from="1" to="5500.0" var="i">
<request>
<http url="/sample/session_file.dump" method="GET" version="1.1" >
<http_header name="Connection" value="close"/>
</http>
</request>
</for>
</session>
</sessions>
</tsung>
セッションファイル自体は、1秒も掛からず終わるサイズ(4kb)で作成してある。
これで「毎秒1ユーザ、5500リクエストが5分間」継続するはずである。
Result
サーバの処理能力が追いつけば、毎秒1ユーザ（5500リクエスト）がどこかのサーバに接続されると共にsession_file.dumpファイルがダウンロードされるだけで、すんなり試験が終わるはずである。
…が3時間経った今も終わらない。
おまけに、サーバのログを見ると「1500万行近くどのサーバも記録されている」。
毎秒5500リクエストを5分間（300秒）と言うことは1650万リクエストが飛ぶので、1500万行のログが出ること自体は驚くに値しないのだが、「10台全てのサーバで1650万行」出るのだとしたら想定していた挙動と違う。
1リクエストで複数のコネクションを張っているという事もあるが、このファイルは別にリンクや画像を埋め込んだ複合的なコンテンツではなく、かつファイルサイズも極限まで小さい物である。
いったいどうしてこうなってるのだろう…？
追記
原因は 5500.0 の小数点の模様。途中で止めたときのログからいっても無限ループになっていた。
当たり前と言えば当たり前か。Ansibleのjinja2フィルタで base_num * X という形で生成していたのだが、1.5みたいなかけ方をしていたので小数点が入ってしまったのが敗因。
5500と、ちゃんと整数にしたら止まった。