RailsアプリのVarnishとRack-Cacheの目的について少し混乱しています。キャッシングではconfig/environments/production.rb、次のように設定できます
config.static_cache_control = "public, max-age=3600"
それを考えると、Railsアプリ自体でキャッシュを設定できる場合、VarnishとRack-Cacheの目的は正確には何ですか？
そして、デフォルトのRailsアプリがラックキャッシュを使用する原因は何ですか？
静的キャッシュ制御は、Cache-Controlのhttpヘッダーに影響します。のように、サーバーは、max-age=3600であることを中間キャッシュに提案します。
Varnish、Rack-Cache、Squidなどは、生成されたコンテンツをサーバーにアクティブにキャッシュします。データベース呼び出しはコストがかかり、要求がdbを呼び出さない場合でも、要求が通過する必要のあるインフラストラクチャが少ないほど、一般的に高速になります。
Rack :: Cacheは、HTTP標準に準拠したキャッシングをサポートするラックミドルウェアです。彼らのFAQページには、他のキャッシングソリューションに対する長所と短所に関するいくつかの良い情報があります。これは、 rack::cacheをherokuのニスと比較する質問です。Railsには、フラグメントとページのキャッシュを処理するActiveSupport::Cacheもあります。違いはわかりませんが、どちらもデフォルトでRailsに含まれています。先ほど、rack :: cacheはデフォルトではないと言っていましたが、間違っていました。
Varnish、Squidなどは、Railsスタックの外側のWebサーバー（Apache / Nginxなど）の前に別のプロセスとして存在します。これらは高度に構成可能で、アプリケーションに依存せず、いくつかの高度な機能（SquidのACLなど）を備えています。ワニスなどには、リクエストが処理されるために通過する必要のあるインフラストラクチャを最小限に抑えるという利点があります。新鮮な場合、リクエストはVarnishにヒットし、すぐにクライアントに戻ります。これは、トラフィックの多いサイトではおそらく最もメリットがあり、小さなアプリではやり過ぎかもしれません。
これは、Rails3でのrack::cacheの使用について詳しく説明しているherokuに関する記事です。アプリ内でページ/フラグメントのキャッシュを実行したり、バックエンドとしてmemcachedを使用したりすることについてもいくつかの優れたレールキャストがあります（これは非常に重要です）。ワニスなどについては、ワニスのサイトでこのチュートリアルから始めることができます。