Насколько медленный Ruby on Rails?

Question

[Edward Ghore]

Начал осваивать язык программирования "Руби" и, в контексте его, параллельно знакомлюсь с фреймворком "Рэйлс". Читая статьи на темы, связанные с оным, частенько сталкивался со, своего рода, упреками в адрес "медлительности" языка и вышеуказанного фреймворка. Насколько тут все критично? С чем это связано на уровне ядра?

Comments

[Everything_is_not_so_bad]

Критично только если у вас сайт с посещаемостью как у twitter.

Answer 1

[Viktor Vsk]

Ваш вопрос вызван преждевременной оптимизацией, что в 97% случаев - плохо.
Вывод - не задавайтесь такими вопросами, пока не станет очень узкоспециализированная задача.

TL; DR:
Ни руби, ни рельсы - не медленные в реальных задачах веб разработки

Руби и рельсы могут считаться относительно медленными по таким причинам:
1. Руби - интерпретируемый язык
2. В руби - очень много сахара для продуктивной разработки и поддержки. Иногда это действительно отражается на производительности.
3. В рельсах из коробки есть очень много вещей. Но не всегда они нужны. Так же, многие бест-практис да и просто ответы в разных источниках показывают самый читабельный\простой\поддерживаемый вариант, а не самый производительный.

Обычно, тормозит не тот или иной язык, а код, что вы на нем написали. Сегодня задач, где необходимы определенные возможности языка \ фреймворка для достижения той или иной производительности - вопрос ну очень уж редкий и специфический: научный расчеты, визуализация, сетевые взаимодействия...

Но на самом деле, пофиг, все равно, серьезное приложение будет размещаться на нескольких машинах. Говорят, что предел рельс - 16000 RPS (requests per second) на сервер.

Comments

[sim3x]

тлдр пишется сначала текста

[Viktor Vsk]

sim3x: :D не зря не хотел писать)

[zooks]

sim3x: точно, это уже подытоживание получается

Answer 2

[zooks]

В сравнении с чем он медленный? С компилируемыми языками вроде C? - Это нормально.
При сравнении с Python на средних проектах скорость вполне сопоставима.
Старый PHP 5.3 значительно медленнее Ruby.

Answer 3

[Dmitri Sinitsa]

Его медлительность (что есть относительное понятие, хотя, вроде и обоснованное) обусловлено большим количеством магии в коде (метапрограммирование), объектно-ориентированностью головного мозга (что есть большой оверхед по памяти и процессору), GIL, спорные решения в области многопоточности ну и так далее и тому подобное.
Для большенства сайтиков при должной оптимизации (кэширование и т.д) - это не будет проблемой.
Но если планируете сделать убийцу vk или facebook, то лучше взять что-то другое.

Answer 4

[Everything_is_not_so_bad]

Почитайте Why do people say that Ruby is slow? и сделайте вывод сами.

Comments

[O Di]

2010 год?

[Everything_is_not_so_bad]

O Di: таки да. Разве это что-то меняет?

[O Di]

Роман: предположил, что да :)

Answer 5

[Kokcuk]

Так как вы в мире веб-фреймворков, то думать не медлительности языка не стоит, все равно 95% времени запроса будет занимать ответ от бд.

Comments

[Dmitri Sinitsa]

Ну почти. Только не сам ответ от БД, а его парсинг и маппинг на объекты.
Потому что сама БД, если спроектирована правильно, будет одной из самых быстрых частей системы.
А вот рендеринг, маппинг - это довольно медленные операции.

Answer 6

[Eugene Burmakin]

Настолько, насколько глупый код вы напишете, используя Rails.

Answer 7

[Алексей]

Все зависит от задачи, к примеру, делал прототип API. Без обращений в БД запрос отрабатывал за 1-2ms, добавляем запрос к БД, получаем уже 14. Необходима сложная сортировка, делаем первое приближение на бд с пост обработкой, уже 40. Пагинация = каждый запрос по 40-50. Делаем максимальную выборку сложную сортировку на стороне приложения и взятие диапазона, 90 (большая часть на передачу данных уходит), но зато результат именно в том порядке что надо. А что если кешировать. Помещаем в кэш. Итого первый запрос первой страницы 90-95 второй 3-5, итого чем дальше проматываем тем дешевле становится каждая страница в среднем, 50-30-25-20 и так далее. Но на все это было потрачено от задумки до рабочего прототипа пару часов. Сколько бы заняло времени на более производительных языках.
Перед тем как упретесь в язык, нужно будет еще для начала получить такое количество пользователей, а это отдельная задача. А переписать узкие места всегда можно.

Answer 8

[caution]

Очень быстрый.