21

以前の2つのHerokuアプリケーションスタックには、httpヘッダーに基づいてコンテンツを自動的にリバースプロキシキャッシュするVarnishレイヤーが付属していました。

新しいHeroku杉スタックにはこのワニスレイヤーがありません。Herokuは、代わりにrack-cachememcacheを使用することを提案しています。

これには、ワニス層を備えた以前のスタックと比較して不利な点がありますか?ラックキャッシュを使用すると、キャッシングレイヤーにサービスを提供するサーバーが少なくなり、最適化されていない方法になりませんか?

4

4 に答える 4

17

ワニス層を削除すると、Herokuの竹から杉のスタックへのキャッシュパフォーマンス(レイテンシとスループットの両方)が大幅に低下することは間違いありません。1つは、アプリケーションリクエストがdyno時間のキャッシュヒットと競合しており、キューに入れられている可能性があることです。

いくつか例を挙げると、デメリットは次のとおりです。インタプリタされたruby(vs.コンパイル済みC)アプリケーションレベル(vs.プロキシレベル)memcachedベース(vs.プロセスメモリベース)ブロッキングI / Oベース(vs.非ブロッキングI / Oベース) 。2つのキャッシング戦略が大規模に競合する可能性があるという提案はばかげています。小規模ではあまり違いは見られません。ただし、1秒あたり数百または数千のキャッシュヒットがある場合、ワニスは実質的に劣化しませんが、杉のスタックは、静的アセットをパフォーマンスの高い方法で提供するためだけに多くのダイノを必要とします。(杉のキャッシュヒットのdyno処理時間は約5〜10ミリ秒です)。

Cedarは、パフォーマンスを向上させるためではなく、アプリケーションに新しいレベルの柔軟性を導入するために構築された方法で構築されました。長いポーリングや静的なアセットキャッシングパラメータのきめ細かい制御などのノンブロッキングI/O操作を実行できますが、目標がインターネットスケールである場合は、herokuが独自のキャッシング/帯域幅を提供することを望んでいることは明らかです。

于 2012-02-17T00:25:39.183 に答える
9

生のリクエストに関して、ラックキャッシュのパフォーマンスがVarnishとどのように比較されるかはわかりません。最善の策は、単純なアプリベンチマークを作成し、スタックを切り替えることです。

heroku.comスタックはNginx->Varnish->Appであるため、正しいHTTPヘッダーを設定している限り、Appレイヤーの作業ははるかに少なくなることを覚えておく価値があります。配信のほとんどはVarnishによって処理され、Varnishは非常に高速であるため、これによりDynoが実際のアプリ処理要求に解放されます。

herokuapp.comスタックが以前にアプリにヒットしたため、キャッシュを効率的に処理するのはあなたとアプリの責任です。これは、rack-cacheを使用して全ページ出力をキャッシュするか、memcachedを使用してデータベースリクエストを処理することを選択する可能性があることを意味します。または両方。

結局、それはあなたのアプリが何をしているかに依存します、それが多くのユーザーに同じ静的コンテンツを提供しているなら、あなたはVarnishの恩恵を受けるでしょう、しかしあなたがユーザーがログインしてコンテンツと対話するアプリケーションを持っているならあなたは勝ちました部分的なコンテンツまたは生のデータベースクエリをキャッシュする方が効率的かもしれないので、Varnishの恩恵を受けるかもしれません。New Relicアドオンをインストールすると、内部を覗いて、アプリの速度が低下している原因を確認できます。

于 2011-11-08T10:40:41.280 に答える
3

ホストされたワニスにはサードパーティのオプションもあります。Fastly/Varnishでのセットアップについて簡単な投稿を書きました。

Fastlyは、Herokuアプリの前に配置され、キャッシュされた応答を提供する、ホストされたVarnishソリューションです。

リンクの更新: https ://medium.com/@harlow/scale-rails-with-varnish-http-caching-layer-6c963ad144c6

私は本当に素晴らしい応答時間を見てきました。Varnishで良好なキャッシュヒット率を得ることができれば、dynoのかなりの割合を抑えることができるはずです。

于 2013-10-10T02:24:15.847 に答える
1

20/20の後知恵で、より現代的な答え:

杉-14の竹のキャッシングパフォーマンスに近づくために、これは通常のパターンです:

  1. 適切なキャッシュヘッダー(つまり、Etags、Cache-Control、Last-Modifiedなど)を生成するようにRailsを構成します
  2. アプリの前にすばやく貼り付ける(サービスとしてニスを塗る)か、cloudflare使用します。アプリのヘッダーが正しく設定されている場合、静的アセットとは対照的に、新鮮である必要があるプロファイルのようなページはキャッシュされません。

複数のレイヤー(FE(CF / FY)、ページ、アクション、フラグメントなど)でキャッシュを実行している場合は、ラックキャッシュバックエンドとしてredis-railsをお勧めします。

于 2015-02-17T05:44:48.820 に答える