Ruby Background Libraries Showdown

Presented on Ruby Slovenia March Meetup 2015

Transcript

1. Ruby background processing libraries showdown RubySlovenia Meetup March 2015 Matic Jurglič @matixmatix jurglic.si
2. Motivation - I was doing lots of asynchronous scraping (sitestalker.net) - Using resque processing library, which drained server resources quickly - Needed to optimize! -> why not do some benchmarks! (github.com/matixmatix/ background-showdown-rails)
3. Delayed Job Resque Sidekiq The Big Three
4. - Single threaded (for each additional level of concurrency a new worker process is needed -> big memory resource consumption) - Simple to configure with ActiveRecord - Stores jobs in a database -> bad performance, scalability issues Delayed Job
5. - Single threaded as well - Similar to Delayed Job, high memory footprint for multiple workers - BUT: Uses Redis - a far better and faster alternative as a queue, compared to a database Resque
6. 6 Resque web interface
7. - Single process, “multi-threaded”, BUT: MRI has a global interpreter lock, so there is no true parallelism - Lightweight, Redis - Workers must be thread safe (some gems might be troublesome (Paperclip, Imagemagick,...)) Sidekiq
8. 8 Sidekiq web interface
9. 1. For simple and IO jobs, Sidekiq should win (lightweight, draining less resources, not a lot of processing power needed) 2. For CPU heavy jobs (hard computations), DJ and Resque should win (because they can utilize all CPU cores) Hypothesis
10. Super Scientific Benchmark
11. 2000 Simple Jobs - Not much work, just a database insert 200 CPU Heavy Jobs - High cost BCrypt hashing algorithm 500 IO Jobs - Scrape a slow website Super Scientific Benchmark
12. - Rails since 4.2 comes with background processing library agnostic worker class: Rails Active Job
13. Rails Active Job
14. Simple Jobs (MRI)
15. CPU Heavy Jobs (MRI)
16. Resque - 12 Workers Sidekiq - 12 Workers CPU & Memory (CPU Heavy jobs, MRI)
17. IO Jobs (MRI)
18. Resque - 12 Workers Sidekiq - 12 Workers CPU & Memory (IO jobs, MRI)
19. 1. Sidekiq wins for simple and IO jobs, consumes less memory while also performing faster 2. Sidekiq is a big loser for CPU heavy jobs Observation?
20. But!
22. - Java implementation of Ruby that allows running on real, native threads - JVM - Eliminates Ruby MRI’s great weakness: GIL (Global Interpreter Lock) - where threads only run one at a time, and MRI switches between threads, giving them a small window of processing time JRuby
23. CPU Heavy Jobs (JRuby)
24. Resque - 12 Workers Sidekiq - 12 Workers CPU & Memory (CPU Heavy, JRuby)
25. IO Jobs (JRuby)
26. Resque - 12 Workers Sidekiq - 12 Workers CPU & Memory (IO Jobs, JRuby)
27. 1. Sidekiq is weak for heavy calculations but on average wins for everything else (on MRI) 2. After switching to JRuby, Sidekiq begins to outperform other libraries in general for every type of job, uses less memory Verdict?
28. 3. In some cases Resque still is a bit faster than Sidekiq, but it it has substantially higher memory footprint Verdict?
29. For average jobs just use Sidekiq, and switch to JRuby for extra JVM performance boost. Final verdict?