In the not-so-distant past, everything except the users and their terminals resided on the database server. Now, as shown in Figure 5-13, different architectural components are spread out (potentially) in different parts of world. The key to diagnosing a performance problem is understanding where the data flow is being blocked or taking a relatively long time to respond. When both the Oracle client and server processes resided on the database server, the problem nearly always resided on the database server. Now, with the various architectural components dispersed, the problem can be spread all over the world.

Figure 5-13. A simplified Oracle architecture consisting of key timing components: the end user, the user's web browser, Oracle's client process, and the Oracle server process residing on the database server. For a strong diagnosis, we need time consumed for each component and between each component.

Let's inject some time into Figure 5-13. Based on the following numbers, the true end-to-end response time is 50 ms, which is not unrealistic by today's web-based application standards.