モジュールは、構成の例HttpUpstreamModuleです。
【シェル】上流http_backend {
サーバー127.0.0.1:8080。
キープアライブ16;
}
サーバー{
...
位置/ HTTP / {
proxy_passのhttp：// http_backend。
proxy_http_version 1.1;
proxy_set_header接続"";
...
}
} [/シェル]
ノートには、いくつかのポイントがあります。
1.デフォルトnginxの後端が短いによって接続されている要求を、nginxのは、新たなポートを開いて、後端の接続は、接続要求回復の端を確立し、（、HTTP1.0です）。上記の構成のようなあなたは、長い接続をセットアップするように、nginxのは、クライアントの要求を受け入れる場合は、nginxの完了後の処理「を維持し、長い接続のバックエンドを続ける」う、同時リクエストがキープアライブ指定に最大接続数を超えた場合、nginxのは、新たに開始します新しい接続要求が完了した後、要求を転送するための接続が閉じられ、接続が新たに付加的な問題を引き起こす可能性が長い接続、最終決定権を確立しています。
前記キープアライブ指定された値は、全体ではなくnginxの長い労働者当たりの後端nginxのに接続された接続の最大数、です。そして、バックエンドは、ここでは、「すべてのバックエンド」とはない（検証）ごとのバックエンドを指します。
3. 公式サイト私はそれが何を意味するのか知りませんでしたが、それは放棄されている、と見て正直に言うと、単一のパラメータがあります見ることができ、ここで
4. HttpUpstreamModuleモジュール総命令もある次のようleast_connは、説明しました：
グループは、要求がサーバのアカウントの重みを考慮して、アクティブな接続数が最も少ないサーバに渡され、負荷分散方式を使用するかを指定します。いくつかのそのようなサーバがある場合、それらは、重み付けラウンドロビン分散方式を使用して順番に試行されます。
翻訳：
負荷分散方法は、その重い重量の値に基づいて、サーバグループを指定し、その中で、サーバに「アクティブな接続の最小数を」要求を送信します。以上のように、Aサーバなら、試してみヘビーローテーション方式を取る権利があります。
バックエンドサーバーへの接続数が非常に少なくなっているようだと、非常に奇妙な、このコマンドを使用して、私は個人的に確認することが、測定されていません。
最初の約最後のポイントは、私は小さなキープアライブ設定された時間、例えば1は、その後、nginxのは同時要求の数が多い後に表示されますときTIME_WAITが上がることがわかった、という現象で始まり、およびキープアライブは（proxy_http_version 1.1とproxy_set_header接続「を」オフに切り替えた場合命令も削除）、その後、TIME_WAITは竜巻を使用してバックエンドサーバー、バックエンドに表示されます、私は桟橋とTomcatが同じであると信じています。
この現象は、それを生産テストを行う方法です。
コマンド：AB -n 100 -c 5のhttp：//pxe1.hy01/
pxe1.hy01（nginxの、長いリンクの上方に配置され、IP：10.0.31.84）が、それはポート8888 pxe0.hy01に行く（竜巻、IP：10.0.11.12）
pxe1.hy01で試験した場合、パケットキャプチャのコマンドを実行します。
＃tcpdumpの-i EM2 -Aホスト10.0.11.12 -n
参照してください：
00：22：53.252039 IP 10.0.31.84.53915> 10.0.11.12.ddi-TCP-1：フラグ[P.]、配列81：161、ACK 275、123を獲得し、長さ80
@]。。。
..T
... ..」...のp％8 | ..P .. {> ... GET / HTTP / 1.1
ホスト：http_backend
のUser-Agent：ApacheBench / 2.3
受け入れます：* / *
次のように長いリンクが配置されている場合は、pxe1.hy01が削除され、その取得は次のようになります。
00：23：58.111974 IP 10.0.31.84.54051> 10.0.11.12.ddi-TCP-1：フラグ[P.]、配列1：100、ACK 1、115を獲得し、長さ99
。。E ... .. @ @ Z =
..T
。...＃」... O ... SUP..s> ... GET / HTTP / 1.0
ホスト：http_backend
接続：近く
のUser-Agent：ApacheBench / 2.3
受け入れます：* / *
上記の現象は説明するようなので、これは次のようになります。
長い接続nginxのNginxは、バックエンドが新しい要求を作成する新しい接続を処理するのに十分ではない、と私たちの設定が死んでHTTP1.1を設定されている場合は、接続が確立された後、バックエンドは、「長い接続」と考えられているが、通常は（ない積極的に密接な接続を行いますアイドルタイムアウト）がある、接続がやってnginxのによって閉鎖されているので、TIME_WAIT nginxのの多くが表示されます。
デフォルトで、後端にnginxのHTTP1.0要求、処理の後端後端TIME_WAITで活性近い接続の完了後。
だから、今は新しい問題であり、十分な長さの長いオープンな接続、および多数の接続とは、その後、nginxのは、ポートの枯渇に疲れあれば、非常に深刻な影響をリードし、TIME_WAITポート集約型の存在する可能性がある場合。