私は PageCaching: http://railscasts.com/episodes/89-page-caching-revisedで RailsCast を見ていましたが、ある時点で Ryan Bates は次のように述べています。フロント エンド Web サーバーによるファイル".
Railsサーバーと「フロントエンド」Webサーバーの違いをよく理解していないことに気づきました。
最近Cedarにアップグレードし、gzip圧縮を手動で処理する必要があるため、誰かが私にこれを説明してくれることを望んでいました。ブログによると、私はread は、「Cedar では、リクエストがプロキシ サーバー (nginx) を通過しなくなった」ためです。
Heroku では、cedar 以降、「フロントエンド Web サーバー」などはもうありません。
cedar の前は、外部からのリクエストが nginx によって処理され (したがってフロント サーバー)、ページの生成をローカルの Rails サーバー (シン、ユニコーン、ウェブリックなど) に依頼していました。
要求された URL が実際に既存のファイルに対応していることをフロント サーバーが検出した場合、Rails サーバー プロセスに何も要求せずに直接提供していました。これは、ほとんどの場合、専用サーバーでリクエストを管理する方法です。
heroku が現在行っていることは、Rails サーバーを外の世界に直接公開することであり、中間に apache や nginx のような従来の Web サーバーはありません。
heroku を使用するということは、アセットとキャッシュ ファイルをサード パーティの cdn サーバーにアップロードして、貴重な Rails 処理時間をそれらのサービスに費やさないようにする必要があるということです。
または、代わりにアクション キャッシングを使用して、.html ではなく memcache に html を書き込むことができますpublic/。それは実際にはheroku's recommandationです。
あなたのローカル環境についての注意: あなたはおそらく Rails サーバープロセスも直接使用しています。を実行すると、これが実行rails serverされます。ポート 3000 に直接バインドされた webrick またはシン サーバーが起動します。したがって、そこにも「フロント サーバー」はありません。
また、アクションとページのキャッシングは rails-4 では標準ではなくなりましたが、 gem によって提供されていることに注意してください。キャッシングの標準的な新しい手段であるrussian doll cachingは、memcache を使用するため、heroku では問題ありません。