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.
Contents PERFORMANCE TUNING OVERVIEW ............................................................................................................... 2 Environment Considerations ................................................................................................................ 3 32-bit and 64-bit Considerations ....................................................................................................... 3 Hardware Multithreading (Hyper-Threading) ......................................
Web Server Tuning ......................................................................................................................... 32 Portlet Caching .............................................................................................................................. 33 MANY PAGES TUNING ................................................................................................................................ 34 DB2 Database Tuning .....................................................
WEBSPHERE PORTAL CACHES.................................................................................................................... 58 General Information ........................................................................................................................ 58 Cache Configuration Properties ..................................................................................................... 58 Cache Usage Patterns ..................................................................
Figures Figure 1 Portal Access Control Cache Hierarchy .................................................................................................. 63 Figure 2 Portal Model Cache Hierarchy.............................................................................................................. 70 Tables Table 1: Additional Sun JVM Settings ..................................................................................................................
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.
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.
Environment Considerations Before beginning your install of WebSphere Portal you should consider how to use the environment in order to achieve ideal performance. Topics to consider include: • Choosing between 32-bit and 64-bit JVMs • Use of hardware multithreading, also known as Simultaneous Multithreading or Hyper-Threading. 32-BIT AND 64-BIT CONSIDERATIONS The choice of a 32-bit or 64-bit JVM involves some trade-offs. The key advantage of a 64-bit JVM is its vastly larger address space.
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.
Application Server Tuning There are many aspects to configuring and tuning an application server in WebSphere Application Server. We found that those aspects presented here were critical to a correctly functioning and optimally performing WebSphere Portal in our laboratory environment. For more details on tuning a WebSphere Application Server, see the Tuning Section of the information center located at: http://www-01.ibm.
JV M M AX I MU M H E AP SI ZE LI MI TS 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.
JVM HEAP LARGE PAGE Large pages can reduce the CPU overhead needed to keep track of heap. With this setting we have seen 10% throughput improvement in our measurements. This setting does improve performance on Windows, we did not set it for our measurements because Portal doesn’t start reliably when –Xlp is set, sometimes it requires a system reboot to get the jvm to start.
JVM HEAP NEW AREA SIZE 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 –Xgcpolicy:gencon commandline option. Use –Xmn to further fine tune the Java heap new area (Nursery). The –Xgcpolicy:gencon option does not apply to Solaris.
SESSION TIMEOUT Session timeout: The default value of Session Timeout is 30 minutes. Reducing this value to a lower number can help reduce memory consumption requirements, allowing a higher user load to be sustained for longer periods of time. Reducing the value too low can interfere with the user experience. For Solaris, on a T5240 hardware, we used a much lower think time, 5 seconds, than was used for other platform hardware measurement of 12 seconds.
SECURITY ATTRIBUTE PROPAGATION 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.
VMM CONTEXT POOLING Tune VMM Context Pooling to improve the performance of concurrent access to an LDAP server. We changed the following Context Pooling settings line in: /config/cells//wim/config/wimconfig.xml You can also set them via the administrative console as described in http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.
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 /PortalServer/config/properties/xxxService.properties 2. uncomment the line, then change the size. 3. run /ConfigEngine/ConfigEngine.
REGISTRY SERVICE WebSphere Portal maintains information about many resource types in its databases. Some of these resources are replicated into memory for faster access; this is provided by the registry service. This replicated information will be periodically reloaded from the database, thus picking up any changes which may have been made on a peer node in a clustered environment. The registry service allows configuring a reload time, in seconds, for each type of data which it is managing.
CACHE MANAGER SERVICE The cache manager service in WebSphere Portal is used to cache a wide variety of types of information in memory. These caches are somewhat similar to the registries maintained by the registry service, as each type of information gets its own cache. The key differences are: The information stored in the cache manager service’s caches tends to be more dynamic than the information stored in the registry service’s registries.
Database Tuning DATASOURCE TUNING FOR DB2 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.
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). our scenarios. This database receives some light traffic in 3.
While the Portal databases are configured for high capacity performance, various tuning adjustments may be necessary from time to time. Typically these tuning needs are based on the volume of database traffic and the size of table populations. Our database tuning settings is documented in the Portal Info Center under ‘Creating Remote Database’ section. DB2 ON Z/OS SETUP After transferring the database tables, first Identify what tables need to be reorganized. Perform a re-org check to improve performance.
optimizer to select an efficient access plan for complex SQL, particularly for queries of the JCR database. We have determined a technique that has the same convenience of the reorgchk command and provides the detailed statistics preferred by the optimizer. db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table ',concat(rtrim(tabSchema),concat('.',concat(rtrim(tabname),' on all columns with distribution on all columns and sampled detailed indexes all allow write access'))))) from syscat.
ORACLE DATABASE SERVER TUNING 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. PL AN N I NG FOR O RAC L E EN TE R PRI SE E DI TI O N D AT AB AS E For our Solaris platform measurements we also used Oracle 10g R2 as our database server. WebSphere Portal V6.
O R AC LE O N AI X SET 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.
R EC O M M EN D ED O RAC LE D AT AB AS E MAI N T EN AN 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.
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.
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.
MaxClient/ThreadsPerChild. MinSpareThreads 25 25 N/A 25 MaxSpareThreads 3750 4500 N/A 4500 MaxClients 3750 4500 N/A 4500 Set it same as MaxClients. We also enabled the server-status module so that we could monitor the number of running and available Web server processes. This enables appropriate tuning of the MaxClients and ThreadsPerChild parameters. We did additional Web Server tuning in Web 2.0 Scenario. See Web 2.0 section for details. Note: For z/OS, no Web Server was configured.
Operating System Tuning In any high-load environment, the network must be closely monitored to ensure that its performance is acceptable and consistent. Note that, the following is not to suggest that all network parameters are set to these values, but merely make the reader aware that the network is also an entity in the performance environment and bottleneck resolution process.
LINUX NETWORK TUNING 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 -p To inspect current TCP parameters, run the command: sysctl -a | fgrep tcp Table 12: Linux Network Settings Parameter Value net.ipv4.ip_forward 0 net.ipv4.conf.default.rp_filter 1 net.ipv4.conf.default.accept_source_route 0 net.core.rmem_max 16777216 net.core.wmem_max 16777216 net.ipv4.tcp_rmem 4096 87380 16777216 net.ipv4.
SOLARIS NETWORK TUNING For Solaris, use the ndd command to set the following TCP layer parameters. These will take effect immediately, improving the network layer performance in high-volume environments.
SO L AR I S C ON T AI 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 –e” to enable pool facility 2.
Z/OS SYSTEM TUNING In the PARMLIB member BPXPRMxx check the values of the following parameters: Table 15: z/OS System Tuning Parameter Value Additional Information MAXPROCSYS 15000 System will allow at most 15000 processes to be active concurrently. MAXPROCUSER 15000 Allow each user (same UID) to have at most 15000 concurrent processes active. MAXUIDS 200 Allow at most 200 z/OS UNIX users to be active concurrently. MAXFILEPROC 65535 Allow at 65535 open files per user.
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.
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 -> Portal Settings -> Supported Clients. Then select IE 7 as the browser and remove support for the ‘vary’ header. Caching Proxy Tuning The following are the settings and tunings specified in the reverse proxy’s ibmproxy.
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\.
# 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.
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.
Cache Manager Service Table 19: Cache Manager Service Settings for Many Pages Parameter Setting Used com.ibm.wps.datastore.pageinstance.OIDCache.size 10000 com.ibm.wps.datastore.pageinstance.OIDCache.lifetime 28800 com.ibm.wps.datastore.pageinstance.DerivationCache.size 10000 com.ibm.wps.datastore.pageinstance.DerivationCache.lifetime 28800 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.
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.
WebSphere Portal Service Properties CACHE MANAGER SERVICE Portal Caches sizes – Ignore the Base Portal values and set the following in CacheManagerService.properties: Table 20: Cache Manager Service Settings for WCM CacheManagerService.properties File Cache Name Value Used cacheinstance.com.ibm.workplace.searchmenu.helper.SearchMenuCacheHelper.size 5000 cacheinstance.com.ibm.wps.ac.ContainedRolesCache.size 500 cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.size 5000 cacheinstance.com.
NAVIGATION SERVICE Portal Navigator Service – In addition to the settings mentioned for Base Portal we set the following property to allow public sessions required for rendering portlets on anonymous pages: Table 21: Navigation Service Settings for WCM NavigatorService.properties File Parameter Default Value Value Used public.
processing session menu nav strategy global module 10000 6000 500 500 8000 100 100 How-To Set: Login to the WAS Administration Console → Resources → Cache instances → Object cache instances. WCM Configuration Service Enable the user cache Find the WCMConfigService.properties file under: /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.
DB2 Tuning (Authoring Environment) MULTIPLATFORM (LUW) 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.
Z/OS The following section details the tunings that we made in our DB2 9 for z/OS backend database during our testing. To start here are a few general recommendations: • When the DB2 z/OS server is on a different server to the Portal/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.
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.
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.
cacheinstance.com.ibm.wps.ac.SingleEntitlementsCache.lifetime 28800 cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.CONTENT_NODE. lifetime 28800 cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.WEB_MODULE.lifetime 28800 cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.APPLICATION_ROLE. lifetime 28800 cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.PORTLET_APPLICATIO N_DEFINITION!PORTLET_DEFINITION.lifetime 28800 cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.
• 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.
7 CLUSTER TUNING The Base Portal Scenario is measured in a three-node horizontal cluster environment, with or without session persistence, and six-members vertical cluster environment. In general, the same tuning that was used for the Base Portal Scenario was used for cluster. The additional settings are mentioned below: Application Server Tuning DYNACACHE CUSTOM PROPERTIES There are several properties which can be set to reduce the number and size of Dynacache messages sent between nodes.
THREAD POOLS Increase Default Thread Pool size to help DRS traffic. How-To Set: Portal Server->Thread Pools ->DefaultPool=150/150 (default=5/20) TRANSPORT BUFFER SIZE Default Transport Buffer size is insufficient. We increase to 200MB. How-To Set: Portal Server-> Core Group Service ->Transport buffer=200mb (default=10MB) Must also configure the same size for Node Agent & DM.
Web Server Tuning Table 26: Web Server Tuning for Clusters Parameter Setting Used ThreadLimit 25 ServerLimit StartServers MaxClients MinSpareThreads MaxSpareThreads ThreadsPerChild MaxRequestsPerChild 180 2 4500 25 4500 25 0 Sample configuration: ThreadLimit 25 ServerLimit 180 StartServers 2 MaxClients 4500 MinSpareThreads 25 MaxSpareThreads 4500 ThreadsPerChild 25 MaxRequestsPerChild 0 48 WEBSPHERE PORT AL V6.
Session Persistence To Database Tuning To enable Session Persistence to Database, a data source with non-XA JDBC driver must be created. We also configured DB2 Session Database with 32K page size to optimize performance for writing large amounts of data to the database. For details on configuring tablespace and page size for DB2 session database visit WebSphere Application Server Info Center.
SES SIO N D AT AB AS E TU NING 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 db2 db2 db2 db2 db2 db2 db2 “update “update “upda
IBM Tivoli Directory Server Tuning The following table shows the tuning values used for the directory servers. How-to-Set: These values are in the file /opt/IBM/ldap/V6.0/etc/SchemaV6.0/ibmslapd.conf. You must restart the LDAP server after changing these values.
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.
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).
IDENTIFYING A FULL FETCH OF USER ATTRIBUTES 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.
MINIMUM ATTRIBUTE SET 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.
Real-World Network Considerations In our lab environment, we had the luxury of our clients and servers being on the same LAN segment, so that they could take advantage of a high-bandwidth, low-latency network connection. However, this is typically not the case for real clients. Over a wide-area network, latencies can be significant, and bandwidth limited. In this case, the time to transfer the page content from the server to the client can become a significant contributor to overall page response time.
BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Don't compress images SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png|exe)$ no-gzip dont-vary ENABLING CLIENT-SIDE CACHING The HTTP protocol allows the server to tell clients how long they can cache responses.
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.
admit-threshold properties do not apply to all cache implementations. In general, only caches that are not shared will use these properties. There are other properties that should not be modified unless specifically instructed to do so by IBM WebSphere Portal support. enabled: The enabled property determines whether a cache is used or not. If a cache is not enabled, the property has a value of false, then no values are held by the cache and every cache lookup will return a null value.
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.
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.
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.
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.
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.
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.
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.
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.
DATASTORE The datastore caches contain data read from the portal database. It is not the goal of these caches to be a complete image of the DB content, but to have frequently-accessed but raw information available for all other portal components to use. com.ibm.wps.datastore.services.Identification.OidAndUniqueName.cache Default size: 5000, default lifetime: infinite, usage pattern: regular. This cache stores unique names.
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.
Figure 29 describes the hierarchy of caches in the model component and depending portal components. The structure of the picture is identical to figure 28: The vertical axis shows caches with increasing aggregation of data. The model component only caches data at a rather high aggregation level. All data cached here hence is rather valuable, reloads can be expensive if the corresponding data is not available in the lower-level caches.
sets of access control rights on these pages. This cache contains very ‘valuable’ information; it utilizes several other caches, for example, page instance and access control caches, to build its data. Hence creating a cache entry usually only requires inmemory information, but can also lead to many database queries. The size of an entry in the cache depends on the complexity of the pages, but typically the objects are mediumsized, since they are usually made of references to other cached data.
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.
com.ibm.wps.model.factory.URLMappingCache.isolated Default size: 50, default lifetime: infinite, usage pattern: regular. This cache is the administration cache for URL mappings. The details given for the other isolated caches also apply here. com.ibm.wps.model.factory.MultiModelCache.live Default size: 50, default lifetime: infinite, usage pattern: regular. This cache contains run-time models for several different resource types in WebSphere Portal, for example clients, supported markups and languages.
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.
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.
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.
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).
entry to the cache involves one database query. One entry is fairly small. Typically there is no need to modify the settings for this cache. POLICY The WebSphere Portal policy manager uses the following caches. com.ibm.wps.policy.services.PolicyCacheManager Default size: 1000, default lifetime: 7780, usage pattern: regular. This cache stores the policies. Out of the box portal comes with twelve theme policies and one mail policy, each of them being one entry into the cache.
com.lotus.cs.services.directory.ldap.BasicLDAPDirectoryService.user Default size: 2000, default lifetime: 10780, usage pattern: regular. This cache stores user-specific information read from the LDAP. It scales with the number of users working with DEPP portlets. The cache is accessed during rendering a DEPP portlet, whenever those need user information. This could be multiple times per page reload. In addition the cache is accessed whenever a mail server is accessed.
com.ibm.wps.pe.portletentity Default size: 10000, default lifetime: 5800, usage pattern: regular. This cache contains configuration for portlets on pages (portlet instances, shared and per-user). It scales with the number of pages defined in your portal, the number of portlets on the pages and the number of portlet instances that have been personalized by users. The cache is accessed many times during portal page rendering. In so far it is important that the most relevant portlet entities are cached.
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.
Example Scenarios This section describes some example usage scenarios along with descriptions of possible cache settings and suggested cache sizes. This discussion may be useful as starting point for the caches in your environment. GENERAL COMMENTS Most portal caches fall into one of four groups: 1. Caches where the number of entries scales with the number of active users. For example, the access control user context cache (com.ibm.wps.ac. AccessControlUserContextCache) falls into this category. 2.
If there is no or very little administration on your system and you have free memory in the Java heap available, it is safe to increase the lifetime of cache content to save the additional workload for reloading cached data. Now we shall consider some recommendations for specific scenarios. SMALL NUMBER OF PAGES AND SMALL NUMBER OF USERS In this scenario a portal only has a limited number of pages and users accessing them.
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. PORTALS WITH LONG SESSION TIMEOUTS If the session timeout has a high value, it is likely that there will be a large number of users who still have sessions with the portal, but who have not interacted with the site for a significant period of time.
We increased the sizes of the following caches in our measurement environments so that all frequently-accessed pages, which depend on our scenario, can be cached. com.ibm.wps.datastore.pageinstance.OIDCache com.ibm.wps.datastore.pageinstance.DerivationCache 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.
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.
WCM BASIC CACHING services/cache/iwk/module Default size: 2000, default lifetime: infinite, usage pattern: regular. This cache is used for WCM Basic caching. See the InfoCenter on setting up Basic caching. The Basic cache stores the entire response. The key is based only on the URL so all users will see the same response. ADVANCED AND RESOURCES services/cache/iwk/processing – Advanced and Resources Default size: 2000, default lifetime: 1 month (configurable), usage pattern: regular.
MENU services/cache/iwk/menu - Menu Default size: 2000, default lifetime: infinite, usage pattern: regular. This cache stores WCM Menu entries. An entry comprises of the Content IDs associated with a particular menu. The entries are retrieved and cached without applying security. Whenever a user needs that menu’s results, their specific security will then be applied to the cached results. A dynamic menu, which is one that is affected by the current user’s context (e.g.
LIBRARY PARENT services/cache/iwk/libparent – Library Parent Default size: 2000, default lifetime: infinite, usage pattern: regular. This cache stores a list of all children library ids to a given parent id. Introduced for Quickr to group libraries within a teamspace together. DRAFT SUMMARY Services/cache/iwk/draftSummary – Draft Summary Default size: 2000, default lifetime: infinite, usage pattern: regular. This cache stores the identity of the draft summary to the identity of the draft WCM Item.
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.
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 Presler-Marshall Terence Walker Laura Yen, Document Coordinator Sonja Zwissler Kenny Sabir Maria Sueli Almeida Alesio Pfeifer Joerg Huehne David De Vos Mike Coletta 91 WEBSPHERE PORT AL V6.
® Copyright IBM Corporation 2008 IBM United States of America Produced in the United States of America All Rights Reserved The e-business logo, the eServer logo, IBM, the IBM logo, IBM Directory Server, DB2, Lotus, WebSphere, POWER4 and POWER5 are trademarks of International Business Machines Corporation in the United States, other countries or both. Lotus and Domino are trademarks of Lotus Development Corporation and/or IBM Corporation.
