In general, the same tuning that was used for the Base Portal Scenario was
used for the IBM® Lotus® Web Content Management authoring, rendering
and API Scenario. The main differences are to the cache tuning settings: Lotus
Web Content Management increases demands on the portal access control component
which requires a different set of cache tunings to accommodate and Lotus Web
Content Management has an internal set of object caches that can be tuned as
well. On top of cache tunings, Lotus Web Content Management can require more
Web Container threads and JCR data source connections than the Base Portal
Scenario, especially for heavy authoring workloads. The differences in tuning
are described in the following sections.
Contents
Application Server Tuning
WebSphere Portal Service Properties
Cache Manager Service
Navigation Service
Lotus Web Content Management Object Cache
Lotus Web Content Management Configuration Service
JCR Text Search
DB2 Tuning (Authoring Environment)
- Web Container Thread Pool - We used 60 threads for both the
minimum and maximum value.
- Data Source Connection Pool - We used the following values:
| Data Source |
Rendering Value (minimum/maximum) |
Authoring/API Value (minimum/maximum) |
| JCRDB |
10/150 |
10/150 |
CACHE MANAGER SERVICE
Portal Caches sizes - Ignore the Base Portal values and set the
following in CacheManagerService.properties:
Table 20: Cache Manager Service Settings for Lotus Web Content
Management
| CacheManagerService.properties |
| Cache Name |
Value Used |
| cacheinstance.com.ibm.workplace.searchmenu.helper.SearchMenuCacheHelper.size
|
5000 |
| cacheinstance.com.ibm.wps.ac.ContainedRolesCache.size |
500 |
| cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.size |
5000 |
| cacheinstance.com.ibm.wps.ac.ApplicationRolesForPrincipalCache.size |
12500 |
| cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.lifetime |
10800 |
| cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.size |
500 |
| cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.ICM_CONTENT.si
ze |
12000 |
| cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.VIRTUAL.size
| 500 |
| cacheinstance.com.ibm.wps.ac.ProtectedResourceCache.size |
12500 |
| cacheinstance.com.ibm.wps.ac.ExternalOIDCache.size |
12000 |
| cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.lifetime |
10800 |
| cacheinstance.com.ibm.wps.ac.RolesCache.size |
7500 |
| cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache.size |
1200 |
| cacheinstance.com.ibm.wps.datastore.pageinstance.DerivationCache.size |
250 |
| cacheinstance.com.ibm.wps.datastore.pageinstance.OIDCache.size |
250 |
| cacheinstance.com.ibm.wps.datastore.services.Identification.SerializedOidStr
ing.cache.size |
500 |
| cacheinstance.com.ibm.wps.model.content.impl.ResourceCache.size |
500 |
| cacheinstance.com.ibm.wps.model.content.impl.TopologyCache.size |
500 |
| cacheinstance.com.ibm.wps.pe.portletentity.size |
250 |
| cacheinstance.com.ibm.wps.services.cache.cachedstate.CachedStateServiceSessi
onBound.cache.size |
250 |
| cacheinstance.com.ibm.wps.ac.ApplicationRoleChildrenCache.size |
500 |
| cacheinstance.com.ibm.wps.ac.ApplicationRoleDescriptorCache.size |
500 |
| cacheinstance.com.ibm.wps.ac.ApplicationRoleOIDCache.size |
500 |
| cacheinstance.com.ibm.wps.ac.ChildEntitlementsCache.size |
500 |
| cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.APPLICATION_ROLE.size |
500 |
| cacheinstance.com.ibm.wps.policy.services.PolicyCacheManager.lifetime |
28800 |
| cacheinstance.com.ibm.wps.model.content.impl.ResourceCache.lifetime |
14400 |
NAVIGATION SERVICE
Portal Navigator Service - In addition to the settings mentioned for
Base Portal we set the following property to allow public sessions required for
rendering portlets on anonymous pages:
Table 21: Navigation Service Settings for Lotus Web Content
Management
| NavigatorService.properties |
| Parameter |
Default Value |
Value Used |
Definition |
| public.session |
false |
true |
This parameter controls whether anonymous users have sessions or
not. |
Table 22: Lotus Web Content Management Object Cache Settings
| Lotus Web Content Management
Object Caches |
| Cache Name |
Value Used |
| abspath |
8000 |
| abspathreverse |
8000 |
| processing |
10000 |
| session |
6000 |
| menu |
500 |
| nav |
500 |
| strategy |
8000 |
| global |
100 |
| module |
100 |
Setting the Lotus Web Content Management Object Cache: In the IBM
WebSphere® Application Server Administration Console, select
Resources > Cache instances > Object cache
instances.
Enable the user cache by doing the following:
- Navigate to the following directory:
wp_profile/PortalServer/wcm/shared/app/config/wcmservices
- Locate the following file: WCMConfigService.properties
- Set the user.cache property to true. For example,
user.cache=true
- Save and close WCMConfigService.properties.
The following properties file disables JCR textsearch:
icm.properties.
During our measurements, we disabled text indexing. Text indexing is done
periodically, adding new content to the text index. However, the indexing
interval is not synchronized with our load plateaus. As a result, if we let
text indexing run during our performance measurements, it would likely reduce
the reliability and repeatability of our measurements.
We do not recommend disabling text indexing in production environments, as
doing so would mean that new content will not be added to the text index, and
therefore would not appear in search results.
If you plan to disable text indexing, do the following:
- Navigate to the following directory:
wp_profile/PortalServer/jcr/lib/com/ibm/icm
- Locate the following file: icm.properties
- Set the jcr.textsearch property to false. For example,
jcr.textsearch=false
- Save and close icm.properties.
MULTIPLATFORM (LUW)
In addition to the DB2® tunings for the Base Portal scenario, we found
that the following tunings to the JCR database below significantly decreased
load on the CPU and disk i/o of the DB2 server in our environment.
In our authoring scenario we found that it was necessary to initially size
the IBMDEFAULTP and ICMLSMAINBP32 bufferpools. The reason for
sizing these bufferpools is that DB2 was unable to autosize the bufferpools
fast enough during our user ramp ups, which caused inconsistent results during
the early stages of the scenario. We also noticed a large amount of database
file handles being opened and closed during our runs. This resulted in
stressing the disk i/o and prompted us to increase the maximum number of file
handles that can be opened for the JCR database. Finally, three indexes were
added to eliminate some troublesome queries that were table scanning.
db2 connect to jcrdb
db2 alter bufferpool IBMDEFAULTBP
IMMEDIATE size 26000
db2 alter bufferpool ICMLSMAINBP32
IMMEDIATE size 24000
db2set
DB2_ASYNC_IO_MAXFILOP=512
db2 update db cfg for jcrdb using
MAXFILOP 512
db2 reorgchk update statistics on table
jcr.icmut01590001
db2 create index taw_entry_idx2 on
jcr.ev_entry (parentid)
db2 reorgchk update statistics on table
jcr.ev_entry
db2 create index taw_ICMSTJCRWSX_2 on
jcr.icmstjcrws (basewsid, wstype)
db2 reorgchk update statistics on table
jcr.icmstjcrws
db2stop force
db2start
Z/OS
The following section details the tunings that we made in our DB2 9
for z/OS backend database during our testing. To start here are a few general
recommendations:
- When the DB2 z/OS server is on a different server to the Portal/Lotus Web
Content Management installation, the use of the Universal Driver type 4
database driver is recommended.
- For data sharing groups, we additionally recommend enabling Sysplex
Distributor to enhance high availability and exploit workload balancing.
In our environment we created nine databases to support Lotus Web Content
Management on Portal. The release, customization, community, likeminds, and
feedback are required for Portal. For Lotus Web Content Management, a minimum
of two JCR databases are required for scalability and in our environment we
used four.
TABLESPACES
Following DB2 best practices, it is recommended to create all tables
into individual tablespaces. This will avoid device contention and provides
better monitoring possibilities. Furthermore, most DB2 utilities such as
REORG operate with tablespaces rather than tables.
BUFFERPOOLS
It is also beneficial to create separate bufferpools for use by Portal
to avoid contention. When creating your database, ensure that each
tablespace/indexspace has a specific bufferpool specified by the
BUFFERPOOL/INDEXBP attributes rather than using the DB2
system defaults. It is recommended that a set of bufferpools separate from the
Portal databases gets created for the JCR databases. The following table shows
the settings for our configuration.
Table 23: DB2 z/OS Bufferpool Settings
| Bufferpool settings |
| Database Domain |
wkplc_comp.properties |
DB2
BP |
BP
Pagesize (KB) |
BP Size |
RELEASE
CUSTOMIZATION
COMMUNITY
LIKEMINDS
FEEDBACK |
domain.Db4KBufferPoolName |
BP2 |
4 |
40000 |
RELEASE
CUSTOMIZATION
COMMUNITY
LIKEMINDS
FEEDBACK |
domain.DbIndex4KBufferPoolName |
BP3 |
4 |
5000 |
RELEASE
CUSTOMIZATION
COMMUNITY
LIKEMINDS
FEEDBACK |
domain.Db32KBufferPoolName |
BP32K |
32 |
1000 |
| JCR |
jcr.Db4KBufferPoolName |
BP4 |
4 |
80000 |
| JCR |
jcr.DbIndex4KBufferPoolName |
BP5 |
4 |
40000 |
| JCR |
jcr.Db32KBufferPoolName |
BP32K1 |
32 |
20000 |
Note: When running Portal, DB2 objects such as tablespaces are
created dynamically. It is important to keep your default bufferpools
well-defined to avoid causing contention due to an overloaded bufferpool. This
is especially true for LOB and 4-KB tablespaces as they default to BP0. In DB2
9 for z/OS, you can set ZPARMs to specify default bufferpools. In our
environment we used the following values:
Table 24: DB2 z/OS Default Bufferpool Settings
| Default Bufferpool
Settings |
| ZPARM |
Value Used |
BP Size |
Description |
| TBSBPLOB |
BP16K0 |
10000 |
Specifies the default buffer pool to use for LOB table spaces that
are created implicitly and for LOB table spaces that are created explicitly
without the BUFFERPOOL clause. |
| TBSBPOOL |
BP4 |
80000 |
Specifies the default buffer pool to use for 4-KB page size table
spaces that are created implicitly and for 4-KB page size table spaces that are
created explicitly without the BUFFERPOOL clause. |
| TBSBP8K |
BP8K0 |
35000 |
Specifies the default buffer pool to use for 8-KB page size table
spaces that are created implicitly and for 8-KB page size table spaces that are
created explicitly without the BUFFERPOOL clause. |
| TBSBP16K |
BP16K0 |
10000 |
Specifies the default buffer pool to use for 16-KB page size table
spaces that are created implicitly and for 16-KB page size table spaces that
are created explicitly without the BUFFERPOOL clause. |
| TBSBP32K |
BP32K |
1000 |
Specifies the default buffer pool to use for 32-KB page size table
spaces that are created implicitly and for 32-KB page size table spaces that
are created explicitly without the BUFFERPOOL clause. |
| IDXBPOOL |
BP5 |
40000 |
DB2 uses the IDXBPOOL value if you do not specify a value for
INDEXBP on the CREATE DATABASE statement. DB2 does not use this value for a
CREATE INDEX statement without the BUFFERPOOL option. In that case, DB2 uses
the default index buffer pool for the database. |
DB2 FOR Z/OS V8 FIXES
The following fixes are required for running Lotus Web Content
Management on WPS 610x on DB2 for z/OS v8:
- PK62728 - DB2 improves the performance of selected queries (UK36555)
- PK67292 - DB2 was fixed to transform the subquery into a join
(UK37970)
- PK68259 - Addresses CORRELATED SUBQUERY TO JOIN TRANSFORMATION
ENHANCEMENT FOR MULTI-TABLE JOINS IN ANY QUERY BLOCK (UK37971)
ADDITIONAL RESOURCES FOR DB2 Z/OS
- Lotus Web Content Management/JCR database table usage information for IBM
WebSphere Portal V6.1.x at:
http://www-01.ibm.com/support/docview.wss?uid=swg21255445
- Performance Improvement Possible For Remote TCP Access to z/OS at:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10621
- DB2 9 for z/OS Performance Topics at:
http://www.redbooks.ibm.com/redbooks/pdfs/sg247473.pdf
In general, the same tuning that was used for the Base Portal Scenario was used for the IBM® Lotus® Web Content Management authoring, rendering and API Scenario. The main differences are to the cache tuning settings: Lotus Web Content Management increases demands on the portal access control component which requires a different set of cache tunings to accommodate and Lotus Web Content Management has an internal set of object caches that can be tuned as well. On top of cache tunings, Lotus Web Content Management can require more Web Container threads and JCR data source connections than the Base Portal Scenario, especially for heavy authoring workloads.