Tuning IBM WebSphere Portal and IBM Web Content Manager for best anonymous page performance
IBM WebSphere Portal (hereafter called "Portal"), with or without IBM Web Content Manager (hereafter called WCM), performs well only with effective caching. There are multiple levels and types of caching within Portal/WCM, including HTTP caching, DynaCache caching, and other custom JavaTM caches.
Out of the box, Portal/WCM is not configured (from a caching perspective) for production loads; instead, it's configured for development usage with all features enabled. For a production environment, Portal (without cache enablement and tuning) is not able to support medium to large transaction rates effectively.
Preparing Portal for a production environment requires effective caching to improve the performance of the Portal/WCM server. This includes improving the caching of the pages, portlets, themes, and static resources.
Although there are various layers of caching available, the single most effective cache option is to cache the HTML rendered for the whole Portal page, including caching the static resources referenced by the page.
The next most effective solution is to cache the HTML for each portlet prior to rendering (portlet caching), and this solution is followed by caching the content of each portlet so that dynamic generation of the portlet is faster.
Note that, as pages and portlets become more cached (that is, there is a higher probability that what the user needs already exists in a cache), the content must become less personalized to the user.
Out of the box, Portal/WCM is not configured (from a caching perspective) for production loads; instead, it's configured for development usage with all features enabled. For a production environment, Portal (without cache enablement and tuning) is not able to support medium to large transaction rates effectively.
Preparing Portal for a production environment requires effective caching to improve the performance of the Portal/WCM server. This includes improving the caching of the pages, portlets, themes, and static resources.
Although there are various layers of caching available, the single most effective cache option is to cache the HTML rendered for the whole Portal page, including caching the static resources referenced by the page.
The next most effective solution is to cache the HTML for each portlet prior to rendering (portlet caching), and this solution is followed by caching the content of each portlet so that dynamic generation of the portlet is faster.
Note that, as pages and portlets become more cached (that is, there is a higher probability that what the user needs already exists in a cache), the content must become less personalized to the user.
The authors are too of IBM's finest minds: -
Alex Lang joined IBM in 1982, since which time he has had various technical and management assignments in networking, digital signal processing, Java advocacy, and IBM WebSphere. He is currently the Technical Team Lead for the WebSphere Portal SEAL team. His primary focus is resolving critical customer situations involving the architecture, deployment, and operation of WebSphere Portal and Web Content Manager. You can reach Alex at alex_lang@us.ibm.com.
Thomas Hurek is a Software Architect at IBM's Research Triangle Park Development Lab. He has worked on the WebSphere Portal development team for ten years, focusing on various components including security and virtual portals. In his current role he supports clients as a lab-based services consultant and works as Chief Programmer on the development of the product. You can contact Thomas at thurek@us.ibm.com.
Thomas Hurek is a Software Architect at IBM's Research Triangle Park Development Lab. He has worked on the WebSphere Portal development team for ten years, focusing on various components including security and virtual portals. In his current role he supports clients as a lab-based services consultant and works as Chief Programmer on the development of the product. You can contact Thomas at thurek@us.ibm.com.
both of whom have been of help to me over the past year or so, as I've been working on a complex-but-enjoyable social portal project for a client here in the UK.
Alex is also a bit of a whiz on virtualization, and has provided some fascinating insights into the performance of WebSphere-based workloads on VMware.
The article is in the Wiki here.
4 comments:
Hi Dave. Don´t forget to enable gzip compression on the IBM HTTPServer and his cache. This weekend i got a huge performance gain using HTTP Compression. (user perspective) the size of the page drops from 3.4MB to 1.6 MB
@Kenio, good call, thanks for the pointer, regards, Dave
gzip on http server is good so long as you don't then go throgh webseal.
Webseal has to decompress, so it's likely unless you havae a very slow wan.. that you'll be getting little benefit for much cpu.
in the case of webseal, look at your network edge appliances which are closer tio the network than webseal to do this.. and also static caching
@Mike - thanks for this, good points, which I'll note for future re-use :-)
Post a Comment