7 Stages of Scaling Web Applications

http://www.slideshare.net/davemitz/7-stages-of-scaling-web-applications?type=powerpoint

by vp • 18 years ago

49 14 18 years ago

jwilliams3• 18 years ago

Great post! It points out up front that performance != scale.

The other scaling point is concurrency. You can't (for example) serially add features to a page. Eventually that page will simply take too long to render.

A lot of "dashboard" pages suffer from this problem. If you reach that stage you need to start thinking about decoupling features - using things like messaging.

Retric• 18 years ago

For most companies performance might as well scale. For example Slashdot uses 4 machines. Now if you are serving up a lot of media that changes things but a single web server can handle a lot of traffic if your app is reasonable.

PS: This is a presentation by Rackspace of course they are going to say write bad software and buy lot's of hardware.

jwilliams3• 18 years ago

I'll admit that depending on your situation you may be more concerned with performance over scalability - but doesn't make them the same thing.

Scale is getting higher throughput by adding resources - Performance is getting higher throughput using the resources you already have.

habs• 18 years ago

Surely concurrency has more to do with performance than scaling?

Scaling is more about a product's ability to easily grow and handle an increasing amounts of work, rather than it's ability to render/dish out pages.

jwilliams3• 18 years ago

> Surely concurrency has more to do with performance than scaling?

What I meant to say was concurrency is a way of distributing load and getting scalability.... But, yeah, you're right - my example was terrible/inaccurate.

tdavis• 18 years ago

The only change I would make to the "stages" is to add caching up front. Most modern web frameworks make the use of caching pretty trivial therefor making it less of a pain than setting up load balancers and multiple web servers, etc. Static content should also make use of caching headers and be served by a separate server than dynamic content; this is also a trivial improvement.

Having only a single web server, database server, and static content server while making liberal use of caching and smart querying result in benchmarks indicating we can sustain around 1900 req/sec. Even if that isn't entirely accurate, the chances of us reaching the 82 million page views per month to find out is all but inconceivable.

litewulf3• 18 years ago

Caching is hard though, and its best to use profiling to decide what to cache. Especially if you have any sort of user-specific content, you need to resort to fragment caching which is sometimes tricky.

alecco4• 18 years ago

1900 req/sec What kind of requests?

Typically dynamic content usually is well below 300 req/s per core and goes down fast on many factors (e.g. non-local database.) Most web frameworks are usually below the 300 req/s mark. Of course it is a very complex subject as there are many things to consider. Good cache management, CDN, SSI, and reverse cache come to mind.

About databases, it can become a problem if you do writes on the same database as locking starts to show its dangerous tentacles.

alecco4• 18 years ago

I agree on many points like performance and scalability are not the same but his traditional approach to just make a bigger clustered database is not good. It's like fixing the bottleneck by making a gigantic bottle, it'll work but the cost will be many times over what was really necessary.

If a any single component is a critical bottleneck the best is to either replace it or redesign to stop requiring it.

Same goes for the more memory approach.

litewulf3• 18 years ago

The day your website starts generating more traffic than one server can handle you need to do something very quickly to make sure it all stays up.

So I think its often reasonable to pay the exorbitant prices as a stopgap before you can start doing any of the more complex scalability re-architecturing.

alecco4• 18 years ago

That's a very addictive and self-validating reasoning path. Beware.

ken• 18 years ago

There's something weird about reading an August 2008 presentation that says "Source Control: RCS, CVS, Subversion" -- right between slides mentioning "64-bit" and "cloud computing".

I haven't used CVS in at least 5 years, and I've never even seen RCS in use. Part of me wonders if RCS is Rackspace's secret weapon.

7 Stages of Scaling Web Applications

Related Stories