PostgreSQL
 sql >> Baza danych >  >> RDS >> PostgreSQL

Jak dostroić aplikację Ruby on Rails działającą na Heroku, która korzysta z poziomu produkcyjnego Heroku Postgres?

Szczególnie rozgryzłem ten problem.

Po pierwsze, zapamiętaj mój kod w widoku:

<% @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 %>

Tutaj otrzymuję każdy odcinek episode_image w mojej iteracji. Mimo że używam includes w moim kontrolerze wystąpił duży błąd w moim schemacie stołu. Nie miałem indeksu dla episode_id w moich episode_images stół! . To powodowało bardzo długi czas zapytań. Znalazłem to korzystając z raportów bazy danych New Relic. Wszystkie inne czasy zapytań wynosiły 0,5 ms lub 2-3 ms, ale episode.episode_image powodował prawie 6500 ms!

Nie wiem zbyt wiele o relacji między czasem zapytania a wykonaniem aplikacji, ale gdy dodałem indeks do moich episode_images tabeli, teraz wyraźnie widzę różnicę. Jeśli masz poprawnie schemat bazy danych, prawdopodobnie nie będziesz miał problemu ze skalowaniem przez Heroku. Ale żadna hamownia nie może ci pomóc ze źle zaprojektowaną bazą danych.

Osobom, które mogą napotkać ten sam problem, chciałbym opowiedzieć o niektórych z moich ustaleń dotyczących relacji między hamowniami internetowymi Heroku, pracownikami Unicorn i aktywnymi połączeniami Postgresql:

Zasadniczo Heroku zapewnia hamownię, która jest rodzajem małej maszyny wirtualnej z 1 rdzeniem i 512 MB pamięci RAM. Wewnątrz tej małej maszyny wirtualnej działa serwer Unicorn. Unicorn ma proces główny i procesy robocze. Każdy z Twoich pracowników Unicorn ma własne stałe połączenie z istniejącym serwerem Postgresql (nie zapomnij sprawdzić to ) Zasadniczo oznacza to, że gdy masz hamownię Heroku, na której biegają 3 jednorożce, masz co najmniej 4 aktywne połączenia. Jeśli masz 2 hamownie internetowe, masz co najmniej 8 aktywnych połączeń.

Załóżmy, że masz standardowego Postgresa Tengu z limitem 200 jednoczesnych połączeń. Jeśli masz problematyczne zapytania ze złym projektem bazy danych, ani baza danych, ani więcej hamowni nie może cię uratować bez pamięci podręcznej... Jeśli masz długie zapytania, nie masz innego wyboru niż buforowanie, jak sądzę.

Wszystko powyżej to moje własne ustalenia, jeśli jest z nimi coś nie tak, ostrzeż mnie swoimi komentarzami.




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Dlaczego wydajność zapytań PostgresQL spada z czasem, ale przywracana jest po przebudowie indeksu?

  2. PSQLException i problem z blokadą po dodaniu wyzwalacza do tabeli

  3. grupuj według przedziału cenowego

  4. Dlaczego warunki CROSS JOIN nie działają w klauzuli „ON”, tylko klauzula WHERE?

  5. GeneratedValue w Postgres