Eu particularmente descobri o problema.
Primeiramente, lembre-se do meu código na view:
<% @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 %>
Aqui estou recebendo cada episódio
episode_image dentro da minha iteração. Apesar de estar usando includes no meu controlador, houve um grande erro no esquema da minha tabela. Eu não tinha índice para episode_id em minhas episode_images tabela! . Isso estava causando um tempo de consulta extremamente alto. Eu o encontrei usando os relatórios do banco de dados da New Relic. Todos os outros tempos de consulta foram de 0,5 ms ou 2-3 ms, mas episode.episode_image estava causando quase 6500ms! Não sei muito sobre a relação entre o tempo de consulta e a execução do aplicativo, mas como adicionei o índice ao meu
episode_images mesa, agora posso ver claramente a diferença. Se você tiver seu esquema de banco de dados corretamente, provavelmente não enfrentará nenhum problema com o dimensionamento via Heroku. Mas qualquer dinamômetro não pode ajudá-lo com um banco de dados mal projetado. Para as pessoas que podem ter o mesmo problema, gostaria de falar sobre algumas das minhas descobertas sobre o relacionamento entre os dynos da web Heroku, os trabalhadores do Unicorn e as conexões ativas do Postgresql:
Basicamente, o Heroku fornece um dinamômetro que é uma espécie de pequena máquina virtual com 1 núcleo e 512 MB de RAM. Dentro dessa pequena máquina virtual, seu servidor Unicorn é executado. O Unicorn possui um processo mestre e processos de trabalho. Cada um de seus trabalhadores Unicorn tem sua própria conexão permanente com seu servidor Postgresql existente (não se esqueça de verificar isto ) Basicamente significa que quando você tem um dinamômetro Heroku com 3 trabalhadores Unicorn rodando nele, você tem pelo menos 4 conexões ativas. Se você tiver 2 dynos da Web, terá pelo menos 8 conexões ativas.
Digamos que você tenha um Postgres Tengu Padrão com limite de 200 conexões simultâneas. Se você tiver consultas problemáticas com um design de banco de dados ruim, nem o banco de dados nem mais dynos podem salvá-lo sem cache ... Se você tiver consultas de longa duração, não terá escolha além do armazenamento em cache, eu acho.
Tudo acima são minhas próprias descobertas, se houver algo de errado com eles, por favor, avise-me por seus comentários.
