Есть ли преимущество в запуске JRuby, если вы не знаете Java?
Я слышал замечательные вещи о JRuby, и я знаю, что вы можете запустить его, не зная Java. Мои навыки разработки сильны, Java просто не один из инструментов, которые я знаю. Это массивный инструмент с множеством сопутствующих инструментов, таких как Maven/Ant/JUnit и т. Д.
Стоит ли переносить мои текущие Rails-приложения в JRuby только по соображениям производительности? Возможно, если я возьму немного базовой Java вместе с ней, могут быть такие дополнительные преимущества, которые неочевидны, например, лучшие инструменты отладки / оптимизации производительности?
Хотелось бы несколько советов по этому вопросу.
5 ответов
Я думаю, что вы в значительной степени прибили это.
JRuby - это еще один движок Ruby, такой же, как MRI, YARV, IronRuby, Rubinius, MacRuby, MagLev, SmallRuby, Ruby.NET, XRuby, RubyGoLightly, tinyrb, HotRuby, BlueRuby, Red Sun и все остальные.
Основными отличиями являются:
Переносимость: например, YARV официально поддерживается только в 32-битной Linux x86. Это не поддерживается в OSX или Windows или 64-битной Linux. Рубиниус работает только в Unix, а не в Windows. JRuby OTOH работает везде: настольные компьютеры, серверы, телефоны, App Engine, вы называете это. Он работает на виртуальных машинах Oracle JDK, OpenJDK, IBM J9, Apple SoyLatte, RedHat IcedTea и Oracle JRockit (и, возможно, еще нескольких, о которых я забыл), а также на виртуальной машине Dalvik. Он работает на Windows, Linux, OSX, Solaris, нескольких BSD, других проприетарных и открытых Unices, OpenVMS и нескольких ОС мэйнфреймов, Android и Google App Engine. Фактически, в Windows JRuby проходит больше тестов RubySpec, чем сам "Ruby" (то есть MRI или YARV)!
расширяемость: программы на Ruby, работающие на JRuby, могут использовать любую произвольную библиотеку Java. Через JRuby-FFI они также могут использовать любую произвольную C-библиотеку. А благодаря новой поддержке расширений C в JRuby 1.6 они могут даже использовать большое подмножество расширений MRI и YARV C, например, Mongrel. (И обратите внимание, что библиотека "Java" или "C" на самом деле не означает написанное на этих языках, это означает только API Java или C. Они могут быть написаны на Scala, Clojure, C++ или Haskell.)
инструмент: всякий раз, когда кто-то пишет новый инструмент для YARV или MRI (например, memprof), оказывается, что у JRuby уже был инструмент 5 лет назад, который делает то же самое, только лучше. В экосистеме Java есть некоторые из лучших инструментов для "понимания поведения во время выполнения" (это термин, который я только что придумал, под которым я имею в виду гораздо больше, чем просто профилирование, я имею в виду инструменты для глубокого понимания того, что именно ваша программа делает во время выполнения, каковы его характеристики производительности, где существуют узкие места, куда идет память и, что наиболее важно, почему все это происходит) и визуализация, доступная на рынке, и в значительной степени все это работает с JRuby, по крайней мере, до некоторой степени.
развертывание: при условии, что в вашей целевой системе уже установлена JVM, развертывание приложения JRuby (и я говорю не только о Rails, я также имею в виду настольные, мобильные и другие виды серверов) буквально просто копирует один JAR (или WAR) и двойной щелчок.
производительность: у JRuby гораздо больше накладных расходов при запуске. Взамен вы получаете намного более высокую пропускную способность. На практике это означает, что развертывание приложения Rails на JRuby является хорошей идеей, так же как и выполнение ваших интеграционных тестов, но для модульных тестов и сценариев разработчика лучше использовать MRI, YARV или Rubinius. Обратите внимание, что многие разработчики Rails просто разрабатывают и тестируют модули на MRI, тестируют интеграцию и разворачивают на JRuby. Нет необходимости выбирать один механизм исполнения для всего.
параллелизм: JRuby запускает потоки Ruby одновременно. Это означает две вещи: если ваша блокировка правильная, ваша программа будет работать быстрее, а если ваша блокировка неправильная, ваша программа сломается. (К сожалению, ни MRI, ни YARV, ни Rubinius не запускают потоки одновременно, так что есть еще какой-то сломанный многопоточный код Ruby, который не знает, что он сломан, потому что, очевидно, ошибки параллелизма могут появляться только при наличии реального параллелизма.)
платформы (это в некоторой степени связано с переносимостью): есть несколько удивительных платформ Java, например, Azul JCA с 768 гигабайтами ОЗУ и 864 ядрами ЦП, специально разработанные для безопасной памяти, безопасной работы с указателями, сбора мусора, объектно-ориентированного языки. Android. Google App Engine. Все они работают на JRuby.
Я бы немного изменил то, что сказал Питер. JRuby может использовать больше памяти по сравнению со стандартным Ruby, но обычно это происходит потому, что вы выполняете работу в одном процессе, который потребует нескольких процессов с Ruby.
Вы должны попробовать Rails.threadsafe! вариант с одной средой исполнения JRuby (например, драгоценный камень Тринидад с --threadsafe опция). Мы слышали несколько историй о том, как это дает вам отличную производительность и низкое использование памяти, одновременно используя несколько процессорных ядер в одном процессе.
У Jruby есть преимущества, если вы используете Windows. Он поддерживает 64 бита, и вы можете использовать множество проприетарных баз данных со стандартными драйверами JDBC.
JRuby - это одна из немногих реализаций, которая использует собственные потоки. Так что если вы хотите сделать несколько многопоточности, пойти на это.
Что касается хостинга, вы должны поместить свое приложение в некий java-контейнер, который, на мой взгляд, гораздо менее прост, чем использование что-то вроде пассажира (для приложений Rack).
Я использую JRuby для приложения, так как мы общаемся через JMS, и он отлично работает, но если бы я не использовал какую-либо Java, я бы, конечно, придерживался CRuby. Моя самая большая претензия в том, что при тестировании запуск тестов с JRuby длится вечно, так как вы должны раскручивать виртуальную машину каждый раз, когда запускаете их. Это значительно усложняет TDD, так как это существенно влияет на время тестирования.
Последние выпуски значительно быстрее, чем Ruby, но также используют значительно больше памяти. Если это ваша единственная причина для использования JRuby, я бы не стал беспокоиться, если бы у вас не было особой потребности в производительности, которую он решает, просто потому, что, хотя он довольно популярен, он менее стандартен для хостинга и меньше людей использует его по сравнению со стандартным Рубин. При этом существует множество других причин для использования JRuby, таких как необходимость взаимодействия с существующим кодом Java и необходимость развертывания в средах, где Java была "благословлена" операционным отделом, а Ruby - нет.