1 / 16

Scaling Synchronous Web Apps: Lessons Learned

Learn from the experiences of scaling synchronous web apps and discover what works and what doesn't. Understand the challenges of synchronous versus asynchronous development and explore strategies for scaling your app effectively. Find out about memory, CPU, bandwidth, storage, and disk considerations, and learn about tools like long polling, web servers, databases, and load balancers. Gain insights into simplicity, efficiency, and the delicate balance between front-end and back-end development. Get practical tips for contingency planning and monitoring your app's health.

jmarco
Download Presentation

Scaling Synchronous Web Apps: Lessons Learned

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. presents...Scaling Synchronous Web AppsWeb 2.0 Expo, New York9/18/2008

  2. 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 :)

  3. 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...

  4. 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

  5. what is synchronous? what part of your app is synchronous? what can you get away with NOT being synchronous?

  6. 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 …

  7. peg helpers these shouldn’t be a surprise long polling (COMET) web servers compiled vs. interpreted databases memcache load balancers

  8. do i really need this? 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?

  9. 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

  10. 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 ;)

  11. 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

  12. 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

  13. 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?

  14. 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?”

  15. 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!

  16. thank you(psst, i can’t help it but... we *are* hiring...)http://jobs.meebo.com

More Related