0

私はかなり遅いコントローラー アクションを持っています。数日ごとにデータを更新するだけでよいので、結果を静的にキャッシュするのは簡単でした。

問題は、アクションが完了するまでに数分かかることであり、古いデータを期限切れにして新しいデータに置き換える最適な方法がわからないことです。

現在、一般的な有効期限/リクエストの問題は、数分間 (アクションが実行されている時間) の間、これらのデータが利用できないことです。

Railsの静的キャッシュメカニズムだけを使用して、このギャップを克服する合理的な方法はありますか? それとも、別の方法で全体を再構築する必要がありますか?

4

1 に答える 1

3

Rails には、新しいキャッシュ値が再生成されている間に有効期限が切れたときに、古いキャッシュをもう少し長く使用する組み込みの方法があります。Rails Guides on Cachingで説明されているように、 と組み合わせて使用​​される:race_condition_ttl設定です。:expires_in

Rails Fragment キャッシングでは、構文は次のようになります。

<% cache 'my_awesome_cache_key', :expires_in => 12.hours.to_i, :race_condition_ttl => 12.hours.to_i %>
  # This block will be cached
<% end %>

結果：

  • 1) 最初のリクエスト: キャッシュが空であるため、ブロックが実行され、結果がキャッシュに書き込まれます
  • 2) 次の 24 時間の間のすべてのリクエスト: キャッシュから直接提供されます (これは最新です)。
  • 3a) 24 時間後、ただし猶予期間内の最初のリクエストは、当時わずかに古いキャッシュから提供されます。キャッシュはバックグラウンドで再生成されます: ブロックは実行され、終了するとすぐにキャッシュに書き込まれます
  • 3b) 24 時間経過後、猶予期間外の最初のリクエストは 1) として処理されます。つまり、直接提供されませんが、ブロックが実行され、キャッシュが書き込まれ、リクエストが提供されます。

race_condition_ttl複数のプロセスがキャッシュを同時に再生成するのを防ぐために導入されました。これにより、すべてのプロセスが一度にデータベースからデータを読み取るなど、非常に要求の高いリソースになりますが、状況によってはうまくいくはずです。

:expires_inとのタイミングを選択する方法:race_condition_ttlはあなたの選択です。次のように計算することをお勧めしますexpires_in + race_condition = expires_in_that_you_would_usually_set。このようにして、特にアクション/ビューがそれほど頻繁にレンダリングされない場合、キャッシュはより頻繁に再生成されますが、より新鮮になります。

于 2012-09-22T11:23:11.020 に答える