6

私は大量のデータを持つサイトを持っており、次のようにすべてのページで「ロシア人形」のキャッシュを行っています。

# articles.html.haml
- cache "list of articles", expires_in: 15.minutes do
  = render partial: "article", collection: @articles

# _article.html.haml
- cache article do
  = article.body
  = render partial: "comment", collection: article.comments

# _comment.html.haml
- cache comment do
  = comment.body

これにより、数十万のフラグメントが作成されます。

1. /tmp/cache ディレクトリに非常に多くのフラグメント ファイルがあると、パフォーマンスが低下しますか?

2.古いフラグメントが自動期限切れになると、Rail は古いフラグメントを自動的に削除しますか?

PS。このサイトは、4GB RAM を搭載した単一の Ubuntu サーバー上にあります。キャッシュ ストアとして memcached を使用するのではなく、標準のファイル ベースの実装をレールですぐに使用できます。

4

2 に答える 2

1

Windows サーバーでホストされていない限り、Rail のキャッシュ内の複数のフォルダーに 10 万個のファイルが分散していても、パフォーマンスが低下することはありません。

于 2014-02-03T04:18:16.293 に答える
1

ある時点で、フラグメントを生成するよりもキャッシュ ヒットの方がコストがかからないかどうかを自問する必要があります。答えが「はい」の場合(そしてこれをベンチマークできる場合)、キャッシュされていない状況と比較してパフォーマンスが向上します。ただし、物理 (プラッター) ハード ドライブに数十万のキャッシュ フラグメントが保存されている場合、I/O ボトルネックには非常に注意を払う必要があります。これが問題になる場合は、キャッシュ戦略の深さを制限して、ファイルの数を減らすことができます。繰り返しますが、ベンチマークしてください。この特定のケースではヒット率が高いと I/O が制限されるため、ヒット率はここでは非常に重要な統計です。

パフォーマンスが気になる場合は、フラグメントが期限切れになる頻度も確認してください。あなたの特定の状況では、コメントが投稿されるたびに「記事のリスト」が無効になります。現在は 15 分ごとに期限切れになりますが、出力の一貫性を保つには、コメントまたは記事が配置または編集された直後に実際に期限切れになる必要があります。記事のリストに毎分複数のコメントがある場合は、個々のコメントをここにキャッシュすることも絶対に正しい. I/O が問題になった場合は、いつでも RAM を追加して memcached (または redis) を使い始めることができます。

ただし、複数層のキャッシングがあるため、ここでは、親の「記事のリスト」フラグメントへのヒットに加えて、ファイル システムへのヒットが 2、3 回だけで、まったく問題ない可能性があります。

于 2014-01-21T16:37:41.987 に答える