Web Content Management Performance

 

+
Search Tips   |   Advanced Search

 

General Tips

  1. Ensure that the WCM server is upgraded to latest version to take advantage of performance fixes

  2. Apply the recommended performance and syndication fixes

  3. Actively resolve all errors (security, missing components etc) found within the Portal logs

  4. Avoid having a homepage larger than 80 Kb

  5. To render static content, use...

  6. For Portal Search, consider using a dedicated server for the crawler and indexer and disable the local Search crawler.

  7. If you are not using Portal Search, disable the Search crawler

  8. Don't syndicate All Items unless necessary, use All Live Items instead

  9. Don't display single large images, break into multiple smaller images

  10. Don't mix cacheable and non-cacheable items on the same page

  11. Use a ratio of at least 2.5 to 1 database connections (for z/OS the terminology is threads) to WebContainer threads (for the Portal Server running Web Content Management)

 

WCM with DB2

  1. Periodically run the dbreorg

  2. Update table statistics: table statistics are updated with the runstats command. This should be done on a weekly basis, or whenever a large change is made in the content in the portal (such as creating pages through XmlAccess). For example, the following command will update the statistics on the USER_DESC table:

    runstats on table tableschema.USER_DESC with distribution and detailed indexes all

  3. Consider changing the DB2 query level to 2 (for the JCR Database)

  4. Consider using binary collation (as the default collation used in the JCR can have major performance issues under DB2)

    Using binary collation will cause ordering within the Web Content Management Authoring UI, Menus and Personalisation Rules to be case sensitive and words with accent and/or non-English characters will also be ordered incorrectly

    This is difficult and time consuming to enable / disable

 

WCM with Oracle

  1. Disable the following optimizations...

    alter system set "_b_tree_bitmap_plans" = FALSE;

    alter system set "_optimizer_cost_based_transformation" = OFF;

  2. Running database statistics periodically is critical to ensuring database performance over the long term...

    execute dbms_stats.gather_database_stats(dbms_stats.auto_sample_size, method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO', cascade=>TRUE);

 

WCM with LDAP

  1. Use a dedicated server

  2. Monitor CPU activity of the LDAP server and add additional hardware as required

  3. Perform tuning as indicated in LDAP products documentation

  4. Avoid too many nested groups

 

Optimizing Menu Components

  1. Avoid too many search criteria (in Menu Element Query section)

  2. Avoid utilizing the options in the Further options section for each criteria unless really necessary, as this stops the menu from being internally cached

  3. For Category and/or Site Area restricted menus, only select both Ancestors and Descendents if really necessary and limit the number of categories and site areas specified

  4. Disable sorting by Description unless really required (set the value to one of the other sort fields to disable)

  5. For unsecure sites (where content is accessed anonymously or always accessed by the same user, eg. Administrator), set Maximum pages to include and Pages to read ahead to 1

  6. If using multiple libraries, ensure that at least a site area is selected in each menu otherwise the menu will search against all libraries

 

Optimizing Navigator Components

  1. Only select both Ancestors and Descendents if really necessary

  2. For unsecure sites (where content is accessed anonymously or always accessed by the same user, eg. Administrator), set Maximum pages to include and Pages to read ahead to 1

 

Optimizing Portal Personalization Rules

  1. Avoid having too many rules based off authoring template elements as they dont perform as well as rules that utilise standard metadata (such as keywords and categories)

 

Optimizing Syndication

  1. Set the subscriber.only property to true in WCMConfigServices.properties for all Workplace Web Content Management instances that will not syndicate their repositories to other servers.

  2. Avoid having too many Subscribers linked to the one Syndicator

 

Optimizing WCM Versioning

  1. Consider disabling Versioning for all items on both authoring and rendering servers

  2. Consider disabling syndication of versions

 

Optimizing Authoring Templates

  1. A well designed Authoring Template is a prerequisite to achieving optimal WCM authoring performance.

  2. For optimal performance of authoring actions, IBM recommends to limit the number of elements to 10 - 15 elements.

 

Optimizing Applications that use the WCM API

  1. Cache the Workspace object for each user in the session Call Workspace.login and Workspace.logout around all WCM API method calls that will execute within the current request Consider caching the results of JSPs using servlet-caching or WCM caching

 

Optimizing WCMs Internal Caches

  1. WCM has various internal caches that store frequently accessed data fragments (not entire rendered pages).

  2. By default these caches have a maximum size of 2000 items, however during performance tuning you may want to try increasing the size of them:

    abspath services/cache/iwk/abspath Stores the path to sites, siteareas and content
    abspathreverse services/cache/iwk/abspathreverse Stores the path to sites, siteareas and content (in reverse)
    menu services/cache/iwk/menu Stores the results of cacheable WCM menus
    nav services/cache/iwk/nav Stores the results of cacheable WCM Navigators
    strategy services/cache/iwk/strategy Stores fragments of WCM objects (ie. Provides a caching layer over the repository)
    summary services/cache/iwk/summary Stores summary information about WCM objects (used throughout the Authoring UI and API)

  3. Go the the Resources \ Cache Instances \ Object Cache Instances section of the WebSphere Admin Console, to change the size of any caches

 

Scaling Authoring Servers

  1. Cluster the authoring server

  2. Libraries can be used to distribute content and design elements within a single server

  3. Database monitoring and tuning is essential for large websites and/or those with heavy rendering loads

  4. Avoid many subscribers pointing to the authoring server

  5. Add more hardware (CPUs / RAM)

 

Scaling Rendering Servers

  1. Load Balance the rendering server
    Horizontal cluster Add additional servers (HW fail-over)
    Vertical cluster Add additional instances (JVM heap size)

  2. Consider caching or pre-rendering

  3. Use local rendering rather than remote rendering

  4. Design your web site to maximise performance and scalability

  5. Libraries can be used to distribute content and design elements within a single server

  6. Database monitoring and tuning is essential for large websites and/or those with heavy rendering loads

  7. Add more hardware (CPUs / RAM)

 

Caching

If the Site is not personalised and is never going to be personalised use the Pre-Renderer or Servlet-caching with Edge Server

If the Site is a mixture of personalised and nonpersonalised content and if you only want to cache your non-personalised content use Servlet caching

To cache both personalised and nonpersonalised content use either WCM Content Caching solely or a combination of it and Servlet caching

If the Site is all personalised (or will be in the future) use WCM Content Caching

 

WCM Content Caching

If content is not personalised use Basic Caching or the Site Advanced cache type so every user can access the same cached items

If content is personalised:

  • If content is unique for different groups of users use the Secured Advanced cache type so users that belong to the same groups will access the same cached items

  • If content is unique for different personalization profiles use the Personalized Advanced cache type so users that share the same personalization profile will access the same cached items

  • If content is unique for every user use the User Advanced cache type so every user gets its own cached items

  • If content is unique for every session use the Session Advanced cache type so every session gets its own cached items

 

Cache Management: Handling textual changes

While the cache expiry and pre-rendering interval should be set adequately to handle normal updating of content, there may be times where an unplanned textual change needs to go through

  1. WCM Content Caching

    Flush the WCM Content Cache

  2. Servlet-Caching

    Option 1: Use the CacheMonitor web application to flush the required page and then optionally re-render the page to force it into the cache (to avoid next user getting a performance hit)

    Option 2: Use the Dynacache API (DynamicCacheAccessor) to flush the required page and then optionally re-render the page to force it into the cache (to avoid next user getting a performance hit)

  3. Pre-Rendering

    Use the CacherModule to flush the required pages and then re-request them via the same module

    Flush the specified page...

    <URL_TO_PAGE>?MOD=CacherModule&SRV=flushPageCache&library=<LIBRARY_NAME>

    Pre-render the specified page

    <URL_TO_PAGE>?MOD=CacherModule

 

Auto-Loading the WCM Content and Servlet Caches

All websites that utilise WCM Content or Servlet caching should consider autoloading the cache whenever the cache is flushed or the server restarted (for memory based caches)

A simple way of auto-loading the cache is to create a HTML page that includes an iFrame for each page you wish to load. Upon rendering that page, each iFrame will load thus loading every page into the cache

Another approach is to use the Java URLConnection class to programmatically open a URL connection to each page you want to cache. This approach is more complicated then the previous one but might be more flexible if you want to tie various start-up commands together

 

Auto-Refreshing the Cache (Single Server Environments)

If your website has a requirement for rapid deployment of content and a high performance requirement that precludes the use of a small expiry/pre-render interval (which is the recommended approach), then you may need to look at ways to auto-refresh the cache (when content changes)

One such strategy is to use the WCM API code together with two special workflow stages after published, one that indicates that the cache needs refreshing and another that indicates that the cache is refreshed.

The WCM API code would poll for new content objects within the first new workflow stage then automate the relevant steps in the Handling Emergency Textual changes section depending on the chosen type of cache and finally push the content objects to the second workflow stage

If you additionally want to handle profiling and name changes, then your API code will need to find all references to the current item and refresh them as well.

If a referrer is a library component (eg. menu or navigator), then you will additionally need to refresh all referrers of the library component

 

Auto-Refreshing the Cache (Multi Server Environments)

Auto-refreshing the cache (when content changes) within multi-server environments is difficult as you cant utilise workflow to identify which items should be refreshed and you cant hook into the Syndication engine to determine which items changed

In this scenario is recommended to periodically flush and re-load the cache using the methods described previously

If your pre-rendering, then you could run the refresh on the on the authoring server (like a single server) then copy the refreshed items to the web server

 

Separate Content and Design Editing

If a separate design editing environment and/or design reviews (separate from content creation) are required, then a split authoring server approach should be considered..

 

See also

  1. IBM WebSphere Portal Web Content Manager and DB2 Tuning Guide
  2. IBM WebSphere Portal Performance Troubleshooting Guide