Portal administration and performance

 A little known fact of Portal (and WAS, for that matter), is that when Portal serves up theme files, there is no default cache-control headers in the HTTP response. As a result, these files is not saved in the browser's local cache. Therefore,  theme components that are scripts (.js), CSS files and images (served up as HREFs in "secondary GET requests" after the initial portal page GET request is parsed by the browser) are returned to the browser with no directive to tell the browser to cache these for future renders.  This means that all of these components are fetched on each and every page render.

Use a tool like "fiddler" or "firebug" to observe this behavior.

This problem could induce long render times for your portal. Users with poor bandwidth, no local edge caching and/or long latency back to the main Portal servers could see dramatically longer render times than users who are local to the portal servers with excellent broadband service.

The solution is to use IHS (Apache) and force these components to have cache-control headers via the httpd.conf IHS configuration file. Then, these theme elements are cached in the browser's cache for a period of time. Here is an portion of an IHS httpd.conf to use as an example to force cache-control headers for static theme elements:

### Force Caching of statics
<LoadModule expires_module modules/mod_expires.so
<IfModule mod_expires.c>

ExpiresActive On
ExpiresByType application/x-javascript "access plus 20 days"
ExpiresByType text/javascript "access plus 20 days"
ExpiresByType text/css "access plus 20 days"
ExpiresByType image/jpeg "access plus 20 days"
ExpiresByType image/jpg "access plus 20 days"
ExpiresByType image/gif  "access plus 20 days"
ExpiresByType image/png  "access plus 20 days"
ExpiresByType image/bmp  "access plus 20 days"
ExpiresByType image/x-icon  "access plus 20 days" 

# The following will modify the Cache Control Header on the WAS content be have the Public attribute and to become stale in intermediate caches after 36001 seconds (10 hours)
# Further, it will force IE to check the server after 18002 seconds (5 hours) to see if an update is available.
# Also, note that if you are using HTTPS (SSL), only "public" content (content with the cache-control header public) is cachable on the browser.

<LocationMatch "\.(css|js|jp?g|gif|png|ico|bmp)$">
Header append Cache-Control "public, s-maxage=36001, post-check=18002"
</LocationMatch>
</IfModule>

As an aside, note that for some reason, WAS currently does not set the mime type correctly for .png files. To resolve this, add ".png" to the virtual host via the WAS Admin Console.

Note: Apache "Expires" will not overwrite an already existing Expires header. So, if you write a custom WebSphere "FileServingServlet", for example, that places an "Expires: 0" header on all the content, regardless of type, then Apache can't really help you. You should take care in WebSphere code to place an appropriate cache control header on your response to insure that content stays in the browser cache as long as appropriate. Setting a cache-control that will allow content to be refreshed from the browser cache will greatly improve overall system performance on highly utilized sites.