こんにちわ、パッションの伝道師こと鰯です。

今回は弊社でピクセルトラッキングを行った際に、EC2(c3.large)を使い倒そうということで、Nginxの設定などの調整やAmazonLinuxのカーネルパラメータの調整しました。ちなみに実績として秒間9000以上はいってますので、普通のWebサイトなら問題ないかと思います。

nginx.confの設定

worker_connections

最大同時接続数は使用できるポート数以上設定しても意味ないので、上限の 65535 を設定

worker_rlimit_nofile

ファイルディスクリプタ上限数は、通常1つの接続につきエフェメラルポート用のソケットファイルと実際に返答するコンテンツファイルだとお思うので、worker_connections に対して2倍以上を設定しておけば良いと思うのですが、ふと HTTP Pipelining が利用された場合はこの比じゃない気がしたんだが、どうなんだろう…。

multi_accept

リクエストを同時に受け付けられるならその方が良いと思う…

use epoll

あれ、これって別に指定しなくても自動で選択されるよね??とりあえず、明示しておいた方が安心なので…

sendfile

empty_gif なので意味はない気がする…

tcp_nopush

なるべく少ないパケットで通信をした方が効率が良いように思うので…

keepalive_timeout

ELB配下のEC2環境なので、AWS推奨の120秒以上に設定

TCP カーネルパラメータ

上記以外の設定に関しては、副作用の問題が報告されてたりして、ちょっと危険そうなのでやってないのと、そもそも、ここまでやっておけば、他のところがボトルネックになる可能性の方が高いと思うの、ひとまずここまでってのもある。

net.ipv4.ip_local_port_range

これを増やさないことには同時接続数を増やしても…。可能なら 1024-65535 とかの方が良いと思う

net.ipv4.tcp_tw_reuse

再利用した方が速いと思うよ…

net.ipv4.ip_dynaddr

DHCP環境なので設定しておいた方が良いかなと

net.ipv4.tcp_rfc1337

RFC1337に準拠させる。TIME_WAIT状態のときにRSTを受信した場合、TIME_WAIT期間の終了を待たずにそのソケットをクローズする

TIME_WAITは何かと問題になるし、待たなくて済むならその方が良いと思うので

net.ipv4.tcp_fin_timeout

タイムアウトはなるべく短い方がいいと思うので

net.ipv4.tcp_keepalive_probes

TCP が keepalive プローブを送る数。この数に達すると、 その接続が壊れたとみなします。デフォルトの値は 9 です。 この値に tcp_keepalive_intvl をかけると、 ある keepalive が送られた後に許される無反応時間が得られます。

あんまり待って欲しくないし、さっさと次へ行ってほしいので

net.ipv4.tcp_slow_start_after_idle

アイドルとかしなくて良いんじゃないか?

こちらの内容は、Qiitaにも投稿しています、参考情報なども合わせて、そちらもご覧になっていただければと思います。
http://qiita.com/iwai/items/1e29adbdd269380167d2

あわせて読みたい記事