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

Question

Мы убедили нашего сотрудника по продуктам, что мы хотим использовать JRuby on Rails, и нам трудно придумать статистику, которая показывает, что:

1. Время написания кода меньше с использованием Rails по сравнению, скажем, с Struts или Zend Framework или чем-то еще.
2. Производительность Ruby (и JRuby в частности) больше не ужасна.
3. Производительность Rails тоже неплохая.

Если вы сможете быстро получить хорошую статистику, у нас может быть шанс!

Обновление:

На самом деле мы убедили бизнес использовать JRuby on Rails, и сейчас мы находимся в этом проекте несколько месяцев. Спасибо за вашу помощь!

Answer 1

Трудно дать количественную оценку 1, даже если это очевидно. Плохая мера, но лучшее, что я могу придумать, - это сравнительный сжатый размер кода:

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=java

Код ruby ​​содержит половину «информации» кода Java. Я выполнил несколько лет рельсов и множество других фреймворков, но количественно определить их практически невозможно, поскольку я никогда не писал один и тот же проект на двух языках / фреймворках.

Единственное, что не учтено в графике, это то, что Ruby не может проверять время компиляции, поэтому вам, как правило, нужно иметь лучшее тестовое покрытие, чтобы быть уверенным в коде, который вы развертываете.

2. Производительность Ruby достигла своего предела с точки зрения производительности. Это все еще плохо, когда вы сравниваете это с чем угодно, но для веб-интерфейса это, честно говоря, не имеет большого значения. JRuby быстрее, чем Ruby (1.8.x), но все еще на порядок от статически типизированного языка JVM (scala / java и т. Д.).

3. Честно говоря, Rails чертовски медленен для фреймворка. Зато вычислительная нагрузка помогает обеспечить безумный темп развития. Для внешнего интерфейса это не так уж важно.

Ваш интерфейс / язык интерфейса только добавит, возможно, 10 секунд миллисекунд к каждому запросу. Если ваше приложение вообще что-то делает с данными, презентация / вызовы внешнего интерфейса не будут занимать большую часть времени запроса.

Это в основном все о компромиссах и о том, что имеет / не имеет значения. Честно говоря, скорость вычислений вашего языка интерфейса не так уж важна, и повышение производительности «более медленного» языка, такого как ruby, обычно перевешивает то, от чего вы отказываетесь.

Answer 2

Если вы хотите сделать ставку на PHP-код Rails с точки зрения сырой скорости, забудьте об этом.

Бизнес-решение касается не только скорости выполнения сценария, а именно:

• совместимость, насколько хорошо ваше новое приложение будет соответствовать в корпоративной среде приложений
• непрерывность, сколько других сотрудников знает (принимает) рельсы, подобные вам, и насколько вероятно, что вы сможете набирать больше, если их нет, что, если вы уйдете, скажем, через 3 месяца?
• безопасность, помимо того, насколько безопасны рельсы, также зависит от того, как быстро могут быть решены любые проблемы, кто это исправит
• надежность, восстановление .. и т. Д.

и вам есть о чем беспокоиться:

• развертывание, mod_rails здесь, но все еще не так просто, как php, вам нужна приверженность команды администратора
• масштабируемость, вероятно, не будет проблемой, когда у вас столько трафика, сколько tweetie, вы получите бюджет для его восстановления; -)

мы знаем, что все мы любим рельсы. многие до сих пор этого не делают. пошли проповедовать; -)

Answer 3

Довольно сложный вопрос для предоставления конкретной информации. Производительность действительно зависит от вариантов использования вашего приложения и архитектуры.

Я бы посоветовал вам создать разные версии конкретного варианта использования и измерить производительность. Это может быть довольно простое представление, которое попадает в базу данных и отображает страницу. Используйте ту же структуру БД.

Ирония всего аргумента в том, что PHP тоже не самая быстрая вещь в блоке. В нетривиальных приложениях вам нужно начать добавлять ускоритель для кэширования вашего байт-кода. JVM имеет невероятно продвинутую поддержку для такого рода вещей. Архитектура Rails, основанная на подходе сервера приложений, обходит много этого, потому что у вас фактически есть область памяти для всего приложения (PHP должен анализировать и отображать все на каждом проходе).

Во всяком случае, исходя из собственного опыта, я использую PHP с 2000 года, перешел на Rails несколько лет назад, еще в дни до версии 1.0, и имею большие производственные системы, использующие оба.

• Я обнаружил, что Rails быстрее развивается на намного . Я нашел его на 50% более эффективным, в зависимости от функции. Как, я могу развиваться в половине случаев.
• У меня есть производственные системы Rails с интенсивным использованием базы данных, которые отображаются за 200-300 мс
• Экосистема Rails в наши дни намного опережает PHP, когда речь заходит о поддержке всех вспомогательных систем и процессов, необходимых для хорошей разработки программного обеспечения. Не случайно в мире Ruby появились такие библиотеки, как Cucumber и rSpec.

Answer 4

Ну, есть Ложь, проклятая ложь и статистика .

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

Что касается времени разработки, я бы сказал, что Rails - это проверенный стек для быстрой разработки. Но так же и PHP. Какой вариант лучше, зависит от программистов.