• Share
  • ?
  • Profiles ▼
  • Communities ▼
  • Apps ▼

Blogs

  • My Blogs
  • Public Blogs
  • My Updates

This community can have members from outside your organization. Portal administration and performance

  • Log in to participate

▼ Tags

▼ Similar Entries

Set up separate IHS ...

Blog: CSE-WebSphere...
YueHWang 3100020K52
Updated
0 people like thisLikes 0
CommentsComments 2

z/VSE security porta...

Blog: Ingolf's z/VS...
Ingolf24 120000DRN3
Updated
0 people like thisLikes 0
No CommentsComments 0

Finding Long Page Re...

Blog: Portal admini...
AlexLang 100000NC7C
Updated
0 people like thisLikes 0
No CommentsComments 0

KFWITM402E when logi...

Blog: Application P...
WalterPietroni 2000000AEC
Updated
1 people likes thisLikes 1
No CommentsComments 0

WebSphere WCM automa...

Blog: WebSphere Por...
Hermann Huebler 270006FSVH
Updated
0 people like thisLikes 0
No CommentsComments 0

▼ Archive

  • March 2018
  • December 2017
  • October 2017
  • September 2017
  • February 2017
  • January 2017
  • October 2016
  • September 2016
  • July 2016
  • May 2016
  • March 2016
  • February 2016
  • November 2015
  • October 2015
  • September 2015
  • June 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • November 2014
  • September 2014
  • July 2014
  • June 2014
  • April 2014
  • March 2014
  • October 2013
  • August 2013
  • June 2013
  • May 2013
  • March 2013
  • February 2013
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • March 2012
  • November 2011
  • September 2011
  • August 2011
  • June 2011
  • May 2011
  • February 2011
  • October 2010
  • September 2010
  • August 2010
  • July 2009
  • June 2009
  • March 2009
  • February 2009
  • August 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008

▼ Links

  • Portal L2 Blog
  • Thoughts on Web Content Manage...
  • Web Content Manager Forum
  • WebSphere Portal Forum
  • WebSphere Portal Security, Por...
  • WebSphere Portal zone

▼ Blog Authors

Portal administration and performance

View All Entries
Clicking the button causes a full page refresh. The user could go to the "Entry list" region to view the new content.) Entry list

Improving Portal Theme Performance

AlexLang 100000NC7C | | Tags:  mod_expires ihs portal theme ‎ | 1 Comment ‎ | 11,384 Views
 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.

  • Add a Comment Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry
Notify Other People
notification

Send Email Notification

+

Quarantine this entry

deleteEntry
duplicateEntry

Mark as Duplicate

  • Previous Entry
  • Main
  • Next Entry
Feed for Blog Entries | Feed for Blog Comments | Feed for Comments for this Entry