truly madly deeply parallel ruby applications

Click here to load reader

Post on 12-Jun-2015

182 views

Category:

Software

0 download

Embed Size (px)

TRANSCRIPT

  • 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