Fundamentals of Capacity Management
(Part II)
Quantifying and tracking demand.
Article 8/98
"The systems administration professional responsible for managing the computer complex must ensure that there is enough capacity to handle anticipated demand on the system." That's all well and good, but where does one start?
This article, the second in the series, will talk about the "demand" that is placed on a computer system, and how to measure it.
We all know what a transaction is, right? Wrong! A "transaction" is usually defined differently for each system, and each application. A transaction means one thing to a systems professional, and usually means something entirely different to the business partner. To a systems professional, a transaction relates to some unit of work on the computer. It typically is a message, a screen of data, or a batch of data. It may be a customer session, with lots of data being retrieved interactively. If we are to relate (as capacity managers) the transaction to the usage of the computer resources, it must be measurable.
But the first rule of tracking demand is to talk to your business partner. Understand thoroughly his/her concept of a transaction, and then relate it to the system's measurable transaction. For example, a gasoline purchase at the pump is typically one business transaction (a credit card purchase), but two system transactions (a pre-authorization, and then a completion). As a systems manager, you must understand the two definitions and be able to relate and explain them.
I'll say it again: The first rule is to talk to your business partner. In many companies, this person is the best source of information about the company's plans. If your system is chugging along fat and happy at 60% busy, and you're unaware that the business partner is about to launch a new advertising campaign or a new product which is expected to double sales within three months, you're going to be in trouble. In these days anything is possible.
After you have a clear idea of where the company is going, your next task is to find out where it has been. You need to create and maintain a history of the system's transaction workload. Every transaction set has its own unique profile, and these rarely follow the traditional straight line or bell curve.
Let me explain. Every transaction set follows cycles over the course of time. Certain times of the day will have heavier traffic than others; certain days of the week will be heavier; certain times of the month will be heavier; and certain seasons or individual days of the year will be heavier. For example: An ATM system will typically show two peaks each week day: one around lunch time, and one around five o'clock. (Side note: A bank I know has its northern California peak at lunchtime and the southern California's peak is always after work. Why? I can speculate, but would probably get myself in trouble.) ATM systems will be quite busy on payday. Mother's Day is always heavy. But the holiday season doesn't pose that large an increase. POS systems are always busiest on weekends. They have a distinct and frequently daunting set of peaks to climb during the holidays. Pharmacy systems worry about cold and flu season. Cash management systems always have their heaviest load after long weekends, especially Thanksgiving.
These peaks must be understood and anticipated. If you are just taking the occasional CPU measurement during the week and it looks fine, I can guarantee that your system probably won't be able to continue processing through a (for example) four-fold increase in your retail credit card volume over Christmas.
I recommend that you capture and compare three numbers each month: 1) The total transactions for the month, and from it calculate the average day's volume for the month; 2) The peak day of the month; and 3) The peak half hour of the month.
Using these numbers, create a small spreadsheet and keep 18 months of history in it. Watch month-to-month and 12-month growth for the average day of the month, the peak day of the month, and the peak half-hour of the month. I think that you'll see that they don't grow in proportion to each other. Business patterns change, and while the total for the month may not grow at all, the peak day or the peak half-hour may grow significantly.
Mergers are a significant factor in today's business climate. You should hope for a merger (if it has to happen) with a company in a different time zone. That way, while your overall volume for the month and the peak day will increase, the volume for the peak half-hour will not grow proportionally, since the clients are in a different time zone.
You also will want to know the system's usage for that peak half-hour. Note CPU use, memory use, cache hit ratio, disk busy for each disk, and the throughput on all of the transaction-related comm lines during that half-hour.
What do you design for? The peak half-hour, of course. In Bill Peach's words, "Designing for the average is like building a bridge for the average height of a sailboat's mast." Guarantees problems. Also from Bill: "And what are your clients paying you for? The performance you deliver during those peak times. You're always measured by your worst performance, not your best." If you design for the anticipated half-hour, based on the observed history and the business partner's projections, you have an excellent chance of getting through your next peak season without getting paged.
| 
