Jeg fandt især ud af problemet.
Husk først min kode i visningen:
<% @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 %>
Her får jeg hver episode episode_image inde i min iteration. Selvom jeg har brugt includes i min controller var der en stor fejl ved mit bordskema. Jeg havde ikke indeks for episode_id i mine episode_images bord! . Dette forårsagede en ekstrem høj forespørgselstid. Jeg har fundet det ved hjælp af New Relics databaserapporter. Alle andre forespørgselstider var 0,5 ms eller 2-3 ms, men episode.episode_image forårsagede næsten 6500ms!
Jeg ved ikke meget om forholdet mellem forespørgselstid og applikationsudførelse, men da jeg tilføjede indeks til mine episode_images tabel, nu kan jeg tydeligt se forskellen. Hvis du har dit databaseskema korrekt, vil du sandsynligvis ikke stå over for noget problem med skalering via Heroku. Men enhver dyno kan ikke hjælpe dig med en dårligt designet database.
For folk, der kan løbe ind i det samme problem, vil jeg gerne fortælle jer om nogle af mine resultater af forholdet mellem Heroku webdynos, Unicorn-arbejdere og Postgresql aktive forbindelser:
Grundlæggende giver Heroku dig en dyno, som er en slags lille virtuel maskine med 1 kerne og 512 MB ram. Inde i den lille virtuelle maskine kører din Unicorn-server. Unicorn har en mesterproces og arbejdsprocesser. Hver af dine Unicorn-arbejdere har deres egen permanente forbindelse til din eksisterende Postgresql-server (Glem ikke at tjekke dette ) Det betyder dybest set, at når du har en Heroku dyno oppe med 3 Unicorn-arbejdere kørende på den, har du mindst 4 aktive forbindelser. Hvis du har 2 webdynoer, har du mindst 8 aktive forbindelser.
Lad os sige, at du har en Standard Tengu Postgres med en grænse på 200 samtidige forbindelser. Hvis du har problematiske forespørgsler med dårligt db-design, kan hverken db eller flere dynos redde dig uden cache... Hvis du har langvarige forespørgsler, har du ikke andet valg end at cache, tror jeg.
Alt ovenfor er mine egne resultater, hvis der er noget galt med dem, så advar mig venligst ved dine kommentarer.