Web Performance Matters

The first post in this series discussed Moore's Law and Wirth's Law. It reviewed how, at an industry level, ever faster processors have been neutralized by ever-growing software. Here I discuss how to manage the balance between hardware and software at the enterprise or application level with a systematic approach to performance tuning.

Performance is all about supply and demand. Performance problems are the visible evidence of a mismatch between hardware supply and software demand -- between the amount of work the software wants to do and the hardware computing resources (processor, memory, storage, or network capacity) available to handle that work. Such mismatches can be caused by resource utilization or contention:

Utilization: Some programs -- weather simulations for example -- do need massive processing resources. If such a program takes too long, that's a resource utilization issue.

Contention: Most shared business applications, including those available over the Web, don't consume massive amounts of any computing resource. So when you or I experience slowdowns it's not because of our resource utilization, it's because of resource contention -- competition -- coming from other users who are sharing the same computing resources. Just as in everyday situations like waiting in the checkout line in the supermarket or driving to work during the rush hour, contention for a common resource introduces delays.

Performance engineering or capacity planning?

So whose job it is to fix mismatches between the computing workload and the computing resources? To answer that we have to dig a little deeper. Why are we experiencing this problem? Is it because:

• we allocated the resources to the workload inefficiently?
• there is too just much work, or -- viewed another way -- there are insufficient resources to handle the work?

Performance specialists make their living solving the first class of problem, looking for more efficient ways to get the same amount of work done. As long as there is some spare capacity in some computing resource somewhere, we can usually find a way to re-align the workload to better match the available resources. This is the practice of performance engineering or performance management.

When there are insufficient computing resources to handle the workload, people’s view of the problem ("too much work", or "not enough computing resources") tends to be a subjective one, depending on where they sit in the organization. Either way, the actions required to improve performance are likely to be painful for someone. To avoid this trauma, organizations whose business depends on having sufficient computing capacity spend a lot of time and money on capacity planning -- tracking evolving workloads, and planning hardware acquisitions to match.

In an ideal world, these two disciplines cooperate seamlessly to eliminate all performance problems before any customer experiences them. In the real world, however, problems arise and must be fixed -- either by controlling the resource demands, or by increasing the supply.

Getting the most out of existing systems

In theory there is a straightforward solution to all resource constraints: buy more. But this brute-force approach is an inefficient and expensive way to solve performance problems. Often it's not even feasible, either because the people tuning the software don't control the hardware execution environment, or because they don't control the hardware budget.

So in performance management, as in other walks of life, we generally look for ways to eke out our existing resources before spending money. When pressured, we look carefully at our use of those resources to see if everything we are doing is really necessary. Similarly, the first rule of performance tuning is to get the most out of the existing hardware and software. Although we might be able to remove some problems by simply upgrading the hardware, that is usually the last resort, after we have exhausted other tuning possibilities.

When teaching these concepts, Nagraj Alur, my former colleague at IBM and DataBase Associates, always recommended following a 5-stage tuning process. In my book, I documented his advice as follows:

Nagraj’s law of tuning choices

1. Do less work: By far the best and fastest way to improve performance is to stop doing work that does not need to be done.
2. Make the best use of what you have: Tune the hardware and software environment (operating system, middleware, database, and so on) to make it match the workload better; tune (and possibly redesign) the applications to cut out any unneeded processing.
3. Steal from Peter to pay Paul: Make tradeoffs between subsets of the overall workload to improve the performance of one at the expense of another.
4. Water down the requirements: Revisit the performance requirements to see whether the business can actually tolerate poorer performance for some application(s). This may be preferable to the final option, which is ...
5. Throw money at the problem: Buy more memory; buy faster disk storage devices or disk controllers, buy fatter, faster network connections, buy a bigger processor or more processors.

-- Guideline 3.14, High-Performance Client/Server, Wiley, 1988.

Much more could be said about each of the first four stages in Nagraj's tuning process, but those discussions will have to be deferred until future posts.

Tuning has its limits

Of course, there is a limit to what can be achieved by tuning, and the law of diminishing returns does apply. After a while, it simply is not cost effective to search for smaller and smaller incremental performance improvements.

But when you finally conclude that you can't squeeze a quart of workload into a pint-sized system, and the only solution is to upgrade, the previous investment in performance tuning will pay off. Because by then you should have a much better idea of where the bottlenecks are, and where to spend your money most effectively -- whether you really need more processing power, more memory, faster disks, or faster network connections.

This post is the second in a new series on fundamental truths about performance.
Tags: performance wisdom, performance tuning, performance, tuning, Nagraj Alur