Отслеживание проблем производительности Common Rails с помощью Skylight

 $ heroku config:add SKYLIGHT_AUTHENTICATION='123abc'

На этой странице представлен полный обзор процесса интеграции Skylight с другими платформами и объясняется, как отслеживать сервисы вне Rails, такие как Net::HTTP

N + 1 проблема запроса

Как только вы закончите настройку, давайте эмулируем первую и, возможно, наиболее известную проблему, называемую «запрос N + 1». Чтобы увидеть его в действии, перечислите все альбомы и их треки на главной странице приложения:

просмотров / альбомы / index.html.erb

 <h1>Albums</h1>
<ul>
  <%= render @albums %>
</ul>

просмотров / альбомы / _album.html.erb

 <li>
  <strong><%= album.title %></strong> by <%= album.musician %>
  <ul>
    <% album.songs.each do |song| %>
      <li><%= song.title %> (<%= song.duration %>s)</li>
    <% end %>
  </ul>
</li>

Загрузите сервер и перейдите по http://localhost:3000 Внутри терминала вы увидите вывод, похожий на этот:

 Album Load (1.0ms)  SELECT "albums".* FROM "albums" ORDER BY published DESC
Song Load (0.0ms)  SELECT "songs".* FROM "songs" WHERE "songs"."album_id" = ?  [["album_id", 301]]
Song Load (1.0ms)  SELECT "songs".* FROM "songs" WHERE "songs"."album_id" = ?  [["album_id", 300]]
Song Load (1.0ms)  SELECT "songs".* FROM "songs" WHERE "songs"."album_id" = ?  [["album_id", 299]]
Song Load (0.0ms)  SELECT "songs".* FROM "songs" WHERE "songs"."album_id" = ?  [["album_id", 298]]
....
.... many similar stuff goes here

По сути, для каждой родительской записи (альбома) мы отправляем отдельный запрос, чтобы извлечь его дочерние элементы (песни) и эффективно спамить базу данных. Разверните свое приложение в производственной среде, откройте его главную страницу, а затем через пару минут обновите панель управления Skylight.

Сама приборная панель действительно хороша и аккуратна, и вы можете прочитать этот документ, чтобы лучше узнать его и узнать об основных концепциях Skylight. Он представляет информацию о запросах в минуту, типичном и неполадках времени ответа, а также общую информацию о конечных точках. В нашем случае конечной точкой будет метод AlbumsController#create В нижней части страницы вы можете выбрать диапазон времени для отображения — вот и все.

Красный значок базы данных рядом с именем конечной точки означает, что у нее есть несколько повторяющихся SQL-запросов, тогда как круговая диаграмма указывает на высокий уровень выделения объектов. Также обратите внимание на столбец «Агония», который рассчитывается по специальному алгоритму Skylight, чтобы определить, какая конечная точка оказывает наиболее неблагоприятное влияние на пользователей приложения. Предположим, у вас есть две конечные точки: одна имеет время отклика 600 мс, но получает множество запросов, тогда как вторая имеет время отклика 3 с, но почти не имеет запросов. Очевидно, что 600 мс намного лучше, чем 3 с, но пока первая конечная точка получает гораздо больше запросов, это должно быть главным приоритетом для дальнейшего сокращения времени отклика.

Теперь, если вы нажмете на конечную точку AlbumsController#create

Эти две циклические красные стрелки рядом с зеленой строкой SQL означают, что запрос не является оптимальным и, скорее всего, имеет
проблема N + 1 (хотя это не всегда так, и в следующем разделе мы увидим пример по этому вопросу).

Таким образом, решение этой проблемы очень просто. Все, что вам нужно сделать, это реализовать так называемую «готовую загрузку»
это значительно уменьшает количество запросов. Это делается с помощью метода include:

 [...]
def index
  @albums = Album.includes(:songs)
end
[...]

 Album Load (1.0ms)  SELECT "albums".* FROM "albums"
Song Load (13.0ms)  SELECT "songs".* FROM "songs" WHERE "songs"."album_id" IN (202, 203, 204, 205, 206, ...)

 <%= render @albums, cached: true %>

 <li>
  <strong><%= album.title %></strong> by <%= album.musician %>
  <ul>
    <% album.songs.each do |song| %>
      <% cache song do %>
        <li><%= song.title %> (<%= song.duration %>s)</li>
      <% end %>
    <% end %>
  </ul>
</li>

 $ heroku addons:create memcachier:dev

 [...]
gem 'dalli'
[...]

 $ bundle install

 [...]
config.cache_store = :dalli_store,
    (ENV["MEMCACHIER_SERVERS"] || "").split(","),
    {:username => ENV["MEMCACHIER_USERNAME"],
     :password => ENV["MEMCACHIER_PASSWORD"],
     :failover => true,
     :socket_timeout => 1.5,
     :socket_failure_delay => 0.2,
     :down_retry_delay => 60
    }
[...]

   [...]
  def create
    50.times do
      Album.create({title: Faker::Book.title, musician: Faker::StarWars.character})
    end
    redirect_to root_path
  end
  [...]

 [...]
resources :albums, only: [:create]
[...]

 [...]
<%= link_to 'add more albums', albums_path, method: :post %>
[...]

 (0.0ms)  begin transaction
SQL (4.0ms)  INSERT INTO "albums" ("title", "musician", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["title", "The Far-Distant Oxus"], ["musician", "Yoda"], ["created_at", 2016-09-13 13:09:29 UTC], ["updated_at", 2016-09-13 13:09:29 UTC]]
(81.0ms)  commit transaction

   [...]
  def create
    Album.transaction do
      50.times do
        Album.create({title: Faker::Book.title, musician: Faker::StarWars.character})
      end
    end
    redirect_to root_path
  end
  [...]

 (1.0ms)  begin transaction
SQL (1.0ms)  INSERT INTO "albums" ("title", "musician", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["title", "A Handful of Dust"], ["musician", "Yoda"], ["created_at", 2016-09-13 13:14:26 UTC], ["updated_at", 2016-09-13 13:14:26 UTC]]
...
many other INSERTs here
...
(133.0ms)  commit transaction

 $ rails g migration add_published_to_albums published:boolean

 def change
  add_column :albums, :published, :boolean, default: false
end

 $ rails db:migrate

 Album.all.shuffle.take(20).each {|a| a.toggle!(:published)}

$ rails db:seed

 def index
  if params[:published] == 't'
    @albums = Album.includes(:songs).where(published: true)
  else
    @albums = Album.includes(:songs).order('published DESC')
  end
end

 $ rails g migration add_missing_index_to_albums

 [...]
def change
  add_index :albums, :published
end
[...]

 $ rails db:migrate