IVP Internet Value Provider IVP Co. Ltd.IVP Internet Value Provider IVP Co. Ltd.

  • タイトル

パフォーマンス診断 (自社製品ERS_V6.5) 第3回 続・負荷試験の有効性

 | 

引き続き負荷試験の有効性を説明していきます。

グローバル回線とLANとの違いによるテストと本番による結果の乖離を防ぐ手段

LAN環境は現在基本的に1Gbpsで構築していっているのですが、
本番環境では 200Mbpsであったり100Mbpsのベストエフォート回線が使用されています。

そのままテストをすると、回線がボトルネックになる場合結果に乖離が発生します。
ですので、100Mbpsに絞って負荷試験を実施します。
ベストエフォート100Mbpsの回線でも実際、80Mbpsは出るので充分参考になる数値が取れると思います。

まとめ

・ページ毎の処理による違いによる試験と実サイトの乖離を防ぐ手段
・ツールの間違いによる試験と実サイトの乖離を防ぐ手段
・読み込み遅延による試験と実サイトの乖離を防ぐ手段
・サーバー性能の違いによるテストと本番による結果の乖離を防ぐ手段
・グローバル回線とLANとの違いによるテストと本番による結果の乖離を防ぐ手段
の5つで試験の有効性を担保させています。

上記のような手段で試験結果と本番環境での乖離しないように努めても
そもそもの想定で負荷試験と実サイトでの乖離が発生する場合が多いです。

一度あった例としては、あるサイトのリニューアルを弊社で担当した際の話です。
そのサイトは以前、閲覧不可能なぐらい重い状態になっていたので、リニューアルで解決しようとしました。
そこで旧サイトのアクセス数はすべての閲覧者の1/2ぐらいはアクセスできているだろうという想定を立てたのですが
特に人気商品が販売される場合、想定と本番環境がまったく違うアクセス数で
リニューアル直後に閲覧不可能に陥ったケースもあります。

また、別によくあるパターンとして下記のようなものがあります。
オープン当初は耐えれていたがアクセス数が増えていき耐えれなくなるような場合。
一部のSQLが極端に重く試験と結果が乖離する場合。
ログファイルが大きくなりすぎてパフォーマンス劣化が発生した場合などになります。

それぞれ、ハードウェアの追加、SQLのチューニングやアプリケーションなどの設定変更
ログローテートの導入やログ退避での対応を実施して解決していっています。

以上のようなことから、負荷試験はそもそもの想定に間違いが無ければ参考になるアクセス数が取れる試験で
次にボトルネックがどこになるかの傾向を見るためのサンプリング試験とも言えそうです。

また、Jmeter , IIS のログだけだと、アクセス数のみしかわからず、今後に活かせないので
ボトルネックを調査するため下記の数値なども測定していきます。

ボトルネックになる箇所はCPU,メモリ、ディスクIO 、トラフィック量、同時接続数などになります。
これらを下記のように取得していきます。

Windows サーバーは下記のようにパフォーマンスログを取得していきます。

スタート>管理ツール>パフォーマンスモニタ を選択
データコレクターセット>ユーザー定義 を選択して右クリック>新規作成>データコレクターセット
名前を入力して手動で作成する(詳細)を選択して 次へ
パフォーマンスカウンタのみにチェクをいれて次へ
サンプルの間隔を1秒にセットし、取得したいデータのパフォーマンスカウンタを追加する。

ログ設定画面

↑の場合は空きメモリ、I/Oキュー、CPU使用率、CPU処理待ち数を追加しています。

すると下記のように数値が採れます。
表1
Linux サーバーはiostat でディスクIO値を取ります。

cronでは1分間隔でしか実行できませんがcrontabにこのように記述すれば1秒間隔でiostatのログを取得することが出来ます。

10 12 * * * root /usr/bin/iostat -xt 1 86400 > /var/log/iostat/iostat_`date +¥%y¥%m¥%d`.txt &

これが1秒間隔で取得したiostatのログです。
avgqu-szの値が待ちI/Oキューの数です。

Linux 2.6.18-371.el5 (centos510-db01) 01/23/14
Time: 12:10:01
表2

表3
これらをawk やgrep などで集計していきます。
CPU、メモリはsarを使用してます。

cronでは1分間隔でしか実行できませんがcronにこのように記述すれば1秒間隔でsarのログを取得することが出来ます。

vi /etc/cron.d/sysstat

* * * * * root /usr/lib64/sa/sa1 1 60
↑1秒間隔で60回実行する設定にします。

以下が1秒間隔で取られたsar -u (CPU使用率)のログになります。
1番左の数値がCPU使用率の値となります。
表4

時刻とCPU使用率の抽出
sar -u | grep PM | grep 1: | awk ’{print $1”,”$4}’ >cpu.csv
↑PM 1:00台のログから1列目(Time)と4列目(CPU使用率)をCSV形式で出力するという意味になります。

このような形で集計をかけて、どこに負荷がかかり、どうすれば対応可能かというのがわかりやすくなります。

他に有効なのは、OSのログや各アプリケーションのログ。
postgres でスロークエリーを出して、SQLをチューニングするなどの手段になってきます。

このようにツールやコマンドを使用することにより、細かいデーターを取ることで
ボトルネックやアクセス数について考察を進めれるようにしていきます。

次回以降で負荷試験の結果と考察を挙げていきます。