私は特に問題を理解しました。
まず、ビュー内のコードを覚えておいてください：
<% @episodes.each do |t| %>
<% if !t.episode_image.blank? %>
<li><%= image_tag(t.episode_image.image(:thumb)) %></li>
<% end %>
<li><%= t.episode_urls.first.mas_path if !t.episode_urls.first.blank?%></li>
<li><%= t.title %></li>
<% end %>
ここでは、各エピソードを取得していますepisode_image 私の反復の中で。 includesを使用しているのに 私のコントローラーでは、テーブルスキーマに大きな間違いがありました。 episode_idのインデックスがありませんでした 私のepisode_imagesで テーブル！ 。これにより、クエリ時間が非常に長くなりました。 NewRelicのデータベースレポートを使用して見つけました。他のすべてのクエリ時間は0.5ミリ秒または2〜3ミリ秒でしたが、episode.episode_image ほぼ6500msを引き起こしていました！
クエリ時間とアプリケーションの実行の関係についてはよくわかりませんが、episode_imagesにインデックスを追加したので テーブル、今私ははっきりと違いを見ることができます。データベーススキーマが適切に設定されていれば、Herokuを介したスケーリングで問題が発生することはおそらくないでしょう。しかし、どのdynoも、不適切に設計されたデータベースでは役に立ちません。
同じ問題が発生する可能性のある人のために、Heroku Web dyno、Unicornワーカー、Postgresqlアクティブ接続の関係についての私の発見のいくつかについてお話ししたいと思います：
基本的に、Herokuは、1コアと512MBのRAMを備えたある種の小さな仮想マシンであるdynoを提供します。その小さな仮想マシン内で、Unicornサーバーが実行されます。 Unicornには、マスタープロセスとワーカープロセスがあります。各Unicornワーカーは、既存のPostgresqlサーバーへの独自の永続的な接続を持っています（これ ）基本的には、3人のUnicornワーカーが実行されているHeroku dynoがある場合、少なくとも4つのアクティブな接続があることを意味します。 2つのWebダイノがある場合、少なくとも8つのアクティブな接続があります。
同時接続数が200に制限されている標準のTenguPostgresがあるとします。悪いデータベース設計で問題のあるクエリがある場合、データベースもそれ以上のdynoもキャッシュなしであなたを救うことはできません...長時間実行されるクエリがある場合、キャッシュ以外の選択肢はないと思います。
上記はすべて私自身の調査結果です。何か問題がある場合は、コメントで警告してください。