In particolare ho capito il problema.
Innanzitutto, ricorda il mio codice nella 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 %>
Qui ricevo ogni episodio episode_image all'interno della mia iterazione. Anche se ho usato includes nel mio controller, si è verificato un grosso errore nello schema della mia tabella. Non avevo l'indice per episode_id nel mio episode_images tavola! . Ciò causava un tempo di query estremamente elevato. L'ho trovato usando i rapporti del database di New Relic. Tutti gli altri tempi di query erano 0,5 ms o 2-3 ms ma episode.episode_image stava causando quasi 6500 ms!
Non so molto sulla relazione tra il tempo della query e l'esecuzione dell'applicazione, ma quando ho aggiunto l'indice al mio episode_images tabella, ora posso vedere chiaramente la differenza. Se hai lo schema del database correttamente, probabilmente non dovrai affrontare alcun problema con il ridimensionamento tramite Heroku. Ma qualsiasi banco di prova non può aiutarti con un database mal progettato.
Per le persone che potrebbero incontrare lo stesso problema, vorrei parlarvi di alcune delle mie scoperte sulla relazione tra i web dyno di Heroku, i lavoratori di Unicorn e le connessioni attive di Postgresql:
Fondamentalmente, Heroku ti fornisce un banco di prova che è una specie di piccola macchina virtuale con 1 core e 512 MB di ram. All'interno di quella piccola macchina virtuale, gira il tuo server Unicorn. Unicorn ha un processo principale e processi di lavoro. Ciascuno dei tuoi dipendenti Unicorn ha la propria connessione permanente al tuo server Postgresql esistente (non dimenticare di controllare questo ) In pratica significa che quando hai un banco di prova Heroku con 3 lavoratori Unicorn in esecuzione su di esso, hai almeno 4 connessioni attive. Se hai 2 web dyno, hai almeno 8 connessioni attive.
Diciamo che hai un Tengu Postgres standard con un limite di 200 connessioni simultanee. Se hai query problematiche con una cattiva progettazione di db né db né più dyno possono salvarti senza cache... Se hai query di lunga durata non hai altra scelta che la memorizzazione nella cache, penso.
Tutto quanto sopra sono le mie scoperte, se c'è qualcosa di sbagliato in loro per favore avvisami con i tuoi commenti.
