NGINXバージョン1.9.1には、
SO_REUSEPORTソケットオプションを使用できる新しい機能があります。これは、DragonFly BSDやLinux（カーネル3.9以降）などの最新バージョンのオペレーティングシステムで使用できます。 このオプションを使用すると、同じアドレスとポートで複数のリスニングソケットを一度に開くことができます。 この場合、カーネルはそれらの間の着信接続を分散します。
（NGINX Plusでは、この機能はリリース7に登場し、今年後半にリリースされます。）
SO_REUSEPORTは、さまざまな問題を解決するための多くの潜在的な用途があります。 そのため、一部のアプリケーションは実行可能コードをその場で更新するために使用できます（NGINXは、太古の昔から、異なるメカニズムを使用して
この可能性を常に持っていました）。 NGINXでは、このオプションを有効にすると、ロックのロックを減らすことでパフォーマンスが向上する場合があります。
図に示すように、
SO_REUSEPORTない
SO_REUSEPORT 1つのリッスンソケットは多くのワーカープロセスに分割され、各ワーカープロセスはそこから新しい接続を受信しようとします。
SO_REUSEPORTオプションを使用すると、各ワークフローに1つずつ、多くのリスニングソケットがあります。 オペレーティングシステムのカーネルは、新しい接続が取得されるのはどれであるかを分散します（したがって、どのワークプロセスが最終的にそれを受信します）。
これにより、マルチコアシステムは、複数のワークフローが同時に接続を受け入れる場合のブロッキングを削減できます。 ただし、これは、長い操作でワークフローの1つがブロックされると、既に処理中の接続だけでなく、キューでまだ待機している接続にも影響することを意味します。
構成
httpまたは
streamモジュールで
SO_REUSEPORTを有効にするには、
reuseportの例に示すように、
listenディレクティブの
reuseportパラメーターを指定するだけで十分です。
http { server { listen 80 reuseport; server_name example.org; ... } } stream { server { listen 12345 reuseport; ... } }
このモードではミューテックスは必要ないため、
accept_mutexを指定する
accept_mutex 、このソケットの
reuseport自動的に無効に
accept_mutexます。
reuseportパフォーマンスのテスト
36の核AWSインスタンスで4つのNGINXワークフローを使用して
wrkを使用して測定を実行し
ました 。 ネットワークのオーバーヘッドを最小限に抑えるために、クライアントとサーバーはループバックインターフェイスを介して機能し、NGINXは
OK文字列を返すように構成されました。 3つの構成を比較しました：
accept_mutex on （デフォルト）、c
accept_mutex off 、
reuseport 。 図からわかるように、
reuseport 2〜3回含めると、1秒あたりのリクエスト数が増え、遅延と変動が減少します。
また、クライアントとサーバーが異なるマシンで実行されており、htmlファイルが要求されたときに測定が行われました。 表からわかるように、
reuseportを使用すると、以前の測定と同様に遅延が減少し、その広がりはさらに小さくなります（ほぼ1桁）。 他のテストでも、このオプションを使用すると良い結果が得られます。 再利用
reuseportを使用して
reuseport負荷はワークフロー全体に均等に分散されました。
accept_mutexディレクティブを
accept_mutexと、テストの開始時に不均衡が発生し、シャットダウンのイベントでは、すべてのワークプロセスがより多くのプロセッサー時間を
accept_mutexた。
| 待ち時間（ミリ秒） | レイテンシー標準偏差（ミリ秒） | CPU負荷 |
|---|
| デフォルト | 15.65 | 26.59 | 0.3 |
|---|
| accept_mutex off | 15.59 | 26.48 | 10 |
|---|
| 再利用ポート | 12.35 | 3.15 | 0.3 |
|---|
これらのテストでは、要求の頻度は非常に高く、複雑な処理は必要ありませんでした。 さまざまな観察から、負荷がこのパターンに一致する場合に、
reuseportオプションの使用による最大の効果が得られることが確認されています。 したがって、メールトラフィックはこれらの条件を完全に満たさないため、
mailモジュールで
reuseportオプション
reuseport使用できません。 全員が独自の測定を行って、
reuseport効果があることを確認し、可能な限りオプションを盲目的にオンにしないことをお勧めします。 nginx.conf 2014カンファレンスのコンスタンチンパブロフ
によるスピーチから、NGINXの
パフォーマンスをテストするためのヒントを見つけることができます。
謝辞
SO_REUSEPORTでSO_REUSEPORTを動作させるための独自のソリューションを提案したSepherosa ZiehauとYingqi Luに
SO_REUSEPORTします。 NGINXチームは、私たちが理想と考える実装のために彼らのアイデアを使用しました。