IBM WebSphere Portal software family
Your world. Your way.
IBM WebSphere Portal 6.1.X
Performance Tuning Guide
IBM WPLC Performance Team
March 2009
Document version 2.1
ABOUT THIS DOCUMENT
This white paper provides a basis for parameter and application tuning for IBM WebSphere Portal for Multiplatform V6.1. 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.
1
???
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.
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.
2
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
???Use of hardware multithreading, also known as Simultaneous Multithreading or
3 2 - B I T A N D 6 4 - B I T C O N S I D E R A T I O N S
The choice of a
A
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
When considering a deployment of WebSphere Portal 6.1, consider the memory demands your applications will have. If you expect a high demand for memory, the best performance will probably come from a
H A R D W A R E M U L T I T H R E A D I N G ( H Y P E R - T H R E A D I N G )
Many modern processor architectures support hardware multithreading. For example, this is known as
3
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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.
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.
4
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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:
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
Customer ports can differ from the ports 10001 or 10027 mentioned on this page. 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:
J V M I N I T I A L A N D M A X I M U M H E A P S I Z E
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.
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.
See instruction on How to get to Admin Console
5
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
J V M M A X I M U M H E A P S I Z E L I M I T S
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 gencon garbage collection policy available in 1.5 IBM JDK which avoids heap fragmentation, this may not be the best choice if you plan to use a different garbage collection. In our measurement runs, the system is under load for a relatively short time (around 3 hours), and it is running with portlets which do not have large memory requirements. When using portlets which have larger memory requirements, or for continuous operation, it may be possible to reduce heap fragmentation by setting the initial heap size to 320 megabytes.
???After doing any tuning of heap sizes, monitor the system to make sure that paging is not occurring. As mentioned above, paging can cause poor performance.
???
???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.
Due to the demands on native memory by WebSphere Portal V6.1 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
On Solaris and zLinux, we use 3.5GB heap size in
J V M H E A P L A R G E P A G E
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
WebSphere Portal
Large pages are supported by systems running Linux kernels V2.6 or higher. See JVM Large Page Tuning for AIX Operation System.
J V M L A R G E P A G E T U N I N G O N A I X O P E R A T I N G S Y S T E M
To use JVM Large Page, AIX operating system must be configured to support large pages.
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
reboot
vmo
chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE $USER
2.Add:
3.In the WebSphere Administrative Console: Servers ??? Application Servers ???
WebSphere Portal ??? Server Infrastructure: Java and Process Management???Process
4.Restart Portal Server. To verify if large pages are being used, run the AIX command vmstat
7
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
J V M H E A P N E W A R E A S I Z E
The Generational Garbage Collector introduced in Java 5.0 is efficient to Portal application JVM memory management, and it is set as default by installation with the
The
How To Set: In the WebSphere Administrative Console: Servers ??? Application Servers ???
WebSphere Portal ??? Server Infrastructure: Java and Process Management???Process Definition ??? Java Virtual Machine
A D D I T I O N A L S U N J V M A R G U M E N T S
On the Solaris platform, we use the following Java HotSpot parameters to achieve optimum performance.
Table 1: Additional Sun JVM Settings
8
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
S E S S I O N T I M E O U T
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 hardware, we used a much lower think time, 5 seconds, than was used for other platform hardware measurement of 12 seconds. With a lower thinktime, fewer vusers will result in a heavier load on the system. The reason we lowered the thinktime was specifically to decrease the number of vusers required for this measurement. Our pool of LoadRunner vuser 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
W E B C O N T A I N E R T H R E A D P O O L S I Z E
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
9
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
S E C U R I T Y A T T R I B U T E P R O P A G A T 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 Subject has not been customized, 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 6.1 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:
Table 2: WebSphere Security Attribute Propagation Settings
For com.ibm.CSI.disablePropagationCallerList create a new property, for the other 3 properties, modify their value to ???false???.
Note to WAS 7:
In our WAS 7 environment, we add com.ibm.CSI.disablePropagationCallerList = true, and use the other 3 default true attributes. For was7, this field is accessed through:
1 0
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
V M M C O N T E X T P O O L I N G
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="0" poolTimeOut="0" poolWaitTime="3000" prefPoolSize="30"/>
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.websph ere.base.doc/info/aes/ae/uwim_ldapperfsettings.html
Table 3: VMM Context Pool Setting
O R B S E R V I C E T U N I N G F O R Z / O S
In the WAS Admin Console, set the ORB Service to be "pass by reference" instead of "pass by value" (default) for both server1 and WebSphere_Portal
How to Set:
-Servers??? Application Servers??? server1??? Orb Service
-check box for "Pass by Reference"
-Servers??? Application Servers ???WebSphere_Portal ??? Orb Service
-check box for "Pass by Reference"
1 1
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
The changes should appear on WAS Console
N A V I G A T 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
Table 4: Navigation Service Settings
NavigatorService.properties
R E G I S T R Y S E R V I C E
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. A full list of the types of information managed by the registry service is in table 4.
Table 5: Registry Service Settings
RegistryService.properties
1 3
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
C A C H E M A N A G E R S E R V I C E
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
???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 V6.1, is given in chapter 2. Table 5 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???.
Table 6: Cache Manager Service Settings
CacheManagerService.properties
1 4
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Database Tuning
D A T A S O U R C E T U N I N G F O R D B 2
Multiple databases are used to hold information in WebSphere Portal V6.1. We used six separate DB2 databases, each representing a separate database domain and having their own datasources. These are:
Table 7: DB2 Database Domains
All datasources are configured in a similar manner by logging on to the WebSphere Application Server administrative console. For the prepared statement cache size, the path is Resources ??? JDBC Providers ??? provider name ??? Data Sources ??? datasource name. The provider name and datasource name are based on the names selected for that database during the database transfer step. Look for the parameter Statement cache size.
For the connection pool settings, the path in the WebSphere Application Server administrative console is Resources ??? JDBC Providers ??? Provider name ??? Data Sources ??? Datasource name ??? Connection Pools. The settings are Minimum connections and Maximum connections.
The default settings were used for the prepared statement cache size, and connection pool minimum and maximum sizes.
D B 2 D A T A B A S E S E R V E R T U N I N G
WebSphere Portal V6.1 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.1 fixpack 5 as our database server. WebSphere Portal V6.1 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.
1 5
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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 V6.1 are:
1.Release (release domain). This is the primary database domain used by the Base Portal and Many Pages Scenarios.
2.Customization (customization domain). This database receives some light traffic in our scenarios.
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.
D B 2 O N A I X S E T U P
We configure our DB2 database on AIX using the following setup,
???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 fileset.
Mount
???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
1 6
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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.
D B 2 O N Z / O S S E T U P
After transferring the database tables, first Identify what tables need to be reorganized.
Perform a
???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
R E C O M M E N D E D D A T A B A S E M A I N T E N A N C E F O R D B 2 L U W
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
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
1 7
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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.
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 exceptions in your connection pools.
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.
1 8
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
O R A C L E D A T A B A S E S E R V E R T U N I N G
WebSphere Portal V6.1 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.
P L A N N I N G F O R O R A C L E E N T E R P R I S E E D I T I O N D A T A B A S E
For our Solaris platform measurements we also used Oracle 10G R2 as our database server. WebSphere Portal V6.1 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,
???Database block size: 8k
???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
oUSERS: 2048MB
???Redo log groups: 500MB each.
1 9
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
O R A C L E O N A I X S E T U P
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
???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
???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
O R A C L E E N T E R P R I S E E D I T I O N D A T A B A S E P A R A M E T E R T U N I N G
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 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 8: Oracle Database Tuning
R E C O M M E N D E D O R A C L E D A T A B A S E M A I N T E N A N C E
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 A T A B A S E C O N S I D E R A T 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
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.
2 1
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
Table 9: IDS Tuning
The IBM Tivoli Directory Server uses IBM DB2 as the database server. The database instance and alias are named IDSLDAP. We applied the following tuning to this database:
db2 ???update db config for idsldap using dbheap 4800???
db2 ???update db config for idsldap using num_ioservers 10??? db2 ???update db config for idsldap using num_iocleaners 5??? db2 alter bufferpool LDAPBP size 3690
db2 alter bufferpool IBMDEFAULTBP size 88500
2 2
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Web Server Tuning
We used IBM HTTP Server 6.1 in our measurement environment. The cluster configuration and the Solaris configuration has a remote web server, find the tuning in 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 10: Web Server Tuning
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
We also enabled the
MaxClients and ThreadsPerChild parameters.
We did additional Web Server tuning in Web 2.0 Scenario. See Web 2.0 section for details.
Note: For z/OS, no Web Server was configured.
2 4
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Operating System Tuning
In any
A I X
N E T W O R K T U N I N G
Use
Then remember to ???Save current parameters for NextBoot???.
Table 11: AIX Network Settings
2 5
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
L I N U X
N E T W O R K T U N I N G
For Red Hat Linux and z/Linux (Suse Linux on zOS), we add the following settings to file /etc/sysctl.conf, then run the command: sysctl
To inspect current TCP parameters, run the command: sysctl
Table 12: Linux Network Settings
W I N D O W S 2 0 0 3
N E T W O R K T U N I N G
Use 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 13: Windows Network Settings
S O L A R I S
N E T W O R K T U N I N G
For Solaris, use the ndd command to set the following TCP layer parameters. These will take effect immediately, improving the network layer performance in
Table 14: Solaris Network Settings
K E R N E L T U N I N G
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
projmod
projmod
projmod
projmod
projmod
2 7
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
S O L A R I S C O N T A I N E R
Use Solaris Containers to better utilize your modern, powerful T2 server with hundreds of virtual processors. In our lab, we use Processor Sets to partition virtual processors. We create a vertical cluster with six Portal members, then bind each member to a Solaris Processor Set, this configuration gives the optimum performance result.
The commands we use to setup,
1.???pooladm
2.???pooladm
3.???poolcfg
Create a processor set, named wp_pset1 or your choice, with between 20 and 21 processors. Create one per processor set.
4.???poolcfg
Create resource pool named wp_pool1 or your choice.
Create one per pool.
5.???poolcfg
Join the pool and the processor set with an association.
Do this for each Processor set.
6.???pooladm
Commit the configuration at /etc/pooladm.conf.
7.???poolbind
Bind the resource pool to a Portal process.
Refer to IBM Redbook ???IBM WebSphere Application Server V6.1 on the Solaris 10 Operating System???, sg247584.
2 8
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Z / O S
S Y S T E M T U N I N G
In the PARMLIB member BPXPRMxx check the values of the following parameters:
Table 15: z/OS System Tuning
Required Fixes
The following fix is required to apply in WebSphere Portal Version 6.1 Solaris environment.
PK73368: Cache synchronization issue, deadlocks can occur in the CacheOnRequest class. This fix is included in WebSphere Portal 6.1.0.1 and later.
2 9
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
3
???
WEB 2.0 THEME TUNING
In the Web 2.0 theme environment a reverse proxy was used to cache content outboard of WebSphere Portal. The reverse proxy was set up to take advantage of the fact that portlet fragments are fetchable and cacheable. This avoids having to refetch the entire portal page in many cases. This allowed some content to be fetched without going to the web server or the portal server. Performance can be further improved by having the reverse proxy set up to gzip much of the content.
In general, the same tuning that was used for the Base Portal Scenario described in previous section was used for the Web 2.0 Scenario. The differences in tuning are mentioned below.
JVM Initial and Maximum Heap Size
JVM???s Initial and Maximum heap size (ms and mx) were set to 1280. With higher values the system ran out of native memory under high Vuser load. This can be alleviated by using the
??? Xalwaysclassgc jvm parameter along with setting
Navigator Service Properties
The following values were specified in NavigatorService.properties in addition to the parameters changed in the Base Portal tuning.
Table 16: Navigation Service Settings for Web 2.0 Theme
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Internet Explorer Support of Vary Header
When Internet Explorer 7 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 7, log in as portal administrator and navigate to Administration
Caching Proxy Tuning
The following are the settings and tunings specified in the reverse proxy???s ibmproxy.conf file for the Web 2.0 performance test.
Table 17: Reverse Proxy Settings
3 1
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Web Server Tuning
Http server tuning for cacheability:
#uncommented these 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]
BrowserMatch \bMSIE\s7
#added this for caching of dojo javascript and the theme???s xsl files,
<Location /wps/themes/dojo>
Header set
</Location>
<Location /wps/themes/html/PortalWeb2/xsl>
Header set
</Location>
#info for these directives at http://httpd.apache.org/docs/2.0/mod/mod_expires.html
#http://httpd.apache.org/docs/2.0/mod/mod_headers.html
#set
<FilesMatch "\.(gif|jpeg|jpg|png|ico|css|js|swf)$">
Header set
</FilesMatch>
3 2
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
# expire images after a month in the client's cache. Note that one month expiration worked fine for a performance evaluation in a test lab. It should be set appropriately for your environment where images might be updated more frequently than once a month.
ExpiresActive On
ExpiresByType image/gif A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000
ExpiresByType
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/xml "access plus 1 week"
ExpiresByType application/vnd.mozilla.xul+xml "access plus 1 week"
ExpiresByType
ExpiresByType text/html "access plus 1 week"
ExpiresByType text/xml "access plus 1 week"
Portlet Caching
portlet.xml is part of a portlet???s war file. It is located in the portlet???s
a.
b.
3 3
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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.
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 18: DB2 Database Settings for Many Pages
db2 ???update db cfg for release using dbheap 4800??? db2 ???update db cfg for release using applheapsz 4096??? db2 ???update db cfg for release using logbufsz 256???
db2 ???update db cfg for release using app_ctl_heap_sz 4096??? db2 ???update db cfg for release using num_IOServers 8???
db2 ???update db cfg for release using num_IOCleaners 8???
3 4
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Cache Manager Service
Table 19: Cache Manager Service Settings for Many Pages
Required Fixes
On WebSphere Portal 6.1, PK70946 is required in Many Pages Scenario. This fix is included in WebSphere Portal 6.1.0.1 and later.
3 5
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
5
???
WEB CONTENT MANAGEMENT TUNING
In general, the same tuning that was used for the Base Portal Scenario was used for the WCM authoring, rendering and API Scenario. 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:
3 6
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
WebSphere Portal Service Properties
C A C H E M A N A G E R S E R V I C E
Portal Caches sizes ??? Ignore the Base Portal values and set the following in CacheManagerService.properties:
Table 20: Cache Manager Service Settings for WCM
CacheManagerService.properties File
N A V I G A T I O N S E R V I C E
Portal Navigator Service ??? In addition to the settings mentioned for Base Portal we set the following property to allow public sessions required for rendering portlets on anonymous pages:
Table 21: Navigation Service Settings for WCM
NavigatorService.properties File
WCM Object Cache
Table 22: WCM Object Cache Settings
3 8
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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 to the value false. This file is found in the directory
<wp_profile>/PortalServer/jcr/lib/com/ibm/icm.
3 9
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
DB2 Tuning (Authoring Environment)
M U L T I P L A T 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, three indexes were added to eliminate some troublesome queries that were table scanning.
db2 connect to jcrdb
db2 alter bufferpool IBMDEFAULTBP IMMEDIATE size 26000 db2 alter bufferpool ICMLSMAINBP32 IMMEDIATE size 24000 db2set DB2_ASYNC_IO_MAXFILOP=512
db2 update db cfg for jcrdb using MAXFILOP 512
db2 create index taw_ut01590_idx6 on jcr.icmut01590001 (attr0000001334, itemid, versionid )
db2 reorgchk update statistics on table jcr.icmut01590001 db2 create index taw_entry_idx2 on jcr.ev_entry (parentid) db2 reorgchk update statistics on table jcr.ev_entry
db2 create index taw_ICMSTJCRWSX_2 on jcr.icmstjcrws (basewsid, wstype)
db2 reorgchk update statistics on table jcr.icmstjcrws
db2stop force db2start
4 0
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Z / O S
The following section details the tunings that we made in our DB2 9 for z/OS backend database during our testing. To start here are a few general recommendations:
???When the DB2 z/OS server is on a different server to the Portal/WCM installation, the use of the Universal Driver type 4 database driver is recommended
???For data sharing groups, we additionally recommend enabling Sysplex Distributor to enhance high availability and exploit workload balancing.
In our environment we created nine databases to support WCM on Portal. The release, customization, community, likeminds, and feedback are required for Portal. For WCM, a minimum of two JCR databases are required for scalability and in our environment we used four.
T A B L E S P A C E S
Following DB2 best practices, it is recommended to create all tables into individual tablespaces. This will avoid device contention and provides better monitoring possibilities. Furthermore, most DB2 utilities such as REORG operate with tablespaces rather than tables.
B U F F E R P O O L S
It is also beneficial to create separate bufferpools for use by Portal to avoid contention. When creating your database, ensure that each tablespace/indexspace has a specific bufferpool specified by the BUFFERPOOL/INDEXBP attributes rather than using the DB2 system defaults. It is recommended that a set of bufferpools separate from the Portal databases gets created for the JCR databases. The following table shows the settings for our configuration.
Table 23: DB2 z/OS Bufferpool Settings
Bufferpool settings
Note: When running Portal, DB2 objects like tablespaces will be created dynamically. It is important to keep your default bufferpools well defined to avoid causing contention due to an overloaded bufferpool. This is especially true for LOB and
4 1
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
to BP0. In DB2 9 for z/OS, ZPARM???s can be set to specifiy default bufferpools. In our environment we used the following values.
Table 24: DB2 z/OS Default Bufferpool Settings
Default Bufferpool Settings
D B 2 F O R Z / O S V 8 F I X E S
The following fixes are required for running WCM on WPS 610x on DB2 for z/OS v8.
???PK62728 - DB2 improves the performance of selected queries (UK36555)
???PK67292 - DB2 was fixed to transform the subquery into a join (UK37970)
???PK68259 - Addresses CORRELATED SUBQUERY TO JOIN TRANSFORMATION
ENHANCEMENT FOR
A D D I T I O N A L R E S O U R C E S F O R D B 2 Z / O S
???WCM/JCR database table usage information for WebSphere Portal v6
???Performance Improvement Possible For Remote TCP Access to z/OS
???DB2 9 for z/OS Performance Topics http://www.redbooks.ibm.com/redbooks/pdfs/sg247473.pdf
4 2
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
6
???
COMPOSITE APPLICATIONS TUNING
For the Composite Application Infrastructure scenario, we started with the tuning given in the Base Portal Scenario above. However, the Composite Application Infrastructure scenario accesses a large number of applications, and therefore a large number of pages and portlets. Therefore there is higher demand on some of the caches in WebSphere Portal; to improve performance in this scenario, we modified the sizes of some of the caches in WebSphere Portal.
Cache Manager Service Properties
The following values were specified in CacheManagerService.properties in addition to the parameters changed in the Base Portal tuning. We recommend that you monitor the caches in your environment to determine which caches might need tuning.
Table 25: Cache Manager Serivce Properties for Application Infrastructure
Composite Applications Best Practices
As with other components of WebSphere Portal, the way in which teamspaces are used will influence the performance of the site. Based on our experience and analysis, the following tips can help you achieve better performance with teamspaces:
???As the measurements above show, the number of teamspaces on the system influences the capacity of the system. However, the key determining factor is not the total number of teamspaces, but rather the number of teamspaces visible to each user. For example, a site with 1,000 teamspaces visible to all users could have a capacity lower than a site with 5,000 teamspaces where the typical user can see no more than 50 of those.
???One way to exploit the observation above is to not make teamspaces public by default. Public teamspaces are visible to all users, so a large number of public teamspaces will increase the average number of teamspaces visible to each user.
4 4
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
???To paraphrase Albert Einstein, ???keep teamspaces as simple as possible, but no simpler???. In implementing this, consider both the number of pages as well as the number of portlets on each page. Adding additional pages or portlets to a teamspace increases the overhead associated with that teamspace. While this is not a great overhead when considering an individual teamspace, when aggregated across thousands of teamspaces, the overhead can become significant. In addition, the more portlets are on each page, the more work will required to render that page.
???Another area to consider regarding teamspace complexity is the number of application roles. For many teamspaces, two roles (manager and user) are adequate. Don???t create additional roles unless they are really needed.
???When assigning membership to a teamspace, the best performance will be seen when membership is assigned by groups rather than by individual users. For example, WebSphere Portal will cache permissions based on the way permissions are assigned, giving the chance for more cache hits if permissions are assigned by groups.
???Memory demand increases with the number of teamspaces on the system. Therefore, if you expect to use large numbers of teamspaces, a
See also the section regarding ???Use of Dynamic Content Features???. Experiments in our lab showed a reduced demand for memory, and thus an improvement in capacity, in the application infrastructure scenario when disabling dynamic content support.
4 5
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
7
???
CLUSTER TUNING
The Base Portal Scenario is measured in a
In general, the same tuning that was used for the Base Portal Scenario was used for cluster. The additional settings are mentioned below:
Application Server Tuning
D Y N A C A C H E C U S T O M P R O P E R T I E S
There are several properties which can be set to reduce the number and size of Dynacache messages sent between nodes. This will improve scalability and reduce resource consumption in a clustered Portal environment. To set these properties, do the following:
1)Open and log in to the Administrative Console.
2)Click Application servers
3)Under General Properties, add the following information:
Name: com.ibm.ws.cache.CacheConfig.ignoreValueInInvalidationEvent
Value: true
Name: com.ibm.ws.cache.CacheConfig.filterTimeOutInvalidation
Value: true
Name: com.ibm.ws.cache.CacheConfig.filterLRUInvalidation
Value: true
Z / O S D Y N A C A C H E C U S T O M P R O P E R T Y
A custom property has been defined: com.ibm.ws.cache.CacheConfig. propogateInvalidationsNotShared, which when set to true leads to invalidations being sent for cache entry insertions and updates for a NOT_SHARED cache instance. This property should be removed on z/OS configurations as it has a major impact on performance.
4 6
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
T H R E A D P O O L S
Increase Default Thread Pool size to help DRS traffic.
T R A N S P O R T B U F F E R S I Z E
Default Transport Buffer size is insufficient. We increase to 200MB.
Portal
Must also configure the same size for Node Agent & DM.
System Administration
System Administration
W M M C O N T E X T P O O L I N G
Tuning Cluster for WMM Context Pooling must be done in Deployment Manager, then do full resync to each node from Administrative Console. See VMM Context Pooling on how to set.
4 7
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Web Server Tuning
Table 26: Web Server Tuning for Clusters
MaxRequestsPerChild 0 </IfModule>
4 8
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Session Persistence To Database Tuning
To enable Session Persistence to Database, a data source with
S E S S I O N D A T A B A S E T U N I N G
In addition to creating bufferpool and tablespace to support 32K page size for Session database, we applied the following tunings to our dedicated session database server,
db2set DB2_USE_ALTERNATE_PAGE_CLEANING=ON db2set DB2_RR_TO_RS=YES
db2set DB2_PARALLEL_IO=*
# disable session tablespace FILE SYSTEM CACHING
db2 alter tablespace sess_user32k NO FILE SYSTEM CACHING db2 alter tablespace sess_temp32k NO FILE SYSTEM CACHING
db2 ???update db cfg for <sess61> using locklist 5120??? db2 ???update db cfg for <sess61> using maxlocks 80??? db2 ???update db cfg for <sess61> using dbheap 4800???
db2 ???update db cfg for <sess61> using num_iocleaners 20??? db2 ???update db cfg for <sess61> using num_ioservers 20??? db2 ???update db cfg for <sess61> using logbufsz 256???
db2 ???update db cfg for <sess61> using logfilsiz 12288??? db2 ???update db cfg for <sess61> using 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:
Name: com.ibm.ws.cache.CacheConfig.cacheEntryWindow Value: 10
Name: com.ibm.ws.cache.CacheConfig.cacheInvalidateEntryWindow Value: 10
Name:com.ibm.ws.cache.CacheConfig.propogateInvalidationNotSharedValue: false
Name: com.ibm.ws.cache.CacheConfig.useServerClassLoader Value: true
???See Transport Buffer Size in Cluster Tuning section to increase transfer buffer size.
???Increase Dynamic cache size to 3500.
How to set: Portal Server
???See WMM 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???
5 0
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
IBM Tivoli Directory Server Tuning
The following table shows the tuning values used for the directory servers.
Table 28: IDS Tuning in Vertical Cluster
The IBM Tivoli Directory Server uses IBM DB2 as the database server. The database instance and alias are named IDSLDAP. We applied the following tuning to this database:
db2 ???update db config for idsldap using dbheap 4800???
db2 ???update db config for idsldap using num_iocleaners 5??? db2 ???update db config for idsldap using num_ioservers 10??? db2 alter bufferpool IBMDEFAULTBP size 88500
db2 alter bufferpool LDAPBP size 3690
Required Fixes
???The following fixes are required to apply in 6.1 Cluster environment,
???PK67324 (for Windows is PK67800)
???WAS DynaCache PK67942
???WAS DynaCache PK59026 (include PK62850 and prereq PK67942), to eliminate renounce messages
???PK70944: to eliminate GroupCache invalidation
???PK70890: Friendly URL fix
???The following fix is required to apply in 6.1.0.1 Cluster environment
PK76988: Cluster performance Degradation by large amount of DRS invalidation messages
5 1
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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:
???Improving portal startup performance
???Managing the retrieval of user attributes
???Use of dynamic content features
Improving Portal Startup Performance
WebSphere Portal 6.1 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
To switch to development mode, run the
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
5 2
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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.
5 3
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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 A T 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,
The last line of the log entry shows the attributes being requested. In this case, the attributes being requested are [preferredLanguage,
5 4
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
M I N I M U M A T 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.
5 5
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
Here are some steps which can help alleviate this situation:
???Compress content on the HTTP server
???Allow
C O M P R E S S C O N T E N T O N T H E H T T P S E R V E R
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
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.
To enable deflate 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...
5 6
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
BrowserMatch ^Mozilla/4
#Netscape
#MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE
#Don't compress images
SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png|exe)$
E N A B L I N G C L I E N T - S I D E C A C H I N G
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
This is done by adding
LoadModule headers_module modules/mod_headers.so
<Location ~ "\.(js|gif|jpg|jpeg|png)$">
Header add
</Location>
5 7
W E BS P HE R E P O R T AL V 6 . 1 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 v6.1 provides, and, finally, some sample portal usage patterns along with suggestions on portal cache properties.
General Information
With WebSphere Portal V6.1, 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 6.1 information center.
C A C H E C O N F I G U R A T I O N P R O P E R T I E S
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
5 8
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
???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
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:
DistributedMap interface.
5 9
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Supported values are true and false. The default values shipped in WebSphere Portal V6.1 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.
6 0
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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);
}
???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.
6 1
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
Cache Instances
This section describes the caches in WebSphere Portal V6.1 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.
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
???Some cache descriptions include a sample scenario with suggested property values.
A C C E S S C O N T R O L 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 with the cache com.ibm.wps.ac.ApplicationRoleOIDCache) used for the WebSphere Portal Composite Application Infrastructure.
1 This section is partially taken from another whitepaper: Portal Access Control Performance Tuning: http://www- 128.ibm.com/developerworks/websphere/library/techarticles/0508_buehler/0508_buehler.html
6 2
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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 1 Portal Access Control Cache Hierarchy
com.ibm.wps.ac.PermissionCollectionCache
Default size: 2000, default lifetime: 10240, usage pattern: regular
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
6 3
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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
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
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
6 4
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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.
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 aresupported, the NestedGroupCache cache will be used, otherwise the GroupCache is used. The caches contain the nested
6 5
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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
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. 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
6 6
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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
com.ibm.wps.ac.ApplicationRoleChildrenCache
Default size: 5000, default lifetime: 8760, usage pattern: regular.
This cache is not used in WebSphere Portal V6.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
P O R T A L U S E R M A N A G E M E N T
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 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.
6 7
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
D A T 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
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
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 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
6 8
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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.
M O D E L
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
6 9
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
Figure 2 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.
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
7 0
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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 in- memory 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 medium- sized, 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
com.ibm.wps.model.factory.ContentModelCache.live
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This
7 1
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
com.ibm.wps.model.factory.NavigationSelectionModelCache.live
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This
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.
com.ibm.wps.model.factory.URLMappingCache.live
Default size: 50, default lifetime: infinite, usage pattern: regular.
This cache is the
7 2
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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
com.ibm.wps.model.factory.NavigationModelCache.live
Default size: 2, default lifetime: infinite.
This cache is not used in WebSphere Portal V6.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 V6.0 and hence disabled. Changing any of its properties does not have any effect.
com.ibm.wps.model.content.impl.DynamicLoadCache
Default size: 4, default lifetime: 600.
This cache is not used WebSphere Portal V6.0 and hence disabled. Changing any of its properties does not have any effect.
7 3
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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.
U R L M A P P I N G S
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
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.
V I R T U A L P O R T A L S
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.
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
7 4
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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.
W S R P
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.
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.
7 5
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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
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
7 6
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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 A M I C A S S E M B L Y / P R O C E S S I N T E G R A T 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 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
7 7
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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.
P O L I C Y
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 V6.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
C O L L A B O R A T 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.
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.
7 8
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
com.lotus.cs.services.directory.ldap.BasicLDAPDirectoryService.user
Default size: 2000, default lifetime: 10780, usage pattern: regular.
This cache stores
com.lotus.cs.services.directory.wmm.WMMDirectoryService
Default size: 4000, default lifetime: 10980, usage pattern: regular.
This cache stores
com.lotus.cs.services.UserEnvironment
Default size: 2000, default lifetime: 10880, usage pattern: regular.
This cache stores
com.lotus.cs.services.domino.DominoService
Default size: 2000, default lifetime: 11080, usage pattern: regular.
This cache stores
M I S C E L L A N E O U S
This group of caches does not fit in any of the other categories.
7 9
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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
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
com.ibm.wps.services.cache.cachedstate.CachedStateServiceCache.cache
Default size: 50000, default lifetime: 7200, usage pattern: typically regular.
This cache stores
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
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 V6.0.
8 0
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
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.
8 1
W E BS P HE R E P O R T AL V 6 . 1 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.
G E N E R A L C O M M E N T S
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.
8 2
W E BS P HE R E P O R T AL V 6 . 1 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.
S M A L L N U M B E R O F P A G E S A N D S M A L L N U M B E R O F U S E R S
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.
S M A L L N U M B E R O F P A G E S A N D L A R G E N U M B E R O F U S E R S
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
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
8 3
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
???com.ibm.wps.puma.OID_User_Cache
???com.ibm.wps.puma.DN_User_Cache
???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.
P O R T A L S W I T H L O N G S E S S I O N T I M E O U T S
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.
P O R T A L S W I T H M A N Y P A G E S
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.
8 4
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
We increased the sizes of the following caches in our measurement environments so that all
???com.ibm.wps.datastore.pageinstance.OIDCache
???com.ibm.wps.datastore.pageinstance.DerivationCache
???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.
8 5
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
10
???
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 V6.1, the WCM caches are managed via the WebSphere Application Server administrative console under Resources > Cache instances > Object cache instances.
W C M I T E M C A C H I N G
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.
W C M S U M M A R Y
services/cache/iwk/objectsummary ??? WCM Summary
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.
8 6
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
W C M B A S I C C A C H I N G
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.
A D V A N C E D A N D R E S O U R C E S
services/cache/iwk/processing ??? Advanced and Resour ces
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 Ta gs??? 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 cachingis not stored in the processing cache, but the ???session??? cache.
S E S S I O N C A C H E
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.
8 7
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
M E N U
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 A V I G A T 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 P A T H
services/cache/iwk/abspath ??? Absolute path
Default size: 5000, default lifetime: infinite, usage pattern: regular.
This cache stores JCR path to id relationships. The cache entry will be cleared when a WCM Item is updated that will affect it.
M I S S E D I T E M S
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.
L I B R A R Y
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
8 8
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
L I B R A R Y P A R E N T
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.
D R A F T S U M M A R Y
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.
U S E R C A C H E
User cache
Size is fixed to 2000. default 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
in WCMConfigService.properties. Need to run a module called MemberCacheManager or restart server. To enable the module, add to WCMConfigService.properties
connect.businesslogic.module.template.class=com.presence.connect.wmmcomms
connect.businesslogic.module.template.remoteaccess=true
connect.businesslogic.module.template.autoload=false
8 9
W E BS P HE R E P O R T AL V 6 . 1 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/v6r1m0/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 V6.1 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 f ound at
http://www.ibm.com/servers/eserver/pseries/hardware/system_perf.html
For additional
???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
???Diagnosing Performance Problems for WebSphere Portal 5.1 (though this document was written for WebSphere Portal 5.1, the lessons apply to WebSphere Portal 6.1 as well):
http://www.ibm.com/support/docview.wss?uid=swg27007059
9 0
W E BS P HE R E P O R T AL V 6 . 1 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, Document Coordinator
Andrew Citron
Nathan Cook
Sabine Forkel
Uwe Haller
Shibi John
Klaus Nossek
Kyung Lee
Denny Pichardo, Technical Lead
Martin
Terence Walker
Laura Yen, Document Coordinator
Sonja Zwissler
Kenny Sabir
Maria Sueli Almeida
Alesio Pfeifer
Joerg Huehne
David De Vos
Mike Coletta
9 1
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E
??
??? Copyright IBM Corporation 2008
IBM United States of America
Produced in the United States of America
All Rights Reserved
The
Lotus and Domino are trademarks of Lotus Development Corporation and/or IBM Corporation.
The following are trademarks of other companies:
Linux is a registered trademark of Linus Torvalds.
Solaris, Java and all
Windows and Windows 2003 Enterprise Server are trademarks of Microsoft Corporation in the United States and/or other countries
Oracle 10 and all
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
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
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
9 2
W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E