rails java ruby-on-rails ruby jruby

rails - ¿Hay alguna ventaja en la ejecución de JRuby si no conoces Java?



jruby on rails (5)

Creo que casi lo has clavado.

JRuby es solo otro motor de ejecución de Ruby, como MRI, YARV, IronRuby, Rubinius, MacRuby, MagLev, SmallRuby, Ruby.NET, XRuby, RubyGoLightly, tinyrb, HotRuby, BlueRuby, Red Sun y todos los demás.

Las principales diferencias son:

  • portabilidad: por ejemplo, YARV solo es oficialmente compatible con x86 32 Bit Linux. No es compatible con OSX o Windows o 64 Bit Linux. Rubinius solo funciona en Unix, no en Windows. JRuby OTOH se ejecuta en todas partes : equipos de escritorio, servidores, teléfonos, App Engine, lo que sea. Se ejecuta en Oracle JDK, OpenJDK, IBM J9, Apple SoyLatte, RedHat IcedTea y Oracle JRockit JVMs (y probablemente un par de otros que olvidé) y también en la máquina virtual Dalvik. Se ejecuta en Windows, Linux, OSX, Solaris, varios BSD, otros Unices propietarios y abiertos, OpenVMS y varios sistemas operativos de mainframe, Android y Google App Engine. De hecho, en Windows, JRuby pasa más pruebas de RubySpec que "Ruby" (es decir, MRI o YARV).

  • extensibilidad: los programas Ruby que se ejecutan en JRuby pueden usar cualquier biblioteca de Java arbitraria. A través de JRuby-FFI, también pueden usar cualquier biblioteca C arbitraria. Y con el nuevo soporte de extensión C en JRuby 1.6, incluso pueden usar un gran subconjunto de extensiones MRI y YARV C, como Mongrel, por ejemplo. (Y tenga en cuenta que la biblioteca "Java" o "C" no significa realmente escrita en esos lenguajes, solo significa con una API Java o C. Pueden estar escritas en Scala o Clojure o C ++ o Haskell).

  • herramientas: cada vez que alguien escribe una nueva herramienta para YARV o MRI (como p. ej., memprof), resulta que JRuby ya tenía una herramienta hace 5 años que hace lo mismo, pero mejor. El ecosistema de Java tiene algunas de las mejores herramientas para la "comprensión del comportamiento en tiempo de ejecución" (que es un término que acabo de inventar, me refiero a mucho más que un simple perfil, me refiero a herramientas para comprender en profundidad qué hace exactamente su programa en tiempo de ejecución, cuáles son sus características de rendimiento, dónde están los cuellos de botella, a dónde va la memoria y, lo que es más importante, por qué sucede todo eso) y la visualización disponible en el mercado, y casi todos trabajan con JRuby, al menos hasta cierto punto.

  • Implementación: asumiendo que su sistema de destino ya tiene una JVM instalada, implementando una aplicación JRuby (y no solo estoy hablando de Rails, también me refiero a servidores de escritorio, móviles, otros tipos de servidores) literalmente solo está copiando un JAR (o WAR) y un doble clic.

  • Rendimiento: JRuby tiene una sobrecarga de inicio mucho mayor. A cambio, obtienes un rendimiento mucho mayor. En la práctica, esto significa que implementar una aplicación Rails en JRuby es una buena idea, ya que está ejecutando sus pruebas de integración, pero para las pruebas de unidades de desarrollo y los scripts, MRI, YARV o Rubinius son las mejores opciones. Tenga en cuenta que muchos desarrolladores de Rails simplemente desarrollan una prueba unitaria en MRI y una prueba de integración y la implementan en JRuby. No hay necesidad de elegir un solo motor de ejecución para todo.

  • concurrencia: JRuby ejecuta hilos de Ruby al mismo tiempo. Esto significa dos cosas: si su bloqueo es correcto, su programa se ejecutará más rápido, y si su bloqueo es incorrecto, su programa se interrumpirá. (Desafortunadamente, ni MRI ni YARV ni Rubinius ejecutan subprocesos simultáneamente, por lo que todavía hay un código Ruby multiproceso roto que no sabe que está roto, porque obviamente los errores de concurrencia solo pueden aparecer si existe la concurrencia real).

  • plataformas (esto está algo relacionado con la portabilidad): hay algunas plataformas Java increíbles, por ejemplo, el Azul JCA con 768 GiBytes de RAM y 864 núcleos de CPU diseñados específicamente para memoria segura, puntero seguro, recolección de basura, orientado a objetos idiomas Androide. Motor de aplicaciones de Google. Todos ellos corren JRuby.

He escuchado grandes cosas sobre JRuby y sé que puedes ejecutarlo sin saber nada de Java. Mis habilidades de desarrollo son sólidas, Java no es una de las herramientas que conozco. Es una herramienta masiva con una gran variedad de herramientas de acompañamiento como Maven / Ant / JUnit, etc.

¿Vale la pena trasladar mis aplicaciones Rails actuales a JRuby solo por razones de rendimiento? Tal vez, si cojo algo de Java básico a lo largo, ¿puede haber beneficios adicionales que no sean tan obvios como mejores herramientas de optimización de depuración / rendimiento?

Me encantaría algún consejo sobre este.

JRuby es una de las pocas implementaciones que utiliza subprocesos nativos. Así que si quieres hacer un subprocesamiento múltiple, hazlo.

En lo que se refiere al alojamiento, tienes que poner tu aplicación en algún tipo de contenedor java, que personalmente me parece mucho menos sencillo que usar algo como pasajero (para aplicaciones Rack)

Utilizo JRuby para una aplicación, ya que nos comunicamos a través de JMS y funciona bien, pero si no estuviera usando ningún Java, me quedaría con CRuby. Mi mayor problema es que, en las pruebas, la ejecución de las pruebas se lleva una eternidad con JRuby, ya que tiene que activar una máquina virtual cada vez que las ejecuta. Esto hace que sea mucho más difícil para TDD, ya que es un golpe importante en su tiempo de prueba.

Jruby tiene ventajas si estás en Windows. Admite 64 bits y puede usar muchas bases de datos propietarias con controladores JDBC estándar.

Las últimas versiones son significativamente más rápidas que Ruby, pero también utilizan significativamente más memoria. Si esa es su única razón para usar JRuby, no me molestaría a menos que tenga una necesidad de rendimiento específica que solucione, simplemente porque, aunque es bastante popular, es menos estándar para el alojamiento y menos personas lo utilizan en comparación con el estándar Rubí. Dicho esto, hay muchas otras razones para usar JRuby, como la necesidad de interoperabilidad con el código Java existente y la necesidad de implementar en entornos donde Java ha sido "bendecido" por el departamento de operaciones y Ruby no.

Yo modificaría lo que Peter dijo ligeramente. JRuby puede usar más memoria en comparación con Ruby estándar, pero eso es generalmente porque estás haciendo el trabajo en un solo proceso, lo que llevaría a varios procesos con Ruby.

Debes probar el Rails.threadsafe! opción con un solo tiempo de ejecución de JRuby (por ejemplo, la gema de Trinidad con la opción --threadsafe ). Hemos escuchado varias historias en las que le brinda un gran rendimiento y un bajo uso de memoria, al tiempo que aprovecha varios núcleos de CPU con un solo proceso.