Nginxのパフォーマンステストの方法とチューニングのメモ
テストツールの種類と特徴
| テストツール |
説明 |
| httperf |
HPが開発した有名なオープンソース(Linux専用) |
| Autobench |
httperfのラッパー。テストのメカニズムや詳細レポートの作りを改良している |
| OpenWebLoad |
windowsもサポートしている小規模なオープンソース |
今回利用するテストツール
- 今回は
Autobenchを利用する
Autobenchはグラフで結果を確認することができるので見やすい- サーバが飽和状態になるまでリクエストを送り続けてくれる
- テスト結果を.tsvファイルにエクスポートできる
Autobenchを導入する
- Autobenchはhttperfのラップしてる為httperfを導入する
- httperfの導入
sudo wget http://httperf.googlecode.com/files/httperf-0.9.0.tar.gz
tar zxf httperf-0.9.0.tar.gz
cd httperf-0.9.0
./configure
make
sudo make install
wget http://www.xenoclast.org/autobench/downloads/autobench-2.1.2.tar.gz
tar zxf autobench-2.1.2.tar.gz
cd autobench-2.1.2
make
sudo make install
Autobenchの使い方
- autobenchのあとにスイッチを記述していく
- スイッチの値を変えながらサーバに負荷をかけてパフォーマンスを計測し改善する
- 主なスイッチは以下
| スイッチ |
意味 |
| --host1 |
テストしたいwebサイトのホスト名 |
| --uri1 |
ダウンロードされるファイルパス |
| --quiet |
画面にhttperfの情報を出さない |
| --low_rate |
テストの最初の段階での1秒あたりの接続数 |
| --high_rate |
テストの終わりの段階での1秒あたりの総接続数 |
| --rate_step |
毎回のテスト後に増やす接続数 |
| --num_call |
1つの接続あたりいくつのリクエストを送るか |
| --num_conn |
接続総数 |
| --timeout |
リクエストが失われたとされる秒数 |
| --file |
指定したファイルに結果をエクスポートする(.tsv) |
デフォルトのパフォーマンスを計測してみる
autobench --single_host --host1 192.168.33.11 --uri1 /index.html --quiet --low_rate 20 --high_rate 200 --rate_step 20 --num_call 10 --num_conn 5000 --timeout 5 --file ~/results.tsv
- 待つこと数分
results.tsvに計測結果が記録されていく
results.tsvの見方
- いきなりresults.tsvを見ても意味がわからないので一旦カラムの意味を理解しておくとよさそう
| 内容 |
意味 |
| dem_req_rate |
1秒あたりの接続数＝実行時のrate |
| req_rate |
1秒あたりのリクエスト数 |
| con_rate |
1秒あたりのコネクション数 |
| min_rep_rate |
1秒あたりの最小リプライ数 |
| avg_rep_rate |
1秒あたりの平均リプライ数 |
| max_rep_rate |
1秒あたりの最大リプライ数 |
| stddev_rep_rate |
リプライレートの標準偏差(ばらつき) |
| resp_time |
リクエストを送った瞬間からレスポンスが返った瞬間までの平均時間(ms) |
| net_io |
通信速度(KB/s) |
| errors |
エラー：正常比率(%) |
実際に結果を見てみる
| dem_req_rate |
req_rate_192.168.33.11 |
con_rate_192.168.33.11 |
min_rep_rate_192.168.33.11 |
avg_rep_rate_192.168.33.11 |
max_rep_rate_192.168.33.11 |
stddev_rep_rate_192.168.33.11 |
resp_time_192.168.33.11 |
net_io_192.168.33.11 |
errors_192.168.33.11 |
| 200 |
200.0 |
20.0 |
200.0 |
200.0 |
200.0 |
0.0 |
0.1 |
180.7 |
0 |
| 400 |
400.1 |
40.0 |
400.0 |
400.0 |
400.0 |
0.0 |
0.1 |
361.4 |
0 |
| 600 |
600.1 |
60.0 |
599.9 |
600.0 |
600.0 |
0.0 |
0.1 |
542.1 |
0 |
| 800 |
800.1 |
80.0 |
799.9 |
800.0 |
800.1 |
0.0 |
0.1 |
722.8 |
0 |
| 1000 |
1000.2 |
100.0 |
999.9 |
1000.1 |
1000.1 |
0.1 |
0.1 |
903.5 |
0 |
| 1200 |
1200.2 |
120.0 |
1199.9 |
1200.1 |
1200.1 |
0.1 |
0.1 |
1084.1 |
0 |
| 1400 |
1400.2 |
140.0 |
1399.9 |
1400.1 |
1400.1 |
0.1 |
0.1 |
1264.9 |
0 |
| 1600 |
1600.3 |
160.0 |
1599.8 |
1600.1 |
1600.1 |
0.1 |
0.1 |
1445.6 |
0 |
| 1800 |
1800.3 |
180.0 |
1799.8 |
1800.1 |
1800.1 |
0.1 |
0.1 |
1626.2 |
0 |
| 2000 |
2000.3 |
200.0 |
1999.8 |
2000.1 |
2000.1 |
0.2 |
0.1 |
1806.9 |
0 |
- どんなに性能上げてもエラーがあれば意味なさそうなので気をつけたい
- 以上がデフォルトのNginxのパフォーマンステストの方法
Autobenchなにがいいの？
- 個人的にhttperfより見やすくて好き
- tsvで結果が作られるのでグラフ化することもできるので良い
- httperfをラップしているので信頼度が高い
Nginxをチューニングする際に覚えておきたいこと
| 項目 |
内容 |
| worker_processes |
Nginxプロセスの数を指定する。autoの場合は自動的にCPUコア数になる |
| worker_rlimit_nofile 1 |
プロセスあたりの最大ファイルディスクリプタ数で worker_connection の数倍が良いらしい |
| use epoll |
Linuxのepollを使う |
| multi_accept |
できるだけクライアントからのリクエストを受け取る |
| worker_connections |
一つのworkerプロセグが開ける最大コネクション数、CPUの性能によってこの値をチューニングする。今回は結果として1024が最適だと判明。 |
| tcp_nopush |
このオプションを使うと、レスポンスヘッダとファイルの内容をまとめて送るようになり、少ないパケット数で効率良く送ることができます。デフォルトの設定値はoffです。 |
| tcp_nodelay |
データをキャッシュしないで、どんどん送信させる、リアルタイムアプリに最適 |
メモ
cat /usr/include/linux/posix_types.h
#ifndef _LINUX_POSIX_TYPES_H
#define _LINUX_POSIX_TYPES_H
#include <linux/stddef.h>
/*
* This allows for 1024 file descriptors: if NR_OPEN is ever grown
* beyond that you'll have to change this too. But 1024 fd's seem to be
* enough even for such "real" unices like OSF/1, so hopefully this is
* one limit that doesn't have to be changed [again].
*
* Note that POSIX wants the FD_CLEAR(fd,fdsetp) defines to be in
* <sys/time.h> (and thus <linux/time.h>) - but this is a more logical
* place for them. Solved by having dummy defines in <sys/time.h>.
*/
/*
* This macro may have been defined in <gnu/types.h>. But we always
* use the one here.
*/
#undef __FD_SETSIZE
#define __FD_SETSIZE 1024
typedef struct {
unsigned long fds_bits[__FD_SETSIZE / (8 * sizeof(long))];
} __kernel_fd_set;
/* Type of a signal handler. */
typedef void (*__kernel_sighandler_t)(int);
/* Type of a SYSV IPC key. */
typedef int __kernel_key_t;
typedef int __kernel_mqd_t;
#include <asm/posix_types.h>
#endif /* _LINUX_POSIX_TYPES_H */
思ったこと
- ベンチの計測時間かかる
- とりあえず知識レベルとして知っておきたかった
- あとはチューニングについても実際にやってみたい感はある
参考元
新ConoHaでのNginxチューニングとConoHaロードバランサーのパフォーマンス調査 - Qiita
autobench/DOS攻撃 - インターネットウィキ
