Das Problem ist mir besonders aufgefallen.
Erinnern Sie sich zuerst an meinen Code in der Ansicht:
<% @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 %>
Hier bekomme ich jede Episode episode_image in meiner Iteration. Obwohl ich includes verwendet habe In meinem Controller gab es einen großen Fehler in meinem Tabellenschema. Ich hatte keinen Index für episode_id in meinen episode_images Tisch! . Dies verursachte eine extrem hohe Abfragezeit. Ich habe es mit den Datenbankberichten von New Relic gefunden. Alle anderen Abfragezeiten waren 0,5 ms oder 2–3 ms, aber episode.episode_image fast 6500 ms verursacht!
Ich weiß nicht viel über die Beziehung zwischen Abfragezeit und Anwendungsausführung, aber da ich meinen episode_images einen Index hinzugefügt habe Tabelle, jetzt kann ich den Unterschied deutlich sehen. Wenn Sie Ihr Datenbankschema richtig haben, werden Sie wahrscheinlich keine Probleme mit der Skalierung über Heroku haben. Aber jeder Prüfstand kann Ihnen mit einer schlecht designten Datenbank nicht helfen.
Für Leute, die möglicherweise auf das gleiche Problem stoßen, möchte ich Ihnen einige meiner Erkenntnisse über die Beziehung zwischen Heroku-Web-Dynos, Unicorn-Workern und aktiven Postgresql-Verbindungen mitteilen:
Im Grunde stellt Heroku Ihnen einen Prüfstand zur Verfügung, der eine Art kleine virtuelle Maschine mit 1 Kern und 512 MB RAM ist. In dieser kleinen virtuellen Maschine läuft Ihr Unicorn-Server. Unicorn hat einen Master-Prozess und Worker-Prozesse. Jeder Ihrer Unicorn-Worker hat seine eigene permanente Verbindung zu Ihrem bestehenden Postgresql-Server (Vergessen Sie nicht, dies ) Dies bedeutet im Grunde, dass Sie, wenn Sie einen Heroku-Dyno mit 3 Unicorn-Workern haben, mindestens 4 aktive Verbindungen haben. Wenn Sie 2 Web-Dynos haben, haben Sie mindestens 8 aktive Verbindungen.
Angenommen, Sie haben ein Standard-Tengu-Postgres mit einem Limit von 200 gleichzeitigen Verbindungen. Wenn Sie problematische Abfragen mit schlechtem db-Design haben, kann weder db noch mehr Dynos Sie ohne Cache retten ... Wenn Sie lange laufende Abfragen haben, haben Sie keine andere Wahl als das Caching, denke ich.
Alles oben Gesagte sind meine eigenen Erkenntnisse, wenn irgendetwas daran nicht stimmt, warnen Sie mich bitte durch Ihre Kommentare.
