When focused on online user response time, a snappy response is desired. To increase the likelihood of snappy response time, we want the likelihood of queuing to be very low. We encourage this by ensuring a low utilization by keeping the arrival rate low enough to prohibit the system from operating in the elbow of the curve. While this produces snappy online response time, it also leaves available computing resources on the table. With a batch process focus, we want to use those leftover and available computing resources. In fact, to leave any available resource unused can be considered wasteful, shows parallelism is limited, and could result in a longer elapsed time. So, with batch processing, we look for ways to use any and all computing resources available to minimize elapsed time. This means the system will be operating in the elbow of the curve.

From a CPU perspective, this means the average run queue will always be equal to or greater than the number of CPU cores. But there is a limit to our aggressive resource usage. If we allow the system to push too far into the elbow, the overhead associated with managing the system increases to the point where the elapsed time begins to degrade. Our job as performance analysts is to find the sweet spot and operate the batch processing there!

This chapter is truly about performance analysis. Some would say it is enough to find a problem and make some changes. I respectfully disagree. I believe we can do so much more, be so much more effective, and add greater value to our organization. Nearly any Oracle analysis will result in a number of recommendations. But in order to responsibly decide which changes to implement first, some ranking must occur. This chapter focused on bringing rational debate and consensus to ranking the performance-enhancing solutions. I hope you have found it enlightening and practical.