Building Scalable Web Apps - LVL.UP KL
-
Upload
gareth-davies -
Category
Internet
-
view
5.290 -
download
0
description
Transcript of Building Scalable Web Apps - LVL.UP KL
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 ScalingScaling up (Vertical)
Scaling out (Horizontal)
Scaling up vs Scaling upScaling 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