Building Scalable Web Apps
 http://www.shaolintiger.com
 @ShaolinTiger on Twitter

So who am I? Mindvalley CTO etc.
- Also Sys Admin
- DevOps Guy
- Technical Architect

Pulse Check
- Familiar with at least 1 of these technologies?
- Setup/used one of these technologies?
- Could debate the pros of nginx over Apache?

This Talk
- Intro to scaling
- 5 Points to consider
- 5 Things you can do

Scalability vs Performance
- Scalability can bring performance, but not vice-versa
“Performance measures the speed with
which a single request can be
executed, while scalability measures
the ability of a request to maintain its
performance under increasing load.” –
Steven Haines

Understand Scaling
Scaling up (Vertical)
Scaling out (Horizontal)

Scaling up vs Scaling up
Scaling up
- Can become very costly
- Single point of failure (SPOF)
- Less complex to manage
- Has a Finite limit
Scaling out
- Cheaper now with cloud/vms/commodity h/w
- Increases availability
- Management can become very complex
- Deployment can become slow

Points to consider 1) Logging
- Logging can get OUT OF CONTROL
- Use a centralized log management system
- Check out Loggly or Papertrail (we use this)

Points to consider 2) User Sessions
- Centralize your user sessions
- Use a fast in memory store
- Remember to invalidate/clear cache
- Check out Redis (or just use Memcache if you
already have it as part of your architecture)

Points to consider 3) Monitoring
- Monitor EVERYTHING
- Make data driven decisions
- Check out Munin (my favourite)

Points to consider 4) Bottlenecks
- Usually the database/datastore
- Can also possibly be the filesystem (caused by
logging, heavy static file delivery etc)
- Also possible to saturate network bandwidth

Points to consider 5) Traffic Profile
- Spiky traffic is a lot harder to deal with than
linear growth (you have to build differently)
- Even tools that ‘autoscale’ take time

Things you can do 1) CACHE!
- You should really by trying to cache everything
you can:
- - Objects
- - User Sessions
- - API Requests
- - Page Cache
- - Partials Caching (In Rails)

Things you can do 2) Understand
- Know your tools/stack (or hire someone who does)
- AKA MySQL query_cache? What’s that?
- Optimize but don’t overdo it (and not too early)
- Build for scale, but don’t get complex without reason

Things you can do 3) Use Queues
- There are great tools out there for this (RabbitMQ etc)
- Makes it much less necessary to scale your database
- Takes the burden of spiky loads without downtime

Things you can do 4) Ditch Search
- This is what happens when you do a full text
search on a database not designed for it.
- Use a specialised data store for search:
- Solr
- Lucene
- Elasticsearch

Things you can do 5) Leverage
- Use a CDN (Like OnApp, CloudFront, Edgecast etc)
- If you can use a specialist host (WPengine/Page.ly)
- Utilise a specialist DNS host (Route 53/UltraDNS)
- Profile your app with NewRelic

The END!
No Questions!
Stalk me @ShaolinTiger
This preso will be on http://slideshare.net/shaolintiger