![val x = Future {
1 + 1
}
val y = x map { case two =>
two * 2
}
y map println
WhitePages Confidential 11
Scala Concurrency: Futures
• Drawbacks
– Have to be used in a non-blocking
way (without Await)
– Confusing types
o Future[Future[Int]]
o Seq[Future[Int]]
o flatMap and sequence functions
help to avoid these types
– Difficult to debug](https://image.slidesharecdn.com/presentation-recover-140910151038-phpapp02/85/Ruby-to-Scala-in-9-weeks-11-320.jpg)
Ruby to Scala in 9 weeks
- 1. Ruby to Scala in 9 Weeks Evolving antiquated software with modern tools Jake Utley (jutley@uw.edu) Sept. 9, 2014
- 2. WhitePages 2 Areas of interest over SDLC • Understanding the problem • Exploring solution space • Speed of prototyping • Performance • Maintainability • Integration prototyping production
- 3. WhitePages 3 Scala and Ruby Similarities • Readable and concise • Object oriented • Highly composable (traits and mixins) • Highly adaptable
- 4. WhitePages 4 Background: Location Services • An internal service at Whitepages, written in Ruby • Rationalizes Foursquare data against Whitepages people data • Modified to use data from Facebook, LinkedIn, and Twitter • Contained many issues that motivated rewrite – Unclear code – Sloppy code organization – Poor performance – Minimal documentation
- 5. WhitePages 5 Migration to Scala • Concurrency – Ruby EventMachine vs. Scala Futures • Type system • Performance – Throughput – Latency – Hardware Utilization
- 6. CONCURRENCY
- 7. • Ruby: No built-in concurrency – Many implementations are single-threaded – Cooperative multitasking comes from external libraries • Scala: Built-in concurrency – Built on top of the JVM – Supports standard concurrency models o Futures, Actors WhitePages 7 Concurrency
- 8. • Ruby library for cooperative multitasking • Uses the reactor pattern • Dangerous: blocking incorrectly can kill entire app • Long chains of callbacks WhitePages 8 Ruby Concurrency: EventMachine Location Services author created DeferrableSequence to manage callbacks Wikipedia: http://bit.ly/1qHMez5
- 9. WhitePages 9 Scala Concurrency: Futures val x = Future { 1 + 1 } val y = x map { case two => two * 2 } y map println • Well known concurrency model • Built into Scala • Functional and imperative: – Composition (via map, zip, etc.) – Callbacks (onComplete, etc.) • Blends nicely into other code • Can be treated like a 1-element collection
- 10. WhitePages 10
- 11. val x = Future { 1 + 1 } val y = x map { case two => two * 2 } y map println WhitePages Confidential 11 Scala Concurrency: Futures • Drawbacks – Have to be used in a non-blocking way (without Await) – Confusing types o Future[Future[Int]] o Seq[Future[Int]] o flatMap and sequence functions help to avoid these types – Difficult to debug
- 12. WhitePages 12 Areas of interest over SDLC • Understanding the problem • Exploring solution space • Speed of prototyping • Performance • Maintainability • Integration prototyping production
- 13. TYPE SYSTEMS
- 14. WhitePages 14 Type Systems • Ruby: Dynamically typed • Scala: Statically typed • Both have advantages depending on the circumstance
- 15. WhitePages 15 Type Systems: Ruby • Dynamic typing – Types are checked at runtime – More flexibility – Easier to express ideas -> faster prototyping – More room for errors – Less self-documentation, potentially harder for others to understand code – Defensive coding
- 16. WhitePages 16 Type Systems: Scala • Static typing – Compiler type checks – Many errors are caught at compile time – Argument types are always documented – Easier for others to maintain code – Strict contracts – IDEs can tell us the types of any variable – Drawback: An IDE becomes a crutch
- 17. WhitePages 17 Areas of interest over SDLC • Understanding the problem • Exploring solution space • Speed of prototyping • Performance • Maintainability • Integration prototyping production
- 18. PERFORMANCE
- 19. Performance: Methodology • Requests from production sent to services for 5 WhitePages 19 minute interval • Request rate increased until majority of requests time out (10 seconds) • Each service ran on identical hardware • 30 seconds warmups • 3 trials at each request rate
- 20. WhitePages 20 Performance tools: Onslaught • Performance testing tool built at Whitepages • Reports throughput, p50, p75, p95, p99, p999, mean, and max latencies • Plan to make Onslaught open-source
- 21. WhitePages 21 Performance: Expectations • Non-blocking I/O – Higher throughput – Better CPU usage (no waits) – Higher memory usage • JVM optimizations – Lower latency
- 22. Throughput (Scala) WhitePages 22 Performance: Throughput 450 400 350 300 250 200 150 100 50 0 Throughput (Ruby) 25 50 75 100 125 150 Successful responses/s Requests/s 450 400 350 300 250 200 150 100 50 0 100 200 300 400 500 600 Successful responses/s Requests/s
- 23. WhitePages 23 Performance: Latency 10000000 9000000 8000000 7000000 6000000 5000000 4000000 3000000 2000000 1000000 0 Latency (Ruby) 25 50 75 100 125 150 Latency (μs) Request rate (Req/s) p50 p95 p99 10000000 9000000 8000000 7000000 6000000 5000000 4000000 3000000 2000000 1000000 0 Latency (Scala) 100 200 300 400 500 600 Latency (μs) Request rate (Req/s) p50 p95 p99
- 24. WhitePages 24 Performance: CPU
- 25. WhitePages 25 Performance: CPU
- 26. WhitePages 26 Performance: Memory
- 27. WhitePages 27 Areas of interest over SDLC • Understanding the problem • Exploring solution space • Speed of prototyping • Performance • Maintainability • Integration prototyping production
- 28. WhitePages 28 Summary Scala or Ruby? • Prototyping: – Ruby’s dynamic typing allows for fast prototyping • Production: – Scala’s static typing catches more errors and can make code clearer – Scala supports concurrency with standard library, Ruby does not – Scala performs better than Ruby in throughput and hardware utilization
Editor's Notes
- #2: Introduction Been moving a service from Ruby to Scala Sharing most interestings aspect of my experience moving a Ruby service that has outgrown Ruby, to Scala Disclaimer: Mostly subjective material, based on experience
- #3: Over course of SDLC, we’re interested in different things Different languages allow us to explore different ideas better Ruby better for prototyping, Scala better for production
- #4: Not “write-only”
- #5: When just Foursquare, resembled prototype Too much added on at a bad state Use Scala for rewrite, better for production What makes Scala better for production? Most issues not due to Ruby
- #8: Main implementations, MRI (Matz’s Ruby Interpreter) C-based, single threaded Similar issues with other interpretted languages (like python) Outside library I used: EventMachine In my case: EventMachine and Futures
- #9: Ask who is familiar with reactor pattern (handler dispatches requests) because single threaded, blocking the thread kills the app long chains of callbacks: hard to trace code Author created DeferrableSequence to manage callbacks. Extra work, non-standard (unfamiliar, error-prone) Event machine only ever doing one thing at a time, not true concurrency
- #10: Built in: reliable, familiar to other developers Callbacks for side effects (don’t return something) Composition for functional code
- #11: Built in: reliable, familiar to other developers Callbacks for side effects (don’t return something) Composition for functional code
- #12: Still need to avoid blocking, not as severe consequences as EM Overall: Often when prototyping, we’re not as concerned with concurrency, so Ruby works perfectly fine. In production, Scala is more appealing Other major difference: Type System
- #13: Other difference: type system
- #16: compiler doesn’t get in the way dynamically typed code has high potential to become hard to maintain code
- #17: Compiler is our friend Code with a longer shelf life
- #18: Type systems and concurrency different, impacts performance
- #19: Dynamic vs. static, interpreted vs. compiled, different concurrency models: expect different performance
- #21: Point out Devin and Paul
- #23: Fairly significant improvement in throughput Seen higher improvements in other services, so we suspect that this can be improved further
- #24: clarify x axis
- #25: Over period of throughput testing Graph shows Idle CPU can be confusing upside down About the same amount of CPU use
- #26: Graph shows Idle CPU can be confusing upside down
- #27: Graph shows Idle CPU can be confusing upside down Overall: Scala seems to use more resources more heavily, but is much faster
- #28: Does anybody not care about performance?