OSCON 2016 - Ruby can too scale: Highly performant microservices in Ruby
6/07/2016The following blog post consists mostly of notes taken from Tim Krajcar's talk at OSCON 2016 in Austin. I am sharing this because I thought it was a great talk that deserved to have something more long form than the speaker deck available here. Although I have some of my own research mixed into these notes, credit for the ideas expressed below belongs to Tim.
Performance
Optimize request queuing time.
- https://docs.newrelic.com/docs/apm/applications-menu/features/request-queuing-tracking-front-end-time
- https://www.appneta.com/blog/measuring-the-impact-of-request-queueing/
- http://blog.leansentry.com/all-about-iis-asp-net-request-queues/
- http://blog.scoutapp.com/articles/2011/03/30/detecting-haproxy-apache-passenger-queue-backlogs
- http://railsware.com/blog/2013/02/25/heroku-queuing-time-part1-problem/
- http://railsware.com/blog/2013/02/28/heroku-queuing-time-part2-solution/
Performance metrics during unit tests
Framework reduction
Scaling tips
- Set reasonable timeouts on your client calls. The Ruby HTTP default timeout of 60 seconds is NOT a reasonable timeout. In tandem, use the circuit breaker pattern to avoid flooding struggling servers. Gems that can help here are the Timeout module and cb2 gem.
- Parallelize operations over collections whenever possible. This is very easy to do with HTTP requests using Typhoeus Hydra. There's also the Parallel library that allows you to operate over collections using multiple processes or threads.
- Rate limit by client. If you are using Rack there's a middleware called rack/throttle that can enforce a minimum time interval between subsequent HTTP requests from a particular client and can also define a maximum number of allowed HTTP requests per a given time period (per minute, hourly, or daily).
0 comments