Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st January 2012
Upcoming SlideShare
Loading in...5
×
 

Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st January 2012

on

  • 768 views

Talk by Martin Buhr, Founder of Loadzen.com at Devtank on the 31st of January about the importance of load testing your site as a startup, how http://loadzen.com was built and the lessons learned.

Talk by Martin Buhr, Founder of Loadzen.com at Devtank on the 31st of January about the importance of load testing your site as a startup, how http://loadzen.com was built and the lessons learned.

Statistics

Views

Total Views
768
Views on SlideShare
760
Embed Views
8

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 8

http://loadzen.com 8

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st January 2012 Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st January 2012 Presentation Transcript

  • Preparing for... inclement weather Martin Buhr @martinbuhr http://loadzen.com
  • So...WHO HERE HAS LOADTESTED THEIR APP?
  • For those that haven’t (or don’t know)
  • Many people may tell you...
  • That these are your problem... (etc)
  • And they really can cause trouble...
  • We know, it happened to us: Jive.ly
  • Day 1:Launch
  • Day 2:Sarky email to TechCrunch
  • Day 3:#1 on TechCrunch UK
  • Day 3:#1 on TechCrunch US
  • Day 3:#1 on Digg
  • Shit.
  • So what happened?To Jive.ly:• Traffic exploded• Sign-ups exploded• In-bound links exploded• Rankings shot up• People were buzzing• Free press!
  • So what really happened?
  • We lost users
  • They lost confidence
  • We lost opportunities
  • And it was expensive...
  • :-(
  • But that isn’t the general case
  • You aren’t a C10K site
  • You’re not trying to piss off Anonymous
  • You’re not on TechCrunch (yet)
  • Remember these? (etc)
  • They don’t matter... yet But these guys do...
  • ANYONE THAT GENERATESTRAFFIC THAT YOU DON’T EXPECT BUT REALLY WANT
  • You may ask yourself: Why should I care?
  • Why should I care?• Your database: – Shared SQL server – Unoptimised queries – Unoptimised schemas – Unnecessary requests
  • Why should I care?• Your code: – Nested nested loops – Inefficient iterators – Large in-memory objects – About a million other bad practices and shortcuts
  • Why should I care?• Your interface: – Large images – On the fly processing – Slow JavaScript – Slow web services
  • All of these are exposed andget exponentially worse the higher your traffic
  • For start-ups, inefficient code is expensive
  • For developers, it’s just embarrassing...
  • Which is why we load test :-)
  • Oh yeah...• Your users get your service• You make the most from your opportunities• Users spend more on responsive sites• You improve your bottom lineAnd best of all:• You become a better developer
  • Learnt that the hard way...
  • That got me thinking... Can I build my own?
  • Yes I can...And that became Loadzen (let’s take a look...)
  • What is it?• Load testing in the cloud• Multi-scenario, weighted testing• Real-time results• Chrome plug-in• Pay as you test
  • What’s it built in?• Django (FCGI)• MySQL• Lighttpd• RabbitMQ• Pyro• TornadIO• SocketIO
  • What’s it really built in?
  • Python. Pure and Simple.
  • Look! A diagram!
  • And what did we learn?
  • Log everything• Dynamic RPC is hard• Black box code hurts, open up your systems• When your site breaks (and it will) – you know why
  • Real-time is awesome• Event-based dev changes the way you think• Queues make everything seem scalable• But they introduce their own problems! – Queue -> Socket -> Browser is a killer on your system – Flow control and timing can be issues
  • UI: Make it simple, stupid• If your UI sucks, your code is useless• It’s not someone else’s problem• If it makes your users life easier, it’s worth it.• Always think – can I make it simpler?
  • Always think scale• Don’t build for it, but think about it – Cache your interface – Use a CDN – Make requests quick: think async – Make sure your database is fast – Use the right tool for the job!
  • Pragmatism pays off• Don’t pick tech because it’s hot• Pick it because it solves your problem: – Elegantly – Efficiently• Architect for extensibility – You’ll deal with it sooner or later
  • Measure Everything.
  • Be inquisitive• Talk to your users• Love them (not too much!)• They are the single most important thing to your company, react. – Even if you can’t fix it
  • And lastly...
  • make stuff, be awesome. (that’s our motto, btw)