This document summarizes the migration of a location services application from Ruby to Scala at Whitepages. It discusses key areas of interest over the software development lifecycle. For prototyping, Ruby was faster due to its dynamic typing. However, for production, Scala was better suited due to its static typing catching errors, built-in support for concurrency using Futures, and better performance in terms of throughput, latency and hardware utilization. Both languages are object-oriented, readable and composable, but Scala integrates better with the JVM and has advantages for maintainability and integration.

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

29. Thank you.
Questions?