Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Truly Madly Deeply Parallel Ruby Web Applications

Truly Madly Deeply Parallel Ruby Web Applications

My slides of talk at http://rubyconfindia.org/2014/

Traditional Ruby application architecture involves multiple processes to achieve parallelism. This talk covers below topics.
1. Process Parallelism is not a very efficient way of scaling.
2. "Safe for Parallelism" is more important than being just "Threadsafe".
3. JRuby or Rubinius

HariKrishnan

March 23, 2014
Tweet

More Decks by HariKrishnan

Other Decks in Programming

Transcript

  1. 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
  2. Because it is very hard to utilize a high spec

    machine Process Context Switch is Expensive
  3. 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
  4. We need to... • Handle about 1 million requests per

    hour • Which means about 40-45 EC2 small instances
  5. 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
  6. Threads are hard* They share memory and mutate things They

    share memory and mutate things * - Supposedly
  7. Libraries • Data structures • JSON, XML parsing, HTTP clients

    etc • Generally, auditing all the gems you use for thread safety is a good idea
  8. #3 - If two libraries are thread safe, code that

    uses both of them need not be
  9. 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.)
  10. 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
  11. 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