In the beginning there is an idea, a goal, a mandate, or a proposal that leads to a performance question.
If you can answer that question though simple performance measurement or capacity planning, then do it and be done.
If this is a new application (and thus no metering is possible), or your computing world is changing radically, then you may need to build a model.
Some ideas take very little modeling to shoot down…
The first step to doing that is to really understand the question. Start with what they give you, and then ask very picky questions to clarify:
Boss: Will this plan to consolidate systems work?
You: At our seasonal peak load?
Boss: At the seasonal peak.
You: How much should I add to last year’s peak to scale for this years peak?
Boss: Plan on adding 10%.
You: How sure are you of that number?
Boss: Pretty sure, plus or minus 10%.
You: So I should plan for 11% (10% + (10% * 10%)?
Boss: No. To be safe, plan for last year’s peak plus 20%.
You: Is there any money available new hardware?
Boss: Not a penny.
Ask all the key players for clarification and additional information in both positive and a negative ways: “What do you want? What must we avoid?” Keep at it until you really understand the critical success factors such as:
- What success looks like in terms of throughput and response time
- Constraints on budget and time that will limit your options for achieving the goals
- Legal and availability concerns that will limit the configuration options
- What is politically and bureaucratically possible
To be clear, this is not a license to waste people’s time by acting like a three year old asking “Why?” over and over and over. Keep your goal in mind, which is a clearly defined question to answer.
Brainstorm, Refine and Choose
To build a model to find an answer to a question you first have to guess the answer; then you can build a model to see if it is really the answer. To guess the answer, you first brainstorm a list of possible answers and then thin that list down to the best candidates.
Create a List Of Possible Solutions
Start with that question, and your knowledge of your computing world, and come up with a couple of workable solutions. This is the intuitive, creative part of modeling, and it is very much like writing a hit song. There is no step-by-step procedure that will always end up with a great song. However, there are guidelines that will improve your odds of creating a workable solution to your question:
- At first, don’t be judgmental. Any idea that, in any way, answers any part of the question is a good one at this point.
- As you are brainstorming, be sure to write things down. The saddest thing is to watch someone struggle to remember, like you do with a fading dream, the key insight that made an idea work.
- Now sift the ideas you have based on key limits and demands of your question. For example, if there is no money for new hardware, then set those ideas requiring new hardware aside, but do not discard them. You may need these ideas later.
- If you have an abundance of ideas that may answer the question, then sort them based on simplicity, risk, and total cost, and take the top three.
- If you have no ideas left that may answer the question, then you should ask the people in charge for guidance as to what in the question can be loosened, ignored, or worked around.
- If you are stuck, go back to those failed ideas you set aside earlier. See if any of them will work for you now.
Refine The Solutions
You should now have a few possible solutions that might work. Before you go through the work to build models, refine your list of solutions by using a bit of simple capacity planning.
To answer the whole question you might need a model, but to figure out that a proposed solution doesn’t work can sometimes be seen with simple capacity planning of some small part of the whole question. That sad news might get you to abandon the idea altogether, or it might lead to a modification of the original idea to make it better. Use simple, rapid tools to find problems in your plan before wasting more time modeling a solution that can never work. Let’s look at an example.
We are planning to add the workload generated by the new XYZ transaction to a key system. There is no test data yet, but reasonable people agree that, due to its complexity, the XYZ transaction should take 2.5 times the CPU resources of the current BBQ transaction on that key system.
The BBQ transaction consumes 20ms of CPU per transaction, so the XYZ transaction will most likely use (2.5 * 20ms)= 50ms of CPU. At peak load you are planning for 100 BBQ TX/sec and estimating that there will be 20 XYZ TX/sec. On this key system, just these two transactions will use three seconds per second of CPU as you can see below.
If that machine is a two CPU machine, then this idea is dead in the water.
Seek Out Missing Information
There will come a point where you know most of what you need to know but are missing a key bit of information on throughput, service time, utilization, etc. Here are a few key performance laws that will help you find the missing piece.
Little’s Law: Mean#InSystem = MeanResponseTime * MeanThroughput (Example)
Utilization Law: MeanUtilization = ServiceTime * MeanThroughput (Example)
Service Demand Law: ServiceTime = MeanUtilization / MeanThroughput
These equations can always be rearranged mathematically (e.g. if A=B*C then B=A/C and C = A/B) to find the thing you are missing.
Double Check Your Work
As you are exploring these solutions, be sure to keep looking for a number that rubs you the wrong way or an assertion you can’t stop thinking is wrong. Keep asking yourself questions like these.
- Will this work at peak load?
- Can that number really be that low?
- Am I using the right metering data?
- Did I mess up the units in this calculation?
A Note To Beginners
If this is your first time doing this, you are starting from scratch. Don’t make the mistake of doing that again next year. Save your report, your notes, and any tools you created to help you write this report. Next time, you’ll have a good base to start with and build on. This will save you time and make sure you don’t forget things. As the time between peaks goes by, you’ll usually find new things to add to the model. Write them down, build them into your performance tools, and file them with all your other modeling data so you don’t forget them when you plan the next peak.
“You’ll do this again. Always take time to make things easier
for your future self.” – Bob’s Tenth Rule of Performance Work
For more info on performance modeling see: The Every Computer Performance Book on Amazon and iTunes.
The Every Computer Performance Blog 