management: Why Are You Tuning?

Many sites or technical groups tune simply because they think they need to. A better performing system/application/database is better for everyone, right? However how does this help your business? Does it reduce costs, meet compliance, make customers happier or give a competitive edge? Too often the answer is 'no', or 'maybe. ' Too often tuning dollars are wasted.

What Is Tuning, Really?

It sounds obvious doesn't it? Tuning is making things run faster. Except that it's not. Tuning is the entire process of making things run better. There are two things here to think about.

The Entire Process

Tuning isn't just changing a program, or system parameter, or database structure. It's the whole process:

1. Measure - measure current performance
2. Evaluate - Determine if this is sufficient
3. Change - Find and fix problem areas if it isn't
4. Re-measure - measure current performance again

And it doesn't stop - ever. Point 4 above is the start of the whole cycle again. Tuning is a constant circle of measurement, evaluation, and sometimes (and only sometimes) making changes for improvement. And it's long term.

Tuning doesn't stop when things are working fine. The best tuning is where performance is regularly measured and monitored, and changes rarely made. In an ideal environment, changes are performed before problems occur. So if an application's response time is measured over a year, trends can be seen. If the response time is seen to be slowly increasing as transaction loads increase, this can be addressed before those times become unacceptable. Tuning vs fire-fighting.

Tuning is the entire long-term, on-going process of making things run better.

Run Better

Tuning isn't just about making things run faster. The most common projects I work on are about reducing the CPU used. Other reasons could be to reduce disk space, tape, or network bandwidth. You may use an API that costs money every time it is called, and want to minimise this cost. Or maybe you may want an application to affect other applications less. For example, use less memory so another application can get more. There are hundreds of possible reasons to tune.

Tuning is the entire process of making things run better, not necessarily faster.

This doesn't mean that tuning is the only work done to improve performance. Your applications staff will be developing new applications with performance in mind. Hopefully, your development process concludes with a complete tuning cycle (measure, evaluate, change and re-measure) in a test environment under load.

Similarly, your DBAs will be designing databases for performance, and your systems programmers will be thinking about performance when installing new software or configuring systems. Everyone wants to improve performance. However often these tasks are done in isolation, without set targets. Tuning is the process of making existing things run better.

Getting Value From Tuning

I remember one site with a team tasked with reducing CPU usage across the board. Targets were set, and bonuses paid when they were met. The problem was that most of the CPU savings gained didn't benefit the organisation. They didn't make customers happier, give any advantage, or satisfy any compliance requirement. In fact the team's purpose was to reduce CPU usage so an upgrade to a larger processor would not be needed; a larger processor costing a lot of money to buy and run. And this was the problem. They needed to reduce the peak CPU usage: only a few hours every month during month-end processing. However the application team were reducing CPU usage at any time they could find.

So before even starting a measurement phase, the reason for tuning must be settled: the mission. This is Project Management 101. So let's work through an example.

Imagine we want to tune to reduce our running costs. Great, but what are those costs? In my field these are usually software licensing, staff, hardware and environmentals. So which one do we go after first? Software licensing is usually the largest by far, so let's start there.

But don't start reaching for your measuring gear. There are many ways to reduce software licensing costs. A review of the software portfolio is an excellent place to start - check that all software is still needed, used, and not duplicated. In my area of mainframes, this is particularly relevant as software has often been installed for decades. Let's also check your software licenses - there may be ways to improve your licensing or configuration to reduce costs.

OK, so let's take another look at that software licensing and see how it is affected by CPU. It can be determined by the size of the processor, the number of systems where it is used, or possibly even how it is used. Let's also look at your systems and see if there any ways of reducing this CPU cost.

OK, now we can start measuring. In my field software licensing is often tied to the highest CPU usage in a four-hour period in each month. So we need to measure to find this peak, then measure again to find the big users in this peak, and start targeting. And for each target, the same measure, evaluate, change, and re-measure cycle starts.

And this goes on. Once changes are made to reduce CPU usage, CPU usage is re-measured. Sometimes changes don't give us what we want, and sometimes our environment changes. A system change can affect things, or maybe our peak four-hour period moves. So after a first round, we measure again, determine the peak period, look for candidates and work from there.

So tuning isn't simply the measure, evaluate, change and re-measure cycle. It's also evaluating what to tune, and what is needed from tuning. Tuning is the considered, planned, targeted process of making thing run better.

When Is It Bad, and When Is It Better?

Another common reason I see for tuning is response time: the time between a user hitting the Enter key, and the screen coming back. Sometimes batch elapsed time is also an issue. However the goal “reduce response time” isn't enough. If response time or batch elapsed time is an issue, specific targets are needed: Service Level Agreements (SLAs). For example: "90% of transactions completed within 1 second", or "batch schedule completed by 6am."

Without such specific targets, it isn't possible to properly tune. If response times are sufficient, you're wasting time tuning. If they aren't, you don't know how much you need to improve. In fact, excessive tuning can make things worse: impacting other areas or applications, increasing costs, and impacting availability by change. Smart managers only change things when they need to be changed.

Tuning is the process of determining why things must be better, and making them so.

Summary

Tuning is an essential part of computing: ensuring that computer resources do what they need to do for the business. However tuning isn't quick, isn't knee-jerk, isn't fast change. Tuning is careful, considered, and long-term. Tuning is evolution: not revolution, not crisis management.

Tuning is the entire long-term process of making things run better.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.