Particularmente descubrí el problema.
En primer lugar, recuerda mi código en la vista:
<% @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 %>
Aquí obtengo cada episodio episode_image dentro de mi iteración. Aunque he estado usando includes en mi controlador, hubo un gran error en el esquema de mi tabla. No tenía índice para episode_id en mis episode_images mesa! . Esto estaba causando un tiempo de consulta extremadamente alto. Lo encontré usando los informes de la base de datos de New Relic. Todos los demás tiempos de consulta fueron 0,5 ms o 2-3 ms pero episode.episode_image estaba causando casi 6500ms!
No sé mucho sobre la relación entre el tiempo de consulta y la ejecución de la aplicación, pero agregué el índice a mis episode_images mesa, ahora puedo ver claramente la diferencia. Si tiene el esquema de su base de datos correctamente, probablemente no tendrá ningún problema con el escalado a través de Heroku. Pero ningún banco de pruebas puede ayudarte con una base de datos mal diseñada.
Para las personas que puedan tener el mismo problema, me gustaría contarles algunos de mis hallazgos sobre la relación entre los dinamómetros web de Heroku, los trabajadores de Unicorn y las conexiones activas de Postgresql:
Básicamente, Heroku le proporciona un banco de pruebas que es una especie de máquina virtual pequeña que tiene 1 núcleo y 512 MB de RAM. Dentro de esa pequeña máquina virtual, se ejecuta su servidor Unicornio. Unicorn tiene un proceso maestro y procesos de trabajo. Cada uno de sus trabajadores Unicorn tiene su propia conexión permanente a su servidor Postgresql existente (no olvide consultar esto ) Básicamente significa que cuando tienes un banco de pruebas Heroku con 3 trabajadores Unicorn ejecutándose en él, tienes al menos 4 conexiones activas. Si tiene 2 web dynos, tiene al menos 8 conexiones activas.
Digamos que tiene un Tengu Postgres estándar con un límite de 200 conexiones simultáneas. Si tiene consultas problemáticas con un mal diseño de db, ni db ni más dynos pueden salvarlo sin caché... Si tiene consultas de ejecución prolongada, creo que no tiene otra opción que almacenar en caché.
Todo lo anterior son mis propios hallazgos, si hay algún problema con ellos, avísenme con sus comentarios.
