Node.jsでの無数の同時接続

TL; DR：

• Node.js v0.8では、追加設定なしでIntel Core i7 Quad / 16 Gb RAMで100万の同時HTTP Comet接続を処理できます。
• 1つの接続は10 Kbを少し超えるメモリを消費します（4.1 Kb Javascriptヒープ+ 2.2 Kb Node.jsネイティブ+ 3.8 Kbカーネル）..
• V8ガベージコレクターは、500 MB以上のメモリを管理するようには設計されていません。 超過した場合は、ガベージコレクションの代替モードに切り替える必要があります。そうしないと、サーバーの「応答性」が大幅に低下します。
• このような経験は、あなた自身で多くの費用をかけずに繰り返すことができます（そしてそうすべきです！）。

はじめに

外国のブログでは、 Mochiweb / Erlangを使用したクラシックなA Million User Comet Applicactionから、最新のNode.js w / 250k同時接続まで、同時接続の最大数のいくつかのテストがレビューされました。 私のテストで達成したいのは、再現性です。 他の人が問題なくテスト結果を繰り返すことができるように。 テストで使用されたすべてのコードはgithubに投稿されました： serverおよびclient 、ようこそ。

サーバー

1.鉄

もちろん、このようなテストを実行するには専用サーバーが必要です。 お気に入りのホスティングプロバイダーに注文するか、既存のプロバイダーを使用します。 Hetzner EX4 （Core i7-2600 Quad、16Gb RAM）を使用しました 。これは非常に安価で強力です。

2.オペレーティングシステム

Ubuntu 12.04 LTSを使用しています。 おそらく私のテストは他のLinuxでも使用できますが、わずかな変更が必要です。 ほとんどの場合、これは他のOSでは機能しません。 ネットワークは、多数の接続用にLinuxをセットアップすることについて多くのことを話しました。 喜ばしいことに、これはほとんど必要ありませんでした：

#/etc/security/limits.conf #     (     ). * - nofile 1048576
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 #/etc/sysctl.conf #   netfilter/iptables,     : net.ipv4.netfilter.ip_conntrack_max = 1048576
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3. Node.jsのコード

すべてのテストはNode.js v0.8.3を使用します。

標準のクラスターモジュールを使用して、いくつかのプロセスに負荷を分散します（コアの数によって）。 Nagleアルゴリズムを無効にします 。

 // Server.js () var cluster = require('cluster'); var config = { numWorkers: require('os').cpus().length, }; cluster.setupMaster({ exec: "worker.js" }); // Fork workers as needed. for (var i = 0; i < config.numWorkers; i++) cluster.fork()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 // Worker.js () var server = require('http').createServer(); var config = {...}; server.on('connection', function(socket) { socket.setNoDelay(); //   . }); var connections = 0; server.on('request', function(req, res) { connections++; //   ''  20  // = 50     1   var pingInterval = setInterval(function() { res.write('ping'); }, 20*1000); res.writeHead(200); res.write("Welcome!"); res.on('close', function() { connections--; clearInterval(pingInterval); pingInterval = undefined; }); }); server.listen(config.port);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

便宜上、何が起こっているのかを監視するために、端末の多くのシステムパラメータの追跡と表示、およびそれらのログを追加しました。 次のように、サーバー上でこの奇跡の対話性を起動できます。

 git clone git://github.com/ashtuchkin/node-millenium.git cd node-millenium #     8888. node server.js
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のような写真が表示されます。





ここでは次のことに注意してください。

1. プロセッサの使用率は、コアの数に応じてどこにでもあります。 つまり 4コアプロセッサでは、最大負荷は400％です。
2. 「使用済み」メモリにはbuf +キャッシュは含まれません。 つまり 使用する必要があります+無料+（buf +キャッシュ）=サーバー上の合計メモリ。
3. 各プロセスについて、そのpid、プロセッサ負荷共有（ユーザー+ sys）、RSSメモリ、接続数、os.memoryUsage（）によるheapUsed / heapTotal、プロセスの応答性の3つの次元（ティック、以下を参照）が表示されます。

プロセスのこの「応答性」とは何ですか？ 条件付きで、これはイベントループNode.jsによって処理される前にイベントが待機する必要がある量です。 このパラメータは、少なくともリアルタイムに依存するアプリケーションでは重要ですが、計算するのはかなり困難です。



次のように測定します。

 //  Node.js      10     . var ticks = []; setInterval(function() { ticks.push(Date.now()); }, 10); //    . setInterval(function() { // 1.    : ticks[i] = ticks[i+1]-ticks[i] // 2.     ticks   (tick-avg), 90-    (tick-max). // 3.         . ticks.length=0; }, 1000);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エラーと加算のバランスとして10ミリ秒の測定間隔が選択されたことに注意してください。 システム負荷。 10/10/10ミリ秒が表示される場合、これはNode.jsが各イベントの処理に10ミリ秒を費やすことを意味しません。 つまり、10 msの測定グリッドを使用すると、イベントループは毎回無料で、着信イベントを一度に処理する準備ができます。つまり、イベント処理の平均時間が大幅に短縮されます。 ガベージコレクターまたは長時間の操作が有効になると、すぐに確認して修正します。



ログはCSV形式で維持され、1秒ごとにシステムのすべての統計情報が記録されます（ githubのリストを参照）。

お客さま

奇妙なことに、必要な負荷を提供することは、サーバーを作成するよりも困難でした。 実際には、TCP接続は4つの[送信元IP、送信元ポート、送信先IP、送信先ポート]によって一意に決定されるため、1台のマシンから1つのサーバーポートまで（送信元ポートの数で）同時接続を64,000を超えて作成できません。 ここで説明するように、異なるIPで16のネットワークインターフェイスを作成することは可能ですが、マシンがホスト上にある場合は困難です。



その結果、1時間あたり2セントでAmazon EC2マイクロインスタンスを使用することが決定されました。 このようなマシンは、プロセッサと特にメモリの制限により、約25,000の接続を安定して保持することがわかりました。 したがって、実行中の40個のインスタンスは100万の接続を提供し、1時間あたり0.8ドルの費用がかかります。 まったく問題ありません。



それとは別に、デフォルトでは、Amazonは、1つのリージョンで20を超えるインスタンスを発生させないことを言わなければなりません。 この制限を増やすリクエストを残すか、いくつかのリージョンでインスタンスを上げることができます。 私は後者を選びました。



最初に、1台のマシンをセットアップし、カスタムAMI作成メカニズムを使用して40回コピーしました。これは、Webインターフェイスを使用して簡単に実行できます。 しかし、サポートするのが難しすぎて管理できないことが判明したため、別のメカニズムに切り替えました： User Data and Cloud Init 。



つまり、標準のUbuntuイメージが使用され（各リージョンで異なる）、インスタンスの起動時にスクリプトがパラメーターとして指定されます。 インスタンスのレイズ直後に実行されます。 このスクリプトでは、ベアシステムにNode.jsをインストールし、必要なファイルを作成して、特定のポートをリッスンするノードを実行します。 さらに、このポートでは、サーバーのステータスを確認したり、コマンド（たとえば、どのIPアドレスで確立する接続の数）を指定したりできます。 チームから作業中の「ドローン」までの時間は約2分です。



すばらしいこと- クライアントコードは、インスタンスを起動する前に編集できます。



ec2-fleetプロジェクトと次のコマンドを使用して、自分で試すことができます。

 git clone git://github.com/ashtuchkin/ec2-fleet.git cd ec2-fleet #     npm install #    accessKeyId, accessKeySecret     Amazon. # https://portal.aws.amazon.com/gp/aws/securityCredentials # ,        (  ) # !         Security Group 'default'   # TCP  8889  source 0.0.0.0/0 -       . nano aws-config.json # , , 10    . #     . ,     . ./aws.js start 10 #      (  top).     . ./aws.js status #   (,     ,   ) ./aws.js set host <ip> #     1000  ./aws.js set n 1000 #    - 25000  ./aws.js set n 25000 #     .    . ./aws.js set restart 1 #      .  -  . ./aws.js stop all
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テスト

それでは、テストを始めましょう。 ここおよび以下のテストでは、100万の接続を作成し、毎秒5万のメッセージを作成します。 Node.jsバージョンv0.8.3。 処理は、サーバーコアの数に応じて8つのプロセス（「ワーカー」）で実行されます。

node server.js

最初のテストでは、標準構成自体で、追加のフラグなしでnode.jsを実行します。 最初のテストを開始します（すべての写真はクリック可能です）：





すべてのグラフで、黒い点線は最大値が100万の接続の数を示します水平-テストの開始からの秒数、垂直線は分を示します。 メモリグラフは以下を示します：合計-使用されたメモリの合計数（思い出すと、テストは合計メモリ容量16 Gbのサーバーで実行されました）、合計netto-最初の秒と比較した合計の増加（このマシンでさらにいくつかが回転しているため導入されました）私のプロジェクトのうち、合計で〜1.3 Gb）、RSSメモリ、JSヒープ合計、JSヒープ使用量-すべてのnode.jsプロセスのRSS合計値（リンク）、JSヒープ合計、JSヒープ使用量を占めています。



視覚的には、灰色の領域のサイズはカーネルによって割り当てられたメモリの量、黄色の領域-node.jsのネイティブ構造、緑-JSヒープを示しています。



ご覧のとおり、ピーク時の合計nettoは10 Gbであり、安定して保持されています。 実験後、ネイティブのnode.js構造を除き、すべてのパラメーターは元の値に戻ります。 以下に戻りましょう。



同じテストでのCPU使用率：





ここではすべてが簡単です-8コア= 800％。 合計-合計負荷、CPU（合計とほぼ同じ）-node.js、ユーザー、Sysプロセスの合計負荷-それぞれユーザーモードとカーネルの合計負荷 線は、移動平均10秒で平滑化されます。



このチャートは、率直に言って、私を失望させました。 負荷が大きすぎるため、何に費やされているかが明確ではありません。 接続の受信は正常で、1秒あたり約5〜7千の接続でした。明らかに、このシナリオは最適化されています。 ただし、特に大規模なバッチでは、切断により負荷が大幅に増加します（グラフ上で、約3分間、40万の接続をすぐに切断しようとしたときの負荷の800％）。



イベントループの動作を見てみましょう。





このグラフは、8人のワーカーの平均tick-avg値を示しています（残念ながら、バグのためtick-maxは復元できませんでした）。 スケールは、大きな変動を反映するために対数です。 黄色の線は、20秒の移動平均を示しています。

ご覧のように、平均で100万の接続で、イベントループには1秒あたり10回しかアクセスできません（黄色の線〜100ミリ秒）。 ただダメです。 40万の接続が切断されると、平均イベント処理時間は400ミリ秒に増加します。



Googleを意図した目的で使用し、小規模のいくつかの実験を行った後、負荷の主な部分はガベージコレクターによって引き起こされることがわかりました。 。 この動作の責任はNode.jsとV8の境界のどこかにあり、アイドル通知メカニズムに関連しています。 要するに、これは作業が現在行われていないことと、特にJS HeapTotal> 128Mbの場合にNode.jsが悪用しているゴミをクリーンアップする時間があることを示すV8のシグナルです。

node --nouse-idle-notification server.js

幸いなことに、フラグ--nouse-idle-notificationを追加することで、このシグナルをオフにできます。 2番目のテストでこれがもたらすものを見てみましょう。





まず、メモリ消費が1 GB（10％）増加し、最後の接続の5分後に安定していることがわかります。これは一般に悪くありません。 また、グラフの「ノコギリ」の性質が見えます。 なんで？



簡単なテストで1人のワーカーのメモリ消費量のグラフを見てみましょう。





今では明らかです-約5分ごとに、各ワーカーでガベージコレクションが行われ、合計メモリのグラフに「のこぎり」が形成されます。



プロセッサとイベントループを見てみましょう。







まあ、それははるかに良いです！ 8個の2〜3個のコアから100万の化合物がロードされます。



3番目のテストで、ガベージコレクターがIdleNotificationなしでうまく機能するかどうかを見てみましょう。





このグラフは、まず、黄色の領域（Node.jsのネイティブ構造）がまだリークしていないが、再利用されたことを示しています。 第二に、ガベージコレクションの方が優れている可能性があります。

node --nouse-idle-notification --expose-gc server.js

さて、私たちはガベージコレクションを自分たちの手に取ります。 フラグ「--expose-gc」を指定してnode.jsを実行し、gc（）を呼び出します。 4回目のテストでは1分間に1回：









まあ、悪くない。 メモリは非常に迅速に解放され、プロセッサは制御されますが、1分に1回、tick-avgバーストが発生します。 これは良い妥協だと思います。

次は？

まず、独立したテストで結果を確認する必要があります。 私はそれを簡単にするためにすべてをしました。 良いマシンがアイドル状態の場合は、自分の道を進んでみてください-これは非常に興味深いです。



第二に、このベンチマークが現実からほど遠いことは明らかです。 おもしろい実際のアプリケーションとして、jabberサーバーの類似物を作成し、同じボリュームでテストするとよいでしょう。

いずれにせよ、現在のフレームワークがNode.jsおよびV8開発者のさらなる最適化に役立つことを願っています。



第三に、見つけるにはさらに実験が必要です。

• Nagleアルゴリズム（socket.setNoDelay（））をオンまたはオフにすることにより影響を受けるもの。
• 接続ごとに20秒に1つのメッセージでは不十分です。 サーバーは1秒あたりいくつのメッセージを維持できますか？ おそらくこれは実際のプロジェクトの制限になるでしょう。
• / proc / sockstatを使用して、ソケットのカーネル割り当てをより正確に決定できます。
• 黄色の領域が解放されないのはなぜですか（Node.jsネイティブ） これは何ですか これはどのように修正できますか？
• ソケットを閉じると、開くよりもプロセッサに多くの負荷がかかるのはなぜですか？
• TCPのカーネル設定を試してみてください。また、netfilter / conntrack / iptablesモジュールをオフにしてください。メモリに良い影響を与える可能性があります。
• 40個のAWSインスタンスでメソッドを使用して、他のテクノロジー（Erlang、Java NIO、Twistedなど）をサーバーにロードしてみてください。 仕様を比較します。
• プロセス間通信はどのくらい高速ですか？ プロセス間でオープンな記述子を渡し、部屋ごとにグループ化して、クライアント間の対話をローカライズすることは可能ですか？ これは実際のプロジェクトで大いに役立ちます。