We added a great new feature to the ADF Performance Monitor: network and browser load time information. Now you know exactly every end-user experience of your ADF application, in real-time. You can quickly resolve any performance bottlenecks with this end-to-end visibility. You can even drill down into an individual user to analyze the experience – to understand the ADF application behavior. The dashboard is improved with several overview and detail graphs that shows the layer (database, webservice, application server, network, and browser load-time) where the time is spent of your application. This is very useful to troubleshoot problems. This blog is about network time. This blog is on browser load time.

The ADF Performance Monitor is an advanced tool specifically build for ADF applications and is aware of the intricacies of the ADF framework. It traces key ADF actions across tiers and services to provide end-to-end visibility and automatically maps each tier to easily visualize the relationship between them. This Tracing provides deep visibility into the cause of application performance issues down to the tiniest detail. 

Network Time to and from the Browser

Network time is the time that it takes to send a HTTP request from a browser (http request network time) to the application server and from the application server back to the browser (http response network time). The browser loadtime is the time that a browser needs to build up the DOM tree and load the page.

Normally, the network time to and from the browser should not be more than ± half a second.

Network Time in the ADF Performance Monitor

For this to work we set a parameter  oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER to true in web.xml. This adds an additional XML element to each HTTP request. This is already build in into the ADF framework. This is also what oracle RUEI uses.

<context-param>
<param-name>oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER</param-name>
<param-value>true</param-value>
</context-param>

Several overview graphs are added to the main dashboard. At the day overview, it shows for each hour of the day (right bottom) the layer where the time is spent. It shows the time spent in the database, webservice, application server, network, and browser load time:

At the top right graph (hourly overview of day performance) we can see a lot of red in the bars. Specifically from 11:00 to 12:00 – apparantly there were many very slow requests. In the graph at the right bottom we can now explain what happened; there were network problems (marked by the purple color). After talking to the infrastructure department – this was indeed the case. They were very busy with maintenance and were not aware (!) that end-users were suffering from there work.

We can drill down to an hour overview we see a lot of purple again in the right bottom chart – showing that lots of time was spent in the network:

Also, we can zoom in into a specific managed server of our 12 server cluster (called regi_adf_server1) from the dropdown list:

We can see here that during the whole hour there were network problems (graph right bottom).

By clicking on the bars in the menu, we can zoom in more to a five minute overview (11:40-11:45):

In the top graph we see all individual http requests in managed server regi_adf_server1. Again, the stacked bars show the time spent in database, webservice, application server, and network/browser load time (purple). We can see that many end-users have to wait ± 5 seconds – on pure network time (!). Note that The JVM is not the problem and is working fine (bottom graph).

The next day the network problem was resolved. We can see this in the following hour overview graph were there is much less purple colour (right bottom):

In the HTTP request popup we can also select a specific end-user an monitor his/her experience. The client response time is the time including everything; the app server process time, the network to browser and browser load time. We can see that in this case the client response time was even more: ± 9 seconds for each HTTP request (!). This user (and organisation) was complaining and calling our support desk where we could monitor and investigate this end-user experience: