Download WebSphere Portal 7 Tuning guide. - IBM developerWorks

IBM WebSphere Portal software family
Your world. Your way.
IBM WebSphere Portal 7.0
Performance Tuning Guide
IBM Collaboration Solutions Performance Team
December 2010
Document version 1
Contents
PERFORMANCE TUNING OVERVIEW ............................................................................................................................................ 1
Environment Considerations .............................................................................................................................................................. 2
32-bit and 64-bit Considerations .................................................................................................................................. 2
Hardware Multithreading (Hyper-Threading) ................................................................................................................ 3
Portal Topologies......................................................................................................................................................... 3
BASE PORTAL TUNING ................................................................................................................................................................... 6
Application Server Tuning .................................................................................................................................................. 7
JVM Initial and Maximum Heap Size............................................................................................................................ 7
JVM Heap Large Pages............................................................................................................................................... 9
JVM Heap New Area Size ......................................................................................................................................... 11
Shared Class Cache Size .......................................................................................................................................... 11
Additional JVM Arguments ........................................................................................................................................ 13
Additional SUN JVM Arguments ................................................................................................................................ 13
Additional Z/OS JVM Arguments ............................................................................................................................... 13
JVM Heap Compressed References Option on z/OS ................................................................................................. 14
JDK fixes ................................................................................................................................................................... 15
Session Timeout ........................................................................................................................................................ 15
Web Container Thread Pool Size............................................................................................................................... 16
DataSource Tuning.................................................................................................................................................... 16
Security Attribute Propagation ................................................................................................................................... 18
Internationalization Service Tuning ............................................................................................................................ 18
Disabling Tagging And Rating ................................................................................................................................... 19
Disabling Friendly URLs ............................................................................................................................................ 19
LTPA Tuning ............................................................................................................................................................. 20
Enabling Base URLs in themes ................................................................................................................................. 20
Disabling Search ....................................................................................................................................................... 21
VMM Tuning .............................................................................................................................................................. 21
ORB Service Tuning For z/OS ................................................................................................................................... 23
WebSphere Portal Services ............................................................................................................................................. 23
Navigator Service ...................................................................................................................................................... 24
Registry Service ........................................................................................................................................................ 25
Cache Manager Service ............................................................................................................................................ 26
Database Tuning ............................................................................................................................................................. 29
DB2 Database Server Tuning .................................................................................................................................... 29
Oracle Database Server Tuning................................................................................................................................. 32
Other Database Considerations ................................................................................................................................. 34
Directory Server Tuning ................................................................................................................................................... 35
Web Server Tuning .......................................................................................................................................................... 36
ii
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Plug-in Tuning.................................................................................................................................................................. 38
Operating System Tuning ................................................................................................................................................ 39
AIX ............................................................................................................................................................................ 39
Linux ......................................................................................................................................................................... 40
Windows 2003 ........................................................................................................................................................... 41
Solaris ....................................................................................................................................................................... 41
Z/OS.......................................................................................................................................................................... 44
Page Builder Theme Tuning ............................................................................................................................................................ 46
CacheManagerService Properties.................................................................................................................................... 46
Ensuring Browser Cache Works Properly for Internet Explorer ........................................................................................ 47
Reducing Redirects.......................................................................................................................................................... 47
Serving WebDAV resources ............................................................................................................................................ 48
Mashup Multipart tuning in Server Side Mode .................................................................................................................. 48
Disabling Personalization visibility rules on pages and portlets ........................................................................................ 49
Using a Caching Proxy .................................................................................................................................................... 49
Web Server Tuning .......................................................................................................................................................... 52
MANY PAGES TUNING .................................................................................................................................................................. 54
DB2 Database Tuning...................................................................................................................................................... 54
Cache Manager Service................................................................................................................................................... 55
WEB CONTENT MANAGEMENT TUNING ..................................................................................................................................... 56
Application Server Tuning ................................................................................................................................................ 56
WebSphere Portal Service Properties .............................................................................................................................. 57
Cache Manager Service ............................................................................................................................................ 57
Access control data management Service ................................................................................................................. 58
Navigation Service..................................................................................................................................................... 58
Personalization service .............................................................................................................................................. 58
WCM Object Cache ......................................................................................................................................................... 59
WCM Configuration Service ............................................................................................................................................. 59
Web Content Viewer portlet caching ................................................................................................................................ 60
JCR Text Search ............................................................................................................................................................. 62
DB2 Tuning (Authoring Environment) ............................................................................................................................... 62
Multiplatform (LUW)................................................................................................................................................... 62
Z/OS.......................................................................................................................................................................... 63
Oracle Tuning (Rendering and Authoring) ........................................................................................................................ 66
CLUSTER TUNING ......................................................................................................................................................................... 67
Application Server Tuning ................................................................................................................................................ 67
Dynacache Custom Properties .................................................................................................................................. 67
Dynamic Cache Replication ....................................................................................................................................... 68
VMM Context Pooling ................................................................................................................................................ 68
Session Persistence To Memory-Memory Tuning ............................................................................................................ 68
iii
WEBSPHERE PORTAL 7.0 TUNING GUIDE
JVM Heap ................................................................................................................................................................. 69
Session Persistence Tuning ...................................................................................................................................... 69
WAS FixPack ............................................................................................................................................................ 70
AIX Network .............................................................................................................................................................. 70
Plugin ........................................................................................................................................................................ 70
Session Persistence To Database Tuning........................................................................................................................ 70
Vertical Cluster Tuning..................................................................................................................................................... 72
OTHER PERFORMANCE TUNING OPTIONS ................................................................................................................................ 73
Nested Group Cache ....................................................................................................................................................... 73
Recording Last Login Time for Users ............................................................................................................................... 74
Optimizing Retrieval of Permissions in Access Control .................................................................................................... 74
Improving Portal Startup Performance ............................................................................................................................. 76
WebSphere Portal Development Mode ...................................................................................................................... 76
WebSphere Portal Light Mode ................................................................................................................................... 76
Managing the Retrieval of User Attributes ........................................................................................................................ 77
Identifying a Full Fetch of User Attributes .................................................................................................................. 78
Minimum Attribute Set ............................................................................................................................................... 79
Use of Dynamic Content Features ................................................................................................................................... 79
Personalization Best Practices ......................................................................................................................................... 79
Compress Content on the HTTP Server .................................................................................................................... 80
Enabling Client-Side Caching .................................................................................................................................... 81
Portlet Caching ................................................................................................................................................................ 81
Setting the Login Page to Cacheable ......................................................................................................................... 82
WEBSPHERE PORTAL CACHES ................................................................................................................................................... 83
General Information ......................................................................................................................................................... 83
Cache Configuration Properties ................................................................................................................................. 83
Cache Usage Patterns ..................................................................................................................................................... 85
Cache Instances .............................................................................................................................................................. 87
Access Control .......................................................................................................................................................... 87
Portal User Management ........................................................................................................................................... 92
Datastore................................................................................................................................................................... 93
Model ........................................................................................................................................................................ 95
URL Mappings........................................................................................................................................................... 99
Virtual Portals ............................................................................................................................................................ 99
WSRP ..................................................................................................................................................................... 100
Dynamic Assembly / Process Integration ................................................................................................................. 102
Policy ...................................................................................................................................................................... 103
Collaboration Services ............................................................................................................................................. 103
Miscellaneous.......................................................................................................................................................... 105
Example Scenarios ........................................................................................................................................................ 107
iv
WEBSPHERE PORTAL 7.0 TUNING GUIDE
General Comments ................................................................................................................................................. 107
Small Number of Pages and Small Number of Users ............................................................................................... 108
Small Number of Pages and Large Number of Users............................................................................................... 108
Portals with Long Session Timeouts ........................................................................................................................ 109
Portals with Many Pages ......................................................................................................................................... 109
WEB CONTENT MANAGEMENT CACHES .................................................................................................................................. 110
WCM Cache Instances .................................................................................................................................................. 110
WCM Item caching .................................................................................................................................................. 110
WCM Summary ....................................................................................................................................................... 111
WCM Basic Caching ................................................................................................................................................ 111
Advanced and Resources ........................................................................................................................................ 111
Session Cache ........................................................................................................................................................ 112
Menu ....................................................................................................................................................................... 112
Navigator ................................................................................................................................................................. 112
Absolute path .......................................................................................................................................................... 112
Missed Items ........................................................................................................................................................... 113
Library ..................................................................................................................................................................... 113
Library Parent .......................................................................................................................................................... 113
Draft Summary ........................................................................................................................................................ 113
User cache .............................................................................................................................................................. 113
Appendix A.
References ........................................................................................................................................................... 115
Appendix B.
Credits .................................................................................................................................................................. 116
Figures
Figure 1 Portlet Settings Screenshot ................................................................................................................................................. 60
Figure 2 Portal Access Control Cache Hierarchy .............................................................................................................................. 88
Figure 3 Portal Model Cache Hierarchy ............................................................................................................................................ 95
Tables
Table 1: Additional Sun JVM Settings ............................................................................................................................................... 13
Table 2: Database Domains ............................................................................................................................................................ 16
Table 3: WebSphere Security Attribute Propagation Settings............................................................................................................ 18
Table 4: Tagging and Rating Setting ................................................................................................................................................. 19
Table 5: Friendly URL’s Setting ........................................................................................................................................................ 19
Table 6: WebSphere Security LPTA2 Settings .................................................................................................................................. 20
v
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Table 7: VMM Context Pool Setting .................................................................................................................................................. 22
Table 8: VMM Cache Setting ............................................................................................................................................................ 22
Table 9: Navigation Service Settings ................................................................................................................................................ 25
Table 10: Registry Service Settings .................................................................................................................................................. 26
Table 11: Cache Manager Service Settings ...................................................................................................................................... 27
Table 12: Oracle Database Tuning ................................................................................................................................................... 34
Table 13: IDS Tuning ........................................................................................................................................................................ 35
Table 14: Web Server Tuning ........................................................................................................................................................... 36
Table 15: AIX Network Settings ........................................................................................................................................................ 39
Table 16: Linux Network Settings ..................................................................................................................................................... 40
Table 17: Windows Network Settings................................................................................................................................................ 41
Table 18: Solaris Network Settings ................................................................................................................................................... 41
Table 19: z/OS System Tuning ......................................................................................................................................................... 45
Table 20: CacheManager Service Settings for default portal 7 Page Builder Theme ......................................................................... 47
Table 21: Mashup Multipart Mode Setting ......................................................................................................................................... 49
Table 22: HTTP server settings for use with HTTP caching ............................................................................................................. 51
Table 23: Reverse Proxy Settings ..................................................................................................................................................... 52
Table 24: DB2 Database Settings for Many Pages ........................................................................................................................... 54
Table 25: Cache Manager Service Settings for Many Pages ............................................................................................................ 55
Table 26: Cache Manager Service Settings for WCM ....................................................................................................................... 57
Table 27: Access Control Data Management Service Settings for WCM ........................................................................................... 58
Table 28: Navigation Service Settings for WCM ................................................................................................................................ 58
Table 29: Personalization Service Setting for WCM Complex Rendering .......................................................................................... 59
Table 30: WCM Object Cache Settings ............................................................................................................................................. 59
Table 31: DB2 z/OS Bufferpool Settings ........................................................................................................................................... 63
Table 32: WebSphere Mem-Mem Session Persistence Tuning......................................................................................................... 69
Table 33: WebSphere Session Persistence Tuning .......................................................................................................................... 70
vi
WEBSPHERE PORTAL 7.0 TUNING GUIDE
1

ABOUT THIS DOCUMENT
This white paper provides a basis for parameter and application tuning for IBM WebSphere
Portal for Multiplatform, for Linux on System Z, and z/OS V7.0. Remember that both tuning
and capacity are affected by many factors, including the workload scenario and the
performance measurement environment. For tuning, the objective of this paper is not to
recommend that you use the values we used when measuring our scenarios, but to make
you aware of those parameters used in our configuration. 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.
PERFORMANCE TUNING OVERVIEW
Tuning a WebSphere Portal environment involves tuning and configuring the various
systems and components of the environment. This chapter discusses some general
concepts and details the specifics of the configuration used in our measurement
environments. These specifics entail:

Configuring the application server and the resources defined for that
application server

Tuning the database(s) and database server

Tuning the directory server and its database

Tuning the web server and/or proxy 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.
1
WEBSPHERE PORTAL 7.0 TUNING GUIDE
In addition to the tuning changes we made in our measurement environments, there are
some additional tuning options available which can improve performance in certain
circumstances; these will be discussed in a separate section.
Environment Considerations
Before beginning your install of WebSphere Portal you should consider how to use the
environment in order to achieve ideal performance. Topics to consider include:
 Choosing between 32-bit and 64-bit JVMs

Use of hardware multithreading, also known as Simultaneous Multithreading or
Hyper-Threading.

Choosing server topology to support user and system load
3 2 - B I T AN D 6 4 - B I T C O N S I D E R AT I O N S
The choice of a 32-bit or 64-bit JVM involves some trade-offs. The key advantage of a 64-bit
JVM is its vastly larger address space. Heap sizes of 2.5GB or larger can be practical on
modern server systems. This can be a significant benefit for applications with high memory
demands.
A 64-bit JVM does have disadvantages as well. Machine instructions and memory
references in a 64-bit JVM are larger than in a 32-bit JVM. This means that Java objects,
which typically contain multiple memory references, are larger in a 64-bit JVM than
compared to a 32-bit JVM. Therefore a 64-bit JVM will need a larger heap than a 32-bit JVM
for the same population of objects.
The increased size of instructions and memory references imposes a second performance
penalty. They increase the demand on the memory subsystem of the system, causing more
cache misses and a higher demand for memory bandwidth. As a result, executing a set of
operations in a 64-bit JVM can be slower than executing the same operations in a 32-bit
JVM.
When considering a deployment of WebSphere Portal 7.0, consider the memory demands
your applications will have. If you expect a high demand for memory, the best performance
will probably come from a 64-bit JVM. On the other hand, if the memory demand is lower, a
32-bit JVM is likely to give superior performance. For some newer hardware, Power6
running AIX 64-bit JVM, for example, 64-bit outperformed the 32-bit JVM. Take this into
account when considering 32-bit versus 64-bit JVMs.
2
WEBSPHERE PORTAL 7.0 TUNING GUIDE
H ARDWARE M ULTITHRE AD ING
(HYPER-THREADING)
Many modern processor architectures support hardware multithreading. For example, this is
known as Hyper-Threading (HT) on Intel processors and Simultaneous Multithreading
(SMT) on Power-series processors. Our experience is that using hardware multithreading
provides an improvement in capacity in all of the scenarios and platforms we have
measured, so we would recommend its use on platforms where this is an option.
PORTAL TOPOLOGIES
WebSphere Portal supports a variety of deployment topologies. Typical deployments will
use a three-tier configuration:

HTTP server(s).

Application server(s)

Database and directory server(s)
The primary benefit of having a multi-tiered configuration is to avoid resource contention
brought on from multiple databases and applications residing on a single server. For
example, if the database server shares a node with the application server, the combined
resource contention would negatively impact the amount of throughput achievable. On the
other hand, a small deployment may have sufficiently small resource requirements that
some of these servers could be deployed on a single node.
SINGLE-SERVER TOPOLOGY
For smaller deployments, some of these tiers may be run on a single system. For example,
a common configuration for smaller environments is to use a single node to run the HTTP
server and the application server, while the database and directory servers are still on
separate systems. This is the configuration we have used for our single-server configuration.
CLUSTER TOPOLOGY
A cluster deployment has one or more nodes in each tier. The cluster configuration we used
in our lab, as follows:
The first tier is a web server.
We used the WebSphere plugin for load balancing. The incoming client HTTP requests are
routed by the plugin to a cluster of Portal servers using the default ‘Round Robin’ load
balancing algorithm.
3
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Many clustered deployments will use multiple HTTP servers with a load balancer directing
traffic to those servers. This will provide additional capacity at the HTTP servers as well as
server failover support at the HTTP server layer.
The second tier consisted of the Portal servers and the Deployment Manager. The Portal
servers execute portlets and other application logic to handle the client requests. The
Deployment Manager coordinates all Portal server processes through a node agent process
running on each node.
Incoming HTTP requests from the web server (first tier) were routed to one of the three
Portal server nodes using the WebSphere plugin. With session affinity, the plugin will
attempt to route all requests associated with a particular session to the same node.
The third tier included all the databases: LDAP, and Portal databases. These servers
received requests from the Portal servers in the cluster.
The following diagram depicts the three-tiered cluster topology we used in our lab for LUW.
Figure 1: Portal Cluster Topology for LUW.
4
WEBSPHERE PORTAL 7.0 TUNING GUIDE
The following diagram depicts the two-tiered cluster topology we used in our lab for System
Z.
Figure 1: Portal Cluster Topology for System Z.
5
WEBSPHERE PORTAL 7.0 TUNING GUIDE
2

BASE PORTAL TUNING
The Base Portal Scenario covers user login, page navigation, and interaction with simple
portlets. Users can see a small set of pages, some of which are visible to all authenticated
users, with access to others based on their group membership.
We have also benchmarked a number of other scenarios, which focus on different functions
or use cases for WebSphere Portal. For example, there are scenarios which make use of
Web Content Management (WCM), and a scenario where users have access to thousands
of pages. While we have used different tuning to optimize performance for some of those
scenarios, the tuning is all based on the tuning done in the Base Portal Scenario. The
tuning covered in this section applies to all portal themes. For the default Page Builder
theme on Portal 7, additional tuning can be found in the Page Builder tuning section.
In all of our measurement environments, we use a separate database server and directory
server, in addition to the WebSphere Portal server. We run these servers on separate
systems to avoid resource contention on the system running the WebSphere Portal server.
This helps improve the maximum capacity achievable.
6
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Application Server Tuning
There are many aspects to configuring and tuning an application server in WebSphere
Application Server. We found that those aspects presented here were critical to a correctly
functioning and optimally performing 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-01.ibm.com/software/webservers/appserv/was/library/
How to get to Admin Console
There are two methods to get to WebSphere Administrative Console.

Start Server1 and use port 10001
1. In <WAS_root>/profiles/wp_profile/bin
2. ./startServer.sh server1
3. http://yourhost:10001/admin

Start Portal and use port 10027
1. In <WAS_Root>/profile/wp_profile/bin
2. ./startServer.sh WebSphere_Portal
3. http://yourhost:10027/ibm/console
The port numbers given above (10001 and 10027) are the port numbers in our lab
deployments, but other deployments may use different ports. To find out the ports in use for
your installation, look for ‘adminhost’ in <wp_profile root>/config/cells/<cell_name>/
nodes/<node_name>/serverindex.xml.
The following are settings based on our experience with the Base Portal workloads
described above:
JVM INITIAL AND MAXIMUM HEAP SIZE
Java Virtual Machine heap size: 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.
How-To Set: 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
See JVM Max Heap Size Limits for further discussion.
7
WEBSPHERE PORTAL 7.0 TUNING GUIDE
See instruction on How to get to Admin Console
JVM MAXIMUM 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 physical 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.
 We set the minimum and maximum heap sizes to the same values since we’re
using the generational concurrent (or ‘gencon’) garbage collection policy available
since 1.5 IBM JDK which policy helps avoid heap fragmentation.
 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.
 32-bit operating systems have an address space limit of 4GBytes, regardless of
the amount of physical memory in the system. This space limits the maximum size of
each individual process in the system. In addition, some operating systems restrict
the size of processes to be even less than this limit. Many versions of Windows limit
processes to 2GBytes in size; you can find more information at
http://support.microsoft.com/default.aspx?scid=kb;en-us;555223.
 The address space limit further restricts the size of the JVM process. If the
process grows larger than the limit imposed by the operating system, it may
terminate unexpectedly.
 After doing any heap size tuning, monitor the verbose garbage collection output
to determine if the selected heap size is appropriate. Ideally, the system should
spend no more than 5-10% of its time in garbage collection. On z/OS systems, make
sure to monitor the control region as well as the servant region(s). To understand
verbose garbage collection output, refer to Memory Analysis in IBM WebSphere Portal
Performance Troubleshooting Guide.
Due to the demands on native memory by WebSphere Portal V7.0 and its underlying
components, we chose a maximum heap size of 1408MB in our Windows environments.
There is a balance between JVM heap and native memory, all of which must fit within the
2GB restriction in 32-bit Windows. 1408MB was the largest value we could use to
successfully measure all of our Windows configurations and workloads. If your application
has additional native memory requirements then you may need to choose a smaller
maximum heap size. For more information, see the WebSphere Application Server
information center.
8
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Parameter
Initial and
Maximum
heap size
(Mbytes)
AIX
32
bit
1792
64
bit
3072
Linux
Solaris
Window
s 2003
z/Linux
2048
N/M
1408
N/M
Not
supported
3584
2560
4096
2048
N/M
z/OS
Note: N/M means “Not measured”
JVM HEAP LARGE PAGES
Large pages can reduce the CPU overhead needed to keep track of heap. With this setting
we have seen 10% throughput improvement in our measurements.
This setting does improve performance on Windows, we did not set it for our measurements because
Portal doesn’t start reliably when –Xlp is set, sometimes it may require a system reboot before
starting or restarting a jvm.
How-to Set: In the WebSphere Administrative Console: Servers  Application Servers 
WebSphere Portal  Server Infrastructure: Java and Process Management  Process Definition 
Java Virtual Machine  Generic JVM Argument. Add –Xlp.
Large pages are supported by systems running Linux kernels V2.6 or higher. See JVM
Large Page Tuning for AIX Operation System.
JVM LARGE PAGE TUNING ON AIX OPERATING SYSTEM
To use JVM Large Page, AIX operating system must be configured to support large pages.
How-To Set:
1. We use the following steps to allocate 4GB of RAM as large pages (16MB) . We chose this
amount based on having 8GB 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=256 -o lgpg_size=16777216
bosboot -ad /dev/ipldevice
reboot -q
vmo -p -o v_pinshm=1
chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE
$USER
2. Add: -Xlp command-line option as described above.
3. In the WebSphere Administrative Console: Servers  Application Servers  WebSphere
Portal  Server Infrastructure: Java and Process ManagementProcess Definition
9
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Environment Entries  New  EXTSHM=OFF (note: When EXTSHM is on it prevents use of
large page).
4. 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.
JVM LARGE PAGE TUNING ON ZLINUX OPERATING SYSTEM
To use JVM Large Page, the zLinux operating system must be configured to support huge
pages.
How-To Set:
1. We use the following steps to allocate 6GB of RAM as huge pages using the default huge
page size of 2MB. We chose this amount based on having 16GB of physical memory
available on this system. These values may need to be adjusted on systems with different
amounts of physical memory.
2. Add: -Xlp command-line option as described above.
3. In the WebSphere Administrative Console: Servers  Application Servers  WebSphere
Portal  Server Infrastructure: Java and Process ManagementProcess Definition
Environment Entries  New  EXTSHM=OFF (note: When EXTSHM is on it prevents use of
huge page).
4. To dynamically allocate the number of huge pages that are available issue command:
echo 3072 > /proc/sys/vm/nr_hugepages
(this must be set across reboots)
5. To permanently set the reboot value across reboots edit /etc/sysctl.conf and add
line: vm.nr_hugepages=3072
6. To verify if large pages are being used issue command:
grep Huge /proc/meminfo
The following information should be displayed:
HugePages_Total:
HugePages_Free:
HugePages_Rsvd:
Hugepagesize:
3072
3072
0
2048
KB
7. Restart Portal Server
Parameter
JVM Heap
Large page
AIX
-Xlp
Linux
-Xlp
Solaris
Windows
2003
Not
Applicable
Not
Applicable
10
WEBSPHERE PORTAL 7.0 TUNING GUIDE
z/Linux
-Xlp
z/OS
Not
Applicable
JVM HEAP NEW AREA SIZE
The IBM Java 5 JVM introduced a new garbage collector, the generational concurrent
garbage collector. In our measurements, we found that this garbage collector gave superior
performance, and this is enabled by default on new WebSphere Portal 7.0 installations. It is
enabled with the JVM command-line argument -Xgcpolicy:gencon. This garbage
collector can be fine-tuned by setting the size of the nursery (the space where new objects
are allocated). This is done with the –Xmn command-line option. In our scenarios, we
observed that the JVM was under-sizing the new area (Nursery) size and increasing the size
to the values recommended below increased throughput.
In Solaris, a generational garbage collector is the default, so the option
-Xgcpolicy:gencon does not apply.
How To Set: In the WebSphere Administrative Console: Servers  Application Servers 
WebSphere Portal  Server Infrastructure: Java and Process ManagementProcess Definition 
Java Virtual Machine  Generic JVM Arguments: –Xmnxxxm
Parameter
New Area
Size
AIX
32
bit
512
Linux
256
Solaris
N/M
Windows
2003
256
z/Linux
N/M
z/OS
Not
supported
N/M
768
256
682
320
64 1024
bit
Note: on Solaris, the nursery size can also be specified with the option –XX:NewSize.
“N/M” means “Not measured”.
SHARED CLASS CACHE SIZE
Class sharing in the IBM JVM offers a transparent and dynamic means of sharing all loaded
classes, both application classes and system classes. More information about this feature is
given in the IBM Java Diagnostics Guide. From the point of performance, this can reduce
the startup time for a JVM after the cache has been created. It can also reduce the virtual
storage required when more than one JVM shares the cache.
WebSphere Application Server enables class data sharing by default, and sets the size of
this cache to 50MB. Many WebSphere Portal applications will have more than 50MB of
shared class data, so an additional benefit can be achieved by increasing this cache size.
We found that about 75MB was in use after starting the portal, so we used a shared class
cache size of 120MB to allow room for additional applications. We also saw that by
11
WEBSPHERE PORTAL 7.0 TUNING GUIDE
increasing the size of the shared class cache, our performance results were more
repeatable across multiple measurements, particularly on AIX.
The shared class cache persists until it is destroyed, thus you must destroy it first if you are
to change its size.
How to Set:
1. In the WebSphere Administrative Console: Servers  Application Servers  WebSphere
Portal  Server Infrastructure: Java and Process ManagementProcess Definition  Java
Virtual Machine  Generic JVM Arguments: –Xscmxnnnm
Parameter
Cache
size
AIX
32
bit
120
64
bit
150
Linux
Solaris
Windows
2003
Not used
Not used
Not used
N/M
Not used
120
z/Linux
z/OS
Not
used
2. Delete the cache
a. Stop Portal server, and WAS server1. Then go under <AppServer root>/java/bin
b. Run the following command,
For aix:
java -Xshareclasses:name=webspherev70_%g,groupAccess,destroy
For windows:
java -Xshareclasses:name=webspherev70,groupAccess,destroy
You will see this message:
JVMSHRC010I Shared cache "webspherev70_system" is destroyed.
Could not create the Java virtual machine.
3. Start Portal Server
4. Check cache size in use,

java -Xshareclasses:name=webspherev70_%g,groupAccess,printStats
12
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ADDITIONAL JVM ARGUMENTS
On all 64 bit platforms we recommend the use of -XX:MaxDirectMemorySize=256000000
to avoid excessive garbage collections. Please note that this JVM argument must be
specified exactly as shown above.
ADDITIONAL SUN JVM ARGUMENTS
On the Solaris platform, we use the following Java HotSpot parameters to achieve optimum
performance.
Table 1: Additional Sun JVM Settings
Parameter
Value
-server
-XX:MaxPermSize
Offers higher throughput than the "client" mode.
768m
-XX:+UseConcMarkSweepGC
-XX:SurvivorRatio
Use concurrent mark-sweep collection for the tenured
generation. The application is paused for short periods
during the collection; we found this collector works best
in Portal.
6
-XX:+UseParNewGC
-XX:ParallelGCThreads
Additional Information
By default concurrent low pause collector uses the
default, single threaded young generation copying
collector. Set this parameter to use parallel young
generation collector for new area.
5
Reduces the number of garbage threads. On the Chip
multithreading processor based system, we set the
threads no higher than one quarter of the hardware
threads. We also distribute the threads for 6 JVMs. Our
system has 128 virtual processors, we set a total of
(128/4)=32 GC threads across all the JVMs. So 5 or 6
GC threads per JVM.
-XX:+PrintGCDetails
Print more details at garbage collection. This does not
improve performance, but it provides additional
information related to garbage collection activity, which
is useful in tuning garbage collection.
-XX:+PrintGCTimeStamps
Print timestamps at garbage collection. See above.
ADDITIONAL Z/OS JVM ARGUMENTS
WebSphere Application Server on z/OS has at least three JVMs:
13
WEBSPHERE PORTAL 7.0 TUNING GUIDE
1. Controller Region is used to requeue the requests to the Servant Region with the
help of WLM.
2. Servant Region runs the application (Portal) code.
3. Adjunct Region is an optional JVM but is automatically configured for Portal
configuration. It contains the JMS Engine.
For optimum performance it is necessary to allocate sufficient heap sizes to all the JVM
regions. Servant region Heap Size is discussed in previous topics.
Controller Region Initial and Maximum Heap Size
How-To Set: In the WebSphere Administrative Console: Servers  Application Servers 
WebSphere Portal  Server Infrastructure: Java and Process Management Process Definition
 ControlJava Virtual Machine
- Initial Heap Size =1024
- Maximum Heap Size = 1024
Adjunct Region Initial and Maximum Heap Size
How-To Set: In the WebSphere Administrative Console: Servers  Application Servers 
WebSphere Portal  Server Infrastructure: Java and Process Management Process
Definition  Adjunct Java Virtual Machine
- Initial Heap Size =1024
- Maximum Heap Size = 1024
JVM HEAP COMPRESSED REFERENCES OPTION ON Z/OS
Compressed references option provides the performance benefit when running with a Heap
Size of 2GB or more. It is enabled by setting –Xcompressedrefs option in the JVM
Environment Entries. When the –Xcompressedrefs option is specified with a –Xmx value
less-than 30 GB, the JVM will try to allocate the Java heap in the 2^31 to 2^35 virtual range.
To enable a 64-bit JVM to run in the compressed references mode, you need to specify a
new environment variable in WebSphere Application Server configuration:



In the administrative console, click: Servers > Server Types > WebSphere application
servers > server_name.
Click the Configuration tab, and then under Server Infrastructure section, click Java
and process management > ProcessDefinition > servant.
Then in the additional properties section, click Environment entries.
Add/update the environment entry for IBM_JAVA_OPTIONS as follows.
14
WEBSPHERE PORTAL 7.0 TUNING GUIDE



If you see an existing environment entry named IBM_JAVA_OPTIONS, edit it to
append the Java option –Xcompressedrefs to the existing value.
Otherwise, click New to create a new environment entry.
Fill in following values in their respective fields of the form:
Name: IBM_JAVA_OPTIONS
Value: -Xcompressedrefs
Description: Enable 64-bit Compressed References mode


Click Apply to update the WebSphere Application Server environment.
Restart WebSphere Application Server to start WebSphere Application Server in
compressed references mode.
JDK FIXES
For any 64 bit platform running Portal using Java 6 SR7 we recommend that the following
fixes be applied to avoid issues with the JIT code cache becoming full:
• APAR IZ73637: increases the default JIT code cache size to 128MB
• APAR IZ69136: disables the Java Interpreter Profiler (JIP) when the JIT code cache is full
The above APARs have been incorporated into Java 6 SR8.
SESSION TIMEOUT
Session timeout: The default value of Session Timeout is 30 minutes. Reducing this
value to a lower number can help reduce memory consumption requirements, allowing a
higher user load to be sustained for longer periods of time. Reducing the value too low can
interfere with the user experience.
For Solaris, on a T5240 platform, we used a much lower think time, 5 seconds, than was
used for other platform hardware measurement of 12 seconds. With a lower think time,
fewer virtual users will result in a heavier load on the system. The reason we lowered the
think time was specifically to decrease the number of virtual users required for this
measurement. Our pool of LoadRunner virtual user licenses was inadequate to generate
enough load with the higher think time. With a shorter think time than is used in the other
measurements, the duration of each virtual user's interaction with the site is shorter by
approximately 2 minutes. To compensate for this, and keep the sessions live on the server
for the same period of time, we increased the session timeout by 2 minutes, to 12 minutes.
How to Set: In the WebSphere Administrative Console: Servers  Application Servers 
WebSphere Portal  Container Settings: Web Container Settings  Session Management
 Session Timeout  Set Timeout
15
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Parameter
AIX
10
minutes
Session
timeout
Linux
Windows
2003
Solaris
10
minutes
12
minutes
WEB CONTAINER THREAD
10
minutes
z/Linux
10
minutes
z/OS
10
minutes
POOL SIZE
Servlet engine thread pool size: Set this value and monitor the results. Increase this value if
all the servlet threads are busy most of the time.
How to Set: In the WebSphere Administrative Console: Servers  Application Servers 
WebSphere Portal  Additional Properties: Thread Pools Web Container  Thread Pool
- Minimum size threads - Maximum size threads
Parameter
Web Container
Thread pool
size
AIX
50
Linux
50
Solari
s
50
Windows
2003
50
z/Linux
50
z/OS
50
D AT A S O U R C E T U N I N G
Multiple databases are used to hold information in WebSphere Portal V7.0. We used six
separate databases on DB2, each representing a separate database domain and having
their own datasources. These are:
Table 2: Database Domains
Database
Release
Community
Customization
Feedback
Likeminds
JCR
Database name
Datasource name
release
community
reldbDS
commdbDS
custom
fdbkdb
lmdb
jcrdb
cusdbDS
fdbkdbDS
lmdbDS
jcrdbDS
On Oracle, we built a single database and create Oracle users to own the tables and data
needed to support each domain. The domains are the same as above.
All datasources are configured in a similar manner. The default settings were used for the
prepared statement cache size.
16
WEBSPHERE PORTAL 7.0 TUNING GUIDE
How to Set: In the WebSphere Administrative Console: Resources  JDBC Providers 
provider name  Data Sources  datasource name  WebSphere Application Server data
source properties  Statement cache size.
The provider name and datasource name are based on the names selected for that
database during the database transfer step.
Parameter
Statement
cache size
AIX
10
Linux
10
Solaris
10
Windows
2003
10
z/Linux
10
z/OS
10
The default settings were used for the connection pool minimum and maximum sizes for the
Base Portal Scenario. For WCM, higher min/max connection pool sizes are needed. Higher
connection pool sizes may also be needed in other cases, such as using parallel portlet
rendering or a larger WebContainer thread pool. In all cases, we recommend monitoring the
database connection pools and increasing their maximum sizes if the pool is completely
utilized.
How to Set: In the WebSphere Administrative Console: Resources  JDBC Providers 
provider name  Data Sources  datasource name  Connection pool properties 
Maximum/Minimum connections.
Parameter
Max/Min
connections
AIX
Linux
Solaris
Windows
2003
z/Linux
z/OS
50/10
50/10
50/10
50/10
50/10
50/10
Be aware that specifying a larger statement cache size can lead to OutOfMemory errors in
situations where your application memory is already being highly utilized by your workload.
Also, in some workloads, increasing the prepared cache statement size will be of no benefit.
For instance, on WCM workloads, due to the dynamic nature of the SQL statements
generated against the JCR database the cache size would have to be very large to cover all
of the different permutations and the hit rate would be very low. In such cases, it is better to
decrease the size of the cache to free up memory resources.
Finally, the prepared statement cache size setting is the maximum allowed cache entries
per database connection so increasing the cache size on a datasource that has a large
number of connections can quickly amplify the heap utilization for these cache objects. Any
changes should be considered for each individual datasource independently instead of
across all datasources globally. Before increasing a datasource's prepared statement cache
size you should monitor your memory usage under a heavy workload to determine if there
are enough memory resources available to handle an additional increase.
17
WEBSPHERE PORTAL 7.0 TUNING GUIDE
S E C U R I T Y AT T R I B U T E P R O PA G AT I O N
To reduce the Security Attribute Propagation (SAP) overhead, please use a custom property
'disable Callerlist'. If SAP is not used, you can disable that, to remove the extra overhead to
improve the login performance.
If WebSphere Subject has not been customized, for example through Trust Association
Intercepter (TAI) or a custom WAS login module, then there is no need to enable Security
Attribute Propagation. Security Attribute Propagation can add extra overhead due to some
extra processing that is required. However, there are certain configurations where
performance might be better with security propagation enabled due to reduction of remote
registry calls. See the WebSphere 7.0 InfoCenter (search for 'security attribute propagation')
for a discussion of when propagating security attributes is desirable. If you want to enable
SAP for functional reasons, you can improve the performance with CallerList tuning
mentioned below.
These settings apply to all platforms.
How to Set: In the WebSphere Administrative Console: Security  Secure Administration,
Applications, and Infrastructure  Custom properties
Table 3: WebSphere Security Attribute Propagation Settings
Security Attribute
Name
Propagation
com.ibm.CSI.disablePropagationCallerList
Value
true
Create a new custom property named, com.ibm.CSI.disablePropagationCallerList,
and set its value as true.
I N T E R N AT I O N A L I Z AT I O N S E R V I C E T U N I N G
An internationalized application can be configured to interact with users from different
regions in culturally appropriate ways. The internationalization service enables you to
configure and manage an internationalization context for an application for which
components are distributed across the enterprise. However if you do not need this feature
you can reduce the overhead by disabling it.
How to Set: In the WebSphere Administrative Console Servers  Application Servers 
WebSphere Portal  Container Services: Internationalization Service  uncheck “Enable
service at server start up”
These settings apply to all platforms.
18
WEBSPHERE PORTAL 7.0 TUNING GUIDE
D I S AB L I N G TAG G I N G AN D R AT I N G
If you are not using Tagging and Rating services they can be disabled. In our results,
disabling this improved capacity by 3%. They are disabled by setting the following
parameters.
How to Set: In the WebSphere Administrative Console Servers  Resources  Resource
Environment  Resource Environment Providers  WP_CPConfigurationService
Table 4: Tagging and Rating Setting
Default Value
com.ibm.wps.cp.tagging.isTaggingEnabled
com.ibm.wps.cp.rating.isRatingEnabled
Value
True
True
False
False
D I S AB L I N G F R I E N D LY U R L S
Friendly URLs enhance the end-user’s experience by placing a meaningful name in the
browser’s address field. However, there is a cost for using friendly URLs. In our results,
disabling friendly URLs improved capacity by 2% or more depending on the theme.
If you are using Blogs and Wikis, or WCM content pages, do not set friendly.enabled
or friendly.pathinfo.enabled to false. For further discussion of this see http://www10.lotus.com/ldd/portalwiki.nsf/dx/Working_with_friendly_URLs_for_web_content_lwcm7
To fully use friendly URLs, pages must be configured with friendly names.
Friendly URLs can be disabled by setting the following parameters.
How to Set: In the WebSphere Administrative Console Servers  Resources  Resource
Environment  Resource Environment Providers  WP_ConfigService
Add the following custom properties.
Table 5: Friendly URL’s Setting
Default Value
friendly.enabled
friendly.pathinfo.enabled
True
True
Value
False
False
Setting friendly.enabled to false, turns off Portal’s use of friendly URLs.
Setting friendly.pathinfo.enabled to false turns off WCM’s use of friendly URLs. If
WCM is not used in an installation, and friendly names are used by portal, it is still
advantageous to set friendly.pathinfo.enabled to false.
19
WEBSPHERE PORTAL 7.0 TUNING GUIDE
LT PA TUNING
LTPA tokens are used by WebSphere as part of the authentication process. Calculating the
cryptographic signature for an LTPA token is an expensive operation which can be improved
by installing PM16589 and setting the following custom security property. This change will
cause no functional impact.
How to Set: In the WebSphere Administrative Console: Security Global Security  Custom
properties
Table 6: WebSphere Security LPTA2 Settings
Security LTPA
Name
Value
com.ibm.ws.security.ltpa.useCRT
True
Create a new custom property named, com.ibm.ws.security.ltpa.useCRT, and set its
value as true.
ENABLING BASE URLS IN THEMES
Enabling base URLs reduces redirects and URL-generation computations. This benefit is
seen on the default themes shipped with Portal 6.1.5 and Portal 7.0, as well as themes
derived from those.
When enabling base URLs, in many configurations host.name needs to be set in
WP_ConfigService. The host.name should be set to the value that an end user knows
portal as. For example if a reverse proxy is used, or virtual portals are used, the
host.name in WP_ConfigService should be the name of the reverse proxy or virtual portal.
How to Set: In the command prompt use XMLAccess tool to import the xml input file as shown
below
Windows: xmlaccess.bat -in redirectOff.xml -user wpsadmin -password
wpsadmin -url http://<hostname>:10039/wps/config
Unix: ./xmlaccess.sh -in redirectOff.xml -user wpsadmin -password
wpsadmin -url http://<hostname>:10039/wps/config
Contents of redirectOff.xml for enabling basehref with default Page Builder theme from
Portal 6.15:
<?xml version="1.0" encoding="UTF-8"?>
<request build="wpnext_372_01" type="update" version="7.0.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd">
20
WEBSPHERE PORTAL 7.0 TUNING GUIDE
<portal action="locate">
<theme action="update" uniquename="ibm.portal.theme.enhanced">
<parameter name="com.ibm.portal.theme.hasBaseURL"
type="string" update="set">true</parameter>
</theme>
</portal>
</request>
Contents of redirectOff.xml for enabling basehref with the default Page Builder theme
from Portal 7.0:
<?xml version="1.0" encoding="UTF-8"?>
<request build="wpnext_372_01" type="update" version="7.0.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd">
<portal action="locate">
<theme action="update" uniquename="csa2.theme">
<parameter name="com.ibm.portal.theme.hasBaseURL"
type="string" update="set">true</parameter>
</theme>
</portal>
</request>
DISABLING
SEARCH
Search can be disabled to improve performance if the search feature is not needed.
How to Set: In the WebSphere Portal Admin Page  Search Administration/Manage
Search  Search Collections  Delete all collections
VMM TUNING
VMM CONTEXT POOL
Tune VMM Context Pooling to improve the performance of concurrent access to an LDAP
server.
We changed the following Context Pooling settings line in:
<wp_profile_root>/config/cells/<cellname>/wim/config/wimconfig.xml
<config:contextPool enabled="true" initPoolSize="10" maxPoolSize="30"
poolTimeOut="0" poolWaitTime="3000" prefPoolSize="30"/>
21
WEBSPHERE PORTAL 7.0 TUNING GUIDE
You can also set them via the administrative console as described in
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/
aes/ae/uwim_ldapperfsettings.html
Table 7: VMM Context Pool Setting
Context Pool
Default Value
Setting
Value
initPoolSize
1
10
prefPoolSize
3
30
maxPoolSize
20
30
Additional Details
Number of open connections to maintain to LDAP server.
We use 40 in AIX Power6 64-bit measurements.
A value of 0 allows the pool to grow as large as needed. If
access to the LDAP server is shared by many systems,
this setting may allow an excessive number of connections
to the LDAP server; in such a case, set the maximum pool
size to a value appropriate to your environment.
We use 40 in AIX Power6 64-bit measurements.
VMM SEARCH RESULTS CACHE
Tune VMM search results cache to improve the performance of VMM search.
We changed the following searchResultsCache settings line in:
<wp_profile_root>/config/cells/<cellname>/wim/config/wimconfig.xml
<config:searchResultsCache cacheSize="4000" cacheTimeOut="600"
enabled="true" searchResultSizeLimit="1000"/>
Table 8: VMM Cache Setting
VMM Cache
Setting
cacheSize
Default
Value
2000
Value
4000
Additional Details
We use 5000 for AIX Power6 64-bit
measurements.
22
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ORB SERVICE TUNING FOR Z/OS
As in our Benchmark Scenario the portal application doesn't connect to any remote
database or transaction manager systems we were able to get best throughput with
minimum number of Threads. In your environment if the application connects to any remote
system then you need to configure the number of ORB threads accordingly. You should
have enough threads to drive the CPU Utilization up as the load increases.
We used CUSTOM workload profile in ORB Container Services and defined the number of
ORB threads by using servant_region_custom_thread_count property defined under
WebSphere variables.
Setting Workload Profile Type




In the administrative console, click: Servers  Server Types  WebSphere
application servers  server_name.
Under Container Settings  Container Services  Click ORB Service
Under Additional Properties  Click z/OS additional settings
Under Workload Profile  Select Workload Profile type as CUSTOM  Click Apply
Setting number of ORB Threads




In the administrative console, Under Environment  Click WebSphere Varaibles
Select scope as the Portal Server
Define New or update existing Variable servant_region_custom_thread_count and
set the value equal to the number appropriate for your environment. Maximum of 100
threads can be configured per Servant.
Click Apply and restart the server
WebSphere Portal Services
WebSphere Portal has a number of configurable “services”; each service has several
parameters available to it. This section describes which services we tuned, the tuning values
used, and the rationale for those changes.
How to Set:
1. Edit <wp_profile_root>/PortalServer/config/properties/xxxService.properties
2. uncomment the line, then change the size.
3. run <wp_profile_root>/ConfigEngine/ConfigEngine.sh update-properties
The changes should appear on WebSphere Integrated Solutuions Console, under the path
Resources  Resource Environment  Resource Environment Providers  WP_xxxService
 Custom properties
23
WEBSPHERE PORTAL 7.0 TUNING GUIDE
N AV I G AT O R S E R V I C E
The navigator service manages the content model for unauthenticated users, which controls
the pages those users are able to see. This content model is periodically reloaded by
WebSphere Portal; new pages which are visible to unauthenticated users will not be
available until the next reload occurs. Our environment assumes a low rate of change for
pages, so we set this reload to only occur once per hour. In a production environment where
new pages for unauthenticated users are rarely created, setting this reload time to an hour
or more will give better performance. In a test or staging environment where updates to
unauthenticated pages need to be seen more often, a lower reload time is more appropriate.
This service also controls the HTTP cache-control headers which will be sent on
unauthenticated pages. While our environment did not exploit HTTP page caching,
increasing these cache lifetimes in a production environment can reduce load on the portal.
For more discussion of the use of HTTP cache-control headers with WebSphere Portal,
refer to the “Caching” section of the “Tuning” topic in the WebSphere Portal V7.0 InfoCenter.
24
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Table 9: Navigation Service Settings
NavigatorService.properties
Parameter
Default
Value
Value
Used
Definition
public.expires
(seconds)
60
3600
Determines cache expiration time for
unauthenticated pages in browser caches and
proxy caches. If the setting
remote.cache.expiration is also set to a value
greater than or equal to 0, the smaller one of the
two values is used.
public.reload
(seconds)
60
3600
WebSphere Portal maintains an internal cache
of the list of pages visible to unauthenticated
users, and the arrangement of portlets on those
pages. This controls how frequently that internal
cache is refreshed. Note, however, that this is
not caching the content of those pages – simply
their layout.
remote.cache.
expiration
(seconds)
10800
28800
Determines cache expiration for caches outside
of portal server for authenticated as well as for
unauthenticated pages
REGISTRY SERVICE
WebSphere Portal maintains information about many resource types in its databases. Some
of these resources are replicated into memory for faster access; this is provided by the
registry service. This replicated information will be periodically reloaded from the database,
thus picking up any changes which may have been made on a peer node in a clustered
environment.
The registry service allows configuring a reload time, in seconds, for each type of data which
it is managing. In a production environment, we expect this type of information changes very
infrequently, so we used very long reload times for the registry service. These values do not
include a size parameter as they are a full replication of the database. A full list of the types
of information managed by the registry service is in table 7.
25
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Table 10: Registry Service Settings
RegistryService.properties
Parameter
Default
Value
Value
Used
Definition
default.interval
1800
28800
Reload frequency for any object types not
explicitly specified in the file.
bucket.theme.interval
3000
28800
Reload frequency for theme definitions
bucket.skin.interval
3500
28800
Reload frequency for skin definitions
bucket.client.interval
19000
28800
Reload frequency for client definitions
bucket.markup.interval
20000
28800
Reload frequency for markup definitions
bucket.transformation
application.interval
600
28800
Reload frequency for transformation
application definitions
bucket.transformation.
interval
600
28800
Reload frequency for transformation
definitions
CACHE MANAGER SERVICE
The cache manager service in WebSphere Portal is used to cache a wide variety of types of
information in memory. These caches are somewhat similar to the registries maintained by
the registry service, as each type of information gets its own cache. The key differences are:

The information stored in the cache manager service’s caches tends to be
more dynamic than the information stored in the registry service’s registries.

The caches used by the cache manager service are limited in size, and
entries will be discarded when the caches become full. The registries used by the
registry service are not size-limited; they contain all entries of the specific data type.

Expiry times are managed individually for each entry in the cache, managed
by the cache manager service. In contrast, when the reload time is reached for a
registry, the entire contents of that registry are reloaded.
Each cache has several configurable options. A full discussion of these options, along with a
list of the caches in WebSphere Portal V7.0, is given in chapter 2. Table 8 lists the changes
which we made to the cache manager service configuration file. Size values are specified in
“number of objects” and lifetime values are specified in “seconds”.
26
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Table 11: Cache Manager Service Settings
CacheManagerService.properties
Default
Value
2000
Value
Used
2600
cacheinstance.com.ibm.wps.spa.parser.theme.
ThemeParserCache.enableDiskOffload
cacheinstance.com.ibm.wps.spa.parser.skin.
SkinParserCache.enableDiskOffload
cacheinstance.com.ibm.wps.spa.parser.locale.
LocalizationParserCache.enableDiskOffload
cacheinstance.com.ibm.wps.services.vpmapping.
HostnameToVirtualPortalIDCache.lifetime
cacheinstance.com.ibm.wps.resolver.service.
PortalPocBootstrapService.enableDiskOffload
cacheinstance.com.ibm.wps.resolver.service.
PocServiceOnRequestImpl.cache.enableDiskOffload
cacheinstance.com.ibm.wps.resolver.data.cache.
DataSourceCache.enableDiskOffload
cacheinstance.com.ibm.wps.puma.OID_User_Cache.size
TRUE
FALSE
TRUE
FALSE
TRUE
FALSE
3600
-1
TRUE
FALSE
TRUE
FALSE
TRUE
FALSE
1500
3000
cacheinstance.com.ibm.wps.puma.OID_Group_Cache.size
500
1500
cacheinstance.com.ibm.wps.puma.OID_DN_Cache.size
cacheinstance.com.ibm.wps.puma.DN_User_Cache.size
1500
1500
3000
3000
cacheinstance.com.ibm.wps.puma.DN_OID_Cache.size
1500
10000
cacheinstance.com.ibm.wps.puma.DN_Group_Cache.size
500
6000
cacheinstance.com.ibm.wps.policy.services.
PolicyCacheManager.lifetime
cacheinstance.com.ibm.wps.pe.portletentity.size
cacheinstance.com.ibm.wps.pe.portletentity.lifetime
7780
43200
10000
5800
20000
28800
Cache Name
cacheinstance.com.lotus.cs.services.UserEnvironment.size
cacheinstance.com.ibm.wps.model.factory.
ContentModelCache.live.size
cacheinstance.com.ibm.wps.datastore.services.
Identification.SerializedOidString.cache.size
cacheinstance.com.ibm.wps.ac.RolesCache.size
2500
5000
10000
20000
cacheinstance.com.ibm.wps.ac.RolesCache.enabled
FALSE
TRUE
cacheinstance.com.ibm.wps.ac.ProtectedResourceCache.
lifetime
cacheinstance.com.ibm.wps.ac.PermissionCollectionCache.
lifetime
cacheinstance.com.ibm.wps.ac.OwnedResourcesCache.enabled
10143
14400
10240
-1
TRUE
false
cacheinstance.com.ibm.wps.ac.ExternalOIDCache.lifetime
8640
-1
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.
USER_GROUP.size
1000
2000
27
WEBSPHERE PORTAL 7.0 TUNING GUIDE
3000
cacheinstance.com.ibm.wps.ac.ChildResourcesCache.
lifetime
cacheinstance.com.ibm.workplace.searchmenu.helper.
SearchMenuCacheHelper.replacement
cacheinstance.DigestCache.cache.size
7200
28800
moderate
25000
We made the following changes from the settings above in our AIX Power6 environment.
We expect these will improve performance in environments using modern processors (such
as Power6 or Power7 processors).
Cache Name
cacheinstance.com.lotus.cs.services.UserEnvironment.size
Default
Value
2000
Value
Used
4000
cacheinstance.com.ibm.wps.puma.OID_User_Cache.size
1500
5000
cacheinstance.com.ibm.wps.puma.OID_Group_Cache.size
cacheinstance.com.ibm.wps.puma.OID_DN_Cache.size
500
1500
2000
5000
cacheinstance.com.ibm.wps.puma.DN_User_Cache.size
1500
5000
cacheinstance.com.ibm.wps.puma.DN_Group_Cache.size
500
10000
cacheinstance.com.ibm.wps.pe.portletentity.size
cacheinstance.com.ibm.wps.model.factory.
ContentModelCache.live.size
cacheinstance.DigestCache.cache.size
10000
40000
10000
28
WEBSPHERE PORTAL 7.0 TUNING GUIDE
40000
Database Tuning
D B 2 D AT A B A S E S E R V E R T U N I N G
WebSphere Portal V7.0 uses database servers for core functionality. In our measurement
environment, we used DB2 database server for the Portal application. The LDAP server,
IBM Tivoli Directory Server also included a DB2 database as a repository, but it is largely
unseen and was operated as an out of box configuration.
We recommend using a remote database server for the largest capacity. For our
measurements we used IBM DB2 Enterprise Edition V9.7 fixpack 1 as our database server.
WebSphere Portal V7.0 uses the concept of Database domains to designate either groups
of tables belonging to one domain, or even entirely separate databases to store the data
specific to each domain.
We built six separate databases within one database server to house the tables and data
needed to support each domain. For the Base Portal and Many Pages measurements, the
Release domain is the primary database being exercised.
The databases and related domains supported by Portal V7.0 are:
1. Release (release domain). This is the primary database domain used by the Base
Portal and Many Pages Scenarios.
2. Customization (customization domain).
our scenarios.
This database receives some light traffic in
3. Community (community domain). This database receives some light traffic in our
scenarios.
4. JCR (JCR domain). JCR database is used heavily in WCM (Web Content
Management) Scenario. This database receives light traffic in all other scenarios
measured in our Benchmark report.
5. Likeminds database, used for Likeminds enabled systems. This database is not used
in the scenarios measured in our Benchmark report.
6. Feedback database, used by the feedback subsystem. This database is not used in
the scenarios measured in this report.
DB2 ON AIX SETUP
We configure our DB2 database on AIX using the following setup,
29
WEBSPHERE PORTAL 7.0 TUNING GUIDE

Set the filesystem which will hold the Portal databases to be a Enhanced
Journal File System (JFS2) because a large file system is limited to 64GB.

Turn on concurrent I/O (CIO) for Enhanced Journal File System as this improves
performance.
To enable CIO, use the following command to mount the database filesystem.
mount –o cio /portaldb

Increase AIX maximum number of processes per user to 4096.
The default 500 processes per user is too low for database server, we increase
it to 4096 in our AIX environment. To increase it,
chdev –l sys0 –a maxuproc=‟4096‟
While the Portal databases are configured for high capacity performance, various tuning
adjustments may be necessary from time to time. Typically these tuning needs are based
on the volume of database traffic and the size of table populations.
Our database tuning settings is documented in the Portal Info Center under ‘Creating
Remote Database’ section.
DB2 ON Z/OS SETUP
After transferring the database tables, first Identify what tables need to be reorganized.
Perform a re-org check to improve performance.

Run the EJPSDBTC job after database transfer. This job contains the DB2
check and RUNSTATS utility for the JCR, Likemind and Feedback database.

For details on re-org DB2 database, visit WebSphere Portal Info Center.
Create a Re-org job to re-org all table spaces in WPSDBJCR database.
RECOMMENDED DATABASE MAINTENANCE FOR DB2 LUW
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 population 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
30
WEBSPHERE PORTAL 7.0 TUNING GUIDE
the statistical details about tables, indexes and columns. We have used two techniques
in our environment to recompute 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 recomputing 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"
The first command is used to create a file, runstats.db2, which contains all of the
runstats commands for all of the tables. The second command uses the db2 command
processor to run these commands.
To determine which tables might benefit from reorganization, we use the command:
db2 reorgchk current statistics on table all
> "reorgchk.txt"
For those tables which require reorganization, we use the command:
db2 reorg table tableschema.tablename
to reorganize the table based upon its primary key.
You should also ensure that your database servers have adequate numbers of disks.
Multiple disks allow for better throughput by the database engine. Throughput is also
improved by separating the database logs onto separate physical devices from the
database.
31
WEBSPHERE PORTAL 7.0 TUNING GUIDE
You should ensure that the database parameter MaxAppls is greater than the total
number of connections for both the datasource and the session manager for each
WebSphere Portal application server instance. If MaxAppls is not large enough, you will
see error messages in the Portal logs.
You should use System Managed Storage (SMS) for temporary table spaces to benefit
complex SQL which require temporary tables to compute their result sets. This saves
time in buffer writes and improves disk utilization.
Database performance is very important for obtaining good performance from
WebSphere Portal. The maintenance tasks and practices mentioned here were found
to be critical to the performance and correct operation of WebSphere Portal in our lab
environment. Additional database maintenance and tuning may be needed in your
production environments. For further information on DB2 administration and tuning,
refer to the DB2 Information Center.
O R A C L E D AT A B A S E S E R V E R T U N I N G
WebSphere Portal V7.0 uses database servers for core functionality. In this measurement
environment, we used Oracle database server for the Portal application. The LDAP server,
IBM Tivoli Directory Server included a DB2 database as a repository.
PLANNING FOR ORACLE ENTERPRISE EDITION DATABASE
For our Solaris platform measurements we also used Oracle 10g R2 as our database
server. WebSphere Portal V7.0 uses the concept of Database domains to designate either
groups of tables belonging to one domain, or even entirely separate databases to store the
data specific to each domain.
On Oracle, we built a single database and create Oracle users to own the tables and data
needed to support each domain. The domains are listed in PortalDatabaseDomain, above. For
the Base Portal measurements, the Release domain is the primary database being
exercised.
A well designed database can save a lot of trouble later down the road, and improve
database performance. We recommend that you refer to the Oracle Administrator’s
Guide to help you make informed database design decisions. Here are the key choices
we have implemented in our Oracle database.

To avoid I/O contention and allow for better throughput, you should ensure your
database server have adequate number of disks. Our database is on seven stripped
disks.

For better management and performance of storage structures, Oracle-Managed
Files are used for database, as well as redo logs, and control files.

Database block size: 8k
32
WEBSPHERE PORTAL 7.0 TUNING GUIDE

The following tablespace sizing was required to support roughly a medium sized
Portal, with 100,000 authenticated users, approximately 180 installed portlets and
220 pages, which the load generally consisting of database read operations. We
recommend monitoring your tablespace sizing and growth on a regular basis. We
used DBCA to create database with the following Tablespace size:
o SYSAUX: 800MB
o SYSTEM: 800MB
o TEMP: 800MB
o UNDOTBS: 1024MB
o USERS: 2048MB

Redo log groups: 500MB each.
ORACLE ON AIX SETUP
We configure our Oracle database on AIX using the following setup,

Set the filesystem which will hold the Portal databases to be a Enhanced
Journal File System (JFS2).

Turn on concurrent I/O (CIO) for database filesystem as this improves
performance. Do not enable CIO for Oracle product filesystem, ie, /u01, as
Oracle could fail to start.
To enable CIO, use the following command to mount the database fileset.
mount –o cio /u02

Increase AIX maximum number of processes per user to 4096.
The default 500 processes per user is too low for database server, we increase
it to 4096 in our AIX environment. To increase it,
chdev –l sys0 –a maxuproc=‟4096‟

Enable AIX async I/O, and increase MinServer to 5.
smitty aio  Change/Show Characteristics of Async I/O 
MinServers = 5

We also set in oracle user’s profile as Oracle Installation Guide for AIX
recommends,
AIXTHREAD_SCOPE=S
ORACLE ENTERPRISE EDITION DATABASE PARAMETER TUNING
Database performance is very important for obtaining good performance from WebSphere
Portal. Below is a list of tuning applied on our Oracle database server with the alter system
command. Additional database tuning maybe needed in your production environments. For
33
WEBSPHERE PORTAL 7.0 TUNING GUIDE
further information on Oracle database tuning, refer to Oracle Performance Tuning Guide at
http://www.oracle.com/technology/documentation/database10g.html.
Command used:
Alter system set <parameter> scope=spfile;
Table 12: Oracle Database Tuning
Parameter
Value
sessions
900
sga_target
1813M
pga_aggregate_target
604M
processes
750
open_cursors
1500
db_files
1024
RECOMMENDED ORACLE DATABASE MAINTENANCE
Optimizer statistics are a collection of data about the database and the objects in the
database, these statistics are used by the query optimizer to choose the best execution
plan for each SQL statement. Because the objects in a database can be constantly
changing, statistics must be regularly updated so that they accurately describe these
database objects, particularly after periods of heavy data modifications (inserts,
updates, and deletes) such as a population phase. We have used the following
commands in our environment to recompute these statistics:
execute dbms_stats.gather_database_stats(dbms_stats.auto_sample_size,
method_opt=>'FOR ALL INDEXED COLUMNS SIZE AUTO',cascade=>TRUE);
O T H E R D AT A B A S E C O N S I D E R AT I O N S
WebSphere Portal maintains some information about users in its database tables, which
grow when a user first logs in. We were interested in the steady-state performance of
WebSphere Portal, not the performance of a user’s first login to the site. Therefore our
performance evaluates after all users logged in at least one time.
One of the most important database tuning factors is bufferpool sizing. It is important to
evaluate the database's physical versus logical reads and size the bufferpools to achieve as
much as a 95% logical read rate if possible.
34
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Directory Server Tuning
Our measurements used IBM Tivoli Directory Server versions 6.0 as the directory server.
These products use a database for storing user information; DB2 Enterprise Server was
used for this database in our environment. This database is typically located on the same
system as the directory server. If your workload involves creating, updating, or deleting
users, then database maintenance described above may be needed on this database.
The following table shows the tuning values used for the directory servers in our Solaris
Base Portal Scenario measurements
How-to-Set: These values are in the file /opt/IBM/ldap/V6.0/etc/SchemaV6.0/ibmslapd.conf.
You must restart the LDAP server after changing these values.
Table 13: IDS Tuning
Parameter
Value
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
db2
db2
db2
db2
“update db config for idsldap using dbheap 4800”
“update db config for idsldap using num_ioservers 10”
“update db config for idsldap using num_iocleaners 5”
alter bufferpool LDAPBP size 3690
alter bufferpool IBMDEFAULTBP size 88500
In addition, if high CPU utilization is seen on the LDAP server, the following steps can be
used to create indexes for the ldap database:
db2 connect to idsldap
db2 "create index givenname_ix2 on idsldap.givenname (givenname)"
db2 "create index displaname_ix2 on idsldap.displayname (displayname,
eid)"
db2 "runstats on table idsldap.givenname with distribution and detailed
indexes all"
db2 "runstats on table idsldap.displayname with distribution and detailed
indexes all"
An alternative to creating the index is discussed at
http://www-01.ibm.com/support/docview.wss?uid=swg21379931
35
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Web Server Tuning
We used IBM HTTP Server 7.0 in our measurement environment. The cluster configuration
and the Solaris configuration has a remote web server; information about tuning the remote
web server can be found under Web Server Tuning in Cluster Tuning section. All other
configurations have the web server running on the same system as the WebSphere Portal
application server. If, during your monitoring, you notice insufficient processor capacity on
the system when running the web server and the portal application server on a single
system, consider separating the servers onto different systems. We used the following
tuning on our web servers:
Table 14: Web Server Tuning
Parameter
Linux & UNIX
(eg: AIX,
z/Linux, etc)
Windows
2003
Additional Information
KeepAliveTimeout
5
5
This value is less than the think time
defined in our scripts to ensure that
testing is conservative. Each user is
assumed to open a new TCP
connection for each page view.
However, in a live environment, it can
be helpful to increase the KeepAlive
Timeout. A higher timeout value can
increase contention for HTTP server
processes, if you are running out of
HTTP processes, decrease this value.
ThreadsPerChild
25
2000
The higher number of threads per
child on Windows is due to a different
process model for IHS on Windows.
MaxKeepAliveRequests
0
0
Selecting 0 lets an unlimited number
of requests on a single TCP
connection.
MaxRequestsPerChild
0
0
StartServers
2
N/A
Access logging
off
off
ThreadLimit
25
2000
This was turned off by commenting
out the following configuration line:
CustomLog
/usr/HTTPServer/logs/access_log
common
36
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ServerLimit
180
N/A
MinSpareThreads
25
N/A
MaxSpareThreads
4500
N/A
MaxClients
4500
N/A
Set it MaxClient/ThreadsPerChild.
Set it same as MaxClients.
We also enabled the server-status module so that we could monitor the number of
running and available Web server processes. This enables appropriate tuning of the
MaxClients and ThreadsPerChild parameters.
We did additional Web Server tuning in Pagebuilder Scenario. See Pagebuilder section for
details.
37
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Plug-in Tuning
The plug-in allows an IBM HTTP Server for WebSphere Application Server to communicate
with a WebSphere Application Server.
The following plugin parameters are set:

ConnectTimeout: 60 (default = 5)
ConnectTimeout is increased for 60 seconds so the plugin will wait for a successful
connection.

ServerIOTimeout: 180 (default=60)
The serverIOTimeout limits the amount of time the plugin will wait for each individual
read or write operation to return. The default value is 60 seconds. We increase the
value to 180 seconds in order to handle the amount of heavy network traffic during
the peak load.
Find more description and how-to set it in,
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.
nd.multiplatform.doc/info/ae/ae/rwsv_plugincfg.html
38
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Operating System Tuning
In any high-load environment, the network must be closely monitored to ensure that its
performance is acceptable and consistent. Note that, the following is not to suggest that all
network parameters are set to these values, but merely make the reader aware that the
network is also an entity in the performance environment and bottleneck resolution process.
AIX
NETWORK TUNING
We changed the following network tuning parameters on all the AIX systems in our
measurement environment.
Table 15: AIX Network Settings
Parameter
Value
tcp_sendspace
131072
tcp_recvspace
131072
udp_sendspace
65536
udp_recvspace
655360
somaxconn
10000
tcp_nodelayack
1
rfc1323
1
These parameters can be set using the no command or through smit. In smit, the path to
the change these is Performance & Resource SchedulingTuning Kernel & Network
Parameters Tuning Network Option Parameters Change/Show Current Parameters. So
that the changes will be permanent, also select “Save Current Parameters for Next Boot”.
These tuning settings - particularly the tcp_sendspace and tcp_recvspace values – will
allocate a significant amount of memory for network buffers. These can cause a
performance problem if the system has a limited amount of memory, in which case it may
make sense to reduce these values. For more discussion on AIX network performance
tuning, please refer to,
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftungd/doc/prftung
d/interface_network_opts.htm and http://www.ibm.com/developerworks/aix/library/auaixoptimization-netperform3/index.html
39
WEBSPHERE PORTAL 7.0 TUNING GUIDE
LINUX
NETWORK TUNING
For Red Hat Linux and z/Linux (Suse Linux on System z), we add the following settings to
file /etc/sysctl.conf, then run the command: sysctl -p
To inspect current TCP parameters, run the command: sysctl -a | fgrep tcp
Table 16: Linux Network Settings
Parameter
Value
net.ipv4.ip_forward
0
net.ipv4.conf.default.rp_filter
1
net.ipv4.conf.default.accept_source_route
0
net.core.rmem_max
16777216
net.core.wmem_max
16777216
net.ipv4.tcp_rmem
4096 87380 16777216
net.ipv4.tcp_wmem
4096 65536 16777216
net.ipv4.tcp_fin_timeout
30
net.core.netdev_max_backlog
3000
net.core.somaxconn
10000
net.ipv4.tcp_keepalive_intvl
15
net.ipv4.tcp_keepalive_probes
5
HIPERSOCKETS ON ZLINUX
HiperSockets is a technology that provides high-speed TCP/IP connectivity within a System
z central processor complex. It eliminates the need for any physical cabling or external
networking connection between servers running in different LPARs. Instead, the
communication is through the system memory of the processor, so servers are connected to
form an “internal LAN”.
With our zLinux Authoring workload, we experimented with using HiperSockets to
communicate between the application server LPAR and the database server LPAR. We saw
no significant performance difference between this and communicating between those
LPARs using a switched 100-megabit Ethernet. We speculate that this workload did not
generate enough network traffic between those two systems to benefit from the performance
advantages of HiperSockets
40
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WINDOWS 2003
NETWORK TUNING
Using the regedit command, the following registry settings were made in the section
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Create a new REG_DWORD named below.
Table 17: Windows Network Settings
Parameter
Value
MaxFreeTcbs
dword:00011940
MaxHashTableSize
dword:0000ffff
MaxUserPort
dword:0000fffe
TcpTimedWaitDelay
dword:0000001e
TcpWindowSize
dword:0000ffff (65535)
SOLARIS
NETWORK TUNING
For Solaris, use the ndd command to set the following TCP layer parameters. These will
take effect immediately, improving the network layer performance in high-volume
environments. We use the following settings in Portal server running Solaris 10:
How-to-Set: ndd -set /dev/tcp <PARAMETER> <VALUE>
Table 18: Solaris Network Settings
Parameter
Value
tcp_time_wait_interval
60000
tcp_keepalive_interval
15000
tcp_fin_wait_2_flush_interval
67500
tcp_conn_req_max_q
16384
tcp_conn_req_max_q0
16384
tcp_xmit_hiwat
400000
tcp_recv_hiwat
400000
tcp_cwnd_max
2097152
tcp_ip_abort_interval
60000
tcp_rexmit_interval_initial
4000
tcp_rexmit_interval_max
10000
tcp_rexmit_interval_min
3000
41
WEBSPHERE PORTAL 7.0 TUNING GUIDE
tcp_max_buf
4194304
KERNEL TUNING
Our Portal Server is running on Solaris 10. In Solaris 10, we use the following ‘projmod’
commands to set system parameters. After making the changes, we must logout then login
to take these changes into effect. To examine your current settings, do ‘cat /etc/project’.
projmod -s
user.root
projmod -s
projmod -s
projmod -s
projmod -s
projmod -s
user.root
-K 'project.max-shm-memory=(privileged,4294967296,deny)'
-K
-K
-K
-K
-K
'project.max-shm-ids=(privileged,1024,deny)' user.root
'project.max-sem-ids=(privileged,1024,deny)' user.root
'process.max-sem-nsems=(privileged,4098,deny)' user.root
'process.max-sem-ops=(privileged,16384,deny)' user.root
'process.max-file-descriptor=(privileged,16384,deny)'
SOLARIS VIRTUALIZATION
Use Resource Management or Zones of Solaris virtualization to better utilize your modern,
powerful T2 server with hundreds of processors.
In our lab, we used processor sets to partition virtual processors. Solaris resource pools
allow us to group a number of processors into a pool and bind the pool with Java process.
Through our experiments, we found that the most efficient usage for our scenario was to
bind 21 compute threads to one JVM. We created a vertical cluster with six WebSphere
Portal members, and then we bound each member to a Solaris processor set. The “right”
number of compute threads (and therefore WebSphere Portal members) can vary with the
application, but we expect that four to six members will give good performance for most
WebSphere Portal applications.
The Solaris commands we use to setup the configuration were the following,
1. pooladm –e
Enable the pool facility.
2. pooladm –s
Create a static configuration file that matches the current dynamic configuration.
3. poolcfg –c „create wp_pset1 (unit pset.min=20; unit pset.max =21)‟
Create a processor set named wp_pset1 with between 20 and 21 processors. Create one
processor set for each application server JVM, each with its own name.
4. poolcfg –c „create pool wp_pool1‟
42
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Create a resource pool named wp_pool1. Create one resource pool for each processor set
created in the previous step, with unique names for each pool.
5. poolcfg –c „associate pool wp_pool1(pset wp_pset1)‟
Associate a resource pool with a processor set. Do this for each processor set/resource pool
pair.
The names used above for processor sets and resource pools are arbitrary; the
requirements are that the processor set name must be matched up with the resource pool
name in step 5, and the resource pool name must be used when binding the JVM to the
resource pool in step 9.
6. pooladm –c
Commit the configuration at /etc/pooladm.conf.
7. Start Portal cluster members from the WebSphere Applications Server administration
console.
8. Find the process IDs for the WebSphere Portal JVMs with the command
ps –ef | grep java
There is a separate process ID for each JVM.
9. poolbind –p wp_pool1 <PortalPID>
This command binds the selected process to a resource pool. Repeat this command for
each of the portal JVMs, using a separate resource pool for each JVM process. If you restart
WebSphere Portal, you need to run the poolbind command with the new WebSphere Portal
process ID. Steps 1-6, though, do not need to be repeated.
More information on these commands can be found in the Solaris documentation set,
System Administration Guide: Solaris Containers-Resource Management and Solaris
Zones, at http://docs.sun.com.
43
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Z/OS
WLM SETUP
On z/OS WLM allows you to effectively and efficiently utilize your computing resources
system-wide, enabling you to achieve defined performance and service goals for your
system.
WebSphere Application Server address spaces are controlled by the Started Task Control
(STC) classification in WLM. STC handles the goals of starting, stopping, logging output,
and assigning resources to the address space execution . STC does not handle work
coming into the server on listening ports. The goals for these address spaces have to be
high to get them to start quickly.
Once requests enter and are placed immediately into a WLM work manager or queue.
Processing switches from an STC responsibility to a CB responsibility.The J2EE application
work handled by WebSphere in the servers is controlled by the CB subsystem. CB is simply
the subsystem name for WebSphere in WLM.
Following are our WLM configuration for WebSphere Application Server
1. CB Classification - WAS/Portal Transactions assigned to a Service Class Defined
with Importance 1 and Average Percentile Response Time Goal of 90% complete
with in 0.3 Seconds.
2. STC Classification - Controller Address Space is assigned to SYSSTC Service
class . Servant and Adjunct address spaces are assigned to a Service Class defined
with Execution Velocity Goal of 70%.
For more information on configuring WLM Policy for WebSphere Application Server on z/OS
refer to following links
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101740
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101754
ENABLE HIPERDISPATCH
HiperDispatch was introduced with IBM’s z10 server, and is available (via PTFs) on z/OS
V1R7, z/OS V1R8, and z/OS V1R9. HiperDispatch was designed to (1) minimize the z10
hardware performance degradation caused by processor cache misses, and (2) maximize
the amount of CPU processing power associated with any single logical processor. It can be
enabled by setting the HIPERDISPATCH=YES parameter in IEAOPTxx
44
WEBSPHERE PORTAL 7.0 TUNING GUIDE
SYSTEM TUNING
In the PARMLIB member BPXPRMxx check the values of the following parameters:
Table 19: z/OS System Tuning
Parameter
Value
Additional Information
MAXPROCSYS
15000
System will allow at most 15000 processes to be active
concurrently.
MAXPROCUSER
15000
Allow each user (same UID) to
concurrent processes active.
have at most 15000
MAXUIDS
200
Allow at most 200 z/OS UNIX
concurrently.
users to be active
MAXFILEPROC
65535
Allow at 65535 open files per user.
MAXPTYS
800
Allow up to 800 pseudo-terminal sessions
MAXTHREADTASKS
5000
System will allow at most 5000 threads tasks to be active
concurrently in a single process
MAXTHREADS
10000
System will allow at most 10000 threads to be active
concurrently in a single process.
MAXMMAPAREA
40960
System will allow at most 40960 pages to be used for
memory mapping.
MAXFILESIZE
NOLIMIT
Unlimited file size.
MAXCORESIZE
4194304
MAXASSIZE
2147483647
This size is same as the region size for TSO. By default
USS ids get some pre-defined minimum which is usually
not enough for WPS kind of stuff. To avoid problems
instantiating java processes this size should be set to
214783647.
MAXCPUTIME
2147483647
To improve the CPU process time.
MAXSHAREPAGES
32768000
System will allow at most 32768000 pages of shared
storage to be concurrently in use.
45
WEBSPHERE PORTAL 7.0 TUNING GUIDE
3

Page Builder Theme Tuning
The default theme shipped with Portal 7 is called the Page Builder Theme with Client-SideAggregation support (CSA). All of the tunings in this section are for the default Page Builder
Theme for Portal 7.
When using the Page Builder Theme, we used the IBM HTTP server to cache content.
Alternatively a reverse proxy could have been used. This section will discuss using an
HTTP server or a reverse proxy to cache content.
In general it is best practice to use a reverse proxy or HTTP server that resides on different
physical hardware from portal server.
To get acceptable throughput and response times for the Page Builder theme, we
recommend having some external caching in place. This allows some content to be fetched
without going to the portal server.
In general, the same tuning that was used for the Base Portal Scenario, described in
previous section, was used for the Page Builder Scenario. That section describes themeindependent tuning settings. The differences in tuning are mentioned below.
CacheManagerService Properties
The following values were specified in CacheManagerService.properties in addition to the
parameters changed in the Base Portal tuning.
46
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Table 20: CacheManager Service Settings for default portal 7 Page Builder Theme
Setting
Used
Parameter
cacheinstance.com.ibm.wps.spa.parser.theme.
FirstLevelThemeParserCache.size
cacheinstance.com.ibm.wps.resolver.data.cache.
FirstLevelDataSourceCache.size
cacheinstance.com.ibm.wps.resolver.data.cache.
DataSourceCache.size
cacheinstance.com.ibm.wps.spa.PageTypeCache.enabled
2003
cacheinstance.com.ibm.wps.spa.PageTypeCache.
supportsDependencies
cacheinstance.com.ibm.wps.spa.PageTypeCache.transactionaware
false
cacheinstance.com.ibm.wps.spa.PageTypeCache.shared
false
cacheinstance.com.ibm.wps.spa.PageTypeCache.size
5000
cacheinstance.com.ibm.wps.spa.PageTypeCache.lifetime
86400
2003
8000
true
false
Ensuring Browser Cache Works Properly for Internet
Explorer
By default WebSphere Portal will send many versions of Internet Explorer a ‘vary’ HTTP
header. If Internet Explorer is sent a ‘vary’ HTTP header, it is unable to cache that reply
effectively. To configure WebSphere Portal to not send the vary header to IE:
1. Log in to WebSphere Portal as an administrator.
2. Navigate to Administration  Portal Settings  Supported Clients.
3. Select .*MSIE 7.0.* (Internet Explorer 7) and click Edit selected client.
4. In the Capabilities field, select CACHE_VARY and click Delete then OK.
5. Repeat this for other versions of Internet Explorer that are listed under ‘supported
clients’. If CACHE_VARY is listed, delete it.
Reducing Redirects
Avoiding redirects improves the performance by reducing overhead from frequent requests.
Do the following to avoid redirects:
1) Enable a base URL.
How to Set: To enable a base URL, See the section on enabling base URLs in themes.
2) Avoid redirect on the home page.
47
WEBSPHERE PORTAL 7.0 TUNING GUIDE
How to Set: modify the content of a JSP file
(/PortalRoot/theme\wp.mashup.cc.theme\installedApps\wp.mashup.cc.theme.ear\PageBuild
er2.war\themes\html\PageBuilder2\bannerCommonActions.jsp) as shown below:
Change the highlighted fields in this part of the file from this:
<portal-logic:if loggedIn="no">
# <portal-navigation:urlGeneration allowRelativeURL="true"
contentNode="wps.content.root" home="protected" > <a
href='<%wpsURL.write(escapeXmlWriter); %>' ><portal-fmt:text
key="link.login" bundle="nls.engine"/></a> </portalnavigation:urlGeneration> </li> </portal-logic:if>
Change the highlighted values to:
<portal-logic:if loggedIn="no">
# <portal-navigation:urlGeneration allowRelativeURL="true"
contentNode="wps.Login" home="public" > <a href='<%
wpsURL.write(escapeXmlWriter); %>' ><portal-fmt:text key="link.login"
bundle="nls.engine"/></a> </portal-navigation:urlGeneration> </li>
</portal-logic:if>
If a custom login page is used, make sure the contentNode matches the unique name of
your login page. In the previous example its wps.Login. You can find the unique name of
your login page under Portal Administration  Manage Pages. The login page is typically
found in ‘Content Root’  ‘Hidden Pages’.
Serving WebDAV resources
With the default Page Builder theme many resources come from WebDAV storage. The
same URL can safely be used for authenticated and unauthenticated users. To enable this
feature: In the WAS admin console:
1. Servers  Server Types  WebSphere application servers  WebSphere_Portal
2. Click on Security Domain
3. Expand Web and SIP security
4. Click on General Settings
5. Check 'Use available authentication data when an unprotected URI is accessed'
6. Save
Mashup Multipart tuning in Server Side Mode
Page Builder theme, server side mode, does not have many widgets and multipart
downloading can be disabled to improve performance.
48
WEBSPHERE PORTAL 7.0 TUNING GUIDE
How to Set: In the WebSphere Administrative Console Servers  Resources  Resource
Environment  Resource Environment Providers 
WP_CommonComponentConfigService
Table 21: Mashup Multipart Mode Setting
Default Value
com.ibm.mashups.multipart.enabled
com.ibm.mashups.multipart.correlatehosts
True
True
Value
False
False
Disabling Personalization visibility rules on pages and
portlets
If a portal installation is not using personalization (PZN) rules on individual pages and
portlets, a large performance gain can be achieved by disabling the processing of
personalization rules for pages and portlets.
How to Set: ./ConfigEngine.sh action-disable-page-as-extension-nodewp.dynamicui.config -DPageUniqueName=wps.content.root
By default the PZN transformation is registered on the wps.content.root. If a customer
changed this manually to another page, that unique name where the PZN transformation is
located would have to be used instead of wps.content.root.
Using a Caching Proxy
With any theme, large resources can have a significant impact on end-user performance.
The performance impact of these can be minimized by compressing and/or caching them
outside the application server.
There are a couple of choices for caching: using a reverse proxy or enabling caching in the
HTTP server. In this section we discuss both options.
We suggest having the HTTP server reside on a different server than portal, use in-memory
caching on the HTTP server, and don’t bother using a reverse proxy.
Other configurations are viable, but make sure that large resources, such as layerLoader.jsp
is cached and compressed. We saw a significant performance improvement by having
portal compress the content and have the HTTP server cache it.
The advantage of using a reverse proxy over an HTTP server for caching depends on the
topology used. In general it is best to have the caching done on a server that the application
49
WEBSPHERE PORTAL 7.0 TUNING GUIDE
server is not running on. So if the HTTP server is on the same server as the application
server, it is good to use a caching reverse proxy that is on a different server.
The disadvantage of using a reverse proxy is the difficulty to configure it so it compresses
content, and caches it, and does not send a Vary header to Internet Explorer.
For HTTP-server caching, the advantage of using in-memory caching is that it is faster than
on-disk caching. The disadvantage is that in-memory caching could use more main
memory.
ENABLING CACHING IN THE HTTP SERVER
For http server caching, there are 2 possibilities: disk caching and in-memory caching. Inmemory caching is faster. However, disk caching does not work on Windows. On windows
the only option is in-memory caching.
These values are set in the HTTP server’s httpd.conf file:
For in-memory caching use:
LoadModule cache_module modules/mod_cache.so
<IfModule mod_cache.c>
LoadModule mem_cache_module modules/mod_mem_cache.so
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize
102400
MCacheMaxObjectCount 10000
MCacheMinObjectSize 1
MCacheMaxStreamingBuffer 6291456
MCacheMaxObjectSize 6291456
</IfModule>
</IfModule>
For caching to disk (not for use on Windows) use the following:
LoadModule cache_module modules/mod_cache.so
<IfModule mod_cache.c>
LoadModule disk_cache_module modules/mod_disk_cache.so
<IfModule mod_disk_cache.c>
# make sure the path below exists and the http server group has
access to it
CacheRoot /usr/IBMIHS7/diskCachetemp/
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
CacheMaxFileSize 10000000
</IfModule>
</IfModule>
50
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Make sure to select either disk or in memory caching, but not both. If a caching reverse
proxy is used, there is no need for caching on the http server as well
When using HTTP in-memory server caching on Unix, use the following settings to override
those mentioned in base portal HTTP server settings. Unix based HTTP servers cache
information in each process. These settings reduce the number of processes and increase
the number of threads per process. This reduces the overall memory needed by the HTTP
server processes.
Table 22: HTTP server settings for use with HTTP caching
Parameter
AIX
POWER5
ThreadsPerChild
150
StartServers
1
ThreadLimit
150
ServerLimit
25
Additional Information
The higher number of threads per child on
Windows is due to a different process model for
IHS on Windows.
Set it MaxClient /ThreadsPerChild.
See Web Server Tuning for other HTTP server settings to set proper HTTP headers. Those
settings are used whether or not the HTTP server is configured for caching:
ENABLING CACHING IN A REVERSE PROXY SERVER
An alternative to caching in an HTTP server is to cache in a reverse proxy. We used IBM
Edge Server Version 6.0.2 plus fixes.
We were unable to get the Edge Server to compress and cache layerLoader.jsp. Therefore
we did not get acceptable results having the Edge Server doing the compression. We did
get good results having Portal compress the content, HTTP server add caching headers,
and the Edge Server cache the results.
Another issue with doing compression in the Edge Server version we used, is that the Edge
Server will send a Vary HTTP response header if the reverse proxy compresses the reply. If
Internet Explorer (IE) receives a reply with a Vary header, IE will always check to see if the
item has been modified the next time that item is requested. That is not the desired
behavior as it causes an unnecessary request to be sent instead of using the version that is
in the browsers cache without sending a message to the server. Make sure that
compressed replies sent to IE do not contain a Vary header.
The following are the settings and tunings specified in the reverse proxy’s ibmproxy.conf file
to get the reverse proxy to work with the Page Builder theme. These settings allow caching
of responses but allow portal to perform the compression of responses.
51
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Table 23: Reverse Proxy Settings
Parameter
Setting Used
Additional Information
Proxy /wps/* http://{server-name}/wps/*
Proxy for /wps
Proxy /wps_semanticTag*
http://{servername}/wps_semanticTag*
Proxy /searchfeed* http://{servername}/searchfeed*
Proxy /portal_dojo/* http://{servername}/portal_dojo/*
Proxy /PageBuilder2/* http://{servername}/PageBuilder2/*
Proxy /mccenabler/* http://{servername}/mccenabler/*
ConnThreads
15
ServerConnPool
on
Proxy for /wps_semanticTag
MaxSocketPerServer
20
CacheTimeMargin
5 seconds
CacheFileSizeLimit
2 M
flexibleSocks
off
LimitRequestFieldSize
16384
Proxy for /searchfeed
Proxy for /portal_dojo
Proxy for /PageBuilder2
Proxy for /mccenabler
Web Server Tuning
The following settings allow the HTTP server to put proper caching headers on requests and
to have the HTTP server do caching.
# uncommented the following to enable statics to be cached
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
# from http://www.contentwithstyle.co.uk/blog/147 avoid gzip bug in IE 6
BrowserMatch ^Mozilla/4\.[0678] no-gzip
BrowserMatch \bMSIE\s7 !no-gzip !gzip-only-text/html
AllowEncodedSlashes On
ExpiresActive On
ExpiresByType text/javascript "access plus 5 days"
# note that the following max-age=86400 are just an example.
#A lower value might be more appropriate for your site
<LocationMatch "\.(gif|jpeg|jpg|png|ico|jsp|css|js|swf|json)$">
header set Cache-Control "public,max-age=86400"
</LocationMatch>
52
WEBSPHERE PORTAL 7.0 TUNING GUIDE
<LocationMatch "/mccenabler/js/com/ibm/mm/livetext/.*\.cfg">
header set Cache-Control "public,max-age=86400"
</LocationMatch>
<LocationMatch "/mccbuilder/widget-catalog/.*\.xml">
header set Cache-Control "public,max-age=86400"
</LocationMatch>
53
WEBSPHERE PORTAL 7.0 TUNING GUIDE
4

MANY PAGES TUNING
The “Many Pages Scenario”, derived from the Base Portal Scenario, measures the effects of
having larger numbers of pages visible to the users. For WebSphere V7.0 and later, a site is
considered as having a large number of pages if it has 2,500 or more pages.
Since it is derived from the Base Portal Scenario, the same tuning that was used for the
Base Portal Scenario applied for the Many Pages Scenario. The differences in tuning are
mentioned below.
DB2 Database Tuning
We applied the following tunings to our Release database.
Table 24: DB2 Database Settings for Many Pages
Release DB
Parameter
Setting Used
dbheap
4800
applheapsz
4096
logbufsz
256
num_IOServers
8
num_IOCleaners
8
How-To Set: In the DB2 server run the following commands:
db2
db2
db2
db2
db2
db2
“update
“update
“update
“update
“update
“update
db
db
db
db
db
db
cfg
cfg
cfg
cfg
cfg
cfg
for
for
for
for
for
for
release
release
release
release
release
release
using
using
using
using
using
using
dbheap 4800”
applheapsz 4096”
logbufsz 256”
app_ctl_heap_sz 4096”
num_IOServers 8”
num_IOCleaners 8”
54
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Cache Manager Service
Table 25: Cache Manager Service Settings for Many Pages
Parameter
Setting Used
com.ibm.wps.datastore.pageinstance.OIDCache.size
10000
com.ibm.wps.datastore.pageinstance.OIDCache.lifetime
28800
com.ibm.wps.datastore.pageinstance.DerivationCache.size
10000
com.ibm.wps.datastore.pageinstance.DerivationCache.
lifetime
28800
55
WEBSPHERE PORTAL 7.0 TUNING GUIDE
5

WEB CONTENT MANAGEMENT TUNING
In general, the same tuning that was used for the Base Portal Scenario was used for the
WCM scenarios. The main differences are to the cache tuning settings: WCM increases
demands on the portal access control component which requires a different set of cache
tunings to accommodate and WCM has an internal set of object caches that can be tuned
as well. On top of cache tunings, WCM 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 mentioned below.
Application Server Tuning

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
JCRDB
Rendering
Value
(min/max)
10/150
Complex
Rendering Value
(min/max)
10/150
56
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Authoring/API
Value
(min/max)
10/150
WebSphere Portal Service Properties
CACHE MANAGER SERVICE
Portal Caches sizes – Ignore the Base Portal values and set the following in
CacheManagerService.properties:
Table 26: Cache Manager Service Settings for WCM
CacheManagerService.properties File
Parameter
cacheinstance.com.ibm.workplace.searchmenu.helper.
SearchMenuCacheHelper.size
cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.
lifetime
cacheinstance.com.ibm.wps.ac.ApplicationRoleChildrenCache.size
cacheinstance.com.ibm.wps.ac.ApplicationRoleDescriptorCache.size
cacheinstance.com.ibm.wps.ac.ApplicationRoleOIDCache.size
cacheinstance.com.ibm.wps.ac.ApplicationRolesForPrincipalCache.
size
cacheinstance.com.ibm.wps.ac.ChildEntitlementsCache.size
cacheinstance.com.ibm.wps.ac.ContainedRolesCache.size
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.
APPLICATION_ROLE.size
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.size
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.VIRTUAL.
size
cacheinstance.com.ibm.wps.ac.ExternalOIDCache.size
cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache.
size
cacheinstance.com.ibm.wps.ac.ProtectedResourceCache.size
cacheinstance.com.ibm.wps.ac.RolesCache.size
cacheinstance.com.ibm.wps.datastore.pageinstance.DerivationCache.
size
cacheinstance.com.ibm.wps.datastore.pageinstance.OIDCache.size
cacheinstance.com.ibm.wps.model.content.impl.ResourceCache.
lifetime
cacheinstance.com.ibm.wps.model.content.impl.ResourceCache.size
cacheinstance.com.ibm.wps.model.content.impl.TopologyCache.size
cacheinstance.com.ibm.wps.model.factory.ContentModelCache.live.
size
cacheinstance.com.ibm.wps.policy.services.PolicyCacheManager.
lifetime
cacheinstance.com.ibm.wps.services.cache.cachedstate.
CachedStateServiceSessionBound.cache.size
cacheinstance.com.ibm.wps.pe.portletentity.firstLevelCacheSize
57
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Value
5000
10800
500
500
500
12500
500
500
500
500
500
12000
1200
12500
7500
250
250
14400
500
500
5000
28800
250
0
cacheinstance.com.ibm.wps.pe.portletentitycounter.
firstLevelCacheSize
cacheinstance.com.ibm.wps.pe.portletregistry.firstLevelCacheSize
cacheinstance.com.ibm.wps.pe.portletmodel.portletdefinition.
firstLevelCacheSize
cacheinstance.com.ibm.wps.pe.contenttypes.nocharset.
firstLevelCacheSize
cacheinstance.com.ibm.wps.pe.contenttypes.result.
firstLevelCacheSize
cacheinstance.com.ibm.wps.contentmapping.ContentMappingInfoCache.
firstLevelCacheSize
cacheinstance.DigestCache.cache.size
0
0
0
0
0
0
20000
A C C E S S C O N T R O L D AT A M A N A G E M E N T S E R V I C E
Table 27: Access Control Data Management Service Settings for WCM
AccessControlDataManagementService.properties File
Parameter
Value Used
accessControlDataManagement.acucIgnoreResourceTypes
Null
N AV I G AT I O N S E R V I C E
Portal Navigator Service – You can realize an increase in performance on anonymous
pages by leaving this disabled. If you are however using the old Web Content Viewer
portlet (based on the IBM Legacy Portlet API) on anonymous pages you should
continue to enable public sessions.
Table 28: Navigation Service Settings for WCM
NavigatorService.properties File
Parameter
public.session
Default
Value
false
Value
Used
Definition
false
Controls whether anonymous users have
sessions
P E R S O N A L I Z AT I O N S E R V I C E
In Complex Rendering scenario, performance can be improved by setting the following
tuning parameters
58
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Table 29: Personalization Service Setting for WCM Complex Rendering
PersonalizationService.properties
Parameter
Value Used
bypassWebContentLinks
rulesengine.cache.timeout
1
900
WCM Object Cache
Table 30: WCM Object Cache Settings
WCM Object Caches
Value Used
8000
8000
10000
6000
8000
4000
Cache Name
abspath
abspathreverse
processing
session
strategy
summary
How-To Set: Login to the WAS Administration Console  Resources  Cache instances 
Object cache instances.
Detailed descriptions of these caches can be found in Web Content Management Caches
section of this document.
WCM Configuration Service
Enable the user cache
Find the WCMConfigService.properties file under:
<wp_profile>/PortalServer/wcm/shared/app/config/wcmservices
Set user.cache=true
Enable the subscriberOnly setting (for rendering only)
Set deployment.subscriberOnly=true
The subscriberOnly setting should be enabled only for environments that will be
subscribed to and not syndicated from. We recommend this be enabled in a production
environment.
59
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Web Content Viewer portlet caching
For the new Web Content Viewer portlet (JSR 286) version, a feature has been added to
allow caching of HTML content generated by the portlet (the portlet fragment). This cache
can be used in addition to the WCM Object Caches. You can achieve a significant
performance increase by enabling this cache, especially if your Web Content Viewer portlet
is displaying non-personalized content. To enable this cache do the following:
1. Enable servlet caching in the WAS admin console under Servers  Application
2.
3.
4.
5.
Servers  WebSphere Portal  Web Container Settings  Web Container
Enable portlet fragment caching in the WAS admin console under Servers 
Application Servers  WebSphere Portal  Portlet Container
Restart the Portal Server
Login to portal as an administrator and navigate to page containing the rendering
portlet that you want to enable portlet caching.
Select “Configure” or “Edit Shared Settings” from the dropdown in the upper right
hand corner of the portlet. When set under in Configure mode the settings apply to all
instances of this portlet as opposed to Edit mode where the settings only apply to that
one instance.
Figure 1 Portlet Settings Screenshot
6. Under Portlet SettingsPortlet Cache Options select the appropriate Cache Scope
and Expiration settings for your portlet.
Cache scope:
Shared cache across users: This type of cache provides the biggest performance
improvement as it caches the output of the rendering portlet across users. This cache
60
WEBSPHERE PORTAL 7.0 TUNING GUIDE
scope should be used only for rendering portlets that render Web content that is not
personalized.
Non shared cache for a single user: This type of cache provides a smaller
performance improvement but allows caching of personalized Web content that is
displayed by the rendering portlet.
Expiration:
Cache always expires: The content will never be cached in either a shared or a
private portlet cache i.e. this setting disables the cache.
Cache never expires: The content can be stored indefinitely in either a shared or a
private portlet cache.
Cache expires after this many seconds: The content will be stored for the number
of seconds specified in either a shared or a private portlet cache
For more information regarding the new WCM portlet caching, please visit the following
URL:
http://www10.lotus.com/ldd/portalwiki.nsf/dx/Caching_with_the_Web_Content_Viewer_%28JSR_286%29_Portl
et_
MONITORING THE WCM CONTENT VIEWER PORTLET CACHE
You can monitor your cache to make sure is working properly. WebSphere Application Server
comes with a Cache Monitor application that allows you to do just that. In addition, there's an
extended cache monitor with more functionality and additional bug fixes. Follow these steps to
view the contents of your WCM Content Viewer portlet cache:
1. Install/Update the Cache Monitor. For information on how to do this, go to:
http://www.ibm.com/developerworks/websphere/downloads/cache_monitor.html
2. Before you can access the Cache Monitor application you will need to give a
administrator account access to this application. Login to the WAS Admin console 
Applications  Application Types  WebSphere enterprise applications  Dynamic
Cache Monitor  Security role to user/group mapping  Select “administrator”  Click
on Map Users  Search for the right user account and add it to the “selected” box 
Click OK  Save
3. Login to the Cache Monitor application. The URL should look like this:
http://myserver.com:<port>/cachemonitor .
4. Select the “baseCache” and click OK
5. At this point any WCM Web Content Viewer JSR 286 portlet with caching enabled should
add entries to this cache.
61
WEBSPHERE PORTAL 7.0 TUNING GUIDE
6. To look at the contents of the cache, simply click on the “Cache Content” link on the left
side menu.
In addition to viewing the contents of the cache, you can also use the Cache Monitor application
to view cache statistics, invalidate individual cache entries, and compare cache content.
JCR Text Search
icm.properties – Disable jcr textsearch
During our measurements, we have 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 wish to disable text indexing, this can be done in the file icm.properties, by
setting the property jcr.textsearch.enabled to the value false. This file is found in the
directory <wp_profile>/PortalServer/jcr/lib/com/ibm/icm.
DB2 Tuning (Authoring Environment)
M U LT I P L AT F O R M ( L U W )
On top of the DB2 tunings for the base portal scenario, during our testing 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. This was because DB2 was unable to autosize them
fast enough during our user ramp ups and it was therefore causing 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 stressing the disk I/O prompting us to
increase the maximum number of file handles that can be opened for the JCR database.
Finally, two indexes were added to improve some troublesome queries:
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
62
WEBSPHERE PORTAL 7.0 TUNING GUIDE
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
Finally, we recommend that you use DB2 in 64-bit mode to allow sufficient memory for the
necessary database objects. This is particulary important with authoring environments as
this can be a very database intensive workload. During our testing, database memory
became a limiting factor with this workload and we were able to achieve a significant
increase in capacity by moving to 64-bit.
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 LPAR to the Portal/WCM installation,
Universal Driver type 4 database driver must be used but when DB2 for z/OS is on the
same LPAR you can also use Type 2 driver which is a recommended configuration.
As part of DB transfer process fifteen databases were created to support WCM on Portal.
One database each for release, customization, community, likeminds, and feedback
and ten databases for JCR.
BUFFERPOOLS
It is also beneficial to create separate bufferpools for use by Portal to avoid contention. 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 31: DB2 z/OS Bufferpool Settings
Bufferpool settings
Database
Domain
RELEASE
CUSTOMIZATION
COMMUNITY
LIKEMINDS
FEEDBACK
wkplc_dbdomain.prop
erties
BP
Page
size
(KB)
DB2
BP
BP
Size
PGFIX
<domain>.Db4KBuffe
rPoolName
BP2
4
80000
YES
<domain>.DbIndex4K
BufferPoolName
BP3
4
80000
YES
63
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Usage
FEE,LIK,REL,C
OM,CUS Table
Spaces 4K
BPOOL
FEE,LIK,REL,C
OM,CUS Index
Spaces
<domain>.Db32KBuff
erPoolName
BP32
32
K1
20000
YES
jcr.Db4KBufferPool
Name
BP4
4
15000
0
YES
BP5
4
15000
0
YES
BP32
32
K1
20000
YES
jcr.bp4ktables
BP1
4
40000
NO
jcr.bp4kindexes
BP1
4
40000
NO
jcr.bp16ktables
BP16
16
K1
20000
YES
jcr.bp32ktables
BP32
32
K1
20000
YES
jcr.bp8ktables
BP8K
8
1
20000
YES
jcr.blobBufferpool
BP32
32
K1
20000
YES
jcr.DbIndex4KBuffe
rPoolName
jcr.Db32KBufferPoo
lName
JCR
REL,CUS,COM
and Application
32K BPOOL
JCR Table
Spaces 4K
BPOOL
JCR Index
Spaces
JCR 32K
BPOOL
4K buffer pool
Used by JCR for
User Tables
4K buffer pool
used by JCR for
creating Index's
for User Tables
16K buffer pool
Used by JCR for
User Tables
32K buffer pool
Used by JCR for
User Tables
8K buffer pool
Used by JCR for
User Tables
BLOB
Tablespaces
PGFIX is an ALTER BUFFERPOOL parameter. PGFIX when set as YES allows DB2 to fix
the buffer pages once and keep them fixed in real storage. This avoids the processing time.
JCR QUERY OPTIMIZATION OPTION FOR AUTHORING
We noticed that certain JCR queries that were consuming lot of CPU Resources will derive
benefit if ran with REOPT(ONCE) .REOPT(ONCE) will cause DB2 to re-calculate the
access path based on the literal values in the queries. We bound another set of DISTSERV
packages just for JCR queries . The new set of packages were bounded using DB2 Jcc
Binder utility with -reopt once and -collection Parameter. The value specified for collection
was used on the CURRENT PACKAGESET custom property of the JCR data source .
To bind the new set of Packages Use
java com.ibm.db2.jcc.DB2Binder -url jdbc:db2://<hostname>:<drdaport>/<DB2
Location Name> -user <username> -password <password> -collection
<collection name> -reopt once
Updating JCR data source to use the new set of packages
64
WEBSPHERE PORTAL 7.0 TUNING GUIDE
In the administrative console, Under Resources > JDBC > Click Data Sources
Select the Appropriate Scope > Click JCR Datasource
Click Custom properties
Update the value of the property currentPackageSet to the collection value you specified
while binding the new set of packages in the step above.
DB2 DRIVER PACKAGES CHANGE FOR WCM RENDERING
For rendering as limited number of different SQL's are executed very often, we reduced the
overhead of short prepares in DB2 by using a new set of JCC packages bounded with DB2
Jcc Binder utility with -keepdynamic yes and -collection Parameter. The value specified for collection was used on the CURRENT PACKAGESET custom property of the all data
sources.
To bind the new set of Packages Use
java com.ibm.db2.jcc.DB2Binder -url jdbc:db2://<hostname>:<drda
port>/<DB2 Location Name> -user <username> -password <password>
collection <collection name> -keepdynamic yes
-
Updating data source to use the new set of packages and the enabling keepDynamic
parameter.
1. In the administrative console, Under Resources > JDBC > Click Data Sources
2. Select the Appropriate Scope > Click Datasource (update the property of all data
sources)
3. Click Custom properties
4. Update the value of the property currentPackageSet to the collection value you
specified while binding the new set of packages in the step above.
5. Update the value of the property keepDynamic and set it to 1.
ADDITIONAL RESOURCES FOR DB2 Z/OS

WCM/JCR database table usage information for WebSphere Portal v6
http://www-01.ibm.com/support/docview.wss?uid=swg21255445

Performance Improvement Possible For Remote TCP Access to z/OS
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10621

DB2 9 for z/OS Performance Topics
http://www.redbooks.ibm.com/redbooks/pdfs/sg247473.pdf
65
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Oracle Tuning (Rendering and Authoring)
In some cases on Oracle 10g, the SQL Tuning Advisor in the Enterprise Manager console
flagged the SQL query below as performing poorly. The cause of the poor performance was
the optimizer was choosing a poor access plan for the query doing a table scan instead of
using an existing index leading to high query response times and high database CPU
utilization.
SELECT OID, CREATED, MODIFIED, RES_TYPE, EXTERNAL_OID, EXTERNAL_UID,
PARENT_OID, OWNER_TYPE, OWNER_UID, INHERITANCE, PROPAGATION,
EXTERNALIZED, IS_PRIVATE, NAME, IS_LEAF FROM jcr.PROT_RES WHERE
(PARENT_OID = :1 AND RES_TYPE = :2)
If you are having problems with this query, you can add the index below and rerun more
detailed statistics gather on the PROT_RES table by executing the following commands:
CREATE INDEX "JCR"."IX2110I" ON "JCR"."PROT_RES" ("PARENT_OID",
"RES_TYPE");
exec dbms_stats.gather_table_stats( ownname=> 'JCR', tabname=> 'PROT_RES'
, estimate_percent=> null, cascade=> TRUE, degree=> NULL, no_invalidate=>
FALSE, granularity=> 'ALL', method_opt=> 'FOR ALL COLUMNS');
After adding this index, we observed that the access plan for this query would replace the
table scan with an index scan using either the new IX2110I or the existing IX2110D index.
In both cases the DB CPU utilization was significantly decreased.
66
WEBSPHERE PORTAL 7.0 TUNING GUIDE
6

CLUSTER TUNING
We have measured the Base Portal scenario in several configurations, including a
three-node horizontal cluster environment (with or without database session
persistence), and a six-member vertical cluster environment. In general, the same
tuning that was used for the Base Portal Scenario was used for these cluster
measurements. The additional settings specific to the clustered environments are
mentioned below.
Application Server Tuning
DYNACACHE CUSTOM PROPERTIES
There are several properties which can be set to reduce the number and size of
Dynacache messages sent between cluster members. This will improve scalability and
reduce resource consumption in a clustered Portal environment. To set these
properties, do the following:
1) Open and log in to the Administrative Console.
2) Click Application servers  WebSphere_Portal  Java and Process
Management  Process Definition  Java Virtual Machine  Custom
properties  New
3) Under General Properties, add the following information:
Name: com.ibm.ws.cache.CacheConfig.ignoreValueInInvalidationEvent
Value: true
There is a custom property: com.ibm.ws.cache.CacheConfig.
propogateInvalidationsNotShared that can significantly affect performance. Out of box
Portal does not set this property and the default is false, which provides the best
performance. If it is set to true, Dynacache will send invalidations to peer members in the
cluster on cache entry insertions and updates for a NOT_SHARED cache instance. This
can cause a significant performance impact, particularly on the z/OS platform. Therefore this
property should be removed (or set to false, its default value). This will not have a functional
impact on WebSphere Portal.
67
WEBSPHERE PORTAL 7.0 TUNING GUIDE
D Y N AM I C C A C H E R E P L I C AT I O N
1. Dynamic Cache replication must be enabled on all nodes in the cluster.
How to set:
1) Open and log in to the Administrative Console.
2) Click Application servers  WebSphere_Portal  Container Services 
Dynamic cache service  click ‘Enable cache replication’  Replication Type  ‘Not
Shared’
2. Set the Dynamic cache size the same for all nodes in the cluster.
How to set:
1) Open and log in to the Administrative Console.
2) Click Application servers  WebSphere_Portal  Container Services 
Dynamic cache service  cache size: 3000
3. Resynchronize each node: From Administrative Console  System administration 
Nodes  select all nodes in the cluster  click ‘Full Resynchronize’
VMM CONTEXT POOLING
Tuning Cluster for VMM Context Pooling must be done in Deployment Manager, then do full
resync to each node from Administrative Console. See VMM Context Pooling for how to set this.
Session Persistence To Memory-Memory Tuning
To enable memory-memory Session Persistence in a cluster, a replication domain must be
created, then you can configure memory-memory session replication for each Portal server
under Session Management from WebSphere Administrative Console. Choose one of the
three types of replication modes. We use the default “BOTH” (Client and Server) mode in
our environment. This means that sessions are sent from the Portal cluster members to
other cluster members – separate application servers are not defined to store the session
data.
This mode of session persistence will cause each cluster member to hold more session data
than if no replication is used. Therefore we recommend 64-bit environments for this type of
session replication, as well as regular monitoring of heap usage.
In addition to the tuning discussed in the previous section for cluster tuning, additional
tunings are applied below:
68
WEBSPHERE PORTAL 7.0 TUNING GUIDE
JVM HEAP
JVM heap size, the new area size, and the shared class cache size are increased to
accommodate the memory requirement.
Parameter
Value used
Initial and
Maximum heap
size
4096 MB
New Area Size
-Xmn1024m
Shared Class Cache
Size
-Xscmx150m
SESSION PERSISTENCE TUNING
Table 32: WebSphere Mem-Mem Session Persistence Tuning
Parameter
Session in
memory count
Setting
40000
Additional Details
The default value of Session in memory count is 1000.
For Session persistence enabled load, we set session
in memory count to 40000. We pick this number to be
large enough to cover the expected working set of
active sessions. Use PMI to monitor your session count
and adjust accordingly.
How-To Set Parameter:
In the WebSphere Administrative Console: Servers 
Application Servers  WebSphere Portal  Container
Settings: Session Management  Max in memory
- Set Max in memory
Write frequency
Time based 10
seconds
Write contents
Only updated
attributes
Schedule
sessions cleanup
false
How-To Set Parameter:
In the WebSphere Administrative Console: Servers 
Application Servers  WebSphere Portal  Container
Settings: Session Management  Distributed
environment settings  Custom tuning parameters 
Custom settings  Write frequency.
How-To Set Parameter:
In the WebSphere Administrative Console: Servers 
Application Servers  WebSphere Portal  Container
Settings:  Session Management
DistributedEnvironment Settings  Custom tuning
parameters Custom settings Write contents
How-To Set Parameter:
In the WebSphere Administrative Console: Servers 
Application Servers  WebSphere Portal  Container
Settings:  Session Management
DistributedEnvironment Settings  Custom tuning
parameters  Custom settings  uncheck ‘Schedule
sessions cleanup’
69
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WAS FIXPACK
WebSphere Fixpack 7.0.0.13 includes numerous fixes benefit to a cluster. Therefore we
recommend using this fixpack level or later.
AIX NETWORK
AIX Kernel parameter somaxconn specifies the maximum listen backlog for TCP
connections. This parameter was increased to 32767 to handle the load in our
measurement. This was set for all three Portal nodes.
See AIX Network tuning on how to set it.
PLUGIN
The following plugin parameter is set:

IgnoreAffinityRequests: false (default=true)
IgnoreAffinityRequests specifies whether the plugin ignores the number of affinity
requests made to a server when selecting servers based on the Round Robin
algorithm. We have found setting it to ‘false’ resulted in better load balancing,
particularly in a session persistence enabled environment.
Find more description and how-to set it in,
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.
nd.multiplatform.doc/info/ae/ae/rwsv_plugincfg.html
Session Persistence To Database Tuning
To enable Session Persistence to Database, a data source with non-XA JDBC driver must
be created. We also configured 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 33: WebSphere Session Persistence Tuning
Parameter
Setting
Additional Details
70
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Session in
memory count
40000
The default value of Session in memory count is 1000.
For Session database persistence enabled load, we set
session in memory count to 40000. We pick this
number to be large enough to cover the expected
working set of active sessions. Use PMI to monitor your
session count and adjust accordingly.
How-To Set Parameter:
In the WebSphere Administrative Console: Servers 
Application Servers  WebSphere Portal  Container
Settings: Session Management  Max in memory
- Set Max in memory
Allow overflow
disable
Session
Distributed
Environment
Enable with
database 32K
page tablespace
ConnectionPool
size for Session
Data Source
Min=10
Max=35
Prepared
Statement Cache
size for Session
Data Source
15
The default value of session allow overflow is checked.
This was disabled for session database persistence to
limit the total number of sessions held in memory.
How-To Set Parameter:
In the WebSphere Administrative Console: Servers 
Application Servers  WebSphere Portal  Container
Settings: Session Management  Allow overflow 
uncheck it.
How-To Set Parameter:
In the WebSphere Administrative Console: Servers 
Application Servers  WebSphere Portal  Container
Settings Session Management
DistributedEnvironment Settings database
Jndi name: jdbc/sessions (set it according to your
Session datasource)
Userid/password: set it according to your session db
DB2 Row size: ROW_SIZE_32KB
Tablespace name=sess_user32k (set it according to
your db tablespace)
Multiple row schema: uncheck it
Refer to Datasource Tuning For DB2 on how-to set
parameter.
Refer to Datasource Tuning For DB2 on how-to set
parameter.
SESSION DATABASE TUNING
We use IBM DB2 database server for persisting the sessions. 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=*
71
WEBSPHERE PORTAL 7.0 TUNING GUIDE
# 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
db2
db2
db2
db2
db2
db2
db2
“update
“update
“update
“update
“update
“update
“update
“update
db
db
db
db
db
db
db
db
cfg
cfg
cfg
cfg
cfg
cfg
cfg
cfg
for
for
for
for
for
for
for
for
<sess70>
<sess70>
<sess70>
<sess70>
<sess70>
<sess70>
<sess70>
<sess70>
using
using
using
using
using
using
using
using
locklist 5120”
maxlocks 80”
dbheap 4800”
num_iocleaners 20”
num_ioservers 20”
logbufsz 256”
logfilsiz 12288”
logprimary 40”
Vertical Cluster Tuning
We set the following in our vertical cluster environment,
 See Dynacache Custom Properties in Cluster Tuning section to reduce the number and
size of Dynacache messages sent between JVMs. Additional DynaCache properties
for Vertical Cluster:
Dynacache
Value
com.ibm.ws.cache.CacheConfig.cacheEntryWindow
10
com.ibm.ws.cache.CacheConfig.cacheInvalidateEntryWindow
10
com.ibm.ws.cache.CacheConfig.propogateInvalidationNotShared
FALSE

Increase Dynamic cache size to 3500.
How to set: Portal Server  Container Services  Dynamic Cache Service  Cache size
= 3500

See VMM Context Pooling on how to improve the performance of concurrent access to
an LDAP server.

Use the following command to increase DBHEAP for Release database.
db2 “update db cfg for <release> using dbheap 4800”
72
WEBSPHERE PORTAL 7.0 TUNING GUIDE
8

OTHER PERFORMANCE TUNING OPTIONS
In addition to the scenarios discussed above, WebSphere Portal has some other tuning
options which may be useful in specific scenarios. These options include:

Use of the nested group cache

Recording last login time for users

Optimizing the retrieval of permissions in access control

Improving portal startup performance

Managing the retrieval of user attributes

Use of dynamic content features

Personalization best practices

Real-world network considerations
Nested Group Cache
In previous versions of this guide, we recommended disabling the nested group cache
(com.ibm.wps.ac.groupmanagement.NestedGroupCache). It’s important to understand how
this cache is used so that it can be set appropriately for your environment.
In some environments – including the lab environment for our performance measurements –
nested groups are not used for access permissions. In such cases, two settings can be used
to improvement performance: disable nested group support, and disable the nested group
cache. This is done with the following two settings:
73
WEBSPHERE PORTAL 7.0 TUNING GUIDE
CacheManagerService setting:
cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache.
enabled=false
AccessControlDataManagementService setting:
accessControlDataManagement.enableNestedGroups=false
However, if permissions are assigned to nested groups, then it is not appropriate to disable
nested group support, so the settings above should not be used. In particular, disabling the
nested group cache while nested group support is enabled can cause significant
performance problem, especially in environments that use third-party authentication
software like IBM Tivoli Access Manager (TAM) WebSEAL.
Recording Last Login Time for Users
By default, WebSphere Portal will record the time a user logs in. This is used for reporting on
the number of users who have logged in recently, and is also needed for session resume
support. If none of these features are needed, then it is possible to disable recording the
user’s last login time. This will eliminate an insert or update operation on the USER_DESC
table on each user login.
More information about user session persistence is given in the WebSphere Portal
information center, under the topic “Configuring user session persistance”. The following
values are prerequisites for disabling the recording of the user last login time:
timeout.resume.session=true
persistent.session.level=0
Do not change these without first understanding the functional impact as described in the
information center.
To disable recording the last login time, change the setting record.lastlogin to false in
the Portal ConfigService.
Optimizing Retrieval of Permissions in Access Control
In WebSphere Portal, permissions are granted by assigning a principal to a specific role.
There are four types of principals:

Users

Groups

Virtual users (the anonymous "user")
74
WEBSPHERE PORTAL 7.0 TUNING GUIDE

Virtual groups (all authenticated users).
When determining a user’s permissions, WebSphere Portal will check for permission
assignments in its access control database for all of these types of principals. However, in
some Portal sites, one or more of these classes of principals has no roles assigned. For
example, if groups are not used for access control, then there would presumably be no roles
assigned to groups.
In this case, a performance optimization is possible. By telling WebSphere Portal that no
roles are assigned to certain types of principals, these queries will never be run. This can
save processing time on the portal server and the database server.
Since roles are always on resources within a specific domain, this performance optimization
is specified at the level of a resource domain. Thus the configuration will tell WebSphere
Portal that "No role assignments exist for this type of principal in this domain" - for example,
"No role assignments exist for Groups in the Community domain".
To enable this performance optimization, first determine which types of principals won't have
role assignments, and in which domains. Then for each principal type + domain pair which
will
not
have
role
assignments,
add
an
entry
to
AccessControlDataManagementService.properties. The format is:
accessControlDataManagement.domain.domain-name.disableRolesFor.
principal-type=true
Replace domain-name with the desired resource domain and principal-type with the
desired type of principal. For example, to indicate that no role assignments exist for Groups
in the Community domain, the setting would be:
accessControlDataManagement.domain.community.disableRolesFor.groups=false
The principal types are specified as follows:

Users: users

Groups: groups

Virtual users: v_users

Virtual groups: v_groups
If requirements change and role assignments which have been disabled are again needed,
this setting can be undone by setting the value to ‘false’. For example, to make use of role
assignments for Groups in the Community domain, the setting would be changed to:
accessControlDataManagement.domain.community.disableRolesFor.groups=true
75
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Improving Portal Startup Performance
WebSphere Portal 7.0 has two options for reducing the time required to start the application
server. These two options are:

Development mode: development mode is intended for software development and
testing environments. It is not intended for use in high-load or production
environments, as runtime performance may be negatively impacted in such
environments.

Portal light mode: light mode is usable in production or test environments. Startup
performance is improved. In addition, most deployments will see some reduction in
memory consumption.
WEBSPHERE PORTAL DEVELOPMENT MODE
WebSphere Portal 7.0 introduced a “development mode” that greatly improves startup
performance, so that WebSphere Portal will start more quickly. This can be very useful for
development environments where WebSphere Portal must be stopped and started
frequently.
However, it’s important to note that this mode is only meant to be used for development or
test environments, not production or performance benchmark environments. Development
mode turns on lazy-start for almost all applications in WebSphere Portal, and this can cause
a performance impact the first time an application is accessed under load. Development
mode also changes the way the JVM is started to give better startup speed at the cost of
reducing capacity under load.
To switch to development mode, run the enable-develop-mode-startup-performance
configuration task to complete the configuration and optimize the portal startup. The
changes can be reverted to the original values using the disable-develop-modestartup-performance configuration task.
For more information, please visit the following URL:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/index.jsp?topic=/com.ibm.wp.ent.doc/install/inst_opt.html
WEBSPHERE PORTAL LIGHT
MODE
WebSphere Portal 7.0 and above provides a new portal light mode which can improve portal
startup time and reduce memory consumption in production environments.
For more information, please visit the following URL: http://www10.lotus.com/ldd/portalwiki.nsf/dx/Enabling_and_disabling_portal_light_mode_wp7
76
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Managing the Retrieval of User Attributes
A user directory doesn’t just contain a user’s ID and password; it also contains a number of
other pieces of information – attributes – about the user. A directory server can contain a lot
of attributes for each user, so if every reference to a user required retrieving all of these
attributes, this would impose a performance penalty on both the Portal server node(s) and
the directory server node(s).
Therefore WebSphere Portal attempts to optimize the loading of these attributes. Two sets
of user attributes are defined: the base set of attributes, and the minimum set of attributes.
Depending on what action caused the user to be retrieved from the directory, either the base
or the minimum set of attributes will be retrieved. Typically, the base set of attributes will be
loaded when the user is retrieved; for example, this is what occurs when a user logs in. If the
user was looked up when searching for users, then the minimum set of attributes will be
loaded. For example, this can occur when searching for users to assign access to a page.
By default, WebSphere Portal defines the user attribute sets as follows:


Base set: the following attributes are in the base set:
o uid
o cn
o sn
o preferredLanguage
o ibm-primaryEmail
o givenName
o displayName
Minimum set:
o uid
o cn
What happens if additional attributes are needed? For example, consider a portlet which
requires the user attribute countryName. Assume that the user in question was looked up on
login, so the base set of attributes was retrieved. The attribute countryName isn’t in the base
set, so the full user record – with all of its attributes – will be retrieved from the directory
server at that point. This will require a second request to the directory server. Also, since all
user attributes are retrieved on the second request, this can end up consuming more
memory on the WebSphere Portal server.
This provides an important performance tuning point to both improve response times and
reduce load on the directory server. If a user attribute will commonly be needed, then it
should be included in the base set of attributes so that it’s retrieved on the initial lookup,
eliminating the need for a second request. However, if an attribute is only needed
infrequently, consider leaving it out of the base set of attributes, so that it’s not retrieved for
all users.
77
WEBSPHERE PORTAL 7.0 TUNING GUIDE
I D E N T I F Y I N G A F U L L F E T C H O F U S E R AT T R I B U T E S
How can you identify a second request is made to the directory server to retrieve the full set
of user attributes? This is best done in a test or staging environment, rather than a live
production environment, as it requires turning on tracing in the portal server, and this can
impose a significant performance overhead. There are two traces to enable to look for this
condition. The first one will show if the all the needed user attributes have been retrieved. If
this is false, then a full fetch of the user information will occur. The second trace shows
which attributes are being requested, so you can tell which ones should be added to the
base set.
The two trace strings are:
com.ibm.wps.um.PrincipalImpl=all=enabled
com.ibm.wps.um.PumaProfileImpl=all=enabled
Enable those traces, and then execute the use case you wish to test. Then, look for this
message in the trace.log:
PrincipalImpl 3 com.ibm.wps.um.PrincipalImpl isCompletelyLoaded false
This message may be output multiple times for the same user, so check all occurrences of
it. If the value after isCompletelyLoaded is always true, then all the needed attributes have
already been loaded, and no changes are needed. In this example, the value after
isCompletelyLoaded is false, showing that the needed user attributes haven’t all been
loaded. This will result in reloading all the user information from the user directory.
In that case, the trace will then typically show a call to reload the information for that user;
this will tell the full distinguished name of the user whose information is being loaded from
the user directory:
PrincipalImpl > com.ibm.wps.um.PrincipalImpl reload ENTRY id: cn=Yin
Yin_000_992, cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software
Group,dc=ibm,dc=com
Next, search above that in the trace for the getAttributes call, which will show the attributes
the user has requested. It will look like this:
PumaProfileIm > com.ibm.wps.um.PumaProfileImpl getAttributes ENTRY id:
cn=Yin Yin_000_992, cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software
Group,dc=ibm,dc=com
…more user details follow…
isExternal: false
[preferredLanguage, ibm-primaryEmail, countryName, displayName,
givenName, cn, sn, uid]
The last line of the log entry shows the attributes being requested. In this case, the attributes
being requested are [preferredLanguage, ibm-primaryEmail, countryName,
78
WEBSPHERE PORTAL 7.0 TUNING GUIDE
displayName, givenName, cn, sn, uid]. Comparing this against the list of base user
attributes, we can see that countryName is not in the base user attributes. Depending on
whether the action being executed is a common one or not, consider adding this to the base
set of attributes.
M I N I M U M AT T R I B U T E S E T
Generally, the minimum set of attributes does not need to be modified from the default
provided by WebSphere Portal, as that attribute set is satisfactory for the user management
applications provided with WebSphere Portal. However, if your site contains a custom
application for managing users and groups, and it uses attributes other than those in the
minimum set, then you should consider expanding the minimum attribute set.
Use of Dynamic Content Features
WebSphere Portal contains dynamic content support infrastructure which supports two
dynamic content features: dynamic user interfaces and attribute based administration. If
neither of these features is being used, the dynamic content support can be disabled. Note
that attribute based administration is only one use of the Personalization capabilities in
WebSphere Portal; other uses of Personalization, such as placing content spots within a
portlet, do not require the dynamic content features.
Disabling the dynamic content features will provide a modest performance benefit. It will
provide a reduction in the memory needed for each user, and also reduce the processing
time for generating pages in WebSphere Portal. For example, in one measurement with our
Base Portal scenario, capacity improved about 5% when disabling the dynamic content
support.
Disabling dynamic content support is done by adding a custom property to the
ConfigService.properties resource provider. The property is:
content.topology.dynamic=false
See “Overview of configuration services” in the WebSphere Portal information center for
more information on how to update configuration properties.
Personalization Best Practices
WebSphere Portal Personalization lets you choose content for users, based on information
in their profiles and on business rules. More information about Personalization is available in
the Portal Information Center, under the topic “Personalizing your content”.
If your site is using Personalization, you’ll want to make sure you’re getting the best possible
performance as well. Performance topics for Personalization are discussed in “Best
79
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Practices for using Personalization in WebSphere Portal”, available at http://www10.lotus.com/ldd/portalwiki.nsf/dx/personalization-best-practices.
Real-World Network Considerations
In our lab environment, we had the luxury of our clients and servers being on the same LAN
segment, so that they could take advantage of a high-bandwidth, low-latency network
connection. However, this is typically not the case for real clients. Over a wide-area network,
latencies can be significant, and bandwidth limited. In this case, the time to transfer the page
content from the server to the client can become a significant contributor to overall page
response time.
Here are some steps which can help alleviate this situation:

Compress content on the HTTP server

Allow client-side caching of images, Javascript files, and stylesheets,

Set the Login page to cacheable
Details on these steps will be given below.
COMPRESS CONTENT ON THE HTTP SERVER
Much of the content served by a WebSphere Portal site can be compressed to reduce
transmission time and save network bandwidth. Typically, images should not be
compressed (as they are usually stored in a compressed format), but other types of content
can show a significant size reduction from compression.
IBM HTTP Server supports Deflate compression through the mod_deflate module. When it
is enabled, the HTTP server checks the Accept-Encoding: header sent by the browser to
see if it can accept a compressed version of the content. If so, the HTTP server will
compress the content before sending it to the browser.
We’ve observed issues using mod_deflate in conjunction with mod_cache. Therefore we
do not recommend using both in the same HTTP-server deployment.
In one measurement, we observed an average of 65% network traffic reduction when
Deflate compression is enabled. However, the compression operation does not come free
as we also observed approximately a 10% processor utilization increase on the HTTP
server.
80
WEBSPHERE PORTAL 7.0 TUNING GUIDE
To enable gzip compression in IBM HTTP Server, add the following lines in httpd.conf:
# compress everything but images
LoadModule deflate_module modules/mod_deflate.so
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|exe)$ no-gzip dont-vary
ENABLING CLIENT-SIDE CACHING
The HTTP protocol allows the server to tell clients how long they can cache responses.
When the client has the content in their cache, they do not need to request it again, saving
the round-trip time to the server to retrieve the content.
This is done by adding Cache-Control: headers to the content which we wish to make
cacheable. By default, WebSphere Portal will include these headers in the stylesheets it
uses, making that content cacheable at a client for 5 days (432,000 seconds). It is possible
to use mod_headers in IBM HTTP Server to add the same headers to images, JavaScript
and other static content by adding the following lines to httpd.conf:
LoadModule headers_module modules/mod_headers.so
<LocationMatch "\.(gif|jpeg|jpg|png|ico|jsp|css|js|swf|json)$">
header set Cache-Control "public,max-age=86400"
</LocationMatch>
Portlet Caching
Portlet caching is not particularly relevant for Page Builder theme in server side rendering mode,
but it could be useful for client side rendering and the theme.
portlet.xml is part of a portlet’s war file. It is located in the portlet’s WEB-INF directory. To make
portlet fragments publicly cacheable set:
1. <expiration-cache>28800</expiration-cache>
2. <cache-scope>public</cache-scope>
81
WEBSPHERE PORTAL 7.0 TUNING GUIDE
SETTING THE LOGIN PAGE TO CACHEABLE
It is possible to set the page that unauthenticated users use to login at as shared and
cacheable. For heavily used sites, setting the default homepage to cacheable, even for 5
minutes, could make a site more responsive.
1. Login to portal as administrator and navigate to the administration page
2. Select Portal User InterfaceManage Pages
3. Search by “Title starts with” Login
4. Edit Page Properties of the Login Page.
5. Expand “Page Cache Options”
6. Set the Cache Scope to “Shared cache across users” radio button
7. Under Cache Expiration click the radio button “Cache expires after this many
seconds”. Set the value to a value such as 6000.
8. Click OK to save.
9. That puts you back on the main ‘administration’ page
10. Select Portlet ManagementPortlets.
11. If the Login portlet is not showing, search by ‘Title starts with’ Login
12. Click “Configure Portlet” (the wrench icon) for the Login portlet
13. Under Cache Scope for HTTP and fragment caches, select “Share cache across all
users)
14. Under Cache Expiration for HTTP and fragment caches select “Portlet cache expires
after this many seconds”. Set the value to a value such as 6000.
15. Click OK
82
82
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
9

WEBSPHERE PORTAL CACHES
In the preceding chapter we described the specific values we modified for the WebSphere
Portal caches in our environments. This chapter describes the WebSphere Portal caches,
the general parameters for those caches, which cache instances WebSphere Portal V7.0
provides, and some sample portal usage patterns along with suggestions on portal cache
properties.
General Information
With WebSphere Portal V7.0, portal configuration properties, including cache configuration
properties, are managed via the WebSphere Application Server administrative console. In
previous WebSphere Portal releases these configuration properties were maintained in
properties files. More information on how to modify portal configuration properties can be
found in the Setting configuration properties section of the WebSphere Portal Version 7.0
information center.
C A C H E C O N F I G U R AT I O N
PROPERTIES
The cache configuration properties are organized in two groups: global configuration
properties and cache instance specific properties. Global properties have the prefix
cacheglobal and apply to all caches unless they are specifically overridden with a cache
instance specific property.
Cache instance specific properties have the prefix
cacheinstance and then contain the name of the cache instance and the name of the
property, for example:
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.USER_GROUP.
size
All entries of a cache are governed by a single set of properties.
The cache configuration properties that are safe to modify are: enabled, lifetime,
size, shared, replacement, and admit-threshold. The replacement and admit83
83
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
threshold properties do not apply to all cache implementations. In general, only caches
that are not shared will use these properties. There are other properties that should not be
modified unless specifically instructed to do so by IBM WebSphere Portal support.
enabled: The enabled property determines whether a cache is used or not. If a cache is
not enabled, the property has a value of false, then no values are held by the cache
and every cache lookup will return a null value. This property should only be
modified for testing purposes, never in a production environment. The supported
values are true and false and the global default value is true.
lifetime: The lifetime property determines the number of seconds an entry will exist
in a cache. A cache no longer returns an entry once the entry has existed longer
than the lifetime property. Cache entries can also be invalidated prior to reaching
their lifetime due to explicit invalidation of the entry or Least Recently Used (LRU)
eviction from the cache.
A value of -1 indicates an infinite lifetime. This value should be used with caution
since cache entries will only be invalidated programmatically. Infinite lifetimes are
particularly discouraged with access control caches because:
 In a cluster there can be rare occurrences when not all cache invalidation
messages are processed on every node due to race conditions in the
application server’s dynacache code. While the probability of this occurring is
low, it can not be completely avoided with the current code base. Finite
lifetimes allow these entries to be invalidated.
 Finite lifetimes allow modifications made to roles, which have been
externalized to an External Security Manager, to be reflected in role caches.
If updates to production environments are restricted to a well-defined staging process
using XML Access, it is usually safe to use infinite lifetimes.
size: The maximum number of entries in a cache is limited by the size property. If this size
limit is reached, entries are removed from the cache by an algorithm which usually
includes 1) remove invalidated entries and entries which have exceeded their lifetime
and 2) apply a LRU algorithm to the valid entries.
Any positive integer is allowed. Cache sizes have a direct impact on the memory
requirements of your portal, specifically the demands on the Java heap. You should
monitor and record the Java heap metrics and any performance impact when
modifying the size of a cache.
shared: Cluster-aware caches are shared across the nodes of a cluster. These caches
propagate invalidations of cache entries by using the WebSphere Application Server
DistributedMap interface.
84
84
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
Supported values are true and false. The default values shipped in WebSphere
Portal V7.0 should apply to most configurations. If you do not have a cluster there
may be a small performance benefit to setting this property to false since a different
cache implementation is used. We did not modify the defaults in our single node
measurement environments.
If this parameter is false in a cluster, it can ultimately lead to data inconsistencies
between the cluster members.
replacement: The cache replacement algorithm used by these caches works on the
frequency of recent access to cache entries; entries that have been used
frequently are less likely to be discarded than entries that have not been used
frequently. This parameter controls how long the access history will be kept. A
setting of aggressive means those only recently accessed entries will be
considered, which causes stale entries to be discarded more quickly. The
opposite setting, conservative, will consider a longer access history. The
intermediate setting of moderate is appropriate for most caches.
admit-threshold: Caches that have a very high insert rate may cause useful entries to
be discarded prematurely. An admittance threshold restricts the rate at which entries
are allowed into the cache by only allowing them to enter after an attempt has been
made to insert the same entry into the cache multiple times. The default value of 0
means “no admittance threshold”, which will allow entries into the cache on the first
insert attempt. This is appropriate for most caches. A higher value indicates that a
cache entry will not be allowed into the cache until that many attempts have been
made to insert the same key. For example, a value of 2 means that the first two
attempts to insert a cache entry will be ignored, and the third attempt will insert the
value into the cache. We did not modify the admit-threshold for any cache in
our measurement environments.
Cache Usage Patterns
Most WebSphere Portal caches follow the simple paradigm: if an entry already exists use it,
otherwise add the entry. However, there are caches that behave differently. Each cache
follows one of the following four patterns:

Pattern: regular
The regular pattern, described earlier, is the most common cache pattern:
value = cache.get(key);
if (value == null) {
value = calculateNewValue();
cache.put(key, value);
}
85
85
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E

Pattern: invalidation checking
Invalidating cache entries in a clustered environment is rather expensive. Therefore, portal caches often check whether the entry to be
invalidated actually exists in the local cache.
test = cache.get(key);
if (test != null) {
cache.invalidate(key);
}
Caches following this pattern follow the regular pattern for all but invalidation
actions.

Pattern: multiple object types
Most caches hold only a single object type. When caches can hold multiple types,
they follow the regular pattern for each of those types.

Pattern: cascading object types
This pattern is a special case of the ‘multiple object types’ pattern in that two or more object types that are queried in a certain order are
stored in a single cache. There may be one cache hit along with a cache miss on a regular basis.
value = cache.get(keyA);
if (value == null) {
value = cache.get(keyB);
if (value == null) {
value = calculateNewValue();
cache.put(keyA || keyB, value);
}
}
86
// either key could be used
86
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
Cache Instances
This section describes the caches in WebSphere Portal V7.0 along with hints to best
configure those caches. As you saw in the modifications we made in our measurement
environments, the size and lifetime properties are the most commonly modified
properties when tuning portal caches. You may wish to increase the size of a cache if many
values are used on a regular basis and there is sufficient space available in the Java heap.
You may wish to increase the lifetime of the entries of a cache if the cached data rarely, if
ever, changes and it is not critical to your business to reflect changes immediately in your
portal.
The changes mentioned in this section are set in the file
{wp_profile}/PortalServer/config/CacheManagersService.properties and are put into effect
by running configengine update-properties as described elsewhere in this document.
Each cache description includes the following attributes:

Default size, default lifetime and cache usage pattern

Cache content and scaling factor (i.e. what causes the cache to grow)

Information on the read and write access to the cache

Approximate costs for re-creating cache entries and relative size of cached
objects. Small objects range from 16 to 300 bytes and the largest cache entries are
not larger than a few thousand bytes. One known exception are access control
caches in systems with many resources per user can hold entries that are very large,
beyond 50,000 bytes, to reflect all the resources which a user can access.

Some cache descriptions include a sample scenario with suggested property
values.
ACCESS CONTROL
1
This section describes each of the access control caches. It is critical for proper operation of
a portal that the access control information be current. Hence it is vital that these caches be
shared within a cluster so that the information is propagated to all members of the cluster.
Different lifetime values should be chosen to avoid concurrent reload of information from
multiple caches. This pattern of rather random lifetime and invalidation intervals could also
be applied to other caches.
The access control caches are divided into two groups: those caches (the first caches in the
list) used during all access control operations in all portal setups and those caches (starting
1
This section is partially taken from another whitepaper: Portal Access Control Performance Tuning: http://www128.ibm.com/developerworks/websphere/library/techarticles/0508_buehler/0508_buehler.html
87
87
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
with the cache com.ibm.wps.ac.ApplicationRoleOIDCache) used for the WebSphere
Portal Composite Application Infrastructure.
Figure 1 shows the relationships among the various caches. The small cylinders represent
cache instances. The green caches are caches of the portal user management (PUMA)
component that are closely related to the caches of the portal access control component.
The PUMA caches contain information originating from the user registry. Portal access
control uses these caches for user identification and group membership retrieval.
The vertical axis represents the cache aggregation direction. The cache instances in layer N
leverage cache instances of lower layers to compute their values. For example, when
computing effective permissions (entitlements) for a user (cached in the
ExplicitEntitlementsCache), the portal access control component leverages existing
cache values from the ChildResourcesCache and RoleMappingCache.
Figure 2 Portal Access Control Cache Hierarchy
com.ibm.wps.ac.PermissionCollectionCache
Default size: 2000, default lifetime: 10240, usage pattern: regular (admit-threshold).
This cache contains permission collections that can be used for permission checks. It
scales with the number of permissions in the system, i.e. the number of portal resources
and permissions assigned on those. Entries in the cache typically are requested very
frequently during permission checks. An admit-threshold is used to avoid caching rarely
used permissions. You may wish to try different admit-threshold settings to tune this
88
88
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
cache. Entries are never invalidated from the cache. Creating a cache entry is very fast
since all required information is in-memory. A cache entry is small.
com.ibm.wps.ac.AccessControlUserContextCache
Default size: 8000, default lifetime: 1200, usage pattern: regular.
This cache contains the access control user context objects, a local cache for
permissions assigned to a specific user. If possible all requests against access control
are answered using this information so that access control methods can return very
quickly. This cache scales with the number of active users. For fast portal operation, you
should make sure that the entries for all actively working users fit into the cache,
especially if a user has access to many portal resources. Entries are invalidated from the
cache upon any portal administrative action. Creating a cache entry typically is rather
cheap because most information is in-memory, but can take a while if the required
information cannot be found in other caches. An entry in the cache can be become very
large, depending on the number of resources the user can access.
com.ibm.wps.ac.ProtectedResourceCache
Default size: 5000, default lifetime: 10143, usage pattern: regular.
This cache contains the resources protected by portal access control. The size of this
cache scales with the number of protected resources accessed by the active users in the
system. Entries are read from the cache during every permission call or entitlements call
against access control. Entries are invalidated from this cache during resource deletion,
resource relocation, modification of the resource state (private/shared), modification of
the resource owner, externalization, internalization, and role block change. Creating a
cache entry requires a single-row lookup in the portal database. An entry in the cache is
relatively small.
com.ibm.wps.ac.OwnedResourcesCache
Default size: 5000, default lifetime: 10043, usage pattern: invalidation checking.
This cache maps resource owners (user groups or individual users) to the resources
they own. This cache scales with the number of active users/groups multiplied with the
different ResourceTypes they access. There is one entry in the cache per principal per
resource type per WebSphere Portal domain. Data is read from this cache during many
portal access control requests, if the corresponding entitlements are not already cached
in an entitlements cache. Entries are invalidated from this cache during resource
deletion, modification of the resource owner, externalization, and logout of the user.
Creating a cache entry means executing a multi-row query against the portal database.
An entry in the cache is relatively small.
89
89
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
com.ibm.wps.ac.RolesCache
Default size: 10000, default lifetime: 3630, usage pattern: invalidation checking.
This cache contains the role instances. The size of this cache scales with the number of
active users/groups multiplied by the different ResourceTypes they access. There is
one entry per role instance per principal per resource type per WebSphere Portal
domain. Data is read from the cache during many portal access control requests, if the
corresponding entitlements are not already cached. Entries are invalidated from this
cache during role mapping creation, role mapping deletion, resource deletion,
externalization, internalization, and logout of the user. Creating a cache entry means
executing at least one, but potentially multiple database queries. An entry in the cache is
relatively small.
com.ibm.wps.ac.ExplicitEntitlementsCache.* and
com.ibm.wps.ac.ChildEntitlementsCache
Default size: 10000, default lifetime: varying (around 10000), usage pattern: invalidation
checking.
These caches contain the permissions of a user or group on a number of resources of
the same ResourceType. There are dedicated caches for the different
ResourceTypes. For example, the cache for pages is called com.ibm.wps.ac.
ExplicitEntitlementsCache.CONTENT_NODE. All ResourceTypes that are not
specified explicitly will be cached in the default cache. The size of this cache scales with
the number of active users/groups multiplied by the different ResourceTypes valid for
this cache and accessed by the users and groups, either by ‘using’ the resource during
navigating the portal or by portal administration. There is one entry per set of
permissions per WebSphere Portal domain. Entries are read during ‘regular’ access
control requests, during page rendering and, especially, during portal administration. If a
certain resource type is not used, you will see only misses and no other activity on the
corresponding cache. Entries are invalidated from this cache during all access control
modifications and logins. Creating an entry in one of these caches typically can be done
from in-memory information in the lower-level caches. If the required information is not
available multiple database requests might be required to create a cache entry. An entry
into the cache is rather small, but built of multiple objects typically stored in other caches.
com.ibm.wps.ac.ExternalOIDCache
Default size: 10000, default lifetime: 8640, usage pattern: regular.
This cache contains the mapping between the external ObjectIDs of individual
protected resources, for example page or portlet IDs, and the portal access control
specific ObjectIDs stored in the database table PROT_RES. Entries are read from the
cache during many portal access control requests. The size of this cache scales with the
number of protected resources accessed by the active users in the system. Since this
mapping is immutable, this cache is never explicitly invalidated. Creating a cache entry
requires a single row database query. An entry in the cache is fairly small.
90
90
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
com.ibm.wps.ac.groupmanagement.NestedGroupCache /
com.ibm.wps.ac.groupmanagement.GroupCache
Default size: 1000, default lifetime: 3600, usage pattern: regular.
Only one of these two caches is used in a WebSphere Portal installation depending on
your ‘nested groups’ setting. If nested groups are supported, the NestedGroupCache
cache will be used, otherwise the GroupCache is used. The caches contain the nested or
direct groups to which a user belongs. The size of this cache scales with the number of
active users and the number of virtual portals they access. The cache is accessed during
login into portal, but typically not during regular portal navigation. Its main use case is
during administration of users and user groups. Entries are invalidated from this cache
during login of the user and after user and group administrative changes. Creating a new
cache entry requires queries against the WMM component and then typically against the
user repository. An entry in the cache is medium-sized.
com.ibm.wps.ac.ChildResourcesCache
Default size: 1000, default lifetime: 7200, usage pattern: regular.
This cache contains the resource hierarchy within portal access control. The size of this
cache scales with the number of protected resources accessed by the active users in the
system, like the protected resources cache. This cache does not contain leaf objects in
the access control tree, so the number of entries typically is smaller. The cache is
accessed during most portal access control requests. Entries are invalidated from this
cache during resource deletion, parent change of the resource, modification of the
resource owner, externalization, internalization, and role block change. Creating a cache
entry includes a multi-row query against the portal database. An entry in the cache is
fairly small.
com.ibm.wps.ac.ApplicationRoleOIDCache
Default size: 5000, default lifetime: 7650, usage pattern: regular.
This cache maps application role names to the corresponding object IDs. It scales with
the number of application roles defined in the system. Data is read from the cache
frequently when accessing or administering composite applications. In all other situations
the cache is basically not used at all. Entries are invalidated when application roles are
deleted. There is one entry in the cache per application role per WebSphere Portal
domain, except for the customization domain. Creating a cache entry means reading a
single row of data from the portal database. A cache entry is fairly small.
com.ibm.wps.ac.ApplicationRoleDescriptorCache
Default size: 5000, default lifetime: 8450, usage pattern: regular.
This cache maps the object ID of an application role to its corresponding descriptor
object, which contains the application name, parent application and other information.
The cache scales with the number of application roles defined in the system. Data is
read from the cache frequently when accessing or administering composite applications.
91
91
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
In all other situations the cache is basically not used at all. Creating a cache entry means
reading a single row of data from the portal database. A cache entry is medium-sized.
com.ibm.wps.ac.ApplicationRolesForPrincipalCache
Default size: 5000, default lifetime: 8760, usage pattern: regular.
This cache maps the available application roles to a portal user. It scales with the
number of active users in the system. Data is read from the cache frequently when
accessing or administering composite applications. In addition this cache is also used as
a lookup for application role information even if no application roles are used. Hence you
will see frequent read access on this cache under all circumstances. Creating a cache
entry is rather expensive. It involves three multi-row queries against three WebSphere
Portal domains. A cache entry is medium-sized.
com.ibm.wps.ac.ContainedRolesCache
Default size: 5000, default lifetime: 8650, usage pattern: regular.
This cache contains the mappings between application roles and the ‘regular’ roles
defined in them. The cache scales with the number of application roles in the system.
There is one entry for every WebSphere Portal domain. Data is read from the cache
frequently when accessing or administering composite applications. In all other situations
the cache is basically not used at all. Creating a cache entry is rather expensive. It
involves two multi-row queries. A cache entry is medium-sized.
com.ibm.wps.ac.ApplicationRoleChildrenCache
Default size: 5000, default lifetime: 8760, usage pattern: regular.
This cache is not used in WebSphere Portal V7.0.
com.ibm.wps.ac.ParentResourceRoleMappingCache and
com.ibm.wps.ac.ResourceRoleMappingCache
Default size: 1000, default lifetime: infinite, usage pattern: regular.
These two caches are used for special access control scenarios and typically are not
accessed during portal processing. Settings of these caches should not be modified
PORTAL USER MANAGEMENT
The following caches are used by the portal user management component (PUMA). In so
far they are closely related to the access control caches and caching within WMM.
com.ibm.wps.puma.DN_OID_Cache / com.ibm.wps.puma.OID_DN_Cache
Default size: 1500, default lifetime: infinite, usage pattern: regular.
These two caches contain the mapping between the distinguished name of users and
groups and their internal ObjectID identifier. The size of these caches scales with the
92
92
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
number of active users and groups or users and groups that are used for delegation.
Entries are invalidated from this cache during deletion of a user or group. Creating an
entry requires one database lookup. An entry into the caches is fairly small.
D AT A S T O R E
The datastore caches contain data read from the portal database. It is not the goal of these
caches to be a complete image of the DB content, but to have frequently-accessed but raw
information available for all other portal components to use.
com.ibm.wps.datastore.services.Identification.OidAndUniqueName.cache
Default size: 5000, default lifetime: infinite, usage pattern: regular.
This cache stores unique names. It is used quite frequently during page rendering and
especially administration of unique names. Page and portlet unique names make up the
biggest part of the cache content. The cache should be large enough to hold entries for
the most frequently used pages and portlets having a unique name associated with
them. Note that not all resources have a unique name associated with them. To
eliminate database lookups the cache size could correspond to the database table
UNIQUE_NAME multiplied by two, to allow for mapping in two directions. Creating a
cache entry involves reading one entry from the portal database. An entry object into the
cache is fairly small.
com.ibm.wps.datastore.PortalIdCache.vpPerLpid.cache
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache maps long Virtual Portal object IDs to the corresponding portal internal short
ID. It scales with the number of virtual portals in the system, plus one additional entry. It
is used heavily only if more than one virtual portal exists in the system. Data is read from
the cache during every rendering request then. For optimal caching the size should be
set to the number of Virtual Portals defined in the system. Creating a cache entry
involves one single-row database lookup. An entry object into the cache is fairly small.
com.ibm.wps.datastore.PortalIdCache.explicitLpidPerVP
Default size: 100, default lifetime: infinite, usage pattern: regular.
This cache maps the short object ID for a virtual portal to the corresponding long ID. In
comparison to cache com.ibm.wps.datastore.PortalIdCache.vpPerLpid.cache it
stores the reverse mappings. Hence all other descriptions given above also apply here.
com.ibm.wps.datastore.pageinstance.OIDCache
Default size: 3000, default lifetime: infinite, usage pattern: regular.
This cache stores information on portal pages for fast retrieval during login or page
navigation. It scales with the number of page instances in the system. It is one of the
most frequently used caches and should be large enough to hold all pages that are
93
93
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
frequently accessed by users. Pages are loaded and put into the cache by direct
navigation, creating a link to another page or by working with the page during portal
administration (always including all higher derivation levels). Creating a cache entry
includes one single-row database lookup. An entry to the cache is medium sized. To
achieve best performance, in terms of cache hit rate, the size should be set to a value so
that all pages defined in the system fit into the cache. This corresponds to the row count
of the database table PAGE_INST.
com.ibm.wps.datastore.pageinstance.DerivationCache
Default size: 3000, default lifetime: infinite, usage pattern: regular.
This cache stores the mappings between pages and their derivation children, or empty
mappings if no such children exist. Like the pageinstance.OIDCache cache this one
also is accessed very frequently during page rendering and administration. Creating a
cache entry involves one multi-row database query. This cache also scales with the
number of pages in the system. Hence, you can use the same sizes for the previous
cache and this one. In most portal usage scenarios the actual size of this cache will be
somewhat lower than with the page instance cache. An average entry in the cache is
rather small. Only if all your pages have long lists of derivation children will the entries
become larger. To achieve best performance, in terms of cache hit rate, the size should
be set to a value so that all pages defined in the system fit into the cache. This
corresponds to the row count of the database table PAGE_INST.
com.ibm.wps.datastore.pageinstance.DynamicNodeCache
Default size: 5, default lifetime: infinite, usage pattern: regular.
This cache stores one list per domain. These lists contain all pages in the corresponding
domain that are flagged as dynamic nodes, i.e. dynamic assembly content nodes can be
added below these pages. Since the number of domains does not grow, the size as well
as other properties of this cache should not be modified. The size of one entry into the
cache ranges from small in a portal with very few dynamic nodes up to medium with
many dynamic nodes in the system.
com.ibm.wps.datastore.services.Identification.SerializedOidString.cache
Default size: 2500, default lifetime: infinite, usage pattern: cascading object types.
This cache stores serialized ObjectIDs used in request parameters or XML Access
files. It contains a subset of all the loaded ObjectIDs in memory. In so far it scales with
the number of ObjectIDs in the system, but not for all of these IDs the serialized
version is requested, hence the actual size is impossible to predict. The cache is used
during every request. Creating a cache entry is rather cheap. Typically all information
can be retrieved in memory, database lookups are scarcely necessary. A cache entry is
fairly small.
94
94
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
MODEL
The model caches can be categorized into two groups: One group of caches is accessed
during every portal request during page rendering. The second group of caches is especially
important for administrative actions. Hence those caches are especially important in those
environments where content and portal administration is done. Most run-time caches have
the name suffix live; the administrative caches have the suffix isolated.
Figure 29 describes the hierarchy of caches in the model component and depending portal
components. The structure of the picture is identical to figure 28: The vertical axis shows
caches with increasing aggregation of data. The model component only caches data at a
rather high aggregation level. All data cached here hence is rather valuable, reloads can be
expensive if the corresponding data is not available in the lower-level caches. Model caches
are dependent upon the datastore and portal access control caches. The figure only
features the most important caches.
Figure 3 Portal Model Cache Hierarchy
com.ibm.wps.model.factory.SimpleCacheKey
Default size: 2500, default lifetime: infinite, usage pattern: regular.
This cache is a helper cache for other model caches used by the portal model factory. It
contains a small number of entries based on the model types available in portal. In
addition there can be one entry per active user session. The size of this cache might be
adapted to the number of active sessions in one portal JVM. Re-creating a cache entry is
a rather cheap operation since it usually can be accomplished in memory. A cache entry
is a small object.
95
95
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
com.ibm.wps.model.content.impl.ResourceCache
Default size: 5000, default lifetime: 5600, usage pattern: regular.
This cache contains aggregated pages. In contrast to the data store page instance
cache this cache contains the complete models of pages and their content, i.e. the
portlets and containers on them. The page instance cache rather holds the raw page
data. This cache scales with the number of pages defined in your portal and the different
sets of access control rights on these pages. This cache contains very ‘valuable’
information; it utilizes several other caches, for example, page instance and access
control caches, to build its data. Hence creating a cache entry usually only requires inmemory information, but can also lead to many database queries. The size of an entry in
the cache depends on the complexity of the pages, but typically the objects are mediumsized, since they are usually made of references to other cached data. The cache should
be large enough to hold the most frequently accessed pages multiplied with the number
of different access control settings on these pages. Increasing the cache lifetime can be
useful if page definitions do not change often in your environment.
Example: A portal has 500 pages and all users have the same permissions on these. In
addition there are another 50 pages; two groups of users have different access rights on
these pages. In this case a maximum of 600 entries would be in the cache.
com.ibm.wsp.mode.content.impl.TopologyCache
Default size: 10000, default lifetime: 5700, usage pattern: regular.
This cache contains portal topology information, i.e. portal navigation elements being
composed of navigation nodes and their sorted, access control-filtered children.
Topology elements undergo several processing steps from first loading from the
database until finally being added to the cache. This cache only contains the completely
processed topology entities. This cache is explicitly used during login and whenever a
user navigates to a part of the portal where he has not been before during the same
session. If a cache entry is not found, a private copy is created that is then further
processed. Once the private copy is completely processed -that does not happen for all
navigation nodes- it is added to the cache. If a user finds an entry in the cache a
reference is copied into his private topology model and additional cache accesses are no
longer necessary. Hence there is only one cache hit (or miss) per user and navigation
node. The cache scales with the number of navigation nodes and the number of different
sets of permissions on these and, possibly, the derivation chain (children and parents) a
page belongs to. Entries in this cache are expensive to create; they rely on other cached
information, like the access control caches and the page instance cache. The entries in
the cache are medium-sized, being mainly some lists of references to other cached data.
The cache should be sized in a way such the most important pages multiplied with all the
different sets of permissions that exist on theses page can be stored.
96
96
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
com.ibm.wps.model.factory.ContentModelCache.live
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This run-time cache contains the content models for portal users. There is one entry per
active portal user. The cache should be large enough to hold all models for these users.
An entry in the cache has the maximum lifetime of the corresponding user session, i.e.
entries are removed at the end of the session. Creating a cache entry can be very
expensive. Typically all required information is in memory, but accessing the database,
also many times, might be necessary if underlying information is also no longer cached.
Furthermore the number of pages summarized in the model can be very large which
also adds to the time it takes to rebuild a cache entry. Building the content model is done
incrementally as required for the current request; the model is not built at once.
Depending on the size of the model also the memory requirements vary. The more
pages a user can access and has accessed already during the current session the larger
the cache entry, ranging from medium to very large. A cache entry typically is composed
of references to other cached and shared objects. Hence an entry size is not made up by
the number of page and all subordinate objects but only contains references to these.
com.ibm.wps.model.factory.ContentModelCache.isolated
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache contains the administrative content models. There is one entry for every user
doing administrative work at a certain point in time. In so far the number of entries in this
cache typically is much lower than in the other cache. But for this cache you should
make sure that no cache entries of active users are evicted. Compare with the content
model run-time cache for all other information.
com.ibm.wps.model.factory.NavigationSelectionModelCache.live
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This run-time cache contains the navigation selection models used by portal users.
There is one entry per user session. The cache should be large enough to hold all these
models for the active users. An entry in the cache has the maximum lifetime of the
corresponding user session, i.e. entries are removed at the end of the session. Creating
a cache entry is less expensive than creating a content model cache entry. Typically all
required information is in memory, but accessing the database might be necessary. In
comparison to the content model cache creating an entry for the navigation selection
model cache is much cheaper. In addition also the in-memory size of elements in this
cache is much smaller since this type of model references fewer objects.
com.ibm.wps.model.factory.NavigationSelectionModelCache.isolated
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache contains navigation selection models used by administrative users. The
details given for the administrative content model cache also apply here.
97
97
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
com.ibm.wps.model.factory.URLMappingCache.live
Default size: 50, default lifetime: infinite, usage pattern: regular.
This cache is the run-time model cache for the URL mappings defined in your portal
installation. It should be large enough to hold all URL mappings defined in your system.
Creating an entry to the cache involves reading one entry from the portal database. A
cache entry is fairly small in size.
com.ibm.wps.model.factory.URLMappingCache.isolated
Default size: 50, default lifetime: infinite, usage pattern: regular.
This cache is the administration cache for URL mappings. The details given for the other
isolated caches also apply here.
com.ibm.wps.model.factory.MultiModelCache.live
Default size: 50, default lifetime: infinite, usage pattern: regular.
This cache contains run-time models for several different resource types in WebSphere
Portal, for example clients, supported markups and languages. One entry, for example,
is a list containing all supported markups. Those resources typically remain stable for a
long time, hence you should mostly experience read accesses to this cache. Creating a
cache entry involves reading the corresponding data from the database. An entry can be
fairly large, but the number is very low so that the total size of this cache is negligible.
com.ibm.wps.model.factory.MultiModelCache.isolated
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache contains the administrative models for several portal resource types.
Typically this cache is empty and not used, because administration on those resource
types is a rare event. There is one entry for every user doing administration on any of the
resource types that are stored in the cache. The creation behavior and size are similar to
the run-time cache.
com.ibm.wps.model.factory.NavigationModelCache.live
Default size: 2, default lifetime: infinite.
This cache is not used in WebSphere Portal V7.0 and hence disabled. Changing any of
its properties does not have any effect.
com.ibm.wps.model.factory.NavigationModelCache.isolated
Default size: 2, default lifetime: infinite.
This cache is not used WebSphere Portal V7.0 and hence disabled. Changing any of its
properties does not have any effect.
98
98
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
com.ibm.wps.model.content.impl.DynamicLoadCache
Default size: 4, default lifetime: 600.
This cache is not used WebSphere Portal V7.0 and hence disabled. Changing any of its
properties does not have any effect.
com.ibm.wps.model.impl.RuntimeClientMap.userAgent2client
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache maps user agent strings, i.e. the identification strings sent by browsers in the
HTTP header, to client profiles. These profiles basically correspond to CC/PP profiles.
Hence the cache scales with the number of browser identification strings. Data from this
cache is accessed during every request. Creating a cache entry is very cheap since the
profile information is in memory already. An entry in the cache hence is fairly small since
already existing data is referenced.
URL MAPPINGS
The following caches contain data on portal URL mappings. Be sure to size the caches in a
way such that these are large enough to hold all defined URL mappings in your system.
wps.mappingurl.ContextsCache
Default size: 500, default lifetime: infinite, usage pattern: regular.
This cache contains URL mapping contexts. It scales with the number of mapping
contexts defined in the system. This cache is used if a URL mapping cannot be resolved
using the lookup cache. Creating an entry involves reading a mapping entry from the
database. An entry in the cache is medium-sized.
wps.mappingurl.LookupCache
Default size: 600, default lifetime: infinite, usage pattern: regular.
This cache is used as a final lookup cache for the computed mappings between (a
hierarchy of) URL mappings and a WebSphere Portal resource. It is accessed during
every request when analyzing the incoming URL for being a URL mapping. The size of
this cache should be the number of all mappings. Creating a cache entry typically is
cheap because the information often s in memory. An entry in the cache is rather small.
VIRTUAL PORTALS
The following group of caches is only relevant if you have defined additional virtual portals in
your system. In all other situations it is safe to set the size of these caches to one and the
lifetime to infinite.
99
99
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
com.ibm.wps.services.vpmapping.VirtualPortalIDToRealmCache
Default size: 120, default lifetime: 3600, usage pattern: regular.
This cache stores the realm information for virtual portals. One realm can contain several
virtual portals, but one virtual portal can only be part of a single realm. As a
consequence, the optimum size of this cache is the number of virtual portals defined in
your environment. You may increase the lifetime for better performance if your setup of
virtual portals changes infrequently. If you only use the default portal and no additional
virtual portal, you will see one entry in the cache and only little traffic on the cache.
Creating a new cache entry requires one database query. An entry into the cache is fairly
small.
com.ibm.wps.services.vpmapping.VirtualPortalIDToURLCache
Default size: 120, default lifetime: 3600, usage pattern: regular.
This cache maps virtual portal IDs to their respective LPID. The LPID usually is used to
create URLs for a specific virtual portal. Since the number of LPIDs is equal to the
number of virtual portal IDs, the optimum size of this cache is the number of Virtual
Portals defined in your environment. You may increase the life time for better
performance if your setup of virtual portals changes infrequently. If you only use the
default portal and no additional virtual portal, you will see one entry in the cache and only
little traffic on the cache.
com.ibm.wps.services.vpmapping.URLToVirtualPortalIDCache
Default size: 120, default lifetime: 3600, usage pattern: regular.
This cache maps LPID values to virtual portal IDs. LPIDs are encoded in a URL that
points to a certain virtual portal. Therefore the number of LPIDs is equal to the number of
virtual portal IDs. Accordingly the optimum size of this cache is the number of virtual
portals defined in your environment. You may increase the lifetime for better
performance if your setup of virtual portals changes infrequently. If you only use the
default portal and no additional virtual portal, you will see one entry in the cache and only
little traffic on the cache.
WSRP
All WSRP caches are only accessed if the portal is used as either a WSRP consumer or
producer. Each of the caches is used on either side of the WSRP communication, but not on
both sides. Most of the WSRP caches are used and read during every WSRP request,
either displaying a page with a provided portlet on it, or administering WSRP properties.
Exceptions to this general rule are noted below.
100
100
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
wsrp.cache.portletdescription
Default size: 500, default lifetime: 3600, usage pattern: regular.
This cache contains the portlet descriptions delivered by producers. These descriptions
could be considered meta information on the provided portlets, like languages and
descriptions. It is used on the producer side. The cache scales with the number of
remote portlets provided by the producer. Increasing the default lifetime can improve
performance if portlet descriptions of the provided portlets change infrequently.
Rebuilding cache entries is rather expensive. It includes loading data from the database
with several calls. The cached entries are rather expensive in terms of memory usage.
wsrp.cache.servicedescription
Default size: 150, default lifetime: infinite, usage pattern: regular
This cache contains service descriptions of WSRP producers. It is used on the
consumer side. It scales with the number of WSRP producers integrated into the
consuming portals; there is exactly one description per producer. The service description
is generated using all the portlet descriptions from the producer portal plus some
additional data. Hence a service description can be large in terms of memory
requirements. Rebuilding the description requires several roundtrips and is an expensive
operation. Cache entries are rebuilt if a user clicks the ‘Browse’ button in the WSRP
administration portlets. This leads to a refresh of all service descriptions of all producers.
This cache is only used during WSRP administration.
wsrp.cache.portlet.instance
Default size: 2500, default lifetime: 3600, usage pattern: regular.
This cache contains the proxy portlet instances on the WSRP consumer side and is only
used there. It scales with the number of integrated remote portlets multiplied with the
number of users having their own customizations of portlet preferences for these remote
portlets (portlet settings for legacy portlets respectively). Creating an entry for the cache
involves one multi-line database query. The size of a cached entry depends on the
number of parameters associated with the portlet. Hence the size ranges from small to
fairly large.
wsrp.cache.producer.user
Default size: 5000, default lifetime: 3600, usage pattern: multiple object types.
This cache contains the descriptor of the producer and context information between
users and producers. It is used on the consumer side. It scales with the total number of
active users accessing remote portlets of these producers, i.e. as a maximum the
number of producers multiplied with the number of active users accessing them plus the
number of producers. Recreating cache entry is fairly expensive. It involves some DB
queries and in-memory operations. Therefore the session timeout should not be higher
than the lifetime of entries in the cache. Cache entries are explicitly invalidated during
user session destruction.
101
101
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
wsrp.cache.portlet.window
Default size: 2500, default lifetime: infinite, usage pattern: regular.
This cache contains a WSRP specific wrapper on a WebSphere Portal portlet entity
object. It is used on the producer side. It scales with the number of provided portlets and
the number of occurrences of these portlets on consumer pages. Recreating cache
entries is rather cheap and typically only includes in-memory operations. An entry into
this cache is fairly small. This cache is accessed very during a request.
wsrp.producer.portletpool.pops
Default size: 1000, default lifetime: infinite, usage pattern: cascading object types.
This cache stores the Producer Offered Portlets and hence scales with their number.
The number of entries in this cache is identical to the number of entries in the
portletdescription cache. The WSRP object model data is stored in here, though.
Offered portlets are first looked up in this cache and, if the lookup is not successful, the in
the ccps cache (see below). Reloading cache entries involves one query against the
database. Cached entries are rather small.
wsrp.producer.portletpool.ccps
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache stores the client configure portlets. It is used on the producer side. It scales
with the number of provided portlets and the number of remote users having
personalized those (Consumer Configured Portlets); hence the maximum would be the
number of provided portlets multiplied by the number of remote users accessing the
producer. Reloading cache entries involves one query against the database. Cached
entries are rather small.
D Y N AM I C A S S E M B LY / P R O C E S S I N T E G R AT I O N
The following caches are used when dynamic UI functionality, often together with
WebSphere Process Server integration are used.
processintegration.PendingTasksCache
Default size: 2500, default lifetime: infinite, usage pattern: regular.
This cache contains the pending process tasks in the scope of a user. The size of this
cache scales with the number of users concurrently using process integration
functionality. Each cache entry consists of a complete set of pending process tasks for a
given user and therefore can be fairly large in memory. Reloading a cache entry involves
accessing the Human Task Manager via an EJB call. The cache is always accessed
when the PendingTasksTag is used in a portlet JSP.
You should also configure the setting processintegration.pendingtasks.lifetime
in ConfigServices.properties which defaults to a value of 30 seconds. This setting
102
102
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
describes the interval at which a process engine is queried for pending tasks of a user
and the cache entries are updated.
wp.te.transformationAssociationCache
Default size: 500, default lifetime: infinite, usage pattern: regular.
This cache contains transformation extension nodes. So typically there are only few
entries in the cache. There is typically one access to the cache per request. Building an
entry to the cache involves one database query. One entry is fairly small. Typically there
is no need to modify the settings for this cache.
POLICY
The WebSphere Portal policy manager uses the following caches.
com.ibm.wps.policy.services.PolicyCacheManager
Default size: 1000, default lifetime: 7780, usage pattern: regular.
This cache stores the policies. Out of the box portal comes with twelve theme policies
and one mail policy, each of them being one entry into the cache. Hence the maximum
number of cache entries depends on your system and the number of custom policies.
This cache is accessed fairly often, if you use policies at all. The WebSphere Portal V7.0
default theme uses policies and query this cache during every request, but it is possible
to create themes that do not use policies at all. Furthermore when opening mails the
cache is accessed. Creating a cache entry involves reading data from a database. An
entry into the cache is fairly small.
com.ibm.wps.policy.services.UserPolicyNodeCacheManager
Default size: 2500, default lifetime: 600, usage pattern: regular.
This cache stores connections between a policy and a policy target, for example a user
distinguished name. Theme policies do not use targets, hence there is no cache entry
based on these policies. The out-of-the-box mail policy uses the user as target. Hence
there is at least one entry for every user accessing the CPP mail portlet. The size of a
cache entry depends on the size of the target object. For a distinguished name a cache
entry is fairly small.
C O L L A B O R AT I O N S E R V I C E S
All of the following caches are used by the DEPP portlets and some services around these
portlets. In so far the caches are not used if the DEPP portlets are not utilized in the portal
system. These caches store credential information needed for the backend servers, server
information for these servers and user information that would otherwise require LDAP
lookups.
103
103
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
com.lotus.cs.services.directory.ldap.BasicLDAPDirectoryService.server
Default size: 50, default lifetime: infinite, usage pattern: regular.
This cache stores mail server information. In so far it scales with the number of different
mail servers used in the environment. It is accessed whenever a mail server is
accessed. Creating a cache entry requires one LDAP search. An entry in the cache is
fairly small.
com.lotus.cs.services.directory.ldap.BasicLDAPDirectoryService.user
Default size: 2000, default lifetime: 10780, usage pattern: regular.
This cache stores user-specific information read from the LDAP. It scales with the
number of users working with DEPP portlets. The cache is accessed during rendering a
DEPP portlet, whenever those need user information. This could be multiple times per
page reload. In addition the cache is accessed whenever a mail server is accessed.
Creating a cache entry is fairly expensive and can involve multiple LDAP lookups. An
entry into the cache is medium-sized.
com.lotus.cs.services.directory.wmm.WMMDirectoryService
Default size: 4000, default lifetime: 10980, usage pattern: regular.
This cache stores user-specific information read from the LDAP and WMM. Entries in
this cache represent a more complete set of data stored in the LDAP than is available in
other parts of WebSphere Portal. The cache scales with the number of users working
with DEPP portlets. The cache is accessed during rendering a DEPP portlet, whenever
those need user information. This could be multiple times per page reload. In addition
the cache is accessed whenever a mail server is accessed. Creating a cache entry is
fairly expensive and can involve multiple LDAP lookups. An entry into the cache is
medium-sized.
com.lotus.cs.services.UserEnvironment
Default size: 2000, default lifetime: 10880, usage pattern: regular.
This cache stores user-specific information. Entries represent a compilation of credential
information for one user to different LDAP directories and details which data on the given
user can be found in which directory. For example, the general info may be stored in one
directory, but the mail server and file may be in another. The cache scales with the
number of users working with DEPP portlets. The cache is accessed whenever a DEPP
portlet is accessed. Creating a cache entry can be fairly expensive since multiple
resources might be queried. An entry to the cache is medium-sized.
com.lotus.cs.services.domino.DominoService
Default size: 2000, default lifetime: 11080, usage pattern: regular.
This cache stores user-specific Domino information. It is used for awareness functions. It
scales with the number of users working with the corresponding function. The cache is
104
104
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
accessed whenever awareness functions are requested during page rendering. Creating
a cache entry is cheap and simply involves creating a new Domino session. An entry to
the cache is medium-sized.
MISCELLANEOUS
This group of caches does not fit in any of the other categories.
com.ibm.wps.pe.portletentity
Default size: 10000, default lifetime: 5800, usage pattern: regular.
This cache contains configuration for portlets on pages (portlet instances, shared and
per-user). It scales with the number of pages defined in your portal, the number of
portlets on the pages and the number of portlet instances that have been personalized
by users. The cache is accessed many times during portal page rendering. In so far it is
important that the most relevant portlet entities are cached. Creating a cache entry
involves a single database lookup. An entry into the cache is fairly small.
Example: In a portal with 500 pages and on average three portlets per page, the optimal
cache size would be 1500 to store all possible portlet entity data in the cache, if users
are not allowed to personalize the portlets. If the portal has 100 users that are logged in
concurrently and these users have personalized 50 portlets on average, the required
cache size to cache all data would be 6500. These numbers give the maximum number
of entries to the cache. Typically for this cache it is not required to have all portlet entities
in memory, because most users will not view all pages so that not all personalized data
must be loaded. The most frequently accessed un-personalized portlet entities should fit
into the cache, though.
com.ibm.wps.services.cache.cachedstate.CachedStateServiceCache.cache
Default size: 50000, default lifetime: 7200, usage pattern: typically regular.
This cache stores session-scoped data in the portal context and is used by various
portal components. This cache scales linearly with the number of active sessions in the
system and the number of portal components using this cache for data retrieval. The
usage pattern, access times, entry creation costs and entry memory sizes depend on
the portal component using this cache and cannot be stated in general.
wp.xml.configitems
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache stores XML Access configuration items. It is used only during XML Access
processing. The entries resemble references between nodes in the XML Access
document. Especially when working with complex XML files, usually used for imports or
Release Builder processes, it can be beneficial to increase the cache size. The cache
will be cleared after XML processing is completed. Reloading a cache entry involves one
database query. Entries in the cache are medium-sized.
105
105
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
PortletMenuCache
Default size: 200, default lifetime: infinite, usage pattern: regular.
This cache contains portlet menu trees for all portlets that define their portal menu as
global, meaning identical for all users. The portal functionality that utilizes this cache is
deprecated with WebSphere Portal Version V7.0.
RegistryService
Default size: 32, default lifetime: infinite, usage pattern: regular.
This cache is used in a cluster for portals to notify the other cluster members when one
of the registries needs to be reloaded due to administrative action. It should never be
disabled or set to shared=false.
com.ibm.workplace.searchmenu.helper.SearchMenuCacheHelper
Default size: 2500, default lifetime: 3730, usage pattern: regular.
This cache stores a variety of information having to do with the search scopes menu,
located at the top of the theme, left to the search box. There are six rather small cache
entries per user. Hence the cache scales directly with the number of users. There are no
invalidations from the cache, but after login a user will always get fresh data from the
cache via a coupling between the cache and the user session. The cache will be
accessed on every subsequent user request for building the search bar. If the search bar
is not used, the cache will not be used, either. Rebuilding the cache is fairly inexpensive,
but it does require some calls to the search engine backend to get the required data.
106
106
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
Example Scenarios
This section describes some example usage scenarios along with descriptions of possible
cache settings and suggested cache sizes. This discussion may be useful as starting point
for the caches in your environment.
GENERAL COMMENTS
Most portal caches fall into one of four groups:
1.
Caches where the number of entries scales with the number of active users. For
example, the access control user context cache (com.ibm.wps.ac.
AccessControlUserContextCache) falls into this category.
2.
Caches where the number of entries scales with the number of users using a
specific function. For example, the cache com.lotus.cs.services.
directory.ldap.BasicLDAPDirectoryService.user falls into this category.
3.
Caches which scale with the number of pages being visited. The resource cache
(com.ibm.wps.model.content.impl.ResourceCache) is an example of this
type.
4.
Caches which scale based on the growth of some other resource, such as URL
mappings, which are stored in the cache com.ibm.wps.model.factory.
URLMappingCache.live.
Those that scale on portal resources should have lifetimes and sizes based on the number
of portal resources in the system and how frequently users access these resources. The
other caches depend upon usage scenarios such as those described in this section.
Most caches have a lifetime associated with them because the cached content might
change over time. For example, access control information could be changed via user
administration in the administrative portlets, XML Access or the WebSphere Portal scripting
interface. All code that uses caches within WebSphere Portal is implemented in a way such
that cache entries that are no longer valid are removed from the cache if the corresponding
information has been changed or deleted. The lifetime therefore is used for three reasons:

Expired cache entries can be removed to free up memory.

There are rare race conditions in cluster setups so that invalidation events are
processed correctly but the cache still reflects wrong data.

Updates within external systems, like an external access control system, will
never become visible.
107
107
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
If there is no or very little administration on your system and you have free memory in the
Java heap available, it is safe to increase the lifetime of cache content to save the additional
workload for reloading cached data.
Now we shall consider some recommendations for specific scenarios.
SMALL NUMBER OF PAGES AND SMALL NUMBER OF USERS
In this scenario a portal only has a limited number of pages and users accessing them. For
example, there might be 200 pages in the system and up to a few hundred users working
with the portal simultaneously. You will find portals of this kind often during development and
testing or in smaller portal production systems.
For portals of this size and usage the default cache values typically are good. Hence only
small modifications to the defaults given above should be required. Nevertheless you should
be careful not to translate those cache settings directly into production for larger user
communities.
SMALL NUMBER OF PAGES AND LARGE NUMBER OF USERS
In this scenario a portal only offers a rather small number of pages to the user. Overall there
might be again only a few hundred pages, maybe with different access rights on them so
that users might see only subsets of the pages. But in this scenario there are thousands of
users accessing the system at the same time. In other words, thousands of users have
active sessions.
Properties of caches that store information on pages typically do not need to be modified in
this scenario. But all caches that store user-dependant information might be a problem.
Assume you have 2000 active users in your system. Per-user caches being sized to only
1000 entries will operate at their upper limit nearly all of the time and constant re-calculating
or re-loading of data from the portal database will the consequence. You should size the
user-dependent caches in a way such that enough entries for the number of currently active
users can remain in memory. We define the number of ‘currently active users’ as those who
have a session and still issue requests against WebSphere Portal. By contrast there are
passive users who still have a session, but no longer issue requests and have forgotten to
log out or simply went away from the screen and let the session time out.
We increased the sizes of the following nine caches in our measurement environments in
such a way that the data of all concurrent users fits into the caches.






com.ibm.wps.model.factory.ContentModelCache.live
com.ibm.wps.ac.ExplicitEntitlements Cache.USER_GROUP
com.ibm.wps.model.factory.NavigationSelectionModelCache.live
com.ibm.wps.datastore.services.Identification.
SerializedOidString.cache
com.ibm.wps.puma.OID_User_Cache
com.ibm.wps.puma.DN_User_Cache
108
108
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E



com.ibm.wps.puma.OID_DN_Cache
com.ibm.wps.puma.DN_Group_Cache
com.ibm.wps.puma.OID_Group_Cache
We increased the lifetimes of all caches to at least one hour.
PORTALS WITH LONG SESSION TIMEOUTS
If the session timeout has a high value, it is likely that there will be a large number of users
who still have sessions with the portal, but who have not interacted with the site for a
significant period of time. These users are known as passive users, and they can cause
some special performance challenges.
In this situation the number of sessions can be much larger. But typically many of these
sessions are ‘passive’. It is typically not necessary to have all information in memory for all
these users when they leave their desk but not the portal, for example during lunch. To find
proper sizes for the portal caches you need a good understanding on the behavior of your
users. Users who have not worked with the portal for more than an hour typically will accept
response times of two or three seconds for their first request after such a long break,
whereas users who work with the portal rather constantly do not want to see their data being
evicted from caches.
For this scenario it is hard to give precise cache size recommendations. The values simply
depend too much on your portal usage scenario. You have to monitor your system and
users closely to determine good values.
PORTALS WITH MANY PAGES
Portals in this group have several thousand pages that are available for larger groups of
users and therefore are potentially accessed quite frequently. We do not count installations
with many customized pages (sometimes known as ‘implicit derivations’) to this group
because these are private resources and are loaded for the current user only. Private data is
not added to the shared portal caches.
For example, your portal could have 5000 pages in total. Half of those are available to all
users; on the other half there are several user groups who have view rights, other have
manage right on those pages. In this case you typically do not want to have all pages and all
corresponding information in memory at all times. But you want to make sure that all
frequently accessed data is in memory. Typically not all portal pages are accessed equally
frequently. The better your page view statistics are, the easier it is for you to tune the portal
caches.
We increased the sizes of the following caches in our measurement environments so that all
frequently-accessed pages, which depend on our scenario, can be cached.


com.ibm.wps.datastore.pageinstance.OIDCache
com.ibm.wps.datastore.pageinstance.DerivationCache
109
109
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
10







com.ibm.wps.model.factory.ContentModelCache
com.ibm.wps.model.factory.NavigationSelectionModelCache
com.ibm.wps.ac.PermissionCollectionCache
com.ibm.wps.ac.ProtectedResourceCache
com.ibm.wps.ac.ExplicitEntitlementsCache.USER_GROUP
com.ibm.wps.datastore.services.Identification.
SerializedOidString
We increased the lifetimes of all caches to at least one hour.
WEB CONTENT MANAGEMENT CACHES
In the preceding chapter we described the specific values we modified for the Web Content
Management (WCM) caches in our environments. This chapter describes the Web Content
Management caches and the general parameters for those caches.
WCM Cache Instances
With WebSphere Portal V7.0, the WCM caches are managed via the WebSphere
Application Server administrative console under Resources > Cache instances > Object
cache instances.
WCM ITEM CACHING
services/cache/iwk/strategy – WCM item caching
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores internal WCM items. Any WCM item read from the database will first
check this cache. WCM items cover Content, Workflow, Workflow Stages, Workflow
actions, Taxonomies, Categories, Authoring Templates, Presentation Templates, Sites,
Siteareas, and all Library Components. The cache entry will be updated or cleared when
its corresponding WCM Item is updated or deleted.
110
110
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
WCM SUMMARY
services/cache/iwk/objectsummary – WCM summaries
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores summaries of WCM Items. The summaries are used to display in lists
in the authoring portlet or used internally in the WCM API to calculate WCM Item
Document IDs used for Iterators. The cache entry will be cleared when a WCM Item is
updated that will affect this summary.
WCM BASIC CACHING
services/cache/iwk/module
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache is used for WCM Basic caching. See the InfoCenter on setting up Basic
caching. The Basic cache stores the entire response. The key is based only on the URL
so all users will see the same response.
ADVANCED AND RESOURC ES
services/cache/iwk/processing – Advanced and Resources
Default size: 2000, default lifetime: 1 month (configurable), usage pattern: regular.
This cache stores the binary MIME for file and image resources in WCM. The maximum
size of resources to store is set in the WCMConfigService.properties file as the property
resourceserver.maxCacheObjectSize (in kb). Resources over this size are not cached
and are streamed directly to the response. The expiry is set in the same file as:
resourceserver.cacheExpiryDate. The cache entry will be cleared when that resource is
updated.
This cache also stores page data if WCM Advanced caching is enabled. See the
InfoCenter for enabling WCM Advanced caching. The processing cache stores
advanced caches for the following types:

Site: Similar to “Basic” Caching except that “Connect Tags” are processed each time.

User: Stores a copy of an item in the cache for each user

Secured: Users that belong to the same groups will access the same cached items

Personalized: Users who have selected the same personalization categories and
keywords, and who belong to the same Group, will access the same cached items
NOTE that the ‘session’ option for Advanced caching is not stored in the processing
cache, but the ‘session’ cache.
111
111
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
SESSION CACHE
services/cache/iwk/session - Session
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores the page data for when session advanced caching is enabled. See the
InfoCenter for enabling WCM Advanced caching.
MENU
services/cache/iwk/menu – Menu
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores WCM Menu entries. An entry comprises of the Content IDs associated
with a particular menu. The entries are retrieved and cached without applying security.
Whenever a user needs that menu’s results, their specific security will then be applied to
the cached results. A dynamic menu, which is one that is affected by the current user’s
context (e.g. based on categories in a users profile) will store a separate cache entry for
each different context. The cache entry will be cleared when a WCM Item is updated that
will affect this menu.
N AV I G AT O R
services/cache/iwk/nav – Navigator
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores parent to child relationships that comprise a WCM navigator. A
complex navigator might have multiple parent to child relationships (e.g. if siblings are
included). The navigator entry is made up of the IDs of the parent and children. This
cache will be cleared upon any WCM Item update in the system.
A B S O L U T E PAT H
services/cache/iwk/abspath – Absolute path
services/cache/iwk/abspathrev – Absolute path reverse lookups
Default size: 5000, default lifetime: infinite, usage pattern: regular.
These two caches store JCR path to WCM item ID relationships (one cache is used for
Path-to-ID relationships, and the other for ID-to-Path relationships). The cache entry will
be cleared when a WCM Item is updated that will affect it. Typically these two caches
should be configured to have the same size.
112
112
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
MISSED ITEMS
services/cache/iwk/missed – Missed items
Default size: 5000, default lifetime: infinite, usage pattern: regular.
This cache stores JCR paths that does not exist. This is used primarily for multi-locale
solutions to determine if items of other locales exist or not. The cache entry will be
cleared when a WCM Item is updated that will affect it.
LIBRARY
services/cache/iwk/global - Library
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache contains a lookup for library id, name and path to the library object. This is
pre-populated up to the cache size at Portal startup.
LIBRARY PARENT
services/cache/iwk/libparent – Library Parent
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores a list of all children library ids to a given parent id. Introduced for
Quickr to group libraries within a teamspace together.
DRAFT SUMMARY
Services/cache/iwk/draftSummary – Draft Summary
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores the identity of the draft summary to the identity of the draft WCM Item.
USER CACHE
User cache
Size is fixed to 2000. By default, this is disabled.
This cache operates using a Least Recently Used algorithm. It is not shared across
nodes in the cluster and it does not use dynacache. It does not update when LDAP
changes. It is disabled by default but can be enabled through setting:
user.cache.enabled=true
This is set in WCMConfigService.properties. Need to run a module called
MemberCacheManager or restart server. To enable the module, add to
WCMConfigService.properties
113
113
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
connect.businesslogic.module.template.class=com.presence.connect.wmmcomms
connect.businesslogic.module.template.remoteaccess=true
connect.businesslogic.module.template.autoload=false
114
114
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
Appendix A. References
WebSphere Portal Information Center:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp
The Tuning section of the WebSphere Application Server Information Center located at:
http://www.ibm.com/software/webservers/appserv/was/library/
Redbook “WebSphere Application Server V7.0 on the Solaris 10 Operation System” located
at:
http://www.redbooks.ibm.com/
WebSphere Portal Benchmark Results:
Contact WPLC Performance team.
DB2 Information Center:
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
Oracle Information Center:
http://www.oracle.com/technology/documentation/database10g.html
The ROLTP factors for IBM pSeries Servers™ can be found at
http://www.ibm.com/servers/eserver/pseries/hardware/system_perf.html
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 Scalability:
http://www.ibm.com/software/webservers/appserv/ws_bestpractices.pdf

WebSphere Portal Performance Troubleshooting Guide
http://www-01.ibm.com/support/docview.wss?uid=swg27007059
115
115
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
Appendix B. Credits
Thanks to the following team members of the WebSphere Portal Performance Team for
contributing to this document.
Mark Alkins, Manager
Lee Backstrom
Gaurav Bhagat
Jan-Paul Buchwald
Andrew Citron
Stephan Laertz
Kyung Chul Lee, Document Coordinator
Klaus Nossek
Denny Pichardo, Technical Lead
Martin Presler-Marshall
John Redmond
Terence Walker
Laura Yen
116
116
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E
®
 Copyright IBM Corporation 2010
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:
Intel is a trademark of Intel Corporation in the U.S. and other countries.
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 PARTICULAR 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 identified 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
117
117
W E B S P H E R E P O R T AL V 7 . 0 . X T U N I N G G U I D E