問題タブ [rack-cache]

私はを使用してRack::Cacheいますが、グーグル検索ボットがすべてのキャッシュミスをトリガーするため、キャッシュは常に私のサイトで最も人気のあるページを表していないページでいっぱいです。IPを無視する方法を見つけることができないか、キャッシュ用のユーザーエージェント、誰かが以前にこの問題を抱えていましたか？

非常に基本的な Rails 3.1 アプリを作成し、Ruby 1.8.7 (P334) を実行するボックスにデプロイしました (残念ながら 1.9.2 に簡単に行くことはできません)。

「bundle install」を展開して実行した後、コンソールを実行しようとしました：

そして私は得る：

どのソースにもrack-cache-1.0.3が見つかりませんでした

コンソールが起動しません。

この特定のバージョンの rack-cache は、ActionPack 3.1.0 によって依存関係としてリストされているようです。

これを解決するために何をする必要があるか、誰かが私に説明できますか?つまり、バンドラーにこのバージョンのラックキャッシュをプロジェクトにアタッチしてもらいますか

また、バンドラーがプロジェクト固有の GEM を「別の場所」に保存することも読みました。つまり、グローバル Ruby GEM パスではなくなりました。このプロジェクト固有の場所のデフォルトの場所はありますか?

ああ、私もRails 3.1で「無効なgemspec」警告を大量に受け取り続けています。

[/usr/local/lib/ruby/gems/1.8/specifications/rack-cache-1.0.3.gemspec] の無効な gemspec: 仕様の無効な日付形式: "2011-08-27 00:00:00.000000000Z"

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

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

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

• http://devcenter.heroku.com/articles/http-routing
• http://devcenter.heroku.com/articles/http-caching
• http://devcenter.heroku.com/articles/cedar

Dragonflyを使用して、Rails アプリの処理済み画像を提供しています。Dragonfly は、これらの処理された画像への将来のアクセスをRack::Cacheに依存しているため、Dragonfly はこれらの画像を何度も処理する必要がなく、CPU 時間を無駄にします。

私の問題はここから始まります: Rack::Cache 経由でファイルを送信しても Rails プロセスが引き続きビジー状態であることが正しければ、30 枚の画像のページを表示すると、これらの画像のファイル サイズが小さい場合でも、Rails プロセスがかなり拘束されます。早く。さらに数人の訪問者がそのページにアクセスすると、応答時間が非常に遅くなります。これらのファイルを X-Sendfile 経由で提供するにはどうすればよいですか?

で次のように設定しましたがproduction.rb、これらは Rails のアセット用であり、Dragonfly ファイル用ではないことがわかっています。

Rack::Cache が何らかの形で X-Sendfile をサポートしていることは知っています (おそらくRack::Sendfileを介して)。これは、に応答する本体を生成するため#to_pathです。ただし、これを有効にする方法がわかりません。Rack::Cache からのファイルをチェックすると、X-Sendfile 情報が表示されません。

私は、ネット上の投稿に基づいて、次のようなものを見ることになっていることを知っています:

最終的に、Dragonfly または Rack::Cache (または両方) を構成する必要があるかどうかはわかりません。Dragonfly や Rack::Cache を取得して X-Sendfile 経由でファイルを提供するにはどうすればよいですか?

私のセットアップに関する情報:

• レール 3.1.1
• 乗客 3.0.9
• CentOS
• 私の知る限り、Sendfileモジュールがインストールされています。私は仮想ホスト構成で指定してXSendFile OnおりXSendFilePath /path/to/app、ApacheはディレクティブXSendFileが存在しないことについて文句を言いません。

ありがとう！

2011 年 11 月 6 日更新

この古い更新に基づいてRack::Sendfile、 が の前に配置されている限りRack::Cache、X-Sendfile が使用されます。私はそれをしました、そしてこれは私のミドルウェアがどのように見えるかです. ただし、ファイルにはまだ X-Sendfile タグがありません。繰り返しますが、これが X-Sendfile が有効になっているかどうかを判断する確実な方法かどうかわからないので、Passenger キューを調べました。ページにアクセスすると、キューが大幅に妨げられているようです。

2011 年 11 月 7 日更新

これは純粋に Rack::Cache と Rails 3.1 の問題のようです。Rack::Cache は Rack::Sendfile を介した X-Sendfile の使用をサポートしていますが (上で述べたように、Rack::Cache はDisk EntityStoreを使用する場合、それが返すボディは File のサブクラスであるto_pathため、 Responds_to を使用するため)、Rails 3.1独自のストレージ ソリューションを使用します。Rails 3.1 は、ファイルで何も指定しない場合、デフォルトで設定されているActiveSupport::Cache::FileStoreを使用します。production.rb

FileStore の問題は、それが返す本文がアップストリームに送信される応答の一部になることです。その本文は に応答しないためto_pathです。本体はActiveSupport::Cache::Entryのインスタンスです。ここで、FileStore がキャッシュされたファイルを読み取るように要求されると、それを読み取ってFile.open('/path/to/file') {|f| Marshal.load(f) }Entry のインスタンスを返すことがわかります。最終的にアップストリームに渡されてクライアントに戻される値はEntry#valueです。

私の質問

これにパッチを当てるか、Rails に Rack::Cache 独自のディスク ストアを使用させるかを決定するために、いくつか質問があります。

1. Rack::Cache 独自のストレージ ソリューションが Rails 3.1 で使用されなかった理由は何ですか? なぜ Rails は独自のものを持っているのですか?
2. マーシャルが使用される理由はありますか? 代わりにデータのバイトストリームを送り返す必要がある理由はありますか?

いつもより深く入り込んで、ちゃんと理解できたらビックリ。答えが見つかることを願っています！

Heroku Cedar には Varnish が提供する http キャッシングがないため、使用したいと思いますRack::Cache。Rails 3.1.1 はRack::Cacheデフォルトでアクティブになっていると言われましたが、構成に必ず含める必要があります。

使用しているこの実験では、キャッシュ ストアを選択する必要があります。

キャッシュしたいページのアクションで、次の行を追加しました。

このコードは Varnish で正常に動作していました。最初のリクエストは 200 を返し、その後 (5 分間) は を返します304。

これは、Rails 3.1 と Heroku Cedar Stack では発生しません。応答でこれらのヘッダーを取得しますが、後続の要求は 304 ではなく 200 を返します。

私は何を間違っていますか？ありがとうございました。

Rack::Cache をスタックの一番上 (最後) のミドルウェアとしてセットアップしました。私のアプリは heroku cedar でホストされているため、Rack::Cache は静的アセットも担当します。

これは heroku memcached 製品に支えられており、次のように構成されています。

薄く動いています。

ab を使用して、イメージ ファイルのパフォーマンスをテストしています。

ab -n100 -c10 https://example.com/foo.jpg

ログを見ると、すべてのリクエストがキャッシュ ヒット (「フレッシュ」) です。しかし、パフォーマンスは悪く、1 秒あたり 6 リクエスト程度しかありません。Rack::Cache が専用の http プロキシほどうまく機能しないことはわかっていますが、これよりも高いスループットを期待していたことは確かです。

更新 前にこれについて考えたことはありませんでしたが、私のベンチマークは確かに私のインターネット接続を最大限に活用しています. jpg の代わりに robots.txt を使用して同じテストを行うと、1 秒あたり 20 のリクエストが得られます (それでもダウンストリームは最大になります)。

ラックキャッシュ経由でページをキャッシュしましたが、キャッシュされたバージョンが表示されているため、ブラウザは更新されたページを表示しません。

すべてのキャッシュをクリアするにはどうすればよいですか? (注: rails_app_root/public ディレクトリからすべてのキャッシュ ページを削除しました)。ラック キャッシュを無効にしてみましたが、キャッシュされたバージョンのページが表示されます。

何か案は？

私の人生のためにこれを理解することはできません。Rack :: Cacheを使用して、静的パブリックページの一部をHerokuにキャッシュしようとしています。さらに、リバースプロキシを通過した場合に備えてアクションキャッシュを実行しています。

たとえば、私の「ホーム」アクションのコードは次のとおりです。

すべての意図と目的のために、これには最大年齢10のパブリックキャッシュ制御タグが必要です。

私はひどく間違ったことをしていますか？その古くて無効なキャッシュ応答に何か問題があるように感じます...それは私がページにアクセスしたのは約4回目です。

構成情報：

（おそらく、cache-controlヘッダーを手動で設定する方法がありますか？もっと簡単な方法があるはずですが）。

アップデート

私はコントローラーのアクションを最小限に抑えようとしました：

そして、それは機能しません...

！

こんにちは、

HTTP キャッシングを Rack::Cache およびアクション キャッシング (Heroku でホストされているアプリ) と組み合わせようとして、いくつかの問題に遭遇しました。

それらを個別に使用すると、機能しているようです。アクション キャッシュを有効にすると、ページの読み込みが速くなり、ログはキャッシュ中であることを示します。コントローラー (eTag、last_modified、および fresh_when) での HTTP キャッシュにより、適切なヘッダーが設定されているように見えます。

ただし、2 つを結合しようとすると、アクション キャッシングのように見えますが、HTTP ヘッダーは常に max_age: 0, must_revalidate です。どうしてこれなの？私は何か間違ったことをしていますか？

たとえば、「ホーム」アクションのコードは次のとおりです。

すべての意図と目的のために、これには max-age 10 no? の public cache-control タグが必要です。

構成情報:

私の考えでは、アクション キャッシングとリバース プロキシを正しく使用できるはずですか? それらがかなり似たようなことをすることは知っていますが (ページが変更されると、プロキシとアクション キャッシュの両方が無効になり、再生成する必要があります)、そこに両方を含めることができるはずだと思います。または、1つを取り除く必要がありますか？

アップデート

以下、回答ありがとうございます！うまくいくようです。しかし、すべてのコントローラー アクションに対して set_XXX_cache_header メソッドを記述する必要がないようにするために、これが機能しない理由が何かわかりますか?

RailsアプリのVarnishとRack-Cacheの目的について少し混乱しています。キャッシングではconfig/environments/production.rb、次のように設定できます

config.static_cache_control = "public, max-age=3600"

それを考えると、Railsアプリ自体でキャッシュを設定できる場合、VarnishとRack-Cacheの目的は正確には何ですか？

そして、デフォルトのRailsアプリがラックキャッシュを使用する原因は何ですか？