Copyright © Meebo, Inc. All rights reserved presents... Scaling Synchronous Web Apps Web 2.0 Expo, New York 9/18/2008

Copyright © 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 © 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 © 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 © 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 © 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? memory CPU bandwidth storage disk i/o …

Copyright © 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 © 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 © 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 © 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 © 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 © 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 © 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 © 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 © 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 © Meebo, Inc. All rights reserved thank you (psst, i can’t help it but... we *are* hiring...)