The document discusses helping customers cut costs in their web APIs. It recommends using Goliath, an asynchronous Ruby web server, Beanstalk for work queues, Couchbase for data storage, and HAProxy as a load balancer. This approach was tested on a mobile game API and increased performance from 450 to 1300 requests per second while reducing the number of application servers needed from 4 to 1, cutting costs while improving scalability.

1. Helping your customers to cut costs in their web APIs.

2.  16 years in Software Development
 From S/390 to Android
 In love with Ruby since 2006
 Working in
 @eljuanchosf
 Love to dance Tango and play Blues guitar

3.  Set of programming components and
standards.
 Open up your app to the world.
 Integration!

4.  Mobile social game (iOS & Android)
 Video upload & encoding
 JSON API
 AWS -> EC2/S3

5. Autoscale with
Scalr.com

6.  Find a way to cut costs and improve
performance.
 Provide a very easy way to scale the new
solution.
 Maintain all the RoR application functionality,
focusing on APIs for the mobile clients.
 Tight, TIGHT budget.

7.  Inspiration: Draw Something –
http://goo.gl/hi7a6
 Goliath
 Beanstalk
 Couchbase
 HAProxy as load balancer.
 Varnish

8.  Asynchronous (non-blocking) web server framework.
 Based on EventMachine
 Lightweight
 Rack API & middleware support
 Very simple yet powerful configuration
 Fully async processing
 Websockets out of the box
 No callbacks!!
 Low memory footprint (only 65 KB!)
 0.3 ms from top -> bottom!
 http://postrank-labs.github.com/goliath/

9.  Very simple, very fast work queue.
 Saves memory (lots of it).
 Multiple queues.
 Generic interface.
 Several Ruby clients to choose from.
 Send your Ruby object as a JSON.
 Parallel and asynchronous.
 Scales VERY easily.
 http://kr.github.com/beanstalkd/

10.  Ruby implementation of the Reactor Pattern
 Highly scalable
 Performance optimized
 Mature & stable
 Eliminates the complexities of threaded network
programming.
 Active community
 Examples: Thin & Goliath.

11.  October 1995 by Douglas Schmidt
 AKA Dispatcher or Notifier
 Handle requests delivered to an application by one
or more clients.
 Single threaded by definition
 Separates application logic from the reactor
implementation
 Task switching = no multithreading!

13. EM.run {
EM::HttpRequest.new(‘http://www.example.com’).get.callback {
|http|
puts http.response
}
}

14. EM::HttpRequest.new(first_url).get.callback {|http|
second_url = extract_next_url(http.response)
EM::HttpRequest.new(second_url).get.callback {|http2|
puts http2.response
}
}

15. require 'em-synchrony/em-http'
http = EM::HttpRequest.new(first_url).get
second_url = extract_next_url(http.response)
http2 = EM::HttpRequest.new(second_url).get
No callbacks and still asynchronous!!!

16.  https://github.com/igrigorik/em-synchrony
 https://github.com/eventmachine/eventmachine/wiki/protoc
ol-implementations

17.  Latest version has no built-in routing system.
 Ilya Grigorik (Goliath’s creator) suggests to
start multiple Goliath servers, each one with
one endpoint and use HAProxy or any reverse
proxy to route the requests.
 That’s kind of cumbersome, don’t you think?

18.  Routing was done thru convention over
configuration with a little of Ruby’s reflection
abilities mixed with some inheritance:
 http://server/api/game/CreateGame was redirected to the
api/game/create_game.rb controller:
class CreateGame < APIController
.
.
.
.
end

19.  Goliath: add processes or servers and
configure them in HAProxy.
 Couchbase: add servers to the cluster.
 Done!
(we used Scalar to automate this, too)

20.  From ~450 req/s to ~1300 req/s.
 From 4 to 1 EC2 application servers.
 Triple performance while reducing costs.
 Video upload and processing fast and
reliable: ~250 jobs/s