VMware上のCentOSでApacheのベンチを行ってみるテスト第3弾
php部分に色々変更を加えてみる。

iptablesの接続テーブルが一杯

ベンチ中に以下メッセージが頻繁に出ている事に気が付いた。
 printk: *** messages suppressed.
 ip_conntrack: table full, dropping packet.
これはiptablesの接続テーブルが一杯になった時のメッセージらしい。

iptables の ip_conntrack の最大値を変更する方法

処理するセッション数が増えると、突然通信できなくなる(又は検査できなくなる。)(ip_conntrack数の変更) - 覚え書き Plus! 
この辺に解決方法あり。

ベンチで発生する問題を解消するためだけにこの方法を取るのは本末転倒。
今の所本番環境には関係なさそうなお話なので、当面は放っておく。
今回のベンチ、同時接続数も接続回数も、数が多すぎた...orz

しかし、現行の本番環境のもたつきは、これに近いかもしれない

画像用サーバー側が、メモリもCPUリソースも全然余裕なのに、妙に反応が遅い時がある。
サーバーログにエラーは見当たらないので、見当違いの可能性も十分あるけれど、これが原因かもしんない。 今回のベンチみたいな無駄なテストも、結構役に立つもんだww

以下、ベンチ結果

まずはサーバーの電源ON/OFF

前回、サーバー再起動と電源ON/OFFではレスポンスが微妙に異なったので、一旦電源ON/OFF Concurrency Level: 300 Time taken for tests: 12.757544 seconds Complete requests: 10000 Failed requests: 9267 (Connect: 0, Length: 9267, Exceptions: 0) Write errors: 0 Total transferred: 421699917 bytes HTML transferred: 419076773 bytes Requests per second: 783.85 [#/sec] (mean) Time per request: 382.726 [ms] (mean) Time per request: 1.276 [ms] (mean, across all concurrent requests) Transfer rate: 32280.20 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 14 209.5 0 3002 Processing: 1 264 1372.2 75 12742 Waiting: 1 263 1372.1 74 12740 Total: 58 279 1398.8 75 12752 Percentage of the requests served within a certain time (ms) 50% 75 66% 82 75% 84 80% 85 90% 88 95% 299 98% 1333 99% 12692 100% 12752 (longest request) この位の数値が今回の目安に。

完全に静的なHTMLに

HTMLでphpが作動するようにしてたけど、完全にOffに。 プログラムの走らないHTMLに変更。 Concurrency Level: 300 Time taken for tests: 3.53485 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 421512147 bytes HTML transferred: 418951891 bytes Requests per second: 3274.95 [#/sec] (mean) Time per request: 91.605 [ms] (mean) Time per request: 0.305 [ms] (mean, across all concurrent requests) Transfer rate: 134807.28 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 52.0 0 3001 Processing: 0 62 333.2 24 3038 Waiting: 0 59 333.4 21 3037 Total: 4 63 338.3 24 3053 Percentage of the requests served within a certain time (ms) 50% 24 66% 25 75% 25 80% 26 90% 26 95% 27 98% 37 99% 3031 100% 3053 (longest request) ぐはっ!こんなにレスポンスアップするのか。。。 しかし、サイドバー部分のインクルードは魅力的だし、悩む。。。 しばらくの間は「たかが50ms」と考え、見なかった事にしよう(^_^;

phpを一切記述しない

AddType application/x-httpd-php .php .html は記載する。
HTML内でphp実行出来るようにするが、一切phpを記述しなかった場合

Concurrency Level: 300
Time taken for tests: 11.404556 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 420474421 bytes
HTML transferred: 418574231 bytes
Requests per second: 876.84 [#/sec] (mean)
Time per request: 342.137 [ms] (mean)
Time per request: 1.140 [ms] (mean, across all concurrent requests)
Transfer rate: 36004.82 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 9 187.2 0 9000
Processing: 2 215 1281.5 58 11369
Waiting: 1 211 1281.9 53 11369
Total: 25 225 1298.6 59 11401

Percentage of the requests served within a certain time (ms)
50% 59
66% 62
75% 64
80% 65
90% 70
95% 73
98% 851
99% 11363
100% 11401 (longest request)

うーむ。結構レスポンス落ちるのな。。。


ヘッダ生成をphpに頼ってみる


MTブログでのアクセス振り分け(PC・携帯をphpで別ページに振り分ける)
http://web.tvbok.com/web/movabletype/mtpcphp.html
さくらでExpires headersを考えてみる
http://web.tvbok.com/web/server/expires_headers.html
上記のphpスクリプトを挿入してみる。

Concurrency Level: 300
Time taken for tests: 12.755658 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 421606683 bytes
HTML transferred: 418986159 bytes
Requests per second: 783.97 [#/sec] (mean)
Time per request: 382.670 [ms] (mean)
Time per request: 1.276 [ms] (mean, across all concurrent requests)
Transfer rate: 32277.83 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 17 248.6 0 9001
Processing: 1 248 1277.3 70 12721
Waiting: 1 248 1277.2 70 12721
Total: 20 266 1318.7 70 12753

Percentage of the requests served within a certain time (ms)
50% 70
66% 72
75% 73
80% 73
90% 76
95% 510
98% 2089
99% 6330
100% 12753 (longest request)

ああ、こんだけでも結構レスポンス落ちるんだ。。。

php include を利用してみる

本番環境と同じく、php include を3個使ってWebページのパーツを呼び出してみる。 ちなみに前項のヘッダ部分は元に戻した。 Concurrency Level: 300 Time taken for tests: 6.337096 seconds Complete requests: 10000 Failed requests: 9271 (Connect: 0, Length: 9271, Exceptions: 0) Write errors: 0 Total transferred: 420542820 bytes HTML transferred: 418642440 bytes Requests per second: 1578.01 [#/sec] (mean) Time per request: 190.113 [ms] (mean) Time per request: 0.634 [ms] (mean, across all concurrent requests) Transfer rate: 64806.65 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 5 127.1 0 3000 Processing: 1 170 753.9 64 6320 Waiting: 0 169 753.8 64 6319 Total: 5 175 765.9 64 6336 Percentage of the requests served within a certain time (ms) 50% 64 66% 70 75% 73 80% 74 90% 77 95% 82 98% 876 99% 6272 100% 6336 (longest request) やはりレスポンスは落ちているが、思ったほどじゃなかった。 どっちにしろ、極力phpで走っている部分を減らさないとダメだな。 完全にphpをOffにするとブログ再構築時の負荷がハンパじゃないし、どうしようか悩む。

ここでページ序文のiptables問題

ここまででかなりのペースでベンチしてたら、 ip_conntrack: table full, dropping packet. が大量発生。 iptablesの接続テーブルは、KeepaliveをOffにしててもしばらくメモリに残って開放されないのか? 今度調べる。  と言う事で、テスト回数を減らし、30分ほど時間を空けてベンチ ab -n 5000 -c 100 http://xxx.xx.xx.xx/test/test.html Concurrency Level: 100 Time taken for tests: 3.279418 seconds Complete requests: 5000 Failed requests: 4659 (Connect: 0, Length: 4659, Exceptions: 0) Write errors: 0 Total transferred: 210598841 bytes HTML transferred: 209288841 bytes Requests per second: 1524.66 [#/sec] (mean) Time per request: 65.588 [ms] (mean) Time per request: 0.656 [ms] (mean, across all concurrent requests) Transfer rate: 62712.96 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 1.5 0 16 Processing: 3 64 4.5 64 95 Waiting: 2 63 4.6 64 94 Total: 8 64 4.9 64 111 Percentage of the requests served within a certain time (ms) 50% 64 66% 65 75% 66 80% 67 90% 68 95% 70 98% 72 99% 80 100% 111 (longest request) 再起動とか全然していないのに、60ms台復活。むう。 50% 18 66% 18 75% 18 80% 19 90% 19 95% 20 98% 20 99% 27 100% 39 (longest request) php実行できないhtmlファイルは上記の通り。20ms切ってた。

今回はここまで

やっぱたまにはベンチ取って色々傾向と対策練るの必要だねー。
ググると似た様な情報は一杯手に入るけど、実際に自分でも試してみないと見えてこない部分も一杯あるもんだ。