J'ai particulièrement compris le problème.
Tout d'abord, souvenez-vous de mon code dans la vue :
<% @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 %>
Ici, je reçois chaque épisode episode_image à l'intérieur de mon itération. Même si j'utilise includes dans mon contrôleur, il y avait une grosse erreur au niveau de mon schéma de table. Je n'avais pas d'index pour episode_id dans mes episode_images tableau ! . Cela provoquait un temps de requête extrêmement élevé. Je l'ai trouvé en utilisant les rapports de la base de données de New Relic. Tous les autres temps de requête étaient de 0,5 ms ou 2-3 ms mais episode.episode_image provoquait presque 6500 ms !
Je ne sais pas grand-chose sur la relation entre le temps de requête et l'exécution de l'application, mais comme j'ai ajouté un index à mes episode_images tableau, maintenant je vois clairement la différence. Si vous avez correctement votre schéma de base de données, vous ne rencontrerez probablement aucun problème de mise à l'échelle via Heroku. Mais aucun dyno ne peut vous aider avec une base de données mal conçue.
Pour les personnes qui pourraient rencontrer le même problème, j'aimerais vous parler de certaines de mes conclusions sur la relation entre les dynos Web Heroku, les travailleurs Unicorn et les connexions actives Postgresql :
Fondamentalement, Heroku vous fournit un dyno qui est une sorte de petite machine virtuelle ayant 1 cœur et 512 Mo de RAM. À l'intérieur de cette petite machine virtuelle, votre serveur Unicorn fonctionne. Unicorn a un processus maître et des processus de travail. Chacun de vos travailleurs Unicorn a sa propre connexion permanente à votre serveur Postgresql existant (n'oubliez pas de consulter ceci ) Cela signifie essentiellement que lorsque vous avez un dyno Heroku avec 3 travailleurs Unicorn en cours d'exécution, vous avez au moins 4 connexions actives. Si vous avez 2 dynos Web, vous avez au moins 8 connexions actives.
Disons que vous avez un Tengu Postgres standard avec une limite de 200 connexions simultanées. Si vous avez des requêtes problématiques avec une mauvaise conception de base de données, ni db ni plus de dynos ne peuvent vous sauver sans cache... Si vous avez des requêtes longues, vous n'avez pas d'autre choix que la mise en cache, je pense.
Tout ce qui précède est mes propres conclusions, s'il y a quelque chose qui ne va pas avec eux, veuillez m'avertir par vos commentaires.
