If your system is more of an OLTP system or more batch-centric, you have some creative choices to maximize your user's experience. For an OLTP system, users want snappy response time. They really don't care about how much work the system is processing, but just want the system to be responsive to their requests. On the other hand, if the focus is on batch processing, responsiveness takes a backseat to throughput. For example, if there are 12 CPU cores along with a long batch process queue, having a CPU idle is something we don't want to see. Let's take this a step further.

We know that the lower the CPU busyness, the shorter the CPU queue. For a snappy OLTP system, we do not want processes waiting in the queue. We want the OLTP-related processes to be serviced immediately! The way to increase the likelihood of this occurring is to keep the CPU busyness relatively low. This means if you have an OLTP-centric system and desire snappy response time, you must keep the CPU subsystem at a low enough utilization to ensure OLTP processes are not queuing. For example, if a system is a mix of OLTP and batch processing, which most systems are, then during key OLTP processing times, you will want to throttle back batch processing to ensure the CPU run queue is not impacting OLTP processing responsiveness.

If the system is batch-centric or batch processing is the priority, the situation becomes very different. For systems focused on batch processing, service levels are not measured by response time. The key service level for batch systems is throughput; that is, response time is not based on a single batch job, but on a group of batch jobs. Put another way, throughput is important, not response time. Idle resources are death to throughput. For a batch-focused system, every bit of CPU power needs to be consumed.