Overinitiation: When more isn’t better
When we push our full cart to the front of the grocery store, we all want to see a lot of open registers. We feel the same when crossing a toll bridge; it can make your day when you see a lot of empty toll lanes. And, though far more rare, don’t we just grin when the flight attendant closes the door and we have an empty row all to ourselves?
From our perspective, more is better. Except that in each case, if a company always offers more capacity than is needed, they will have to raise prices to afford this largesse. Empty airplane seats and extra staff—any unused capacity—is bad in the business world.
And while a batch job may ‘enjoy’ being initiated as soon as it hits the system, we don’t do capacity planning like that. The goal in every system is to minimize waits for important work while keeping the system running near 100% busy.
No grocery store really wants people abandoning carts because the wait seems endless. Airlines don’t want to bump people any more than they want to fly empty. Our goal as systems managers is like the goal in every other business – to run as close to capacity as possible, without missing service levels. We want our jobs to be ‘happy,’ but not too happy.
The dangers of overinitiation
And yet, even knowledgeable performance experts make the mistake of throwing more resources at work. If 10 buffers are good, 15 would be even better, right? If we have more batch work, throw initiators at it; it will get things moving faster. But it turns out that overinitiation is very similar to putting up more toll collectors on a bridge.
Immediately after the toll is paid, the lanes have to shrink to the number that fits on the bridge. If you have too many toll takers, the merge following the toll gets crazy, accidents can happen and no one is moving fast. When more people wait in the lanes to pay toll, the merge is smoother and the flow across the bridge works better. Getting to the bridge earlier isn’t as good as getting across it faster. But you have to strike a balance.
The same is true with job initiation. Overinitiation doesn’t necessarily translate to better job throughput. For one thing, initiators take up resources, resources that could be better used actually doing work. Next, batch jobs aren’t created equal. Some have heavy demand for I/O, others for CPU and others fly by quickly without much demand on anything.
Ideally, just like the aisles at supermarkets, you want to be able to efficiently manage the load, not having people with one or two items waiting behind the person who is shopping for the ‘long winter.’
The Workload Manager approach
WLM gets it. It starts initiators based on:
- the queue of jobs awaiting execution in WLM-managed classes.
- the performance goals and relative importance of this work.
- the success of meeting these goals.
- the capacity of each system to do more work.
But this doesn’t address the resource demands of each job. If you want true efficiency, resulting in better throughput, you have to look at the entire equation.
The ThruPut Manager approach
ThruPut Manager addresses this aspect, adding value to the management functions that WLM already has in place. Our batch automation solution understands that wait time grows exponentially with utilization; so, when you think you are using the system efficiently (running at 100% CPU busy), you’re actually causing a huge amount of wait. So, it designs job initiation around minimizing wait, not maximizing CPU utilization. Less wait is better.
So next time you start to think that more is better, go through the entire scenario. If you have more of a good thing, will this result in more of something you don’t want, like waiting? Keep the entire picture in mind when solving performance problems. Otherwise, you just move the bottleneck without eliminating it. Look for solutions that understand this complex balance, like ThruPut Manager.