By James Cock (james@smokeclouds.com)
Interactive deck at http://media.imaj.es/scale/

= Art and Rails

== Scalability is an artform

Zed Shaw: Everything takes time
- If you canøt make the computer fast, trick the people to think fast

=== There are no easy answers

- except maybe this:

=== Measure, refactor.- The
Take a measurement, mock around with the code, and test it again
Twitter has done this to get better

=== Planning helps

Twitter was a prototype built for a few 100 people playing around with it


= Testing: Verify your performance

Be sure that your performance is what you think it is
Measure: Response times, concurrent reqs & server load
Look for a tight standard deviation in requests
- Large deviation means that your app is now performing realibily
Keep asking users: "What's Slow?"


= MySQL: Built to perform

- mysql> \s
	- Querys per second: 227
	
Ditch the query cache. It doesn't help you like you think.
- The MySQL team doesn't even recommend it themselves

Become best friends with the various table engines - InnoDB, MyISAM, NBD, etc.
- InnoDB is the default
	- Useful for most stuff
	- But the worst possible type for massive inserts
- MyISAM is good for log files with many inserts

Watch the process list. Hawk like.

Know which queries hurt ...
- Look at slow query load (queries that takes over 1 second)

Some key variables to tune:
- max_allowed_packet & key_buffer_size (keeps your index quicksort from chunking)
- Put more memory in the machine and up the key_buffer_size

Care about wait_timeout, net_write_timeout, net_read_timeout, and max_connections if you use networked db servers
- It is cheaper to close and reopen and non-working connection than waiting for it to timeout

Consider ditching ActiveRecord
- You don't always have to use AR
- E.g. don't use AR for importing


= Caching: How to fix nearly anything

This really defines 80/20
There are few scenarios which are truly uncacheable

Memcached is the defacto tool, and cache_fu (Rails plugin) is the best way in

Memcache is your friend, learn to love it like it loves you :)
(Except on JRuby)

Be wary of over-reliance on memcache
- Facebook runs over 200 gb of memcache, twitter consumes about 40 gb
- Restarting your cache is slow, so find ways to mitigate a cold cache

File I/O lets you down almost all the time
NFS is not as bad as it used to be (distributing disks over network)
Consider offloading to s3 - it's not as expensive as you think
Okay, if you have money, buy a blade center, SAN, NAS


= Deployment: get it out there for real

Going alone? That's ok. Here's a rough guide

Web/proxy + static (2): mginx, thin, rack
App layer (4): Mongrel, Glassfish, Swiftiply
Data stores (2): MySQL, SDB, PostgreSQL

Got cash? Make it someone else's problem.


= Rails: can be monkey patched

Don't be afraid to improve it
But follow edge if you do

== ActiveRecord:
- Take only what you need: :select, :limit, :offset
	- People often do the restrictions in Ruby - that's a bad idea!
- Eagerly associate with :include => :association
- @var ||= Model.find(..)
	- If var is nil, it will load the Model
- Don't forget constants and class variables

== Views & Controllers

- Use HTML helpers sparingly (url_for, etc.)
	- They are all expensive
- Consider template optimization
	- Generates Ruby byte code of the templates
- Know how your rendering engine works
	- Erubis instead of erb
	
== Meta programming monkey patching

Try not to override to_s, stuff like that