WebSphere Portal Version 6.0 Web Content Management and DB2 Tuning Guide

IBM
WebSphere Portal Version 6.0
Web Content Management
and
DB2
Tuning Guide
IBM WPLC Performance Team and IBM Toronto Lab
December 18, 2007
RCSﬁle: wp6wcmdb2-TuningGuide.tex,v Date: 2007/12/18 17:23:34 Revision: 1.3

Contents
Preface ii
1 Performance Tuning the Environment 1
2 Understanding the Environment 1
3 Application Server Tuning 2
3.1 JVM Max Heap Size Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2 JVM Large Page Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3 kCluster and pCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4 Datasource Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5 Application Server Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 DB2 registry variables 5
4.1 Optional variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Database Manager configuration parameters 7
6 Database configuration parameters 8
6.1 Parameters for all databases . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 Parameters for the JCR database . . . . . . . . . . . . . . . . . . . . . . . . 9
7 Database Tuning 10
7.1 Collating Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 changing JCR tables to be not volatile . . . . . . . . . . . . . . . . . . . . . 10
8 Ongoing database maintainence 11
8.1 runstats and reorg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2.1 Buffer pool analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9 Directory Server Tuning 14
10 WebSphere Portal Service Properties 15
A Stored Procedures - Buffer Pool Hit Ratio 16
A.1 bphr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2 bphr all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
B References 18
C Credits 19
i

Preface
This document was written with intent to be a central source for tuning a Websphere
Portal Web Content Management and DB2 environment.
It describes the different parts of the environment that are special to that environment. It
was written by the IBM WPLC Performance Team and IBM Toronto Lab.
The document describes how to tune the Application Server and the WebSphere Por-
tal. Furthermore it points out various registry variables and several database manager and
database configuration parameters that should be set to the specified values as a good start.
The ongoing maintenance section is a guideline how to keep the DB2 system performant
during the growth of the system.
ii

IBM WebSphere Portal Web Content Manager and DB2 Tuning Guide
1 Performance Tuning the Environment
Tuning a WebSphere Portal environment involves tuning and configuring the various sys-
tems and components of the environment. This chapter discusses some general concepts
and details the specifics of the configuration used in our measurement environment. The
tuning and configuration for the WebSphere Portal Web Content Management (WCM) AIX
Power4 measurement environment was based upon the WebSphere Portal AIX Power4 en-
vironment detailed in the IBM WebSphere Portal Version 6.0 Tuning Guide. All differences
in the environment used to measure WCM are explicitly mentioned in this chapter. The
overall tuning and configuration approach to any WebSphere Portal environment includes:
• Configuring the application server and the resources defined for that application
server
• Determining the cloning strategy for expanding or extending the environment
• Tuning the database(s) and database server
• Tuning the directory server and its database
• Tuning the web server
• Tuning the operating system and network
• Tuning the WebSphere Portal services
When tuning your individual systems, it is important to begin with a baseline, monitor the
performance metrics to determine if any parameters should be changed and, when a change
is made, monitor the performance metrics to determine the effectiveness of the change.
2 Understanding the Environment
WebSphere Portal V6.0 uses additional servers to provide its functionality. In our measure-
ment environment, there is a web server, database server and directory server in addition
to the portal server itself. For maximum performance, these servers should reside on sep-
arate systems from the WebSphere Portal system. The primary benefit of having such a
configuration is to avoid resource contention from multiple servers residing on a single sys-
tem. Additional servers contending with the WebSphere Portal server for system resources
impacts the system’s achievable throughput. The configuration used for the measurements
in this report had the IBM HTTP Server on the same system as WebSphere Portal.
See Appendix B: WCM Benchmark Environment for the details of our lab configuration.
Date: 2007/12/18 17:23:34 1 / 20 Revision: 1.3

3 Application Server Tuning
There are many aspects to configuring and tuning an application server in WebSphere
Application Server. We found that those presented here, and in the IBM WebSphere
Portal Version 6.0 Tuning Guide were critical to a correctly functioning and optimally per-
forming WebSphere Portal in our laboratory environment. For more details on tuning a
WebSphere Application Server, see the Tuning Section of the information center located at:
http://www.ibm.com/software/webservers/appserv/was/library/
The following are settings, based on our experience with the workloads described in this
document, which differed from those in the IBM WebSphere Portal Version 6.0 Tuning
Guide for AIX on the Power4 platform:
Parameter Setting Additional Details
Java Virtual
Machine heap
size
1792 Remember that the value of the JVM
Heap size is directly related to the
amount of physical memory on the
system. Never set the JVM heap size
larger than the physical memory on the
system
see section 3.1
JVM Heap
Large page
-Xlp Used with the IBM JVM to allocate
the heap using large pages.
see section 3.2
kCluster and
pCluster
-Xk30000
-Xp24000k,2400k
Pinned clusters. Pre-allocates JVM
heap for class files, since they are oth-
erwise pinned in memory once loaded.
see section 3.3
3.1 JVM Max Heap Size Limits
When setting the heap size for an application server, keep the following in mind: Make
sure that the system has enough physical memory for all of the processes to fit into physi-
cal memory, plus enough for the operating system. When more memory is allocated than
the physical memory in the system, paging will occur, and this can result in very poor
performance.
While we set the minimum and maximum heap sizes to the same values, this may not
Date: 2007/12/18 17:23:34 2 / 20 Revision: 1.3

be the best choice for production systems which are running on IBM JDKs. In our mea-
surement runs, the system is under load for a relatively short time (around 3 hours), and
it is running with portlets which do not have large memory requirements. When using
portlets which will have larger memory requirements, or for continuous operation, it may
be possible to reduce heap fragmentation by setting the initial heap size to 320 megabytes.
After doing any tuning of heap sizes, monitor the system to make sure that paging is
not occurring. As mentioned above, paging can cause poor performance.
How-To Set Parameter:
In the WebSphere Administrative Console: Servers → Application Servers → WebSphere
Portal → Server Infrastructure: Java and Process Management → Process Definition →
Java Virtual Machine
- Initial Heap Size
- Maximum Heap Size
3.2 JVM Large Page Tuning
This setting can be used with the IBM JVM to allocate the heap using large pages. AIX
operating system must be configured to support large pages. Using large pages can reduce
the CPU overhead needed to keep track of heap. With this tuning, we have seen 10%
throughput improvement in our measurements.
1. In the WebSphere Administrative Console: Servers → Application Servers → Web-
Sphere Portal → Server Infrastructure: Java and Process Management → Process
Definition → Java Virtual Machine → Generic JVM Argument, Add: -Xlp
2. In the WebSphere Administrative Console: Servers → Application Servers → Web-
Sphere Portal → Server Infrastructure: Java and Process Management → Process
Definition → Custom Properties → New → EXTSHM=OFF
(note: When EXTSHM is on it prevents use of large page).
3. Stop Portal server
4. Configure AIX to support large pages. We use the following steps to allocate 1856
MB of RAM as large pages (16MB). We chose this amount based on having 4GB of
physical memory in these systems. These values may need to be adjusted on systems
with different amounts of physical memory.
vmo -r -o lgpg regions=116 -o lgpg size=16777216
Date: 2007/12/18 17:23:34 3 / 20 Revision: 1.3

bosboot -a
reboot -q
vmo -p -o v pinshm=1
chuser capabilities=CAP BYPASS RAC VMM,CAP PROPAGATE $USER
5. Restart Portal Server. To verify if large pages are being used, run the AIX command
vmstat -l 1 5 and check the ”alp” column which is the active large page used. It
should be a non-zero value if large pages are being used.
3.3 kCluster and pCluster
Objects that are on the JVM heap are usually mobile; that is, the Garbage Collector can
move them around if it decides to re-sequence the heap. Some objects, however, cannot be
moved either permanently or temporarily. Such immovable objects are known as pinned
objects.
In release 1.3.1 Service Refresh 7 and above, the Garbage Collector allocates a kClus-
ter as the first object at the bottom of the heap. A kCluster is an area of storage that is
used exclusively for class blocks. It is large enough to hold 1280 entries. Each class block
is 256 bytes long.
The Garbage Collector then allocates a pCluster as the second object on the heap. A
pCluster is an area of storage that is used to allocate any pinned objects. It is 16 KB long.
When the kCluster is full, the Garbage Collector allocates class blocks in the pCluster.
When the pCluster is full, the Garbage Collector allocates a new pCluster of 2 KB
Because this new pCluster can be allocated anywhere in the heap and must be pinned,
it can cause fragmentation problems. The pinned objects effectively deny the GC the abil-
ity to combine free space during heap compaction and could result in a heap that contains a
lot of free space but in relatively small discrete amounts, so that an allocation that appears
to be well below the total free heap space will fail. To solve this problem, release 1.3.1
at SR7, and later, provides command-line options to specify the kCluster (-Xk), pCluster
(-Xp) and pCluster overflowsize (-Xp). Use these options to set the initial sizes of the
’clusters’ to be large enough to avoid fragmentation issues.
In the WebSphere Administrative Console: Servers → Application Servers → WebSphere
Portal → Server Infrastructure: Java and Process Management → Process Definition →
Java Virtual Machine → Generic JVM Argument: -Xk30000 -Xp24000k,2400k
Date: 2007/12/18 17:23:34 4 / 20 Revision: 1.3

3.4 Datasource Tuning
As is described in the WebSphere Portal information center, multiple databases are used
with WebSphere Portal V6.0. We used seven separate databases, each with their own
datasources. These are:
Database Database name Datasource name
Release release reldbDS
Community community commdbDS
Customization custom cusdbDS
Feedback fdbkdb fdbkdbDS
Likeminds lmdb lmdbDS
JCR jcrdb jcrdbDS
Member Manager wmmdb wmmdbDS
For the prepared statement cache size, the path is Resources → JDBC Providers → provider
name → Data Sources → datasource name → WebSphere Application Server data source
properties. The provider name and datasource name are based on the names selected for
that database during the database transfer step. Look for the parameter Statement cache
size.
We set the prepared statement cache size to 1 statement for all Datasources to reduce
the demands on native memory, thus avoiding crashes.
3.5 Application Server Cloning
We did not measure any cloned environment for this report.
4 DB2 registry variables
The following registry variables should be set (by using the db2set command) at the
instance level:
DB2_RR_TO_RS=YES
DB2_EVALUNCOMMITTED=YES
DB2_SKIPDELETED=ON
DB2_INLIST_TO_NLJN=YES
DB2_MINIMIZE_LISTPREFETCH=ON
DB2 RR TO RS This parameter is deprecated since DB2 v8.2. If you don’t get an error
when trying to set the parameter in DB2 higher than version 8.2, it is ok to have it set. If
you get an error, never mind. The next two variables are the replacement for it.
When DB2 RR TO RS is on, RR behavior cannot be guaranteed for scans on user tables
Date: 2007/12/18 17:23:34 5 / 20 Revision: 1.3

because next key locking is not done during index key insertion and deletion. Catalog tables
are not affected by this option. The other change in behavior is that with DB2 RR TO RS
on, scans will skip over rows that have been deleted but not committed, even though the
row may have qualified for the scan.
DB2 EVALUNCOMMITTED When enabled, this variable allows, where possible, table
or index access scans to defer or avoid row locking until a data record is known to satisfy
predicate evaluation. DB2 EVALUNCOMMITTED is applicable only to statements using either
Cursor Stability or Read Stability isolation levels. For index scans, the index must be a
type-2 index. Furthermore, deleted rows are skipped unconditionally on table scan ac-
cess while deleted keys are not skipped for type-2 index scans unless the registry variable
DB2 SKIPDELETED is also set.
DB2 SKIPDELETED When enabled, this variable allows statements using either Cursor
Stability or Read Stability isolation levels to unconditionally skip deleted keys during index
access and deleted rows during table access. With DB2 EVALUNCOMMITTED enabled, deleted
rows are automatically skipped, but uncommitted pseudo-deleted keys in type-2 indexes
are not skipped unless DB2 SKIPDELETED is also enabled.
DB2 INLIST TO NLJN Sometimes the optimizer does not have accurate information to
determine the best join method for the rewritten version of the query. This can occur if the
IN list contains parameter markers or host variables which prevent the optimizer from using
catalog statistics to determine the selectivity. This registry variable causes the optimizer
to favor nested loop joins to join the list of values, using the table that contributes the IN
list as the inner table in the join.
DB2 MINIMIZE LISTPREFETCH Necessary to avoid an inefficient access plan for a
common query on one of the tables in the JCR database.
4.1 Optional variables
If the system, where DB2 is running, is CPU bound, then the following parameter can be
set as well. Since this variable affects all statements that have more than 5 joins involved,
it should be used with caution. This parameter can help to reduce time and resource usage
during optimization. Although optimization time and resource use might be reduced, the
risk of producing a less than optimal data access plan is increased.
DB2_REDUCED_OPTIMIZATION=5
Attention: This parameter should only be set when explicitly advised by IBM.
Date: 2007/12/18 17:23:34 6 / 20 Revision: 1.3

5 Database Manager conﬁguration parameters
parameter value
QUERY HEAP SZ 32768
MAXAGENTS 1000
SHEAPTHRES 50000
HEALTH MON OFF
ASLHEAPSZ 60
RQRIOBLK 65535
FEDERATED NO
As the instance user enter the following commands:
db2 "update dbm cfg using query_heap_sz 32768"
db2 "update dbm cfg using maxagents 1000"
db2 "update dbm cfg using sheapthres 50000"
db2 "update dbm cfg using health_mon off"
db2 "update dbm cfg using aslheapsz 60"
db2 "update dbm cfg using rqrioblk 65535"
db2 "update dbm cfg using federated no"
Note: If you need federated database support, you must not set FEDERATED to NO.
Date: 2007/12/18 17:23:34 7 / 20 Revision: 1.3

6 Database conﬁguration parameters
6.1 Parameters for all databases
parameter value
APPLHEAPSZ 4096
APP CTL HEAP SZ 1024
STMTHEAP 8192
DBHEAP 2400
LOCKLIST 1000
LOGFILSIZ 1000
LOGPRIMARY 12
LOGSECOND 20
LOGBUFSZ 128
AVG APPLS 5
LOCKTIMEOUT 30
MAXLOCKS 70
MAXAPPLS AUTOMATIC
As the instance user enter the following commands, but change DBNAME to the actual
database name:
db2 "update db cfg for DBNAME using applheapsz 4096"
db2 "update db cfg for DBNAME using app_ctl_heap_sz 1024"
db2 "update db cfg for DBNAME using stmtheap 8192"
db2 "update db cfg for DBNAME using dbheap 2400"
db2 "update db cfg for DBNAME using locklist 1000"
db2 "update db cfg for DBNAME using logfilsiz 1000"
db2 "update db cfg for DBNAME using logprimary 12"
db2 "update db cfg for DBNAME using logsecond 20"
db2 "update db cfg for DBNAME using logbufsz 128"
db2 "update db cfg for DBNAME using avg_appls 5"
db2 "update db cfg for DBNAME using locktimeout 30"
db2 "update db cfg for DBNAME using maxlocks 70"
db2 "update db cfg for DBNAME using maxappls automatic"
Date: 2007/12/18 17:23:34 8 / 20 Revision: 1.3

6.2 Parameters for the JCR database
parameter value
DBHEAP 4800
SORTHEAP 4096
APPLHEAPSZ 16384
APP CTL HEAP SZ 20000
STMTHEAP 16384
NUM IOCLEANERS 11
NUM IOSERVERS 11
As the instance user enter the following commands, but change JCRDB to the name of the
JCR database:
db2 "update db cfg for JCRDB using dbheap 4800"
db2 "update db cfg for JCRDB using sortheap 4096"
db2 "update db cfg for JCRDB using applheapsz 16384"
db2 "update db cfg for JCRDB using app_ctl_heap_sz 20000"
db2 "update db cfg for JCRDB using stmtheap 16384"
db2 "update db cfg for JCRDB using num_iocleaners 11"
db2 "update db cfg for JCRDB using num_ioservers 11"
Date: 2007/12/18 17:23:34 9 / 20 Revision: 1.3

7 Database Tuning
Database performance is very important for obtaining good performance from WCM. The
maintenance tasks and practices mentioned here and in the IBM WebSphere Portal Ver-
sion 6.0 Tuning Guide were found to be critical to the performance and correct operation
of WebSphere Portal in our lab environment. Additional database maintenance and tun-
ing may be needed in your production environments. For further information on DB2
administration, tuning, and monitoring refer to the DB2 Information Center.
7.1 Collating Sequence
DB2 offers a choice of collating sequences when creating databases. We have found that
this choice can have a performance impact. While the use of UCA400 NO collation had
virtually no effect on the throughput for the scenario described in this report, it yielded
much higher database CPU costs. But in a separate investigative measurement the use of
the UCA400 NO collation had an obvious impact on some WCM authoring transactions.
As a rule of thumb, the need for special locale specific data ordering should be weighed
against some possible higher database CPU cost. We did not specify any COLLATE option
when we created our databases.
7.2 changing JCR tables to be not volatile
The DB2 configuration of the JCR schema marks most of the tables as having VOLATILE
CARDINALITY. This is true during the initial population since many tables grow from
zero or a few rows to many rows. This attribute is an indication to the DB2 optimizer
to not trust the table statistics indicating that the table is very small since the optimizer
would normally choose scanning the table over utilizing an index for a small table. Once
the database has reached a steady state we want the optimizer to choose the best access
plan according to the catalog statistics (see the following section for recommendations on
how to maintain these statistics). In order to accomplish this we ran the following com-
mands:
db2 -x -r "nonVolatile.db2" "select rtrim(concat(’alter table ’,
concat(rtrim(tabSchema), concat(’.’, concat(rtrim(tabname),
’ not volatile’))))) from syscat.tables where type=’T’ and
volatile=’C’ and tabSchema=’JCR’"
db2 -v -f "nonVolatile.db2"
Date: 2007/12/18 17:23:34 10 / 20 Revision: 1.3

8 Ongoing database maintainence
8.1 runstats and reorg
Two of the database attributes, which DB2 relies upon to perform optimally, are the
database catalog statistics and the physical organization of the data in the tables. Catalog
statistics should be recomputed periodically during the life of the database, particularly
after periods of heavy data modifications (inserts, updates, and deletes) such as a popu-
lation phase. Due to the heavy contention of computing these statistics, we recommend
performing this maintenance during off hours, periods of low demand, or when the portal
is off-line. The DB2 runstats command is used to count and record the statistical details
about tables, indexes and columns. We have used two techniques in our environment to
compute these statistics. The form we recommend is:
db2 runstats on table tableschema.tablename on all columns with distribution
on all columns and sampled detailed indexes all allow write access
These options allow the optimizer to determine optimal access plans for complex SQL.
A simpler, more convenient technique for computing catalog statistics is:
db2 reorgchk update statistics on table all
Not only does this command count and record some of the same catalog statistics, it also
produces a report that can be reviewed to identify table organization issues. However, we
have found instances where this produces insufficient information for the optimizer to select
an efficient access plan for complex SQL, particularly for queries of the JCR database. We
have determined a technique that has the same convenience of the reorgchk command and
provides the detailed statistics preferred by the optimizer.
db2 -x -r "runstats.db2" "select rtrim(concat(’runstats on table’,
concat(rtrim(tabSchema), concat(’.’,concat(rtrim(tabname),
’ on all columns with distribution on all columns and sampled detailed
indexes all allow write access’))))) from syscat.tables where type=’T’"
db2 -v -f "runstats.db2"
Reorganizing all the tables would be over-kill in a production environment. To determine
which tables might benefit from reorganization, use the command:
db2 reorgchk current statistics on table all > "reorgchk.txt"
The tables that need reorganization are indicated by a ∗ in at least one of the three columns
next to the table name. For those tables that require reorganization, use the command:
db2 reorg table tableschema.tablename
to reorganize the table based upon its primary key.
Date: 2007/12/18 17:23:34 11 / 20 Revision: 1.3

8.2 Monitoring
Snapshot monitoring is used to identify the behavior of a database over a period of time.
It is further used for fine-tuning the system and finding problems regarding performance.
For snapshot monitoring to work, you need to active the different monitors first. There are
two ways to do this. You can either configure the database manager to activate monitor-
ing at instance level, or you can turn on monitoring at a specific time for the current session.
To turn on default monitoring at instance activation or instance level use the following
command:
db2 update dbm cfg using DFT_MON on
where DFT MON is one of the following values:
DFT_MON_BUFPOOL DFT_MON_LOCK DFT_MON_SORT DFT_MON_STMT
DFT_MON_TABLE DFT_MON_TIMESTAMP DFT_MON_UOW
To turn on monitoring for the current session use the command:
db2 update monitor switches using MON_SWITCH on
where MON SWITCH is one of the following values:
monitor value
Buffer Pool Activity Information BUFFERPOOL
Lock Information LOCK
Sorting Information SORT
SQL Statement Information STATEMENT
Table Activity Information TABLE
Take Timestamp Information TIMESTAMP
Unit of Work Information UOW
Note: Since activated monitors increase the utilisation of the CPU, you should activate
all monitors only when needed.
To get the currently activated monitor switches use the following command:
db2 get monitor switches
Date: 2007/12/18 17:23:34 12 / 20 Revision: 1.3

To get a snapshot for a database, run the following command:
db2 get snapshot for all on DBNAME >snap.out
Another way to monitor a DB2 system is db2top. You can get this utility at:
http://www.alphaworks.ibm.com/tech/db2top
8.2.1 Buffer pool analysis
A buffer pool is memory used to cache table and index data pages as they are being read
from disk, or being modified. The buffer pool improves database system performance by
allowing data to be accessed from memory instead of from disk. Because memory access
is much faster than disk access, the less often the database manager needs to read from or
write to a disk, the better the performance.
Since there is no SYSIBMADM.BP HITRATIO table in DB2 v8, I’ve written two stored proce-
dures1, for calculating the buffer pool hit ratio:
stored procedure description
bphr shows the bufferpool hit ratio of the actual
database
bphr all shows the bufferpool hit ratio of all active
databases within the instance
The stored procedure is invoked with the following command:
db2 call SPNAME
where SPNAME is the name of the stored procedure.
You can download the latest version of the stored procedures at:
http://www.evermeet.cx/cvs/db2scripts/
They are installed (after connecting to a database) with the following command:
db2 -td@ -f bphr.db2
1
see Appendix A
Date: 2007/12/18 17:23:34 13 / 20 Revision: 1.3

In DB2 9, you can either use the two stored procedures, or the following SQL statement
to get the buffer pool hit ratio:
db2 "select snapshot_timestamp, substr(db_name,1,10) as dbname,
substr(bp_name,1,18) as bufferpool, total_hit_ratio_percent as total,
data_hit_ratio_percent as data, index_hit_ratio_percent as index
from sysibmadm.bp_hitratio"
An ideal buffer pool hit ratio is above 96%. It would be well worthwhile to increase the
size of the buffer pool and see if the hit ratio increases. If the hit ratio remains low, you
may need to redesign your logical layout of your table spaces and buffer pools.
The size of the buffer pool can be changed online by the following command:
db2 alter bufferpool BPNAME immediate size NUMBER_OF_PAGES
9 Directory Server Tuning
Our measurements used IBM Tivoli Directory Server (ITDS) version 5.2 as the directory
server. The configuration details are the same of the AIX ITDS V5.2 directory server
configuration specified in the IBM WebSphere Portal Version 6.0 Tuning Guide.
Date: 2007/12/18 17:23:34 14 / 20 Revision: 1.3

10 WebSphere Portal Service Properties
WebSphere Portal has a number of configurable ”services”; each service has several pa-
rameters available to it. This section describes which services we tuned different from that
described in the IBM WebSphere Portal Version 6.0 Tuning Guide.
The only service we tuned differently was the Cache Manager Service. For this service
we accepted the defaults shipped with WebSphere Portal except for the changes listed in
the following table:
Cache Name AIX POWER4 WCM
Rendering Scenario
com.ibm.wps.ac.ExplicitEntitlementsCache.
ICM CONTENT.size
2000
com.ibm.wps.datastore.services.Identification.
SerializedOidStringCache.size
5000
com.ibm.wps.model.content.impl.ResourceCache.
lifetime
14400
Date: 2007/12/18 17:23:34 15 / 20 Revision: 1.3

A Stored Procedures - Buﬀer Pool Hit Ratio
A.1 bphr
CREATE PROCEDURE bphr ()
SPECIFIC tessus_bphr LANGUAGE SQL DYNAMIC RESULT SETS 1
BEGIN
DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr,
idx_hr, page_clean_ratio )
AS
(
SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
CASE
WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND
(pool_data_l_reads > 0 OR pool_index_l_reads > 0))
THEN
DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
ELSE
NULL
END CASE,
CAST( (CAST( pool_data_l_reads - pool_data_p_reads
AS DOUBLE)*100.0)/(pool_data_l_reads+1) AS DECIMAL(3,1)),
CAST( (CAST( pool_index_l_reads - pool_index_p_reads
AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
CAST( (CAST( pool_async_data_writes + pool_async_index_writes
AS DOUBLE)*100.0)/(pool_data_writes+pool_index_writes+1)
AS DECIMAL(3,1))
FROM TABLE(snapshot_bp(’’,-1)) AS BP
ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr
FROM bp_snap;
OPEN res;
END@
Date: 2007/12/18 17:23:34 16 / 20 Revision: 1.3

A.2 bphr all
CREATE PROCEDURE bphr_all ()
SPECIFIC tessus_bphr_all LANGUAGE SQL DYNAMIC RESULT SETS 1
BEGIN
DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr,
idx_hr, page_clean_ratio )
AS
(
SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
CASE
WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND
(pool_data_l_reads > 0 OR pool_index_l_reads > 0))
THEN
DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
ELSE
NULL
END CASE,
CAST( (CAST( pool_data_l_reads - pool_data_p_reads
AS DOUBLE)*100.0)/(pool_data_l_reads+1) AS DECIMAL(3,1)),
CAST( (CAST( pool_index_l_reads - pool_index_p_reads
AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
CAST( (CAST( pool_async_data_writes + pool_async_index_writes
AS DOUBLE)*100.0)/(pool_data_writes+pool_index_writes+1)
AS DECIMAL(3,1))
FROM TABLE(snapshot_bp(CAST(NULL AS VARCHAR(128)),-1)) AS BP
ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr
FROM bp_snap;
OPEN res;
END@
Date: 2007/12/18 17:23:34 17 / 20 Revision: 1.3

B References
WebSphere Portal Information Center:
http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html
WebSphere Application Server Information Center:
http://www.ibm.com/software/webservers/appserv/was/library/
DB2 Information Center:
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp
IBM WebSphere Portal Version 6.0 Tuning Guide:
http://www-1.ibm.com/support/docview.wss?rs=688&uid=swg27008511
IBM WebSphere Portal Version 6.0 Benchmark Results and Tuning Guide is available
by request from the WPLC Performance Team.
IBM WebSphere Portal Version 6.0 Document Manager Benchmark Results and Tuning
Guide is available by request from the WPLC Performance Team.
For additional performance-related information, consult the following resources:
WebSphere Application Server Performance information:
http://www.ibm.com/software/webservers/appserv/was/performance.html
Recommended reading list: J2EE and WebSphere Application Server
http://www.ibm.com/developerworks/websphere/library/techarticles/0305_issw/
recommendedreading.html
WebSphere Application Server Development Best Practices for Performance and Scala-
bility:
http://www.ibm.com/software/webservers/appserv/ws_bestpractices.pdf
Diagnosing Performance Problems for WebSphere Portal 5.1 (though this document was
written for WebSphere Portal 5.1, the lessons apply to WebSphere Portal 6.0 as well):
http://www.ibm.com/support/docview.wss?uid=swg27007059
IBM Developer Kit and Runtime Environment, Java(TM) 2 Technology Edition, Version
1.4.2 Diagnostics Guide
http://www-128.ibm.com/developerworks/java/jdk/diagnosis/142.html
Date: 2007/12/18 17:23:34 18 / 20 Revision: 1.3

C Credits
Thanks to the following team members of the WPLC Performance Team for contributing
to this document.
Mark Alkins, manager
Nathan Cook, report author
Rich Hall, report author
Andrew Citron
Susan Hanis
Ruthie Lyle
Denny Pichardo
Martin Presler-Marshall
Evan Thompson
Terence Walker
Laura Yen
Thanks to the following people from the IBM Toronto Lab.
Helmut K. C. Tessarek, DB2 Performance, report author
Date: 2007/12/18 17:23:34 19 / 20 Revision: 1.3

c Copyright IBM Corporation 2006-2007
IBM United States of America
Produced in the United States of America
All Rights Reserved
The e-business logo, the eServer logo, IBM, the IBM logo, IBM Directory Server, DB2, Lotus, WebSphere, POWER4
and POWER5 are trademarks of International Business Machines Corporation in the United States, other countries
or both.
Lotus and Domino are trademarks of Lotus Development Corporation and/or IBM Corporation.
The following are trademarks of other companies:
Linux is a registered trademark of Linus Torvalds.
Solaris, Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United
States, other countries or both.
Windows and Windows 2003 Enterprise Server are trademarks of Microsoft Corporation in the United States and/or
other countries
Oracle 10 and all Oracle-based trademarks and logos are trademarks of the Oracle Corporation in the United States,
other countries or both.
LoadRunner is a trademark of Mercury in the United States and/or other countries.
Other company, product and service names may be trademarks or service marks of others.
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PAPER ”AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTIC-
ULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions,
therefore, this statement may not apply to you.
Information in this paper as to the availability of products (including portlets) was believed accurate as of the
time of publication. IBM cannot guarantee that identiﬁed products (including portlets) will continue to be made
available by their suppliers.
This information could include technical inaccuracies or typographical errors. Changes may be made periodically
to the information herein; these changes may be incorporated in subsequent versions of the paper. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this paper at any time without
notice.
Any references in this document to non-IBM web sites are provided for convenience only and do not in any manner
serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this
IBM product and use of those Web sites is at your own risk.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing,
to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY, USA 10504-1785
Date: 2007/12/18 17:23:34 20 / 20 Revision: 1.3

WebSphere Portal Version 6.0 Web Content Management and DB2 Tuning Guide

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Viewers also liked

Viewers also liked (20)

Similar to WebSphere Portal Version 6.0 Web Content Management and DB2 Tuning Guide

Similar to WebSphere Portal Version 6.0 Web Content Management and DB2 Tuning Guide (20)

Recently uploaded

Recently uploaded (20)

WebSphere Portal Version 6.0 Web Content Management and DB2 Tuning Guide