JRuby Everything in a single process Presentation based on moving real world Rails application to JRuby [email_address] oc...
Agenda <ul><li>JRuby - pros and cons
Reasons to move to JRuby
Short JRuby servers description
Quartz Scheduler Integration </li></ul>
JRuby  myths <ul><li>JVM is slow and  memory  greedy </li><ul><li>Actually fast and can save a lot of memory! </li></ul><l...
It's just Ruby on JVM </li></ul></ul>
JRuby cons <ul><li>Longer startup times
Problems with C extensions </li><ul><li>Situation gets better </li></ul></ul>
JRuby pros <ul><li>JVM – advanced VM
Fast Ruby implementation </li><ul><li>Bright future – invokedynamic (Java 7) </li></ul><li>No GIL (Global Interpreter Lock...
Motivations to move to JRuby <ul><li>SEO  application
New feature in the App – long time, I/O bound task
Tens of concurrent requests
Traditional Ruby approach would require many gigabytes of RAM </li><ul><li>Single request per process (REE with copy-on-wr...
Available servers <ul><li>Three servers reviewed
Upcoming SlideShare
Loading in …5
×

JRuby - Everything in a single process

3,250 views
3,082 views

Published on

Presentation based on moving real world Rails application to JRuby.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,250
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

JRuby - Everything in a single process

  1. 1. JRuby Everything in a single process Presentation based on moving real world Rails application to JRuby [email_address] ocher
  2. 2. Agenda <ul><li>JRuby - pros and cons
  3. 3. Reasons to move to JRuby
  4. 4. Short JRuby servers description
  5. 5. Quartz Scheduler Integration </li></ul>
  6. 6. JRuby myths <ul><li>JVM is slow and memory greedy </li><ul><li>Actually fast and can save a lot of memory! </li></ul><li>Ruby developers hate Java </li><ul><li>JRuby can be used in the same way as MRI, without touching Java
  7. 7. It's just Ruby on JVM </li></ul></ul>
  8. 8. JRuby cons <ul><li>Longer startup times
  9. 9. Problems with C extensions </li><ul><li>Situation gets better </li></ul></ul>
  10. 10. JRuby pros <ul><li>JVM – advanced VM
  11. 11. Fast Ruby implementation </li><ul><li>Bright future – invokedynamic (Java 7) </li></ul><li>No GIL (Global Interpreter Lock) </li><ul><li>All CPU cores available </li></ul><li>Mature Java libraries </li></ul>
  12. 12. Motivations to move to JRuby <ul><li>SEO application
  13. 13. New feature in the App – long time, I/O bound task
  14. 14. Tens of concurrent requests
  15. 15. Traditional Ruby approach would require many gigabytes of RAM </li><ul><li>Single request per process (REE with copy-on-write GC support saves only about 30% memory) </li></ul><li>Java multithreaded servers to the rescue! </li></ul>
  16. 16. Available servers <ul><li>Three servers reviewed
  17. 17. Very easy configuration
  18. 18. Run almost out of box </li></ul>
  19. 19. <ul>TorqueBox </ul><ul><li>TorqueBox – based on JBoss app server
  20. 20. Complex solution </li><ul><li>Message Queue
  21. 21. Jobs scheduling </li></ul><li>Problems with Hot Deployment </li><ul><li>Takes about 4 minutes to deploy the app
  22. 22. Server is down during that time
  23. 23. Use cluster if zero downtime deploys needed </li></ul></ul>
  24. 24. Trinidad and Kirk <ul><li>Trinidad – based on Tomcat </li><ul><li>Better configuration options than Kirk
  25. 25. Small problem with hot deploy </li><ul><li>Should be fixed in Trinidad 1.2 </li></ul></ul><li>Kirk – based on Jetty </li><ul><li>Simple (too simple?) configuration DSL
  26. 26. No other disadvantages </li></ul><li>Kirk wins </li><ul><li>May be changed to Trinidad when deploy problem is fixed </li></ul></ul>
  27. 27. Job scheduling <ul><li>Many frequent jobs in the app
  28. 28. cron has many disadvantages </li><ul><li>Each job needs to load whole application </li><ul><li>Waste of CPU and RAM
  29. 29. Takes a lot of time (impossible to run very frequent tasks) </li></ul><li>No easy way to keep jobs from overlapping </li></ul><li>Solution: use Quartz library </li></ul>
  30. 30. Quartz Scheduler <ul><li>Popular and proven Java scheduling solution
  31. 31. Thread pool
  32. 32. quartz-jruby gem by Vagmi Mudumbai rewritten to support Quartz 2 and run out of box
  33. 33. Runs frequent jobs at almost no extra cost </li></ul>
  34. 34. jruby-quartz gem example require 'quartz' class TestScheduler include Quartz ::Scheduler schedule(:say_hello_5, :every => 5) { puts &quot;every 5 seconds&quot; } schedule(:say_hello_5_dc, :cron => &quot;0/5 * * * * ? &quot; , :disallow_concurrent => true ) do puts &quot;no overlapping&quot; sleep(8) # !!! end end TestScheduler .instance.run
  35. 35. Quartz – Rails integration # config.ru file # Stop current Quartz Scheduler instance during redeployment # QuartzTasksScheduler is a class which includes Quartz::Scheduler module # and defines jobs at_exit do if QuartzTasksScheduler .instance.scheduler.started? QuartzTasksScheduler .instance.scheduler.shutdown( true ) end end # Run quartz scheduler instance QuartzTasksScheduler .instance.run
  36. 36. JRuby hints <ul><li>Remember about setting max heap size -J-Xmx </li><ul><li>App dependent value
  37. 37. Too small heap means problems </li><ul><li>Worse performance
  38. 38. OutOfMemoryErrors </li></ul></ul><li>Monitor memory usage and opened files (lsof) </li><ul><li>Long running processes introduce new problems </li></ul></ul>
  39. 39. Move to JRuby - Summary <ul><li>Better app architecture
  40. 40. Many more concurrent requests possible
  41. 41. Huge memory saving
  42. 42. No precise benchmark, but definitely not slower </li></ul>
  43. 43. Links <ul><li>http://www.jruby.org/
  44. 44. http://torquebox.org/
  45. 45. https://github.com/trinidad/trinidad
  46. 46. https://github.com/strobecorp/kirk
  47. 47. https://github.com/ocher/quartz-jruby </li></ul>

×