19. #1: simpler is better
Don’t try to solve a scaling problem you don’t have (yet)
Build it as quickly and as inexpensively as possible
You want to save time to iterate upon other ideas in case
this one doesn’t work
Setting yourself up for success – easier to optimize
something you understand
25. #2: know your bottlenecks
your type of app determines the type of scaling
don’t prematurely optimize
know system at different levels: oprofile,
valgrind, gdb
know your bottlenecks: memory, cpu, bandwidth,
storage, disk i/o
confidential
36. #3: quick fix or homerun
users just want it to work (now)
use the time the quick fix affords you wisely
aim for small or big, avoid the middle
fix the root issue
40. ui
meebo
dlg
IMDlg BuddyListDlg
button menu
EventMgr NetworkMgr
element
ajax util.js
41. Firefox
iPhone
iPhone
meeboApp meeboApp
PubSub
ui
meebo dlg
Buddy BuddyList Account button menu
EventMgr NetworkMgr element
ajax util
42. #4: useful abstractions
keep it simple, flexible, so you can adapt quickly
to changes and scale with needs
abstractions allow you to reuse existing
components to scale to new challenges
it’s hard to know where the useful abstractions
are when you start a project
44. today
3 years old
45 people (2 dogs)
35 million uniques per month
350 years worth of usage per day
200 million messages per day
54,000 kiss emoticons each day :-*
2.5 hour session length
