Did you notice the initial drop (not increase) in the response time? This occurs in Oracle systems because cache efficiencies (Oracle and the operating system) increase as the workload begins to increase. For IO subsystems, I have seen response-time curves (based on real data) that look like a smiling face because of the significant cache efficiency effect. This is what we want to see! Eventually, however, as the workload increases, some component in the system will reach its capacity limit (in Figure 9-10, it was the CPU subsystem and concurrency issues), and the classic response-time curve elbow will appear.

Now that I've detailed how to collect data and plot the actual response-time graph, it's time to move on to creating a response-time graph that is more general and suitable for anticipating the impact of a solution.

This is where the real fun-and also the real risk-begins. The moment you draw a picture of your system, all eyes will be focused on you. Your objective is to convey the situation as simply as possible, without misleading anyone. Simplicity and abstraction are your friends. The moment you attempt to be precise or get heavily into the mathematics, you're doomed. This book is not about predictive performance analysis, and this is not our focus here either. Our goals are to convey the situation and anticipate the general effect of our proposed solutions. Providing more information promotes better decisions about which solutions to implement and in what order.