NginxのKeepAlive設定と考え方まとめ（Timeout･upstream等 ）
doudonn 更新日：
NginxのKeepAlive設定は理解が大事
一番最初に悩むところじゃないだろうか。
ここの疑問を無くすべく熱く語りたい。
※難しい言葉は使わない
１、KeepAliveとは
サーバーへ接続しっぱなしの状態にすること。
例えばKeepAliveが無いと画像のダウンロードの度にサーバーに新規接続します。
処理が重く・遅く、無駄でしかない。
それを解決したのがKeepAlive。
ApacheもNginxもデフォルトで有効になっています。
２、KeepAliveの効果について
新規接続にかかる時間が無くなるので高速に。
1回くらいなら気付かないレベルですが、
画像等を多数読み込むとなるとだいぶ遅く感じます。
KeepAliveが効いているかどうかは上図のようにデベロッパーツールで確認してみてください。
３、フロントからバックエンドに接続するKeepAliveについて
Nginxはフロント→バックエンドのKeepAliveはデフォルトでOFF。
バックエンドへの転送は送受信完了後に必ず切断されます。
毎回新規接続になるので遅い。あのグラフのような感じになっています。
したがって、基本的にはKeepAliveはONにした方が良いと思います。
４、バックエンド側KeepAliveのデメリット
コネクションを多く使ってしまうことがデメリット。
KeepAlive用のコネクションが設定した分追加されます。
そのため、ここで使い切ってしまうとクライアントからの新規接続を処理できない。
双方余裕ある設定にする必要があります。
メモリも消費されますが、使用量は少ないのでよほど多くしない限りは大丈夫かと思います。
５、同時アクセス対策でのKeepAlive設定について
昔の情報は信じてはいけない。
今のWEBサイトは「lazyload」で画像を断続的にダウンロードする仕様です。
これも新規接続なので、同時アクセスの一員となる。
最初の表示だけで終わりではないのが今のWEBです。
KeepAliveタイムアウトが3秒とかだと、常にDDos攻撃状態になる。
訪れたユーザーは必ずスクロールをします。
数秒ごとに画像をどんどんダウンロードしていく。
KeepAliveが効いていないとやばい状況です。
昔はlazyloadが無く最初に全部読み込んだのでKeepAliveは3秒とかで良かった。
今はそれとは違うので、ググって見かける情報には要注意です。
６、NginxでのKeepAlive設定（Module ngx_http_core_module）
それぞれ簡単に説明します。
※クライアント→フロント側の設定です。
keepalive_requests
Syntax: keepalive_requests number; Default: keepalive_requests 1000; Context: http, server, location This directive appeared in version 0.8.0.
keepaliveの設定時間に関係なく、指定したリクエスト数に達したら切断します。
何かしらの原因で永遠に残り続けるユーザーを切断するためです。
デフォルトの1000は多すぎるので、100くらいで良いと思います。
keepalive_time
Syntax: keepalive_time time; Default: keepalive_time 1h; Context: http, server, location This directive appeared in version 1.19.10.
リクエスト数に関係なく、指定した時間に達したら切断します。
バージョン1.19.10で登場したので、これを書いていないサイトが多いです。
リクエスト数よりも時間の方が適しているので、こちらをメインで考えると良い。
デフォルトの1時間はさすがに長いので、10分くらいが良いかなと思います。
keepalive_timeout
Syntax: keepalive_timeout timeout [header_timeout]; Default: keepalive_timeout 75s; Context: http, server, location
新規ダウンロード等が指定の時間無かった場合に切断します。
この時間の間に一度でもダウンロードがあったら秒数をリセット。
スクロールしてlazyloadでダウンロードまでの時間を考えて指定したい。
20秒経ってもダウンロードしないとかありえないなら、20sを設定しよう。
※デフォルト値は「次のページに行くまでの秒数」を想定していると思います
７、NginxでのKeepAlive設定（Module ngx_http_upstream_module）
こちらはフロント→バックエンドの設定です。
keepalive
Syntax: keepalive connections; Default: — Context: upstream This directive appeared in version 1.1.4.
これを設定すると各ワーカープロセス→バックエンドでのkeepaliveが有効になります。
各ワーカープロセスごとのkeepaliveの最大コネクション数を指定します。
同時アクセス数を想定して設定するのが良いですが、コネクション不足にならないよう注意です。
（フロント側で限界設定している場合、少し緩めた方がいい）
詳しくはこちらの公式の解説を見てください。
keepalive_requests
Syntax: keepalive_requests number; Default: keepalive_requests 1000; Context: upstream This directive appeared in version 1.15.3.
フロント側のやつと同じなので省略。
keepalive_time
Syntax: keepalive_time time; Default: keepalive_time 1h; Context: upstream This directive appeared in version 1.19.10.
こちらもフロント側のやつと同じなので省略。
keepalive_timeout
Syntax: keepalive_timeout timeout; Default: keepalive_timeout 60s; Context: upstream This directive appeared in version 1.15.3.
こちらもフロント側のやつと同じなので省略。
８、NGINXでの具体的なkeepalive設定例
当ブログは下記のように設定しています。
クライアント→フロント側
keepalive_requests 200;
keepalive_time 5m;
keepalive_timeout 20s;
画像を段落ごとに入れてちょくちょく読み込むので、
keepaliveは20秒でタイムアウトになるようにしています。
20秒も画像を読み込まない＝離脱と考えて良いだろうと。
一応は同時アクセス対策として早めに切っておきたい。
総合のタイムアウトは5分ですが、ここは適当です。
フロント→バックエンド側
upstream backend {
server 192.168.0.1:80;
server 192.168.0.2:80;
keepalive 128;
keepalive_requests 500;
keepalive_time 10m;
keepalive_timeout 60s;
}
コネクション数は128。
ワーカープロセスは3個あるので合計最大384コネクションとなります。
自分の場合ロードバランサが2個あるので、2倍の768コネクションとなる。
SSLの処理が重くてそれくらいしか同時アクセスが無理なので十分。
こちらのタイムアウト系は長くしています。
上限を指定しているのでコネクションを使い切る心配が無いためです。
こちらはできるだけ何度も使い回したい。
けど、少し怖いので控えめな数字。
まとめ
keepaliveは自分のサイトに合わせた設定を。
サイトによって設定が全然違ってくることが分かったかと思います。
Lazyloadを使っておらず最初に全部読み込むなら、タイムアウトは3秒とかで良い。
ただ、アクセス集中で負荷が重くなり3秒以上かかってしまう可能性があることには注意。
今は自分がやっている設定のように少し長めにするのが良いと思います。
これが同時アクセスに弱くなるか？というと難しい。
クライアントから受けられるコネクション数は減りますが、処理速度は上がる。
結果的にどうか？は実使用に合わせた評価をしないとわからない。
keepaliveでの快適さと同時アクセス対策を両立するなら、
ロードバランサを増やして余裕ある状態にすることが一番。
2台なんて甘い。6台くらいで分散だ。
あとはCDNを使うのは良いですね。
Lazyloadが問題なので、そこをCDNにすれば最初の読み込みだけ考えれば良い。
昔のように「keepalive_timeout 3s」とかにできます。
こんな感じで是非いろいろ設定してみてください。
※解説が間違っているかもしれないので、必ず公式解説も確認ください。
＜公式解説＞
・Module ngx_http_core_module
・Module ngx_http_upstream_module
