Saya secara khusus menemukan masalahnya.
Pertama, ingat kode saya di tampilan:
<% @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 %>
Di sini saya mendapatkan setiap episode episode_image di dalam iterasi saya. Meskipun saya telah menggunakan includes di controller saya, ada kesalahan besar pada skema tabel saya. Saya tidak memiliki indeks untuk episode_id di episode_images saya meja! . Ini menyebabkan waktu kueri yang sangat tinggi. Saya menemukannya menggunakan laporan basis data New Relic. Semua waktu kueri lainnya adalah 0,5 md atau 2-3 md tetapi episode.episode_image menyebabkan hampir 6500 md!
Saya tidak tahu banyak tentang hubungan antara waktu kueri dan eksekusi aplikasi, tetapi ketika saya menambahkan indeks ke episode_images saya tabel, sekarang saya dapat dengan jelas melihat perbedaannya. Jika Anda memiliki skema database dengan benar, Anda mungkin tidak akan menghadapi masalah dengan penskalaan melalui Heroku. Tetapi dyno mana pun tidak dapat membantu Anda dengan database yang dirancang dengan buruk.
Untuk orang-orang yang mungkin mengalami masalah yang sama, saya ingin memberi tahu Anda tentang beberapa temuan saya tentang hubungan antara dyno web Heroku, pekerja Unicorn, dan koneksi aktif Postgresql:
Pada dasarnya, Heroku memberi Anda dyno yang merupakan semacam mesin virtual kecil yang memiliki 1 inti dan ram 512MB. Di dalam mesin virtual kecil itu, server Unicorn Anda berjalan. Unicorn memiliki proses master dan proses pekerja. Setiap pekerja Unicorn Anda memiliki koneksi permanen mereka sendiri ke server Postgresql yang ada (Jangan lupa untuk memeriksa ini ) Ini pada dasarnya berarti bahwa ketika Anda memiliki Heroku dyno dengan 3 pekerja Unicorn yang berjalan di atasnya, Anda memiliki setidaknya 4 koneksi aktif. Jika Anda memiliki 2 web dyno, Anda memiliki setidaknya 8 koneksi aktif.
Katakanlah Anda memiliki Postgres Tengu Standar dengan batas 200 koneksi bersamaan. Jika Anda memiliki kueri bermasalah dengan desain db yang buruk, db atau lebih banyak dyno tidak dapat menyelamatkan Anda tanpa cache... Jika Anda memiliki kueri yang berjalan lama, Anda tidak punya pilihan selain caching, menurut saya.
Semua di atas adalah temuan saya sendiri, jika ada yang salah, harap peringatkan saya dengan komentar Anda.
