Node.jsのバグを修正し、誤ってパフォーマンスを2倍にする方法

それはすべて、 Node.jsで実行されているImpressアプリケーションサーバーでHTTP 408 Request Timeoutエラーの戻りを最適化したという事実から始まりました。 ご存じのとおり、http.Server ノードには、指定された時間内に閉じられなかった場合に、開いているソケットごとに発生するタイムアウトイベントがあります。 各リクエストではなく、つまりそれを明確にしたい 関数が2つの引数（req、res）を持っている各リクエストイベント、つまり各ソケットに対してではありません。 単一のソケットを介して、 キープアライブモードの多くの要求を順番に受信できます。 このイベントを設定する場合、server.setTimeout（2 * 60 * 1000、関数（ソケット）{...}）を使用して、ソケットsocket.destroy（）を自分で破棄する必要があります。 ただし、ハンドラーをインストールしない場合、http.Serverには2分でソケットを自動的に破棄する組み込みのハンドラーがあります。 このタイムアウトで、408エラーを出して、インシデントが解決したと考えることができます。 1つのことがなければ...中断されたソケット、既に応答を受け取ったソケット、クライアント側で閉じられたソケット、一般的にキープアライブモードのすべてのユーザーに対してタイムアウトイベントが発生することに驚いた。 この奇妙な振る舞いは非常に複雑であることが判明したため、以下で説明します。 タイムアウトイベントに1つのチェックを挿入することは可能ですが、私の理想主義では抵抗できず、バグを1レベル深く修正するのに役立ちました。 http.Serverでは、キープアライブモードがRFCを介してだけでなく、公然と追加されていないことが判明しました。 接続の個別のタイムアウトと個別のキープアライブタイムアウトの代わりに、すべてが高速タイムアウト（登録/登録解除）で実装される同じタイムアウトにありますが、デフォルトでは2分に設定されています。 ブラウザがキープアライブでうまく機能し、それを効果的に再利用するか、未使用の接続を閉じても、それほど怖くはありません。

最初に結果

12行の変更後、タイムアウトイベントは、サーバーがクライアントに応答せず、クライアントがそれを待つときにのみ発生し始めました。 接続タイムアウトはデフォルト値の2分のままですが、http.Server.keepAliveTimeoutはデフォルト値の5秒（Apacheなど）で表示されました。 修正リポジトリ： tshemsedinov / node （node.js 0.12の場合）およびtshemsedinov / io.js （io.jsの場合）。 すぐに、それぞれjoyent / nodeとnodejs / nodeにプールリクエストを送信します（以前のio.jsですが、現在は既にプロジェクトを結合しています）。



修正の本質は、接続がハングしてリクエストが応答されないままで、ソケットが開いている場合に接続タイムアウトが機能するはずであるが、すべてのリクエストが応答されると、キープアライブモードで別のリクエストを送信する機会を与える必要がはるかに少なくなる必要があることです。



副作用についてはすでに推測できます。多くのメモリとソケット記述子が解放され、現在の高負荷プロジェクトですぐに全体のパフォーマンスが2倍以上向上しました。 ここで、コードを使用した小さなテストを示します。その結果は下のグラフで確認でき、何が起こっているのかを知ることができます。

テストの本質：15,000のHTTP / 1.1接続（特別なヘッダーがなくてもデフォルトでキープアライブと見なされる）を作成し、ソケットの作成とクローズの強度とメモリ消費を確認します。 テストは200秒間実行され、データは10秒ごとに記録されました。 左側のグラフは修正なしのNode.js 0.2.7であり、右側のグラフはNode.jsにパッチを適用して再構築したものです。 青い線は開いているソケットの数、赤い線は閉じたソケットの数です。 もちろん、これを行うには、すべてのソケットを配列に書き込む必要がありましたが、メモリを完全には解放しませんでした。 したがって、テストのクライアント部分には、メモリをチェックするためのソケットの配列を使用する場合と使用しない場合の2つのオプションがあります。 予想どおり、ソケットは2倍速く解放されます。これは、記述子を占有せず、オペレーティングシステムのTCP / IPスタックをロードしないことを意味します。ノードに加えて、各記述子のデータ構造とバッファを保持します。

青い線はRSS（常駐セットサイズ）-合計プロセスにかかる時間、赤い線-ヒープ合計-アプリケーションに割り当てられたメモリ、緑の線-使用されたヒープ-使用されたメモリ 当然、解放されたすべてのメモリは、最初の割り当てよりも高速で、他のソケットに再利用できます。



テストコード：

問題の詳細

クライアント側がキープアライブを要求しない場合、Node.jsはres.end（）を呼び出すことですぐにソケットを閉じ、リソースリークは発生しません。 したがって、http.get（ '/'）を大規模に行うすべてのテストでは、On（ 'error'、function（）{}）またはcurl http://domain.com/またはab（apacheベンチマーク）を介して、いいね また、ブラウザは常にキープアライブを望んでいますが、ノードのようにうまく機能しません。 キープアライブの問題は、複数のリクエストを順番に送信できるだけで、各回答がどの競合リクエストに応答するかをマークするバッチメカニズムがないことです。 同意します、これは非常に不便です。 SPDYおよびHTTP / 2では、このような問題はありません。 ブラウザーが多くのリソースを含むページをロードするとき、キープアライブを使用することがありますが、多くの場合、正しいヘッダーを送信し、サーバーに開いた接続を維持するように指示し、自分自身でそれをほとんど使用しないか、無視することさえできます。 ここで、FirebugとDevToolsは、リクエストが完了し、ソケットがハングしていることを示しています。 ページがすでに完全にロードされていて、いくつかのソケットが作成されていても、それらは閉じられておらず、APIに不幸なリクエストを1つ行う必要がありますが、私の観察では、ブラウザーは常に新しい接続を作成し、ソケットはサーバーまで保持し続けることを示しています閉じます。 このような一時停止されたソケットは並列リクエストとは見なされないため、ブラウザーの制限に影響しません（私は理解しているように、ハーフオープンとしてマークされ、使用されず、カウンターから除外されます）。 これは、ブラウザを閉じると確認できます。ノードサーバーでは、2分のタイムアウトを待つ時間がないソケットの束がすぐに閉じられます。



応答がクライアント側に送信されるかどうかに関係なく、ノードのタイムアウトは2分です。 このタイムアウトを、たとえば5秒に下げることはオプションではありません。その結果、客観的に5秒以上かかる接続は切断されます。 キープアライブには別のタイムアウトが必要です。そのカウントダウンはすぐには開始されませんが、ソケットの最後のアクティビティの後、つまり これは、クライアントからの次のリクエストを待つリアルタイムです。



一般に、キープアライブを完全に実装するには、さらに多くのことを行う必要があり、クライアントから送信されたHTTPヘッダーから目的のタイムアウト時間を取得し、応答ヘッダーで実際に設定されたタイムアウト時間をクライアントに送信し、maxおよびKeep-Alive Extensionsパラメーターを処理します。 しかし、最新のブラウザはこれらすべてを使用しているわけではありません。いずれにしても、私が実施した実験では、これらのHTTPヘッダーは無視されていました。 そのため、小さな編集で素晴らしい結果が得られ、落ち着きました。

Node.jsの修正

最初に、イベントを発生させないae9a1a5を防ぐために、簡単な方法で追加のタイムアウトを使用して問題を修正することにしました 。 しかし、そのためにはコードに慣れる必要があり、コードの記述方法が気に入らなかった。 一部の場所には、関数のネストを取り除くために大きなクロージャーを分解する必要があるというコメントはありますが、テストを収集できず、多くの人々がすべての依存コードを台無しにする可能性があるため、これらのライブラリには触れません。 さて、すべては機能しませんが、ソケットのリークは私に休息を与えませんでした。 そして、私は1つのres.end（）が既に送信されたときにServerResponse.prototype.detachSocketの後にソケットを破棄することで問題を解決することを計画しましたが、これは多くの有用なキープアライブ動作を壊しました： 9d9484b 。 他のサーバーのRFCとドキュメントを読んで実験した結果、キープアライブタイムアウトを実装する必要があり、接続タイムアウトとは異なることが明らかになりました。



修正：

1. server.keepAliveTimeoutパラメーターが追加されました。このパラメーターは手動で設定できます/lib/_http_server.js#L259
2. prefinishイベント関数の名前を別の場所で使用するように変更しました/lib/_http_server.js#L455,L456
3. すべてがすでに回答された瞬間をキャッチするために、終了イベントをハングさせました。 いいえ、ソケットのタイムアウトイベントでハングするEventEmitterからハンドラーを削除し、ソケットを破壊するイベントをブロードキャストします/lib/_http_server.js#L483,L491
4. httpsサーバーの場合、keepAliveTimeoutパラメーターを追加します。これは、 / lib / https.js＃L51プロトタイプから他のすべてを継承するためです。

Impress Application Serverの場合 、これらの変更はすべて美しいパッチの形で内部的に実装され、Node.jsにパッチがなくても効果を利用できます。ソースでは、その簡単さがわかります。 さらに、最近のプロジェクトでは、SSEプロトコル（サーバー送信イベント）に基づいてクラスターに統合された4台のサーバーで1000万の永続的な接続（サーバーあたり250万）など、他の印象的な結果を達成しました。 Webソケットでも同じです。 Impressクラスターにアプリケーションバランシングを実装し、以前に使用したZMQの代わりにクラスターノードをTCPベースのプロトコルで接続しました。 この作業の結果は、次の記事でも一部公開されます。 多くの人が、この最適化とパフォーマンスを必要とする人はいないと言っています。誰もが無関心です。 しかし、少なくとも4つの高負荷のライブ例では、中国の顧客とインタラクティブテレビ形式「Seventh Sense」の場合、生産性が2〜3倍から1注文に全般的に向上していることがわかります。 これを行うには、ミドルウェアの原則を放棄し、プロセス間通信を書き直し、アプリケーションバランシングを実装する必要がありました（ハードウェアバランサーは対応できません）など。 これは、ミドルウェアを使用する際のパフォーマンスの恐ろしさについての別の記事です。「ノードが与えたもの、その後ミドルウェアが取ったもの」。 私はすでに十分な事実、統計、例を用意しており、見返りに何かを提供しています。

すぐにすべてが欲しいですか？

次に、ビルドに基づいてではなく、Node.js 0.12.7の公式バージョンでその効果を示すために、このようなパッチをテストする必要があります。 次に、リクエストイベントにさらに7行のコードを追加した場合に何が起こるかを確認します。 ソケットは必要に応じて閉じられ、余分なタイムアウトイベントを伴うエラーも消えます。これは理解できます。 しかし、メモリがあれば、状況は確かに改善されますが、Node.jsを再構築するときほどではありません。

 http.createServer(function (req, res) { var socket = req.socket; res.on('finish', function() { socket.removeAllListeners('timeout'); socket.setTimeout(5000, function() { socket.destroy(); }); }); res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

グラフの結果を比較します。左側はNode.js 0.12.7の初期状態、中央はリクエストへの7行の追加であり、公式の0.12.7で起動されます。右側は私のリポジトリからパッチを適用したNode.jsです。 この理由は明らかです。0.12.7のクローンは作成しませんでしたが、少し新しいバージョンを作成し、それを撃退しました。 もちろん、最後のテストを除くすべてのテストは、パッチを使用して、パッチを使用せずに私のリポジトリで実行されました。 そして、最後のテストを公式バージョン0.12.7と比較したので、これが現在のコードにどのように影響するかが明確になりました。

リポジトリのV8のバージョンは0.12.7と同じですが、ノードで最適化が行われたことは明らかです。 しばらく待つ場合は、上記のパッチを使用するか、修正がノードに適用されます。 これら2つのオプションの結果はほぼ同じです。 一般的に、私はこの方向で実験と最適化を続けていきます。アイデアがあれば、遠慮なく、最も重要な組み込みノードライブラリのコード変換を提案して適切な外観に接続してください。 私を信じて、あらゆるレベルの専門家のために多くの仕事があります。 さらに、ソースコードを勉強することは、プラットフォームを開発する上で知っている最良の方法です。



更新 ：_lastに別の問題が見つかりましたが、誰も計算していません。 近隣の編集とマージされ、テストされ、プールリクエストとhttps://github.com/nodejs/node/pull/2534が投稿されました。