概要
Apache Bench(ab)を使って負荷検証をします
どういう風に進めていくのか考える所からabを使って実際に負荷検証を行ってみます
Apache Bench(ab)とは
Apacheに同梱されているWebサーバの負荷検証を行うためのツール
例えばabを使うと、任意のURLに並列数10で1000回アクセスするなどが行えて
平均レスポンスタイムはこれぐらいで1秒間にこれぐらいさばける、などの結果を調べることができる
負荷検証の目的を明確にする
どのように負荷検証を進めていくのかについて
大事なのは「どういう目的で負荷検証を行うか」
case 1
「このページへのアクセスが2倍に増えた時にサーバが耐えられるか」という検証を行いたい場合
→ 現状のアクセス数を調べた上でabを使って2倍のアクセスを行ってみる
※ 当然本番環境ではなくテスト環境として別途サーバを用意して検証を行う
- 全てのアクセスが正常に処理されているか
- レスポンスタイムに劣化が見られないか
- 1秒毎にさばけるアクセス数に劣化が見られないか
- サーバのCPUやbusyが上がって高負荷状態になっていないか
- 連携先(例えば別にDBがあってアクセスする場合はDBサーバ)側の負荷が上がっていないか
などを確認する(上3つはabの結果で表示される、4つ目はsarコマンドで確認できる)
case 2
「新しく用意したWebサーバがどれくらいのアクセスを耐えられるのか」という検証を行いたい場合
→ 並列数とアクセス総数を少しづつ上げていってレスポンス劣化やサーバ高負荷になる値を模索していく
→ 古いサーバがあって新しいサーバがどれくらいスペックが良くなるのかを調べる場合は新旧のサーバで同様のテストを行って比較する形で負荷検証を行う
こちらも確認することとしてはほとんどcase 1の時と同じである
Apache Bench使い方まとめ
環境準備
※ 既にapacheが用意されていて、負荷検証を行うページが用意されている場合はsarだけ導入してそれ以外は飛ばしてください
動作検証環境
$ cat /etc/redhat-release CentOS release 6.8 (Final)
サーバの負荷を確認するsarコマンドの導入
$ sudo yum install sysstat
apache2.4環境を準備
$ sudo wget -O /etc/yum.repos.d/epel-httpd24.repo http://repos.fedorapeople.org/repos/jkaluza/httpd24/epel-httpd24.repo $ sudo yum -y install --enablerepo=epel-httpd24 httpd24 $ sudo ln -s /opt/rh/httpd24/root/etc/httpd /etc/httpd24 $ sudo ln -s /opt/rh/httpd24/root/var/www/html /var/www/html24 $ sudo ln -s /opt/rh/httpd24/root/var/log/httpd /var/log/httpd24 $ sudo sed -i 's/#ServerName www.example.com:80/ServerName www.example.com:80/' /etc/httpd24/conf/httpd.conf $ sudo yum -y remove httpd $ sudo service httpd24-httpd restart
テストページを作成
$ cat /var/www/html24/index.html <html> Hello World! </html>
http://{サーバー名 or ipアドレス}/
にアクセスできることを確認する
abを実行
とりあえず実行してみる
// abコマンドが使えることを確認する $ ab -V This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
アクセス総数(-n)は1、並列数(-c)を1でサーバにリクエストを行う
基本的に-nと-cのオプションだけ覚えていれば大丈夫
$ ab -c 1 -n 1 http://{サーバー名 or ipアドレス}/
実行結果
$ ab -c 1 -n 1 http://{サーバー名 or ipアドレス}/
... 中略 ...
Benchmarking XXXXXXX (be patient).....done
Server Software: Apache/2.4.6
Server Hostname: XXXXX
Server Port: 80
Document Path: /
Document Length: 28 bytes
Concurrency Level: 1
Time taken for tests: 0.002 seconds
Complete requests: 1
Failed requests: 0
Write errors: 0
Total transferred: 289 bytes
HTML transferred: 28 bytes
Requests per second: 554.94 [#/sec] (mean)
Time per request: 1.802 [ms] (mean)
Time per request: 1.802 [ms] (mean, across all concurrent requests)
Transfer rate: 156.62 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 1 0.0 1 1
Processing: 1 1 0.0 1 1
Waiting: 1 1 0.0 1 1
Total: 2 2 0.0 2 2
出力結果の見方について
| 出力結果 | 説明 | どういう風に見るべきか |
|---|---|---|
|
Complete requests: Failed requests: |
正常に処理したリクエストと失敗したリクエスト | アクセスや並列数を上げていった時にFailed requestsが0ではなくなるとそこがWebサーバの処理の限界となる |
| Requests per second: | 秒間にどれくらいアクセスをさばいているか(req/secとも呼ぶ) | 想定アクセス数が分かる場合はそれよりもさばけることを確認する |
|
Time per request: (mean, across all concurrent requests) |
1リクエストあたりの処理時間の平均(レスポンスタイム) |
遅い場合は、そのページを表示するロジックの見直しやDBを使っている場合はDBのチューニングなどを行う (体感で3秒ぐらいかかると離脱するユーザが増えるという噂がある) |
サーバ負荷確認方法について
sarの実行中にabコマンドを叩いてサーバの負荷が問題ないかを確認することができる
// 5秒毎にCPU状態を監視する $ sar 5 -u 06:07:07 PM CPU %user %nice %system %iowait %steal %idle 06:07:12 PM all 0.10 0.00 0.20 0.00 0.00 99.70 06:07:17 PM all 0.00 0.00 0.10 0.00 0.00 99.90 // その他のオプションについて // -q ロードアベレージ (システム全体の負荷状況を表す指標) // -r メモリ (apacheやその他のプロセスでメモリを食いつぶしてないかなど) // -d ディスクbusy (ioがメッチャ多くてディスクが限界まで頑張りすぎていないかなど) // 他にもあるので調べてみてください
結論の出し方
最初に定めた「どういう目的で負荷検証を行うか」という問いに対して応える形でまとめてみる
例えば「今だと秒間10アクセスがあるが今後30アクセスに増えそう」ということならば
並列数1でアクセス総数10000回でアクセスしてみてreq/secの値が30以上だったら問題ない
もし30未満だったとしてもその結果はapacheの1プロセス分での結果に過ぎないのでapacheのmaxclientsが30だった場合は単純計算で×30アクセスがさばけるということになるのでその辺りも考慮して考える必要がある
また、それ以外にも最初に述べたように(目的の結果としては問題なかったとしても)req/secやレスポンスタイムが劣化していないか、サーバの負荷が高くなっていないこともまとめると丁寧な結論になる
■ 終わりに
簡単にですがabの使い方とどういう風に負荷検証を行うのかについてまとめてみました
負荷検証を行う目的は色々あるため一概にも今回のやり方でできるとは限りませんが何かしらの参考になればいいなと思います
コメントを書く
コメント一覧