With an increase in performance (decrease in response time), users may perform work more rapidly, increasing the workload. The more time users are sitting and waiting for the application to return control to them, the more of a workload increase we can expect to see. It is possible a significant increase in the workload could offset the gain in response time. But either way, the users win. If they don't increase the workload, online performance increases. If they do significantly increase the workload, they will get more work done!

When making a statement like this, someone is likely to ask how much more throughput can be expected. That's when it's time to once again show the response-time graph in Figure 9-25, which illustrates the current situation in a pure logical IO (CPU) perspective. If the service time does not decrease (this is detailed in the second analysis cycle), then it appears we can nearly double the workload before response time significantly increases. Unless you have a way to control the user workload or understand the application very well, there may be no way of knowing if the users can or will increase the workload. But regardless, you have graphically and with simplified numbers demonstrated the performance impact of increasing the buffer cache.

As described in the previous section, an Oracle buffer cache increase was chosen as the first performance-enhancing change. We are anticipating around a 30% decrease in total Oracle response time, and for users who run multiple serial queries at a single touch to feel around a 50% decrease in response time. We are not sure if users will be able to take advantage of faster response time and get more work done, but it won't surprise us if they can.