Может ли приложение Rails быть достаточно медленным, чтобы оно становилось узким местом, а не БД?

Question

Обычно доступ к базе данных, как правило, является самой дорогостоящей операцией с точки зрения времени.

Однако, поскольку Ruby является одним из самых медленных исполняемых языков (с рельсами, представляющими абстракцию, построенную поверх уже существующей абстракции), приложения rails имеют тенденцию выполнять медленнее (или медленнее) большинство запросов кдб

Answer 1

Это действительно субъективный вопрос, но, короче говоря, да, конечно, он может стать более узким местом, чем БД, в зависимости от ваших основных бизнес-задач.Если, скажем, единственная причина, по которой у вас есть база данных, - это требование входа в систему и, следовательно, только один вызов таблицы пользователей, но ваш веб-сайт полностью посвящен обработке изображений, и вы выполняете много вычислительно дорогих вещей, тогда ruby ​​будет болееВас беспокоит больше, чем база данных.

Старая идея о том, что вы должны выбрать правильный инструмент для работы, никогда не ошибется.

Answer 2

Этот вопрос похож на вопрос: «Можно ли замедлить Porsche до более медленной скорости, чем Пинто?».

Вы должны оценивать свою производительность по среднему времени отклика в миллисекундах. Например, если на страницу вашего приложения уходит в среднем 100 мсек, то теоретически вы можете получать 10 запросов в секунду. Если вы исследуете и определяете, что 100 мс - это потому, что 60 мс тратится на разбор некоторой строки ... строки, которую можно уменьшить или даже проигнорировать, тогда проблема на самом деле не в Ruby или Rails, не так ли?

Ruby / Rails - fast enough для большинства веб-приложений. Я думаю, что вы пытаетесь убедить себя использовать что-то кроме Rails. Если вы не хотите использовать Rails, это нормально. Но не отказывайтесь от Rails, потому что он МОЖЕТ быть замедлен плохим программированием. Это верно для любого языка.

Вместо этого, примите Rails (или Синатру, Падрино или Джанго) и получайте удовольствие. Беспокойство о производительности, когда производительность является проблемой.

Answer 3

Да.

Глупым, но верным примером будет ...

def index
  @thing = Thing.find_by_something_not_needed params[:something_not_needed]
  unless something_happens do
    sleep
  end
end

def something_happens; nil; end

Теперь представьте, что вы выполняете некоторую сложную логику - например, обработку изображения или, возможно, посторонний удар в проблема коммивояжера с существенными данными - это можно смоделировать с помощью смертельной петли , которую я привел в своем глупом примере.Другими факторами могут быть внешние веб-запросы, которые просто не работают.

Answer 4

Rails уже является самым медленным фреймворком среди остальных «активных» фреймворков Ruby (Camping, Sinatra, Merb, Padrino, Ramaze). Я нашел недавний «ненаучный» бенчмарк: http://pastie.org/2294509 (репозиторий github фреймворка исходного кода платформы padrino), который дает некоторые результаты.

Медлительность может не проявляться так сильно в работе (вероятно, это не должно быть причиной узкого места), но вы наверняка почувствуете это при разработке приложений: чрезвычайно медленное время загрузки, медленные задачи разгона, очень медленные тестовые наборы, высокая объем памяти.

Это компромисс. Rails обладает богатым функционалом и давно существует с большим активным сообществом.

К сожалению, ситуация может не улучшиться, так как с каждой новой версией Rails инфраструктура становится больше, с дополнительными уровнями абстракции, которые влияют на скорость. Это чистое предположение с моей стороны, но, судя по пользовательской базе, мы не увидим каких-либо радикальных изменений в самом Rails, чтобы облегчить эти проблемы. Последняя изменяющая игру версия 3 принесла много долгожданных улучшений, но они были скорее улучшением модульности инфраструктуры, а не улучшением производительности.

Answer 5

У меня нет большого опыта в этой теме, так как я больше не занимаюсь разработкой Rails.Тем не менее, Аарон «нежная любовь» Паттерсон выступил с докладом «ЗОМГ, ПОЧЕМУ ЭТОТ КОД ТАК МЕДЛЕН?»( slideshare , записывает видео ), где он говорил о том, что ActiveRecord ранее был медленным, потому что реализация Ruby раньше была неоптимальной.