presents... scaling synchronous web apps web 2.0 expo, new york 9/18/2008
DESCRIPTION
presents... Scaling Synchronous Web Apps Web 2.0 Expo, New York 9/18/2008. lessons learned. things to keep in mind... what works for someone else doesn’t always work for you you know the most about your stuff don’t get married to a technology but don’t be a total flirt - PowerPoint PPT PresentationTRANSCRIPT
Copyright © 2007-2008 Meebo, Inc. All rights reserved
presents...
Scaling Synchronous Web Apps
Web 2.0 Expo, New York9/18/2008
Copyright © 2007-2008 Meebo, Inc. All rights reserved
lessons learned
things to keep in mind...
what works for someone else doesn’t always work for you
you know the most about your stuff
don’t get married to a technology but don’t be a total flirt
remember this is supposed to be fun :)
Copyright © 2007-2008 Meebo, Inc. All rights reserved
why’s it hard?
synchronous versus asynchronous...
traditionally, “asynchronous” implies “more complex”
on the web, it’s the opposite, browsers are built for asynchronous
building synchronous web apps is like shoving a square peg in a round hole...
Copyright © 2007-2008 Meebo, Inc. All rights reserved
it won’t fit
the “hole”- multi-platform (lots o’ browsers)- spotty network connections- only 2 simultaneous open HTTP requests allowed
(for now anyway)- page views- static content- no downloads
the “peg”- instantaneous data transfer- long polling- making the browser do work- seamless user experience
Copyright © 2007-2008 Meebo, Inc. All rights reserved
what is synchronous?
what part of your app is synchronous?
what can you get away with NOT being synchronous?
Copyright © 2007-2008 Meebo, Inc. All rights reserved
i heart server
find the right holes for your pegs
don’t underestimate the server side architecture!
the type of app determines the type of synchronous scaling…
where are your bottlenecks?
memoryCPU
bandwidthstoragedisk i/o
…
Copyright © 2007-2008 Meebo, Inc. All rights reserved
peg helpers
these shouldn’t be a surprise
long polling (COMET)
web servers
compiled vs. interpreted
databases
memcache
load balancers
Copyright © 2007-2008 Meebo, Inc. All rights reserved
simple is usually better(unless you can dish out a lot of $$$)
first ask: what am i using it for?
am i using memcache because that’s what everyone else does? is my data cacheable?
what am i gaining (or losing)?
can i use DNS round robin instead of load balancers?
FastCGI vs web modules vs PHP
do i need to save state? is it persistent?
do i really need this?
Copyright © 2007-2008 Meebo, Inc. All rights reserved
tug of war
front-end versus back-end
always a delicate balance between what you can push to the browser and what you can let the server handle
where does the workload make sense?
browser can be SLOW (just because you CAN do it in JavaScript, doesn’t mean you should)
efficiency with data transfer
Copyright © 2007-2008 Meebo, Inc. All rights reserved
good enough versus perfect
perfection is enough simplicity in the system to allow for adaptation
“perfection” can mean a lot of different things...
users don’t care how clever you are, they just want their product to work
long polling isn’t perfect, browsers have quirks up the wazoo, things will never be “done”
sometimes “perfect” is NOT good enough (look at Ruby =p)
release enough and things will asymptotically approach perfection ;)
Copyright © 2007-2008 Meebo, Inc. All rights reserved
think ahead but not too much
don’t over-design for the unknown
over-designed code can be worse than hacky code
difficult to roll back an entire design
build horizontally
can you throw more servers at the problem initially?
adding servers is expensive but has a shorter lead time, architecture takes longer but is “free”
you won’t know where your bottlenecks are until you let it loose
Copyright © 2007-2008 Meebo, Inc. All rights reserved
nothing simulates real life
you’re not the end user
contingency plans are key
have a few tricks up your sleeve
you’ll always miss something, but that’s okay
don’t build flood gates, build dams:- be able to enable/disable components or change operating parameters during runtime- this includes front-end and back-end
your users will behave in ways you never imagined
Copyright © 2007-2008 Meebo, Inc. All rights reserved
use your own product
don’t be afraid to find bugs
i said you weren’t your end user, but you still have to be a user
overcome the fear of breaking your own product
keep your finger on the pulse of the community, trust your users
i usually use firefox, but because 70% of meebo’s users use IE, guess what i use to run meebo?
Copyright © 2007-2008 Meebo, Inc. All rights reserved
being big brother
be aware of what is going on
monitor key areas- zabbix, nagios, hyperic, ganglia, etc.- you WILL have to build something custom
don’t go overboard on monitoring, you’re going to learn to ignore your alerts
ignoring what your system (not just the hardware) tells you is extremely dangerous
this is another example of “good enough versus perfect“
monitoring is basically asking: “is your app healthy?”
Copyright © 2007-2008 Meebo, Inc. All rights reserved
final thoughts
there’s no magic solution to scalability
it’s very important that you understand the nooks and crannies of your architecture
be able to correlate effects to any system changes you make
always keep the goal in mind, don’t lose sight of it (what are you scaling?)
everyone scales differently!
Copyright © 2007-2008 Meebo, Inc. All rights reserved
thank you
(psst, i can’t help it but... we *are* hiring...)http://jobs.meebo.com