What does scalability mean to you?

Question

I posted a similar question on how scalable linq is. There were so many different views on what scalability actually meant in some recent conversations, so it has sparked me to ask this question as well. What does scalability mean to you?

Answer 1

I answered that question as if you meant fast, but that's because I didn't want to be a jerk :) -- meaning, I didn't want to start a discussion about what scalable means. I think of scalable as: adding resources to the system increases its performance.

In that sense, PLINQ is scalable, because adding more cores will make it run faster.

Answer 2

Just to add to @Lou Franco's post.

PLINQ even has freakish "Super Linear" Performance in some scenarios with limited overhead (according to some of their demos). Try it out.

If you are a C++ guy, Microsoft is also looking to release concurrency features that apparently have no runtime cost associated with them and additional task based concurrency tools to help you call better.

Answer 3

Scalability means the ability to handle growth in either of these 2 areas:

1) Ease of adding new features, fixing bugs. To make the code do these new things how hard is it to do? While this may be maintainability in some ways, it is also the question of whether you can build the code to handle a bigger scale easily.

2) Ability to handle greater and greater load which may be multiple requests simultaneously in Web Development or larger datasets for a simple Database-driven website, e.g. could you make an application that handles tables with hundreds of thousands of rows that is still viewed as "quick"?

Generally for me scalability means the ability to grow.

Answer 4

Scalability - The ability of a system to use additional resources to achieve increased capacity or throughput. Additional resources such as drives, memory, network cards, processors, or machines.

I don't directly associate scalability with feature growth, although adding features to a system at its scale limit may not be possible.

Answer 5

I look at scalability from two perspectives:

Scaling Up

If I add more RAM to the box that something is running on, how much additional performance and capacity do I gain? If one application I have can handle 300 more connections and runs 15% faster when I add 2 GB of RAM to my server and another application can only handle 100 more connections and runs 5% faster, application A is clearly more scalable.

Scaling Out

Now, if I add more boxes to my set up, how much additional performance and capacity do I gain? Can I set up web front ends to handle more client traffic? If so, is there a linear increase? If I add 3 boxes, can I get 3x more users accessing my site? Can I add more databases to distribute the data load? Can I scale up multithreading? If I can easily add a machine to my network to add capacity to my application, then it is scalable.

This, by the way, is one of the primary drives of n-tier.

Answer 6

These days and specially for webapps, but in some cases also for enterprise apps, the horizontal scalability is what you want to have,

Can I handle more (traffic, data, processing) by adding more commodity hardware ? even using "cloud servers" amazon ec2, google app engine and similar ?

Answer 7

Scalable means I can cram n resources into a system and it will grow in both space and time between O(log(n)) and O(n log n). That's somewhat unrealistic, but that's how I think of "scalable".

Answer 8

I don't think scalability makes an iota of sense without context.

When I'm asked about the scalability of a system, the first thing I need to know is the ways in which its utilization is expected to grow. Will it be getting more users? Will the existing users be making heavier use of it? Will its feature set be growing? Will the mix of transactions that it's presently supporting change? Will the user experience need to change?

(OK, so the answer to all of those questions is usually "Yes"; then prepend the word "How" to those questions.)

To pick a not entirely fictitious example: a system currently supporting very few users, and whose user base is expected to grow rapidly, has a serious scaling problem if the DBA has to spend two hours manually running queries from information picked out of email messages every time he has to set up a new account. That's not a problem that can be fixed by adding more resources, unless you're including DBAs in the list of resources you're going to add (and there are a lot of reasons that's not going to scale well).

Or imagine a social-networking site that rolls out the exciting new feature that you can see if your friends are online and chat with them through a nice Ajax-y UI. Suddenly, with no increase in the user base, the number of HTTP requests your servers are handling per day jumps twenty-fold, and your worries about the scalability of your database recede into the background. (Unless, of course, you've involved the database in your chat application. Good thinking!)

Sure, making your web apps stateless so that you can add web servers, making web pages idempotent so that you can add proxies, designing your application so that you can partition your database across servers, those are all going to make your application scalable in various dimensions. It's very much worth thinking about that stuff. But it's much more important to figure out what your real enemy is before you start fighting.

Answer 9

Woh!, big word....

I define it a-new every project, because it depends on what the client wants.

Scalability isn't always about adding processing/storage capacity, but can include the support of many inputs and many outputs as well.

Answer 10

I think of scalability as a measure of the smoothness of the cost-performance curve.

That is, if you can spend a little on computing resources and get a low performance system, and gradually adding resources you can get a proportionally better system, it's scalable. If you have to add resources in expensive chunks, to get less than linear improvements, it's not scalable.