Preparing for... inclement

weather

Martin Buhr

@martinbuhr

http://loadzen.com

WHO HERE HAS LOAD

TESTED THEIR APP?

So...

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 GENERATES

TRAFFIC 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 and

get 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 line

And best of all:

• You become a better developer

Learnt that the hard way...

That got me thinking...

Can I build my own?

And that became Loadzen (let’s take a look...)

Yes I can...

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)