node.jsアプリケーション、nginxをベースサーバーとしてスケーリングしますが、キャッシュ用にニスまたはredisを使用しますか？

Question

私はnginxやニスの使用に精通しているとは言えませんが、これが現時点での私の設定です。

Json、htmlテンプレート、またはsocket.ioイベントのいずれかを提供するnode.jsサーバーを実行しています。次に、すべての静的コンテンツ（css、jsなど）を提供しているノードの前でnginxを実行しています。

この時点で、静的コンテンツと動的コンテンツの両方をメモリにキャッシュしたいと思います。

ワニスは静的コンテンツを非常にうまくキャッシュでき、アプリケーションコードに触れる必要がないことは私の理解です。また、動的コンテンツをキャッシュすることもできると思いますが、Cookieヘッダーはありませんか？

私は現在、セッションデータを保持するためにredisを使用しており、重要ではないが楽しい統計を追跡するなど、将来的に他の目的で使用する予定です。

サイト上のすべてのキャッシュをどのように処理すればよいのかわかりません。私はそれがこれらのオプションに帰着すると思いますが、もっとあるかもしれません：

Nginxの前にワニスを投げ、ワニスに静的ページをキャッシュさせます。アプリコードは変更されません。 Redisは、アプリコードの変更が必要な動的db呼び出しをキャッシュします。
ワニスの使用を完全に無視し、redisにすべてのキャッシュを処理させてから、nginx-redisモジュールの1つを使用します。これが（静的ファイルの）多くのアプリコードの変更を必要とするかどうかはわかりません。

Nginx + varnishとnginx + redisを比較するベンチマークを見つけることができず、経験が浅すぎて自分でベンチマークすることはできません（構成がひどい可能性が高い）。

私は基本的に、req/secの点で最も効率的で、将来的にスケーラブルなソリューションを探しています（問題に新しいハードウェアを投入し、構成内のいくつかの値を調整する=新しいサーバーを半無痛で稼働させる）。

Ladadadada · Answer

純粋に静的なコンテンツの場合、通常、nginxやApacheなどの成熟したWebサーバーの前でVarnishを実行しても、ほとんど利点がありません。（node.jsはまだ使用していないため、話すことができません。）これは、カーネルが最近アクセスしたファイルをRAMに格納するファイルシステムキャッシュを維持しているためです。正確にwhichファイルをキャッシュに保持し、どれを排出するかを選択する際に、Varnishがカーネルよりもわずかに優れた仕事をする可能性がありますが、より悪い仕事をする可能性もあります。これは、システムが他に何をするか、およびキャッシュ保持ポリシーの違いによって異なります。 Webサーバーの前にプロキシがあることによって生じる余分な待ち時間は、Varnishとカーネルファイルシステムのキャッシュの違いをはるかに超えます。

あなたは正しいですワニスは_Set-Cookie:_ヘッダーで送信された応答をキャッシュしません。また、リクエストに_Cookie:_ヘッダーが含まれている場合は、キャッシュの確認をスキップします。これは、特定のページにアクセスするユーザーごとにそのような一意の応答が1つあり、各ユーザーが同じページに再度アクセスする可能性が低いためです。つまり、キャッシュは使用されないエンティティでいっぱいになります。

ワニスcan動的コンテンツをキャッシュします。これが、その魅力です。あなたのウェブサイトのフロントページがPHPコードコンパイルとコールドキャッシュでの20のデータベースクエリを必要としているとしましょう。ウォームキャッシュ（APC、memcached、Redis、MySQLクエリキャッシュなど）ではまだ必要ですmemcached/Redisを検索し、リクエストに含まれるすべてのPHPファイルでstat()を実行します。適度に最適化されたサイトがあると仮定すると、これは少なくとも1/10秒（そしてそれはかなり最適化されています;私の経験では1〜3秒がはるかに一般的です）Varnishは1/1000秒未満で同じページを喜んで提供します。しかしそれはあなたのユーザーができることを意味します_Cookie:_ヘッダーを取得できないため、Webサイトのフロントページにログインしませんが、これが許容できる場合は、Varnishが簡単に勝ちます。

ワニスも正しいキャッシュヘッダーが必要です。オブジェクトをキャッシュしても安全かどうかわからない場合は、キャッシュしません。これらすべての要件を満たしている場合は、ワニスがツールになる可能性があります。とはいえ、正しいヘッダーを配置するだけで、クライアントはコンテンツ自体をキャッシュすることになり、Varnishよりもはるかに大きな違いが生じる可能性があります。

セットアップを自分でベンチマークする経験が不足している場合は、今がその経験を得るときです。構成の適切性を評価するためのベンチマークを行っています。何かを試してabを実行し、次にoneを変更して、それに対してまったく同じ方法でabを実行します。構成。これで、どちらが「優れている」かがわかります。すすぎ、繰り返します。（また、常にabを2回実行し、最初の結果を無視します。これにより、ウォームキャッシュのみをテストし、コールドキャッシュに対してテストされたために1つの構成が悪いと誤解しないようにします。）

Webサイト向けのスケーラブルなソリューションの設計は、ServerFaultの回答に収まらないほど複雑なトピックです。これらの問題が発生した場合は、その個々の部分（「memcachedサーバーをmemcachedクラスターにスケールアウトするにはどうすればよいですか？」など）を確実に支援できます。

さらに読む：

少し前に、ベンチマーク時にボトルネックを見つけるに関するセクションがある回答を書きました。
Wombleは最近私にボトルネックを見つけるための優れた投稿を指摘しました。