深入浅出ノード.js(八):Connectモジュール解析(その二)静的ファイル中間件

前のコラムではConnectモジュールの基本的なアーキテクチャを簡単に紹介しました.その実行モデルは非常に簡単で、中間部品の構造も非常に拡張しやすく、良好な伸縮性を備えています.Connectの良好な構造の下で、私達の本章はConnectの生態圏の中で中間部品の部分を次第に解いて、この部分はConnectに良好な機能の拡張を与えます.
静的ファイル中間件
あなたはまだ私が書いたNode.js静的ファイルサーバが実戦的であることを覚えているかもしれませんが、その記事ではNode.jsを利用して、静的ファイルサーバの技術的詳細をたくさん実現します.ルートの実現、MIME、キャッシュ制御、転送圧縮、安全、歓迎ページ、断点更新などを含めて.しかし、ここでは詳細を直接処理する必要はありません.Connectのstaticミドルウェアは上記のすべての機能を提供してくれます.コードはわずか3行でいいです.

var connect = require('connect');  
var app = connect(); 
app.use(connect.static(__dirname + '/public'));

プロジェクトでは、静的サーバを一時的に構築する必要があります.apacheなどのサーバーをインストールする必要がありません.NPMでConnectをインストールしてから、3行のコードで需要を解決できます.ここで言及したいのは、このモジュールを使用する点の性能に関する詳細である.
動静分離
前の章では、app.use()方法は、ルーティング情報が指定されていない場合、app.use("/", middleware)に相当する.これは、静的ファイルの中間デバイスが、すべてのパスの要求を処理することを意味する.静的要求が混在するシーンでは、静的中間ウェアは、動的要求時にもfs.statを呼び出して、ファイルシステムに静的ファイルがあるかどうかを検出する.これは性能を低下させるために不必要なシステム呼び出しをもたらした.影響性能を解決する方法は動態分離である.ルーティング検出を利用して、不要なシステム呼び出しを回避し、動的要求に対する性能影響を効果的に低減することができる.

app.use('/public', connect.static(__dirname + '/public'));

大規模なアプリケーションでは、動的分離は通常、ノード.jsの一例で行われる必要はなく、CDNの方式は直接ドメイン名上で分離を要求する.小型アプリケーションでは、静的分離を適切に行うことで、不要な性能損失を回避することができます.
キャッシュポリシー
キャッシュポリシーは、クライアントとサービス端末の2つの部分を含む.クライアントのキャッシュは、HTTPプロトコル応答ヘッダのcache-controlおよびexpiresフィールドに対するブラウザのサポートを主に利用するものである.ブラウザは、明確なヘッダを取得すると、ファイルをローカルにキャッシュし、cache-controlおよびexpiresの値に従って対応する古いポリシーを実行します.これにより、重複アクセス中に、ブラウザはローカルキャッシュからファイルを読み込むことができ、ネットワークからファイルを読み込むことなく、ロード速度を向上させることができ、サーバへの圧力を低減することができる.デフォルトでは静的ミドルウェアの最大キャッシュは0に設定されています.ブラウザが閉じたらクリアされるという意味です.これは明らかに私たちの期待した結果ではない.開発環境でmaxAgeの設定を無視できる場合を除き、生産環境は必ずキャッシュを設定してください.

app.use('/public', connect.static(__dirname + '/public', {maxAge: 86400000}));

maxAgeオプションの単位はミリ秒です.YUI 3のCDNサーバは10年間の有効期限を設定していますので、参考になる値です.静止ファイルがクライアントにキャッシュされ、キャッシュをクリアする必要がある場合、どうやってクリアすればいいですか?ここの実現方法はわりに多くて、1種の比較的に推薦する方法はファイルのためにmd 5処理を行うのです.

http://some.url/some.js?md5 

ファイルの内容が変更されると、md 5値も変更されます.ブラウザはURLによって静止ファイルを再取得します.md 5の方式は、不必要なキャッシュクリアを回避してもよく、キャッシュを正確にクリアすることができます.ブラウザ自体のキャッシュ容量の制限のため、10年の有効期限を設定することができますが、2日間後には新しい静的ファイルによってローカルキャッシュが押出されるかもしれません.これは、静的サーバの応答、すなわちクライアントキャッシュがサーバ圧力を低減する問題を完全に解決することができないことを意味する.静的サーバがディスクの繰り返し読み取りによる圧力を解決するためには、第二の関連する中間デバイスを引き出す必要がある.

app.use(connect.staticCache());  
app.use(“/public”, connect.static(__dirname + '/public', {maxAge: 86400000}));

これは上部キャッシュ機能を提供する中間デバイスで、応答速度とパフォーマンスを向上させるためにディスク中のファイルをメモリにロードすることができます.その公式テストのデータは以下の通りです.

static(): 2700 rps 
node-static: 5300 rps 
static() + staticCache(): 7500 rps

もう一つの静的ファイルのためのモジュールはstaticCacheと呼ばれ、その性能はConnect静的ファイルの中間部品の効率の二倍である.しかし、キャッシュの中間部品の協力のもとで、性能損失を補うことができます.実は、この中間部品は生産環境では推奨されていません.また、Connect 3.0バージョンでは除去されます.しかし、その実現には味のあるところがあります.Node.jsモデルの長所と短所を知るのに役立ちます.node-staticミドルウェアには2つの主要なオプションがあります.staticCacheとmaxObjects.代表的なのは、いくつかのファイルと単一のファイルを格納することができる最大サイズであり、そのデフォルト値は128および256 kbである.なぜこの2つのオプションが設定されているのかというと、V 8にはメモリ制限があるため、キャッシュとしての有効期限が切れていないとキャッシュが無限に増加します.記憶数と単一ファイルサイズを設定すると、キャッシュエリアのサイズを効果的に抑えることができます.実際には、このキャッシュにまだ存在する欠陥はシングルマシンの場合、通常はCPUを効果的に利用するために、Node.jsのインスタンスは一つだけではなく、複数のインスタンスプロセスの間に冗長なキャッシュ占有が存在し、これはメモリ使用にとって無駄である.また、V 8のゴミ回収メカニズムは、JavaScriptスレッドの実行を一時停止し、スキャンによって対象を回収するかどうかを決定する.キャッシュオブジェクトが大きすぎると、キーが多すぎるとスキャンの時間が増加し、JavaScriptがトラフィックロジックに応答する速度が遅くなります.しかし、このモジュールは存在する意味がないわけではなく、上述の欠陥の多くはV 8メモリ制限とNode.jsシングルスレッドの原因である.この問題を解決する方法が明らかになります.リスク移行はNode.jsの中で資源不足問題を解決するためによく使われています.特にメモリの問題です.キャッシュポイントを、Node.jsのインスタンスプロセスから第三者の成熟したキャッシュに移しても良いです.これは保証できます

キャッシュ内容は冗長ではない.

集中キャッシュは、不一致の発生を低減する.

キャッシュされたアルゴリズムは、より高い命中率を維持するためにより優れている.

はNode.jsを軽量化して、より得意な問題を解決します.

Connect推奨サーバ端キャッシュは、maxLengthという成熟したキャッシュエージェントを採用する.筆者の現在のプロジェクトはvarnishを通じてバックエンドキャッシュのタスクを完了します.
参考の内容

https://www.varnish-cache.org/releases

http://www.senchalabs.org/connect/static.html

http://www.senchalabs.org/connect/staticCache.html

作者について
田永強、新浪微博@朴灵、先端技術者はSAPに就職しました.現在はタオバオという名前の朴灵に就職して、NodeJSとMobile Web Appの研究開発に取り組んでいます.ダブル修理の前後にJavaScriptを持って、NodeJSをもっと多くのエンジニアに紹介したいです.趣味:万巻の本を読んで、万里の道を行く.個人のGithub住所:http://github.com/JacksonTian.