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
35. Libraries
● Data structures
● JSON, XML parsing, HTTP clients etc
● Generally, auditing all the gems you use for
thread safety is a good idea
36. If you only use thread safe
libraries are you ‘safe for
parallelism’?
37. Rails is thread safe right?
Why is everyone concerned
about thread safety in the
first place?
38. #3 - If two libraries are
thread safe, code that uses
both of them need not be
39. 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.)
40. #4 - Try and stick to Rails’
way of handling requests
41. Are you ‘Safe for
parallelism’ if you follow
these steps?
50. 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
51. 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
