First, let's be crystal clear about what end-to-end response time means. It is what the end user personally experiences. If the end user held a stopwatch and timed, for example, a query, that is end-to-end response time. It's not what Oracle's performance views can possibly show us. It's not what our ORTA shows us (sorry to disappoint you). It's not what an Oracle wait-event analysis shows us. It's not what the network team shows us. And it's not exactly what the bot on the user's PC tells us. It is only what the user experiences. Whenever you hear people mention end-to-end response time, be sure you understand their definition, because it may not be the same as your definition.

An Oracle process time contribution increase does increase end-to-end response time, but understanding the details is becoming more and more complicated. Here are just of few of the time consumers between the database and the end user: cloud computing, security checks, application servers, web servers, web services, and load-balancing algorithms.

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.