Friday, 29 February 2008

Deploying Oracle ADF: What did I learn about caching

Our company's production application server is located at a site different than the one we do our development. Whenever we deployed a new application users were always complaining about long response times, but we usually blamed that on the network. When we moved away from jsps and started working with JSF pages things really got out of hand.

Response times took as much as 10 seconds when application pages where accessed via WAN, rising the user complaint level to maximum levels.

Additionally the network link appeared to be utilized below 80% and then application server response times as shown at OC4J administration website where much below 0.045 sec.

First thing we tried was to use Oracle's ADF Cache library as explained in Chapter 23 of the ADF Programmers guide for Forms/4GL Developers, without any success. To be precise the library was indeed incorporated into the application but the server response time was still as long as 9 or 10 seconds.

It was then when we asked for help from Oracle Support. So thanks to Kavintha we learned the following :

  • First thing we learned was that the problem was indeed related to caching. Every JSF page created using Oracle ADF utilizes a Javascript file named Common10_1_3_3_0.js with a file size of 120 KB. This is an external script referenced at every page. The problem was that this script was never cached so users had to download it every time causing the delays mentioned above. If this file -- and all related page images -- are cached, then the usual size of an ADF/JSF generated HTML code ranges between 1 and 2 KBytes.
    Enabling full caching options on the Oracle Apache Server can be done by uncommenting the # CacheNegotiatedDocs line of the httpd.conf file located in $ORACLE_HOME/Apache/Apache/conf.
  • Next thing was that if an application is protected by Single-Sign-On then in that case, no matter whether CacheNegotiatedDocs is commented out or not, Apache will always send no-cache headers practically undoing whatever the Apache configuration or the ADF Faces Cache library do.
    The way to allow caching for SSO protected applications is to modify mod_osso.conf located in $ORACLE_HOME/Apache/Apache/conf so the entry for each application looks like this :
            <Location /ProductionDelays>
                    OssoSendCacheHeaders off 
                    require valid-user
                    AuthType Basic
            </Location>
    
    More information about how to to disable the caching headers sent by SSO is available on Metalink note 226119.1. Also you may have a look at a one of my previous postings regarding using SSO which is available through here
  • Last thing we learned about this caching business was that when a JSF application is accessed via SSL, then again caching issues still apply. Firefox will disable caching by default whenever the user loads an https:// URL. IE on the other hand does cache SSL pages by default but this setting can change by a policy set by your system administrator. I realize that in this case Firefox uses the safest approach but unfortunately this will produce very poor results if ADF/JSF pages are to be accessed.
    Enabling disk caching of SSL pages in Firefox can be done by changing the value of the browser.cache.disk_cache_ssl parameter available from the about:config URL.
    IE on the other hand has an option called Do not save encrypted pages to disk available in the Security section of the Advanced internet properties tab. If you want IE to cache content from SSL pages this option must be unchecked.

2 comments :

wing bird said...

hi,

I am running into this issue too, but there is also something which i noticed, the adf js, css there is an jsessionid attached. This cause every brand new browser request cause a hit to apache and therefor not being cached. For example:
**Common10_1_3_3_0.js;jsessionid=0a10f2d230dfc430ad09fa9b48548c23e24439c6f720[1].e38PaheSax8Pby0LaN50

**Common10_1_3_3_0.js;jsessionid=0a10f2d230dfa0e7a1aed9264b5ebe59e39c78775db0[1].e38PaheSax8Pby0LaN50

We are using Jdev 10.1.3.3, i am whether you have seen this before and possibly how to solve it.

Thanks in advance,
Wing

javakias said...

An excellent observation! I will try this tomorrow and hope to be able to give you a response on whether it actually works or not! Sharing experience like this is really what the net is all about...!