IBM Support

Open Mic Webcast replay: WebSphere Portal Performance Tuning and Troubleshooting - 26 June 2012 [slides & audio & summary attached]



IBM hosted an Open Mic webcast with Lotus Development and Support Engineers on 26 June 2012. The topic was "WebSphere Portal Performance Tuning and Troubleshooting."


For more information about our Open Mic webcasts, visit the IBM Collaboration Solutions Support Open Mics page.

Presentation & Audio Replay

OpenMic - Portal Performance June 26.pdfOpenMic - Portal Performance June 26.pdf

Audio replay:
WebSphere Portal Performance Open Mic Jun 26 2012 (edited).mp3WebSphere Portal Performance Open Mic Jun 26 2012 (edited).mp3


Q: What is the current recommendation regarding 64-bit JVM? It used to be that 32-bit JVM were better performing in 6.1 and earlier releases. The documentation for WebSphere Application Server 7 & later still says to use 32-bit unless you need a larger heap.
A: A 32-bit JVM is going to perform a little better than a 64-bit JVM. The key, as you said, is if you need a larger heap because you expect a high demand for memory. What we find with Portal, because Portal makes such extensive use of caches, is that the more memory you can give Portal, the better it performs. Portal uses that extra memory to create larger caches, doing less database access and pulling more things from memory. While overall performance might be a little bit slower, the fact that you can use 2 GB more memory for caching with a 64-it JVM provides a performance benefit.

Q: From the forum: How do I decrease start up time in production? Can we delete the out-of-box portlets that we are not using?
A: There are modes for Portal that you can set: development or test, production, or production light where some applications are not started until needed. Do not delete the portlets, but disable them using those modes. Or you can manually disable the applications that you do not want starting up. Disabling is a better option in case you discover you need something later. The current Performance Tuning Guide for Portal 7, and the one pending for Portal 8, will have information on this topic.

Q: What caches can you enable? How do the caches relate to 32- or 64-bit hardware?
A: The available caches are documented in the Tuning guide that we publish to the WebSphere Portal wiki. We are currently finishing up the Portal 8 tuning guide and expect publication in July. Until then, the 7.0 version should get you started. In our testing, most of what we tune is user caches. And the tuning there is around how many users you are going to have accessing your site in a certain period of time. In cases where we need cache sizes that allow for many users, like 20,000 to 30,000, being active on the site at once, 64-bit can be helpful because you need more than 2 GB memory to cache that amount of data. For some tuning scenarios and a checklist of options, refer to the following Open Mic given in 2011: "Open Mic session for Portal Performance Tuning."

Q: In the presentation, you noted that the performance team measured hundreds of creations and publications per hour and thousands of edits per hour. What hardware was this run on? Were the authoring and rendering environments on separate hardware?
A: That measurement is specifically an authoring measurement, where we are not doing any other workflow other than what it takes for an author to get to the pages to be edited. The hardware was an IBM x3550 M2 server, approximately 2010-era Intel chips, running Windows 2008, with 4 cores with 8 GB of memory. For the database, we ran that on a six-disc RAID array. We had a separate database server and Portal server.

Q: We have had problems with the cache settings, and it's not clear to us which cache controls what. Is the hierarchy of caches documented, namely which depend on what and what data is held in these caches?
A: No hierarchy chart exists specifically. Some of the relationship are documented in the Portal wiki, but the information may be scattered. In the Tuning guide, we go into background of the caches and why we tune them. Start with the tuning guide to see if that answers your questions. There is some duplication in the caching structure, for example, there are VMM caches that store LDAP DNs, and there are caches on top of that that pull out, say, the CN (common name) and store that. There is hierarchy in that sense.
There is a portlet called CacheViewerPortlet that you can request by opening a service request with IBM Support. That portlet will show you the hit rates and the discard rates on all the caches, which you can review for your particular environment to see which ones need to be increased.

Q: We've noticed massive files with Page Builder. Where is the Page Builder theme headed? Is it replaced or superseded? Are the Portal and Portal 8 themes intended to replace Page Builder? It seems that all the features of Page Builder are now in the Portal theme.
A: The new theme introduced in and added on in 8.0 supersedes Page Builder. Page Builder runs on Portal 8; however, it's not something we explicitly performance tested but it was functionally tested to know that it works. After migrating to Portal 8, you can change to the new theme.
When you say massive files with Page Builder, my guess is you are looking at the Dojo, IBM Mashup enablers, and some other pieces that are included. The newer themes are now modularized, so if you don't need Dojo on a page for example, you can remove it from the the profile or load another module instead. For the Dojo needed internally by administrative portlets and other pieces, that has been moved to a notion of a deferred set of modules; it is included in the profile but does not load until specific events are triggered. Even the newer themes have some big artifacts. The key is to make sure they are cached when served, if shared and cacheable, and do HTTP server tuning.

Q: Earlier you mentioned the various mode options, such as development or production. Where do you change that mode? 
A: Refer to Enabling and disabling portal light mode, and the portlet development mode topic in the Tuning guide. Also, search for documentation on syndication for Web Content Manager in the Portal wiki. The documentation outlines common topologies for this setup, where you have your authoring environment isolated to create content there and then syndicate it to the production site.

Q: I turned off the privileged user role so users have only the user role and cannot change anything. However, I observed that the customization database, the source pool size, was up to 20 connections. This usage is not attributable to customization that I saw.
A: Some suggestions: The Customization database would not be involved much unless things are changing. Ten to twenty connections does not seem huge, but if all are active all the time, then that points to a configuration problem somewhere. Database snapshots are a technique to tell if the database has slow queries that could be optimized. Troubleshooting a situation like this is better handled in the Portal Forum or via a service request with IBM Support.

Q: What is the precise name of the theme in version 8 that is the successor to the "Portal" theme in 7?
A: The official name of the WebSphere Portal 8 theme in portal administration is "Portal 8.0."

Q: How can I disable the toolbar in production systems? I know how to use profiles for modules, but not sure if there is a built-in way to disable the toolbar in + theme.
A: The Portal 8 tuning guide, expected publication this summer, will include details on that task.

Q: Do you have any information like performance benchmarks for the same application but on different hardware and OS (Linux, HP-UX, AIX and etc.), 32 versus 64 bit?
A: IBM runs a performance benchmark on several different OS's and hardware. The benchmark report is confidential but can be shared with customers that have signed a non-disclosure agreement.

Q: When you ran your tests creating thousand(s) pages, did you run it in on stand-alone WebSphere Portal instance or in cluster?
A: That test was run on a stand-alone server.

Q: In IBM Connections we have the ability to separate modules in different JVMs. Is there a separation of portal modules that can be done in Portal to allow for the use of multiple 32-bit JVMs rather than one 64-bit? Also, can the cache be sent to a separate JVM?
A: There is no easy way to separate different Portal pieces into separate JVMs - Portal is more monolithic. The only option for caching in a separate JVM would be to use something like WebSphere eXtreme Scale.

Q: For the new Managed Pages functionality...on pages where we intend users to have full control: layouts, styles, page creation, portlet drag-n-drop... should we always set a given profile on those pages? profile_full.json or profile_deffered.json?
A: For managed pages, leave the profile as _deffered. That profile is needed to load the Managed Pages site toolbar.

Q: Can you share the name of the tool used to generate traffic and the profile of utilization used for the tests?
A: We use many tools, such as Rational Performance Tester, HP LoadRunner, and more.

Date and time

Date: 26 June 2012

Time: 11:00 AM EDT (15:00 UTC, or GMT -4)

Document information

More support for: WebSphere Portal End of Support Products
Performance & Tuning

Software version: 7.0

Operating system(s): AIX, IBM i, Linux, Solaris, Windows, z/OS

Reference #: 7024895

Modified date: 28 June 2012