NGINX-Windowsでの再生の歴史

ここやここなど、nginxの「週」があるので、いわば貢献しようとします。 これは、nginx 4のウィンドウ、つまり、このプロプライエタリのための多少公式なアセンブリであり、あまり人気のないプラットフォームです。



なぜWindows。 Windowsの企業部門では、サーバー上およびワークステーション上で簡単です。多くの場合、必要なプログラムです。 また、プラットフォームのこれらの要件から、たとえば、クライアントから表明された最終通告の形式では、どこにもアクセスできません。

Windowsがありますが、IIS、Apache、およびそれらのような他のユーザーを苦しめる気はありません。お気に入りのツールを使用したい場合 、nginxは間違いなくそれらを参照します。 むしろ、それは必要でした...



これらの制限があっても、nginxは、安定性、メモリ消費、そして最も重要なパフォーマンスを含む多くの要因について、Windowsの下のほとんどすべてのWebサーバーにオッズを与えることに注意する必要があります。



私はすぐに良いニュースを共有することを急いでいます-高性能のために重要な制限がさらにあります。窓の下でngi​​nxを使用する場合、実際にはありません。重要なものの最後は、高い確率ですぐに消えます。 しかし、順番に...



ここでは 、nginx 4ウィンドウの既知の問題について説明します 。

• ワークフローは、最大1024の同時接続を処理できます。
• これらのバージョンのWindowsではアドレス空間のランダム化が有効になっているため、共有メモリのサポートを必要とするキャッシュおよびその他のモジュールはWindows Vista以降では機能しません。
• 複数のワークフローを実行することは可能ですが、実際に機能するのはそのうちの1つだけです。

私は注文を少し変えました これらの制限を理解したのは、この順序で「歴史的に」分類されています。

1024の同時接続

実際、これは真実ではなく、むしろ真実ではありません-太古から、nginxはこの制限なしでWindowsで構築できました-構築段階で必要な接続の数に等しいFD_SETSIZE



を決定する必要がありました。

たとえば、VSの場合、ディレクティブ--with-cc-opt=-DFD_SETSIZE=10240



追加すると、構成でworker_connections 10240;



を指定すると、nginxワーカーは10Kの同時接続を管理できますworker_connections 10240;



。

共有メモリのサポートを必要とするキャッシュおよびその他のモジュール

最近まで、これらのすべての機能とモジュールは、x64バージョンから、またはデフォルトでシステム全体がASLRをオンにして動作するWindowsで実際に動作しませんでした。

さらに、nginxのASLRを無効にしても何も変わりません。 共有メモリを操作するための関数は、カーネルの奥深くに配線されています。 ASLR（およびおそらくDEP、何らかの理由で動作しませんでした）は、システム全体で無効にする必要があります。



これは実際には、機能の小さなリストではありません：キャッシュ、ゾーン、それぞれ、limit_reqなど。 など ちなみに、共有メモリのサポートなしでは、3番目の制限、つまり、 Windowsで複数のワーカーのサポートを実装します。



私はこれに苦労したので読者を退屈させるつもりはありませんが、Max（ mdouninに感謝）と一緒にリリースバージョンまでやりました。 これについては、興味のある方は、ネタバレやhg.nginx.orgまたはgithubのソースを参照してください...



つまり 公式には、この制限は2015年4月28日付けのリリース1.9.0では無効になりました。

 Feature: shared memory can now be used on Windows versions with address space layout randomization.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際に機能するワークフローは1つだけです。

Nginxには、マスタープロセスと、ワーカーまたはワーカーと呼ばれる子プロセスがあります。

Windowsでは、nginxはいくつかのワークフローを実行できます。 構成で「 worker_processes 4;



」を指定すると、ウィザードは4つの子ワークフローを開始します。 問題は、そのうちの1つだけが（SO_REUSEADDRを使用して）マスターからリスナー接続を「盗む」ことで、実際にこのソケットをリッスンすることです。 着信接続を受け入れます。 その結果、他のワーカー-着信接続なし-作業なし。

この制限はwinsockの技術的な実装に関連しており、Windows上のすべてのワークプロセスに対して分散リスナー接続を取得する唯一の方法は、マスタープロセスからソケットを複製することです。 ソケットから継承されたハンドルを使用します。

実装の詳細に興味のある人は、これまでのgithubでのみ、ネタバレやソースでそれらを見ることができます。



その結果、windowsでのnginxは、「リッスン」の観点からNを開始し、最も重要なことには、接続を確立し、着信接続を実際に並行して処理するワークフローを開始します。



この修正は実際には「プールリクエスト」にあります（変更セットをnginx-devに送信しました）が、たとえばgithubからダウンロードして、 Windowsで自分でビルドすることで、既に試すことができます。 希望する人がいれば、どこかにバイナリを投稿します。



私はかなり長い間ハードウェアを拷問し、テストと負荷のある「スクリプト」の下でそれを追いかけました-その結果、すべてのワーカーはほぼ均等にロードされ、実際に並行して動作します。 また、nginxを再起動するためにオンザフライ（リロード）を試み、後者の「クラッシュ」をシミュレートして一部のワーカーをランダムに「殺し」ました。

これまでのところ、唯一の「欠陥」が現れました、私見-あなたが実行した場合

 netstat /abo | grep LISTEN
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「リスナー」のリストにはマスタープロセスのみが表示されますが、実際には接続を確立することはなく、子ワークフローのみを確立します。



ちなみに、これまでの私の経験では、Windowsプラットフォームのaccept_mutex



はおそらく「 accept_mutex off;



」を無効にする必要があるとaccept_mutex off;



少なくとも私のテストシステムでは、 accept_mutex



有効accept_mutex



すると、無効にした場合よりも大幅に遅くなりました。 しかし、私は誰もがこれを実験的にチェックすべきだと思います（コアの数、ワーカー、キープアライブ接続などのパラメーターの束に依存するため）。



さて、パフォーマンス比較番号を持つ美しいプレートがないように、前（最初の列は** NFとマークされています）と後です。

テストはWindows7で行われます-i5-2400 CPU @ 3.10GHz（4コア）。

リクエスト：静的、452バイト（+ヘッダー）-小さなgifアイコン。

労働者x同意。	1 x 5 ** NF	2×5	4 x 5	4 x 15
取引	5624ヒット	11048ヒット	16319ヒット	16732ヒット
在庫状況	100.00％	100.00％	100.00％	100.00％
経過時間	2.97秒	2.97秒	2.97秒	2.96秒
転送されたデータ	2.42 MB	4.76 MB	7.03 MB	7.21 MB
応答時間	0.00秒	0.00秒	0.00秒	0.00秒
取引レート	1893.60トランス/秒	3719.87トランス/秒	5496.46トランス/秒	5645.07トランス/秒
スループット	0.82 MB /秒	1.60 MB /秒	2.37 MB /秒	2.43 MB /秒
並行性	4.99	4.99	4.99	14.92
成功したトランザクション	5624	11048	16319	16732
失敗したトランザクション	0	0	0	0
最長トランザクション	0.11	0.11	0.11	0.11
最短取引	0.00	0.00	0.00	0.00

また、nginxがWindowsの下にもあります。