The Base Portal Scenario is measured in a three-node horizontal cluster
environment, with or without session persistence, and six-members vertical
cluster environment. In general, the same tuning that was used for the Base
Portal Scenario was used for cluster. The additional settings are outlined in
the following section:
Contents
Application Server
Tuning
Dynacache
Custom Properties
z/OS
Dynacache Custom Properties
Thread
Pools
Transport Buffer Size
WMM Context Pooling
Web Server Tuning
Session Persistence To Database
Tuning
Vertical Cluster Tuning
DYNACACHE CUSTOM PROPERTIES
There are several properties which can be set to reduce the number and
size of Dynacache messages sent between nodes. This will improve scalability
and reduce resource consumption in a clustered IBM® WebSphere® Portal
environment. To set these properties, do the following:
- Open and log in to the IBM WebSphere Application Server Administration
Console.
- Select Application servers > WebSphere_Portal
> Java and Process Management > Process
Definition > Java Virtual Machine > Custom
properties > New
- Under General Properties, add the following:
Name:
com.ibm.ws.cache.CacheConfig.ignoreValueInInvalidationEvent
Value: true
Name:
com.ibm.ws.cache.CacheConfig.filterTimeOutInvalidation
Value: true
Name:
com.ibm.ws.cache.CacheConfig.filterLRUInvalidation
Value: true
Z/OS DYNACACHE CUSTOM PROPERTY
A custom property has been defined:
com.ibm.ws.cache.CacheConfig.propogateInvalidationsNotShared,
which when set to true leads to invalidations being sent for cache entry
insertions and updates for a NOT_SHARED cache instance. This
property should be removed on z/OS configurations as it has a major impact on
performance.
THREAD POOLS
Increase the default Thread pool size to make the DRS traffic more
efficient.
Setting the default Thread pool size: In the WebSphere Application
Server Administration Console, select Servers > Application
Servers > WebSphere Portal > Additional
Properties: Thread Pools > Default
In the
General Properties section, set the Minimum Size field to
150 and the Maximum Size field to 150.
(Default setting: The default setting is Minimum Size =
5 and Maximum Size = 20.)
TRANSPORT BUFFER SIZE
The default Transport buffer size is insufficient. We increased this
setting to 200MB.
Setting the default Transport buffer size: In the WebSphere
Application Server Network Deployment Administration Console, select
Servers > Application Servers > WebSphere
Portal > Additional Properties: Core group service.
In the Transport buffer size field, enter 200.
(Default setting: The default Transport buffer is 10MB.)
You
must also configure the same Transport buffer size for the Node agent and
Deployment Manager.
Setting the Transport buffer size for the
Node agent: In the WebSphere Application Server Network Deployment
Administration Console, select System Administration > Node
agents > node_agent > Additional
Properties: Core group service.
In the Transport buffer
size field, enter 200.
Setting the Transport
buffer size for the Deployment Manager: In the WebSphere Application Server
Network Deployment Administration Console, select System Administration
> Deployment Manager > Additional Properties: Core
group service.
In the Transport buffer size field, enter
200.
WMM CONTEXT POOLING
You must tune WMM Context Pooling for your cluster in the Deployment
Manager then fully resynchronize to each node from the Administration Console.
Refer to VMM Context Pooling for instructions on tuning WMM
Context Pooling for your cluster.
Table 26: Web Server Tuning for Clusters
| Parameter |
Setting Used |
| ThreadLimit |
25 |
| ServerLimit |
180 |
| StartServers |
2 |
| MaxClients |
4500 |
| MinSpareThreads |
25 |
| MaxSpareThreads |
4500 |
| ThreadsPerChild |
25 |
| MaxRequestsPerChild |
0 |
Sample configuration:
<IfModule worker.c>
ThreadLimit 25
ServerLimit 180
StartServers 2
MaxClients 4500
MinSpareThreads 25
MaxSpareThreads 4500
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
To enable Session Persistence to Database, a data source with non-XA
JDBC driver must be created. We also configured IBM DB2® Session Database
with 32K page size to optimize performance for writing large amounts of data to
the database. For details on configuring tablespace and page size for DB2
session database visit WebSphere Application Server Info Center. Additional
tunings are applied below:
Table 27: WebSphere Session Persistence Tuning
| Parameter |
Setting |
Additional Details |
| Session in memory count |
2000 |
The default value of session in memory count is 1000. For session
database persistence enabled load, we set session in memory count to 2000.
Setting the parameters: In the WebSphere Application Server
Administration Console, select Servers > Application
Servers > WebSphere Portal > Container
Settings: Session management.
Locate the Maximum in-memory
session count field and set the maximum number of sessions to maintain in
memory. |
| Allow overflow |
disable |
The default value of session allow overflow is selected. For
session database persistence enabled load, we deselected it.
Setting the parameters: In the WebSphere Application Server
Administration Console, select Servers > Application
Servers > WebSphere Portal > Container
Settings: Session management
Locate and deselect the Allow
overflow field. |
| Session Distributed Environment |
Enable with database 32K page tablespace |
Setting the parameters: In the WebSphere Application Server
Administration Console, select Servers > Application
Servers > WebSphere Portal > Container
Settings: Session management > Additional Properties:
Distributed environment settings.
Locate and select
Database then enter the following parameters:
Datasource
JNDI name:jdbc/sessions (Set the value for this field
according to your session datasource)
User ID: / Password:
Set these values according to your session database.
DB2 Row
size:ROW_SIZE_32KB
Table space
name:sess_user32k (Set the value for this field according to
your database table space.)
Use multi row schema Deselect
this option. |
| ConnectionPool size for Session Data Source |
Min=10
Max=33 |
Refer to Datasource Tuning For DB2 for instructions on
setting the parameters. |
| Prepared Statement Cache size for Session Data Source |
15 |
Refer to Datasource Tuning For DB2 for instructions on
setting the parameters. |
SESSION DATABASE TUNING
In addition to creating bufferpool and tablespace to support 32K page
size for Session database, we applied the following tunings to our dedicated
session database server:
db2set DB2_USE_ALTERNATE_PAGE_CLEANING=ON
db2set DB2_RR_TO_RS=YES
db2set DB2_PARALLEL_IO=*
# disable session tablespace FILE SYSTEM CACHING
db2 alter tablespace sess_user32k NO FILE SYSTEM CACHING
db2 alter tablespace sess_temp32k NO FILE SYSTEM CACHING
db2 update db cfg for using locklist 5120
db2 update db cfg for using maxlocks 80
db2 update db cfg for using dbheap 4800
db2 update db cfg for using num_iocleaners 20
db2 update db cfg for using num_ioservers 20
db2 update db cfg for using logbufsz 256
db2 update db cfg for using logfilsiz 12288
db2 update db cfg for using logprimary 40
We used the following settings in our vertical cluster environment:
- Refer to Dynacache Custom Properties in the Cluster
Tuning section of this document to reduce the number and size of
Dynacache messages sent between JVMs. Additional DynaCache properties for
Vertical Cluster:
Name: com.ibm.ws.cache.CacheConfig.cacheEntryWindow
Value:10
Name: com.ibm.ws.cache.CacheConfig.cacheInvalidateEntryWindow
Value: 10
Name:
com.ibm.ws.cache.CacheConfig.propogateInvalidationNotShared
Value: false
Name: com.ibm.ws.cache.CacheConfig.useServerClassLoader
Value: true
- Refer to Transport Buffer Size in the Cluster
Tuning section of this document to increase transfer buffer
size.
- Increase Dynamic cache size to
3500.
Increasing the Dynamic cache size: In the WebSphere Application Server
Administration Console, select Servers > Application
Servers > WebSphere Portal > Container
Settings: Container Services > Dynamic Cache Service.
In the Cache size field enter 3500.
- Refer to WMM Context Pooling for instructions on improving
the performance of concurrent access to an LDAP server.
- Use the following command to increase
DBHEAP for the
Release database: db2 update db cfg for using
dbheap 4800
IBM Tivoli Directory Server Tuning
The following table shows the tuning values used for the directory
servers:
Setting the tuning values: Locate these values in
the following file:
/opt/IBM/ldap/V6.0/etc/SchemaV6.0/ibmslapd.conf. Server
Restart: You must restart the LDAP server after changing these
values.
Table 28: IDS Tuning in Vertical Cluster
| Parameter |
Setting Used |
Ibm-slapdACLCacheSize |
250000 |
Ibm-slapdEntryCacheSize |
250000 |
Ibm-slapdFilterCacheSize |
250000 |
Ibm-slapdFilterCacheBypassLimit |
7500 |
The IBM Tivoli® Directory Server uses IBM DB2 as the database server.
The database instance and alias are named IDSLDAP. We applied the following
tuning to this database:
db2 update db config for idsldap using dbheap 4800
db2 update db config for idsldap using num_iocleaners 5
db2 update db config for idsldap using num_ioservers 10
db2 alter bufferpool IBMDEFAULTBP size 88500
db2 alter bufferpool LDAPBP size 3690
Required Fixes
The following fixes are required in 6.1 cluster environments:
- PK67324 (for Windows is PK67800)
- WAS DynaCache PK67942
- WAS DynaCache PK59026 (including PK62850 and prereq PK67942) to eliminate
renounce messages
- PK70944: to eliminate GroupCache invalidation
- PK70890: Friendly URL fix
The following fix is required in 6.1.0.1 cluster environments:
PK76988: Cluster performance Degradation by large amount of DRS invalidation
messages
The Base Portal Scenario is measured in a three-node horizontal cluster environment, with or without session persistence, and six-members vertical cluster environment. In general, the same tuning that was used for the Base Portal Scenario was used for cluster.