4 ms·
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.
by jwilliams 18y 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 18y agoFor 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.
- jwilliams 18y agoI'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 18y agoSurely 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.
- jwilliams 18y 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.