Comparing Elasticity of Reactive Frameworks – James Ward – Users Want
Comparing Elasticity of Reactive Frameworks – James Ward – Users Want
1 4
comparing-elasticity-reactive-frameworks
On Github jamesward / comparing-elasticity-reactive-frameworks
Comparing Elasticity of Reactive Frameworks
James Ward
Users Want
- In-Sync Data
- Real-time Collaboration
- Instant Feedback
- To Not Wait
Users Want Reactive Apps
www.ReactiveManifesto.org
Elastic
The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.Elastic
Resource Contention is a conflict over access to a shared resource- Message-Driven / Async
- Reactive All The Way Down
- Idle Threads = Contention Point
- Shared / Distributed state = Contention Point
Reactive Streams
www.reactive-streams.org
Back Pressure
- Stream-oriented
- Sensible behavior on resource contention
- Avoids unnecessary buffering
- Iteratees, Rx, Reactive Streams
Reactive Requests & Reactive Composition
Example Use Case
Reactive composition of stateless nano-services Request a random number that is around 5 Make that many requests to a random word service Return the random string of gibberishThe Old Way
- Servlets, Blocking, & No-Parallelism (cause it's hard)
- Code: github.com/jamesward/gibberish-legacy
- App: gibberish-legacy.herokuapp.com
Play + Scala
- Netty for Reactive IO
- Scala Futures for Async & Parallelism
- Code: github.com/jamesward/gibberish-play
- App: gibberish-play.herokuapp.com
RatPack + RxJava
- Netty for Reactive IO
- RxJava Observables for Async
- RxRatPack for Adapters and Parallelism
- Special thanks to Luke Daley
- Code: github.com/jamesward/gibberish-ratpack-rxjava
- App: gibberish-ratpack-rxjava.herokuapp.com
Akka HTTP
- Reactive Actor-based IO (Akka IO)
- Reactive Streams
- Very New & Experimental
- Producer & Consumer with Non-Blocking Back Pressure
- Code: github.com/jamesward/gibberish-akka-http
NodeJS + Express + Q
- Express for routing / request handling
- Requests for HTTP requests
- Q for Async
- Code: github.com/jamesward/gibberish-nodejs-express
- App: gibberish-nodejs-express.herokuapp.com
Load Testing
- Pretty Unscientific
- Zero App Optimizations
- All Apps run on Heroku
- No Auto-Scaling
- loader.io for Load Test
- randnum.herokuapp.com - 10 Dynos
- random-word.herokuapp.com - 50 Dynos
Legacy - 1000 Concurrent for 1 Minute
Requests / SecAverage Response Time (ms)1 Dyno2 Dynos4 Dynos8 Dynos07501,5002,2503,000
Average Response Time (ms)
Play - 1000 Concurrent for 1 Minute
Requests / SecAverage Response Time (ms)1 Dyno2 Dynos4 Dynos8 Dynos07501,5002,2503,000
Average Response Time (ms)
RatPack - 1000 Concurrent for 1 Minute
Requests / SecAverage Response Time (ms)1 Dyno2 Dynos4 Dynos8 Dynos01,5003,0004,5006,000
Average Response Time (ms)
NodeJS - 100 Concurrent for 1 Minute
Requests / SecAverage Response Time (ms)1 Dyno2 Dynos4 Dynos8 Dynos05001,0001,5002,000
Average Response Time (ms)
Conclusions
- Stateless apps scale horizontally
- Reactive Composition is pretty easy
- Reactive all the way down is optimal
- Do your own load tests