ラウンドアバウトのテスト2 メモリ使用量調査
前回の記事から随分と間があいてしまいましたが、ラウンドアバウトのテストに関して2本目の記事です。 前回の「ラウンドアバウトのテスト1 品質管理チーム」では僕が何も知らない状態でラウンドアバウトの品質管理チームになったこと、 何も知らないことには意味があったことに関して主に書いていました。 今回は、実際にラウンドアバウトのメモリ使用量の調査を中心に話を進めていきます。
メモリ使用量の調査？
品質管理チームとして、ラウンドアバウト動作時のメモリ使用量の調査を行うことになりました。そのために、WEBサーバーに大量にリクエストを送信して、負荷がかかっている状態を作り出します。
ラウンドアバウトが変換を行うのは、HTMLやCSS等の文書ファイルと、JPEG、GIF等の画像ファイルです。 特に、画像ファイルの変換にはCPUもメモリも使用します。それなら、一つの画像ファイルにいっせいにアクセスすればいいか、というとそうではないんです。 一度変換した画像ファイルはキャッシュしてしまうため、2回目以降はほとんど負荷がかかりません。 となると、大量にコンテンツを用意しないとならないですね。
メモリの使用量はfreeコマンドからused、freeの値を、psコマンドからhttpdデーモンのVSZ、RSSの値を取得することで計測しました。当時、マシン全体のメモリ使用量より、プロセス毎の使用量の使用量の方が多い事が不思議でした。しかし、考えてみれば当たり前の話で、マシン全体のメモリ使用量はswapを含まない値を 、プロセス毎の使用量はswapを含んだ値を取得していたため、swapを使えば使うほど、プロセス毎の使用量の方が多くなっていたんですね。
テスト用コンテンツ取得
大量にコンテンツを用意するといっても、100ファイルや200ファイルじゃ話になりません。メモリの使用量の調査を行うためには、最低でも一晩はリクエストし続けられるぐらいの量を集める必要があります。そのために、wgetコマンドを使って、インターネットに既にあるコンテンツをダウンロードすることにしました。
wgetコマンドを使ってコンテンツを取得することには、手間が省けるだけではなくて、もう一つ意味があるそうです。ラウンドアバウトは、普段の仕事で作っているようなWEBアプリケーションと違って、サーバーの出入り口で動作するので、仕様外のリクエストを受けたから、といって落ちるわけにはいきません。テスト用に作成した仕様の範囲内のコンテンツではなく、ラウンドアバウトの事なんて全く知らない人たちが作ったコンテンツを集め、テストをすることで、どんなコンテンツが来ても落ちない事を確認することが出来るのです。
以下に記載したwgetコマンドがコンテンツを集める際に利用していたものです。人力でいくつかのサイトに目星をつけておき、list1.txtに書いておくと、wgetコマンドがそのURLに対してリクエストを送ります。後は、そのサイトに記載されているURLをたどって、再帰的にコンテンツを取得します。
wget -r -k -H -t1 -i ./list1.txt -o ./site1.log -P /home/symm/roundabout/site1/
メモリ使用量の調査
コンテンツを集めることが出来たので、いよいよメモリ使用量の調査を行います。
メモリ使用量の調査の際にもwgetコマンドを使用しました。
WEBサーバーの負荷テストを行うにはApache Bench等の有名なツールがありますが、wgetコマンドをテストで使用したことに関しては・・・・、何か理由があったはずなんですが・・・。
あ、思い出しました。今回wgetでテストを行った理由は、通常のブラウザがするようなリクエストを送りたいから、でした。ラウンドアバウトは、リクエストしてきた携帯に応じて、画像のサイズを変えたり、HTMLの記述を変更する機能があります。そのため、Apache Benchiのように単一のURLに対する負荷を測るだけでなく、HTMLをリクエストした後に、そのファイルの中に書かれている画像ファイル、CSSファイル等にリクエストを送るwgetでテストを行いました。
また、前述したようにラウンドアバウトには一度リクエストされたコンテンツをキャッシュする機能がありますから、次々と違うURLにアクセスすることが出来るという点もwgetコマンドを使用した理由です。
以下が使用したwgetコマンドです。取得したコンテンツのURLをsamplelist1.txtに記載しておき、wgetコマンドを実行します。一つのリストに全てのURLを書いてしまうと、途中で何かあった場合にテストが終わってしまうので、
一つのファイルに書くURLの数は300程度にして、分割しました。こうすることで、一つのwgetコマンドが途中で終了してしまったとしても、次のwgetコマンドが動作します。
一晩かけてテストが終わっているはずが、次の日の朝に確認したら、前日会社を出た5分後にテストが終わっていた時の切なさといったら、とても言葉にすることは出来ません。
wget -e robots=off -p -P ./wget1 -a ./ra1.log -i ./samplelist1.txt --user-agent="KDDI-CA3A"
こうしてリクエストを送っている間、サーバーサイドで定期的にメモリの状況を取得し、メモリ使用量の調査を行いました。
メモリ使用量の調査結果
以下が、上記で取得したメモリ使用量をまとめたグラフです。緑の線がマシン全体の使用メモリ、青の線がマシン全体の空きメモリ、黄色の線がアパッチのプロセス数です。
図1は品質管理チームになった直後に行ったテストです。
テスト開始直後からメモリ使用量がどんどん上昇し、あっという間にusedとfreeが逆転しています。その後もどんどん上昇を続け、OSが何度か強制的にプロセスを止めていたようです。
この頃は頻繁にメモリーリーク、という言葉を耳にしました。
図2はリリース直前に行ったテストです。
テスト開始直後にメモリ使用量が上昇しているものの、安定した波形を描いています。
これなら、安心して使うことが出来ますね！
開発チームでどのような修正を行ったのか、僕には具体的なことはわかりませんが、こうしてテストを行うことで品質の向上を実感することが出来ました。
ラウンドアバウトの開発の苦労等の詳細は、ナカニシさんやkoreadaysさんが、きっと書いてくれるんじゃないかと思います。
次回はwgetコマンドをメインに話していきたいと思います。