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.
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 firstname.lastname@example.org.