Every customer I’ve worked with expects portal to perform well as it should. This inevitably requires tuning throughout every aspect of the solution deployed. There are a lot of knobs to turn, levers to pull and buttons to push during the tuning phase ranging from caching to pooling to JVM settings and much more. The final session at the 2013 IBM Exceptional Web Experienced conference was “Optimizing Your Portal Experience: Advanced Performance Tips and Techniques” delivered by Hunter Presnall, Portal Performance Lead, IBM Software Group and Denny Pichardo Portal Architect, IBM Software Services for Collaboration. I’ve summarized some of the key tips and techniques discussed around several performance topics.
General Performance Tips
- Smaller is almost always faster whether it is session memory size, page sizes, portlets on a page, etc.
- Optimizing the home page is usually what will give you the best overall gain since it gets the most traffic. If you can cache it, you should.
- A 64 bit JVM is usually better because it supports a larger heap size which enables larger caches. It also uses larger machine instructions which executes code faster.
- Use the new portal theme. The 7.0.0.2 and newer themes contain modular capabilities which reduce the footprint and increase the client side performance.
- For a theme, if you are not using elements like site analytics and tagging and rating, disable them.
- There are many other tuning opportunities. For example, does LDAP have enough capacity, are there enough HTTP server threads, does the caching proxy have enough memory and threads? Also look at the load balancers, security infrastructure and databases.
- Older hardware is much slower. Consider a hardware upgrade. Performance on Intel and Power series has nearly doubled in the last 5 years.
- Make sure to apply settings in the tuning guide.
Web Content Management Performance
- WCM needs all the same tuning as portal plus some additional ones.
- Tune the JCR database. Use as much memory as possible and run runstats and reorg after content population.
- Manage old content using the history cropper to remove old versions, the member fixer to remove old users and remove old managed pages in portal 8.
- If possible, use WCM pre-rendering.
- Portlet fragment caching and WCM basic caching can massively improve content performance.
- Use a proxy server to cache content wherever possible.
- Disable versioning if it isn’t needed.
- Limit the number of elements in authoring templates when possible.
- Minimize access control records by using security inheritance.
- For syndication set the subscriber.only property to true if an environment does not need to syndicate.
- For managed pages, if you don’t need the site toolbar (project menu) disable it. This reduces permission checks and reduces the HTML footprint.
Personalization
- Keep rules as simple as possible
- Unique queries for small groups of users will yield few cache hits.
- Broad queries may return many results which can consume memory and CPU time.
- Try to limit the number of content spots on a page to 4.
- Limit the rules on a page as much as possible.
Web Experience Factory
- Avoid retrieving large datasets and use paging instead
- Enable cross-user caching where feasible
- Use built in performance logging and tracing tools
Client Side
- Web 2.0 applications have a significant client side impact. Downloading JavaScript isn’t the same as running it since JavaScript can perform poor in a browser.
- Reduce client side requests by combining CSS, javascript, use image sprites, etc.
- Close HTML tags.
- Defer parsing of JavaScript.
To summarize, it is important to look at every aspect of your solution when it comes to performance. Performance testing and tuning is an iterative test, tune, retest process that takes a little time but if you do it right, you will have a great performing production solution which can scale to meet your current and future needs.
