今日もWEB負荷テスト

今日も一日客先でWEB負荷テストでしたので、またまたWEB負荷試験の話題くらいしかかけないのですが、午前中にシナリオを取り直し、午後に23パターンの試験を行いました。なかなかハードでした。。

WEB負荷テストで確認したいポイントは様々で、それに応じてテストの方法も変える必要があります。

通信経路への負荷
・できるだけ測定したいポイントに近い箇所に負荷発生装置を接続する
・HTTPの厳密な測定というよりは、とにかく高負荷をかける
・ソースIPアドレスが異なることが大事な試験もある
・負荷発生装置側のボトルネックにも注意

WEBサーバへの負荷
・負荷を段階的に発生させる
・それぞれの負荷状態で、レスポンスタイムを測定する
・それぞれの負荷状態で、体感速度も確認する
・WEBサーバ側のCPU負荷・メモリー使用量などを観察する

システムのサイジングの判断
・想定ユーザ数・ユーザの操作に似せた負荷をかける
・レスポンスタイムやサーバの負荷状態を観察する

DBサーバへの負荷
・DBアクセスを伴うコンテンツを対象に負荷をかける
・DBサーバのCPU負荷・メモリー使用量などを観察する

こんな感じでしょうか。

開発時点ではWEBサーバを対象にすることがほとんどだと思いますが、この場合は静的コンテンツと動的コンテンツをしっかり分けて測定すると良いでしょう。HTTPサーバが遅いのか、動的コンテンツ、つまりプログラムが遅いのかを切り分けないと、高速化の検討が困難です。また、WEBサーバ自体の性能を把握しておくためにも、本当は単体で試験できる時点でしっかり確認をしておくのがベストです。実環境に組み込まれてしまうと、ロードバランサーや各種フィルターなどの影響も出てしまい、厳密なWEBサーバの試験が困難です。従ってシステム構築が完了してから測定するのではなく、開発時点に常に測定しておくのがお勧めです。そうするとある時点で突然遅くなった場合にも、前回と変わった部分の問題ということがすぐにわかり、対策も簡単です。

リリース直前の負荷試験では、よりユーザ側の視点での試験になりますが、私は基本的にこの試験はあまり興味がありません。あらかじめ限界性能をきちんと測定した上で、さらに、運用状態の感触をつかむために行うのであれば良いのですが、大抵は、リリース直前に「本当に大丈夫か？」という感じで測定することが多く、実際に負荷をかけてみると「性能が思ったほど出ない」ということが多く、そういうときには大抵、「ユーザはこんなに早く操作しないから、リクエストの間に待ち時間を入れて、負荷を下げて、問題ないという結果を出して見せよう」という方向に行くからです。流量制限フィルターなどをシステムに組み込んでいれば、まあ、それでも良いのかもしれませんが、素通しであれば、やっぱり想定より高い負荷をかけて結果を見ておくべきで、限界状態を直視しておくべきだと思うのです。SADEE2を開発した当初は、リクエストの間に待ち時間を入れるなど、負荷テストツールとしてありえない、と思っていて、その要求はかなり長いこと拒否していたのですが、途中で指定できるようにしてしまいました。。まあ、ユーザ側視点での測定ではあった方が便利だとは思いますが、開発・構築側としてはとことん高負荷で大丈夫なようにしておいて欲しいものです。

いずれにしても、開発と平行して常に負荷テストを行うことが、安心してリリースにたどり着く安心な方法だと思います。

厳密な測定結果が欲しければ、市販の高価なツールを検討しても良いかもしれませんが、負荷をかけるだけなら自作してもそれほど手間にはなりませんし、良い勉強になります。WEBの場合、セッション情報を引き継ぐために、CookieやURL埋め込み、FORM埋め込みなどに対応しないとできない試験が多く、それもまたプログラミングの良い練習になります。

WEB負荷テストツールを自作するなら、古いですが、この著書にサンプルが出ていますし、

ネットワークプログラミングの詳しいテクニックは種田君と共著のこの本を是非どうぞ。

さらに、この著書までマスターすれば、インフラ側のこともだいぶ理解できると思います！