Harold Carr attended Alois Reitbauer's session "Why applications do not scale" at Jazoon09, and posted detailed notes in his blog. If you haven't done much work with scaling systems, some of the points Alois made might surprise you. For example:

Scalability does not improve performance

• Increases complexity and degrades performance
• Slower in single user mode
• performance is still an issue

How can this be? Well, to understand this, you have to think about the difference between performance and throughput. Performance is actually a measure of throughput per unit something. Say you have a computer and you have a process that receives some kind of input and produces some kind of output. You could define your performance as being the amount of output data that is produced by that single machine in an hour. So:

Performance = OutputDataBytes per Hour

Now, let's say your application is a success, and more customers want to send you input data and receive your output data products. You're sufficiently successful that your one machine cannot process all the input data requests. What do you need to do? You need to scale your application.

"Easy!" you say. "I'll buy another computer!" Fine, so now you have two computers. But there are some problems:

• how are you going to determine which computer receives which input requests?
• what if you receive only a single giant request? How do you split that single request between your two computers? And if you're able to do this, how do you repackage the output into a single entity to send it back to the requestor?

Well, the answer is: you have to add new software to your application, overhead software that makes these assessments and performs these kind of tasks. Suddenly, your application has grown in size and complexity. So, is a bigger, more complex application, that performs more processing on the same amount of incoming data, going to have better performance or worse performance than a simpler application? Clearly, performance is worse in the bigger, more complex app, right?

And here's where our original definition of performance was incorrect. Performance is really the amount of throughput that a single node produces per unit time:

As soon as you introduce a second node and add overhead software to manage and coordinate the processing performed by each node, your performance drops, because you are doing more work per unit of output data.

So, if performance decreases, then why scale? Because even if your performance is reduced by 10%, your throughput can be increased. Your throughput, in our example, can be defined as the total amount of output data your entire system produces:

Throughtput = Total OutputDataBytes

So, here's the theoretical relationship between performance and throughput for an unscaled application running on one computer and a scaled application running on multiple computers:

Ah, but if only the real world was as simple as this! Because, in fact, as you add successively more machines, your overhead processing that scales your application inevitably begins to bump up against bottlenecks of various kinds. The greater the number of nodes, the lower your performance factor. Take a look at the "Limiting factors" section in Harold's notes.

A more realistic table might look like this:

In the bottom row, you've multiplied your number of machines by a factor of 10, but your throughput has increased only by a factor of 7. The "law of diminishing returns" has kicked in.

It looks like "Why applications do not scale" was a very interesting and enlightening session. You can learn a lot (or be re-reminded of a lot) just by reading Harold's notes. I'm glad he chose to document his Jazoon sessions so thoroughly!