Your SlideShare is downloading. ×
  • Like
Truly madly deeply parallel ruby applications
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Truly madly deeply parallel ruby applications



Published in Software
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Truly Madly Deeply Parallel Ruby (Web)* Applications @harikrishnan83 * Thanks @headius
  • 2. How many of you are building web applications?
  • 3. How many of you have more than 1 user using it at a time?
  • 4. How many of you use scaling out as the way hit scale?
  • 5. How many of you are scaling up to hit scale?
  • 6. What is a parallel environment?
  • 7. Parallelism
  • 8. Concurrency Thread A - load Thread B - load Thread A - increment Thread B - increment Thread A - save Thread B - save i = 0 i = 0 i = 1 i = 1
  • 9. Ruby web application deployment
  • 10. Process Parallelism Reverse Proxy Unicorn Processes Database Layer
  • 11. On my current project
  • 12. We only use EC2 small instances
  • 13. Because it is very hard to utilize a high spec machine Process Context Switch is Expensive
  • 14. Today... ● We have 4 small EC2 instances ● 2 Puma processes run on each ● Handles about 100,000 requests per hour ● And this is our Private alpha
  • 15. We need to... ● Handle about 1 million requests per hour ● Which means about 40-45 EC2 small instances
  • 16. This is not trivial ● Costs a lot of money ● Lot of time required to maintain these boxes ● Being elastic will become very important ● Cost also in terms of more Devops time
  • 17. In general
  • 18. It is easier to baby sit few boxes
  • 19. Than a lot!
  • 20. Ideally, we would like to both scale up and scale out
  • 21. i.e. we want to achieve the same throughput with, say, just 5 large instances
  • 22. Enter thread based parallelism
  • 23. Why were we not doing this till now?
  • 24. Threads are hard* They share memory and mutate thingsThey share memory and mutate things * - Supposedly
  • 25. And there is the ubiquitous issue ‘Thread Safety’
  • 26. Before we go there, first lets look at some code
  • 27. The real question is...
  • 28. Are you “Safe for Parallelization”
  • 29. Understanding this will take you a long way in “getting parallel”
  • 30. Things to remember while moving to threaded parallelism
  • 31. #1 - Always identify the shared resources
  • 32. Shared Resource ● Objects ● DB rows ● Caches ● Log files!
  • 33. #2 - Bank on thread safe libraries
  • 34. Libraries ● Data structures ● JSON, XML parsing, HTTP clients etc ● Generally, auditing all the gems you use for thread safety is a good idea
  • 35. If you only use thread safe libraries are you ‘safe for parallelism’?
  • 36. Rails is thread safe right? Why is everyone concerned about thread safety in the first place?
  • 37. #3 - If two libraries are thread safe, code that uses both of them need not be
  • 38. Rails thread safety model ● Instantiate everything for every request ● No shared state (global objects) ● Different from, say, Java (single servlet object per container, IOC with singletons etc.)
  • 39. #4 - Try and stick to Rails’ way of handling requests
  • 40. Are you ‘Safe for parallelism’ if you follow these steps?
  • 41. Well, it depends...
  • 42. Validating, say, through a green bar is very hard.
  • 43. Always give yourself some time to stabilize. The move is definitely not overnight!
  • 44. Speaking of the move, move where?
  • 45. Since Rubinius is mostly MRI like, its simpler
  • 46. I personally love JRuby more because of my JVM background
  • 47. Lots of good things have been spoken about JRuby
  • 48. Some gotchas based on my experience
  • 49. JRuby impacts Developers ● The JRuby startup time (mostly because of the JVM startup time) can sometimes kill red- green cycle time ● Sometimes, you should be OK with stooping down to Java code to figure out why something is not working
  • 50. JRuby impacts OPs ● You no longer have a ruby app in prod, its a Java app ● GC tuning, Process monitoring, Profiling etc. are very different on a JVM
  • 51. Thread Parallelism Reverse Proxy Puma Instance Database LayerThreads
  • 52. Thank you! @harikrishnan83