問題タブ [rack-cache]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
327 参照

ruby-on-rails - CDN からのリクエストに対して Rack::Cache をバイパスする

Heroku にデプロイされた Rails 3.2 アプリがあります。Rack::Cacheと Amazon CloudFrontでキャッシングを使用しています。

CloudFront (主にアセット) を介して提供されるリクエストの場合、Rack::Cache を使用したキャッシング レイヤーは冗長であり、そこでは使用したくありません (heroku の memcached は高価です) 。

これらのリクエストで Rack::Cache をスキップする良い方法は何ですか?

0 投票する
0 に答える
463 参照

ruby-on-rails - Rack-Cache: 「古い、有効な、保存」

私の Rails アプリでは、expire_at ステートメントと共にページ キャッシング ソリューションを使用しています。

私のページは 1 時間有効で、その後やり直す必要があります。

なんらかの理由で、Railsサーバーが「新鮮」にサービスを開始し、その後スタイルになると、すべての単一のリクエストが「古い、有効な、ストア」として提供されます....ストアは、アプリサーバーに移動して試行することを意味します新しいコピーを取得します。

私は Heroku を使用しており、メタストアには memcached でユニコーンとラック キャッシュを使用し、エンティティ ストアにはファイル バックアップ キャッシングを使用しています。

なぜそれが起こるのでしょうか?

私のローカルの comp/dev マシンでは、同じ症状は見られません。ページが古くなると、最初のリクエストは「古い、有効な、保存された」状態で提供され、後続のリクエストは 1 時間経過して再び古くなるまで「新鮮な」状態で提供されます。

0 投票する
0 に答える
200 参照

ruby-on-rails - Rack::Cache とページ キャッシングの違い

私たちは現在、職場でサイトを更新しており、キャッシュ戦略の選択/設計を担当しています。

私たちのサイトはすべて記事ベースの雑誌サイトですが、購読が必要な制限付き記事のユーザー システムを備えているサイトもあります。

これまで、ページ キャッシングを使用して (そしてページを memcached に保存して)、JavaScript を少し使用してきました。ただし、Rack::Cache またはおそらく Varnish の方が優れたソリューションであると考えています。私が見る限り、パフォーマンスに関してはほぼ同じように機能しますか?

  • ページ キャッシングは、ページ全体を memcached にキャッシュします。このキャッシュは、将来のリクエストで nginx によって memcached から直接提供されます。
  • Rack::Cache は、ページ全体を memcached にもキャッシュしますが、キャッシュされたバージョンは nginx ではなく Web サーバーによって提供されます。Rack::Cache は HTTP キャッシング ヘッダーを使用します。これは、訪問者がブラウザにローカル キャッシュを保存することを意味します。さらに、HTTP キャッシュ ヘッダーも使用する Varnish に簡単に置き換えることができます。

2 つの戦略の違いやパフォーマンスについて、他にコメントはありますか? 両方を使用することも可能ですが、同じタイプのページをキャッシュするため、このアプローチには利点があります。

0 投票する
2 に答える
367 参照

ruby-on-rails - Rails + Rack::Cache を使用した HTTP キャッシュが無効にならない

私のRails 3アプリは、指定された期間変更され、残りのライフタイムでは静的(変更なし)になるページを生成します(スポーツのスコアボードを考えてみてください)。

これはページ全体をキャッシュする絶好の機会のように思われるので、応答の Last-Modified 部分を使用してキャッシュが無効になったことを示す Rack::Cache を選択しました。

キャッシュはうまく機能します。Last-Modified フィールドがリクエストの If-Modified-Since フィールドより後の日時で更新され、レスポンスがステータス 200 (304 ではなく) を生成した場合でも、ブラウザは引き続きサーバーにキャッシュされているページのバージョン。

サーバーのデバッグログに表示される内容は次のとおりです。

リクエスト/レスポンスの例を次に示します (200 ステータスを参照)。

関連するコントローラーでは、特定のアクションに before_filter を使用し、そのフィルターでは、ページの最後に更新されたオブジェクトで fresh_when を使用します。これにより、応答で正しい日付/時刻が生成されるように見えますが、考えられるエラーのコードを含めています (簡潔にするために show アクションを削除しました)。

0 投票する
2 に答える
183 参照

ruby-on-rails - ラックキャッシュから個々のキーを無効にしますか?

Rails アプリのパスがラック キャッシュでスタックしたとします。「/games/zelda」をラックキャッシュから削除/無効化する必要があると言う方法はありますか?