Scaling Rails: a system-wide approach to performance optimization

Scaling Railsa system-wide approach to performance optimization

February 2010

FEUP

Exploratory Case Study: http://escolinhas.pt

< Problem >

Scaling Rails: a system-wide approach to performance optimization2

Web 2.0


Better web

Better tools


Ruby on Rails


Popularity brings USERS

USERS need scalability


Rails doesn’t scale


Twitter


Twitter abandoning Rails?


“FWIW: Twitter currently has no plans to

abandon RoR. Lots of our code is not in

RoR, already, though. Maybe that's why

people are confused.”


- Evan Williams, Twitter CEO

YellowPages


More users?

“Just throw hardware at it.”


Rails doesn’t scale


Hulu


Scribd


They scaled

They gave keynotes on

HOW


What’s missing here?


No general approaches to scaling


Problem Overview


Rails doesn’t scale?

Twitter

YellowPages

Rails doesn’t scale?

Hulu

Scribd

General approaches to scaling?


< Problem Overview >

< Motivation >


WEB


WEB

WEB

WEB

WEB

USERS


USERS

USERS

USERS

USERS

IMPORTANCE


IMPORTANCE

IMPORTANCE

IMPORTANCE

IMPORTANCE

Better web


Better tools


UX involves reasonable response

times and service uptime


Most recent tools are great


“Ruby on Rails is a breakthrough in lowering the

barriers of entry to programming. Powerful web

applications that formerly might have taken

weeks or months to develop can be produced in

a matter of days.”


- Tim O'Reilly, Founder of O'Reilly Media

Everything can be improved

There is no perfect tool

There are always pitfalls


What’s really motivating?


Fixing pitfalls on great tools

Improving UX for everyone


Motivation Overview


Web keeps growing

More users, importance

Web 2.0

User Experience

Also dependant on:

Response times and availability

Recent tools are great

There are always pitfalls

Fixing pitfalls on great tools

Improving UX for everyone


< Motivation Overview >

< Goals >


What about scaling?


Everything is easy

Scaling should also be easy


Creation of


Guidelines and conventions

for high performance

Rails applications


Optimal Rails-oriented

configurations for every involved

component


Patches to improve the

components performance from a

Rails-perspective


Objectives Overview


Scaling should be easy

Creation of:

Generic guidelines and conventions

Optimal configurations

Patches for all components

All from a performance-oriented philosophy centered

in Ruby on Rails!


< Objectives Overview >

< State of the Art >


< Operating Systems >


Most used OS in servers: Linux


BSD faster than Linux


Linux faster than BSD


Linux Ruby 1.8 2x faster

than Windows Ruby 1.8


Linux Ruby 1.9 70% faster

than Windows Ruby 1.9


Rails widely deployed in Linux


< Ruby >


Ruby 1.8 is the most widely used


JRuby is the fastest implementation


Ruby 1.8 will soon be outdated


Ruby 1.9 will soon be outdated


Ruby 1.9 has only one interpreter


Ruby MRI 1.9


Ruby MRI 1.9

Rails bottleneck: GC


< Web servers >


Webrick


Webrick

Pioneer, slow


Mongrel


Mongrel

Much faster, excellent HTML parser


Thin


Thin

Mongrel’s HTML parser


Thin

New I/O back-end: EventMachine


Thin

Faster than those before


Passenger


Passenger

Not self-contained


Passenger

Module for Apache/Nginx


Passenger

Good performance, great at scaling


Thin is the fastest

Passenger scales better


< Database >


MySQL


PostgreSQL


MySQL is faster and more popular


Schema-less databases


Schema-less databases

Said to have better performance than SQL


MongoDB


CouchDB


Benchmarks are scarce


Major improvement in all DB:

Caching, caching, caching!


< Rails >


Rails 2.3


Many performance pitfalls

improved in Rails 3


Rails 3

Beta release in February


Immediate need: form helpers, i18n


< Application >


Porting to Ruby 1.9 (from 1.8)


Porting to Rails 3 (from 2.3)


Check code for common pitfalls

Eager loading

Fetching records in batches

Database Indexes

Caching


< Methodology >


State of the Art narrows options down


Benchmarking

Controlled tests to choose the best

software for each component


Tweaking

Try out different configurations and

architectures


Testing

Measuring of results, finding bottlenecks


Developing

Improving over bottlenecks



Benchmarking

Tweaking

Testing

Developing

and

Improving


Recipe: repeat for all components


Rails perspective!


Escolinhas


Butterfly Effect


Consider sensitive dependencies

< Work schedule >



Activity Start Date Duration (weeks)

OS testing and choosing 15/02/2010 1

OS kernel testing and tuning 22/02/2010 1

Web server testing and bottleneck research 01/03/2010 1

Web server bottleneck improvements 08/03/2010 1

Ruby interpreter testing and bottleneck research 15/03/2010 1

Ruby interpreter bottleneck improvements 22/03/2010 1.5

DB testing and bottleneck research 31/03/2010 1

DB bottleneck improvements 07/04/2010 1

Rails bottleneck research 14/04/2010 1

Rails bottleneck improvements 21/04/2010 2.5

Escolinhas analysis and bottleneck research 10/05/2010 1

Escolinhas improvements 07/05/2010 3

Writing of dissertation report 07/06/2010 4

< Thank you >

http://snaprails.tumblr.com

Gonçalo S. SilvaAdvisor: Ademar Aguiar

http://goncalossilva.comhttp://twitter.com/goncalossilva

Scaling Rails: a system-wide approach to performance optimization

Technology

Transcript of Scaling Rails: a system-wide approach to performance optimization