WebSphere Portal 6.1.X Performance Tuning Guide

 

+

Search Tips   |   Advanced Search

 

  1. Overview
  2. 32-bit vs 64-bit JVMs
  3. Hardware multithreading (hyper-threading)
  4. Base portal tuning
  5. JVM initial and maximum heap size
  6. JVM heap large page
  7. JVM large page tuning on aix operating system
  8. JVM heap new area size
  9. Additional sun jvm arguments
  10. Session timeout
  11. Web container thread pool size
  12. Base security attribute propagation
  13. VMM context pooling
  14. Orb service tuning for z/os
  15. WebSphere portal services
  16. Navigator service
  17. Registry service
  18. Cache manager service
  19. Datasource tuning for db2
  20. DB2 database server tuning
  21. DB2 on aix setup
  22. Recommended database maintenance for db2 luw
  23. Planning for oracle enterprise edition database
  24. Oracle on aix setup
  25. Oracle enterprise edition database parameter tuning
  26. Recommended oracle database maintenance
  27. Other database
  28. Directory Server Tuning
  29. Web Server Tuning
  30. AIX network tuning
  31. Linux - network tuning
  32. Windows 2003 network tuning
  33. Solaris network tuning
  34. Kernel tuning

 

Overview

Basic performance tuning...

  1. Begin with a baseline
  2. Monitor the performance metrics to determine if any parameters should be changed
  3. When a change is made, monitor the performance metrics to determine the effectiveness of the change.

Components to tune...

 

32-bit and 64-bit JVMs

64-bit JVMs use a significantly larger address space, with heap sizes of 2.5GB or larger possible. This is especially useful for memory intensive applications.

One disadvantage of 64-bit JVMs is that Java objects, which typically contain multiple memory references, are larger in a 64-bit JVM than compared to a 32-bit JVM. Therefore a 64-bit JVM will need a larger heap than a 32-bit JVM for the same population of objects.

The increased size of instructions and memory references increases demand on the memory subsystem of the system, causing more cache misses and a higher demand for memory bandwidth. As a result, executing a set of operations in a 64-bit JVM can be slower than executing the same operations in a 32-bit JVM.

If you expect a high demand for memory, the best performance will probably come from a 64-bit JVM. On the other hand, if the memory demand is lower, a 32-bit JVM is likely to give superior performance.

See also:

  1. Tune the IBM virtual machine for Java

 

HARDWARE MULTITHREADING (HYPER-THREADING)

Hyper-Threading (HT) on Intel processors and Simultaneous Multithreading (SMT) on Power-series processors provides an improvement in capacity in all of the scenarios and platforms, so we would recommend its use on platforms where this is an option.

 

BASE PORTAL TUNING

The Base Portal Scenario covers...

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.

 

JVM INITIAL AND MAXIMUM HEAP SIZE

How-To Set: In the WebSphere Administrative Console:

Servers | Application Servers | WebSphere Portal | Server Infrastructure: Java and Process Management | Process Definition | Java Virtual Machine

When setting the heap size for an appserver, keep the following in mind:

On Solaris and zLinux, you can use 3.5GB heap size in 64-bit environment.

Parameter AIX POWER5 Linux Solaris Windows 2003 z/Linux z/OS
Initial and Maximum heap size (Mbytes) 1792 2048 3584 1408 3584 2048

 

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.

How-to Set:

Servers | Application Servers | WebSphere Portal | Server Infrastructure: Java and Process Management | Process Definition | Java Virtual Machine | Generic JVM Argument

Add -Xlp.

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.

Large pages are supported by systems running Linux kernels V2.6 or higher. See JVM Large Page Tuning for AIX Operation System.

 

JVM LARGE PAGE TUNING ON AIX OPERATING SYSTEM

To use JVM Large Page, AIX operating system must be configured to support large pages.

How-To Set:

  1. For a system with 8GB of physical memory, to allocate 4GB of RAM as large pages (16MB)...

    vmo -r -o lgpg_regions=256 -o lgpg_size=16777216
    bosboot -ad /dev/ipldevice
    reboot -q
    vmo -p -o v_pinshm=1
    chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE $USER

  2. Add: -Xlp command-line option as described above.

  3. In the WebSphere Administrative Console:

    Servers | Application Servers | WebSphere Portal | Server Infrastructure: Java and Process Management | Process Definition | Environment Entries | New | EXTSHM=OFF

  4. Restart Portal Server.

To verify if large pages are being used, run the AIX command...

vmstat -l 1 5

...and check the "alp" column which is the active large page used. It should be a non-zero value if large pages are being used.

 

JVM 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 command-line option...

Use -Xmn to further fine tune the Java heap new area (Nursery).

The -Xgcpolicy:gencon option does not apply to Solaris.

How To Set:

Servers | Application Servers | WebSphere Portal | Server Infrastructure: Java and Process Management | Process Definition | Java Virtual Machine | Generic JVM Arguments: -Xmn256m

Parameter AIX POWER5 Linux Solaris Windows 2003 z/Linux z/OS
New Area Size -Xmn320m -Xmn256m -Xmn768m -Xmn256m -Xmn1024m -Xmn320m

 

ADDITIONAL SUN JVM ARGUMENTS

On the Solaris platform, we use the following Java HotSpot parameters to achieve optimum performance.

Parameter Value Additional Information
-server
Offers higher throughput than the "client" mode.
-XX:MaxPermSize 768m
-XX:+UseConcMarkSweepGC
Use concurrent mark-sweep collection for the tenured generation. The application is paused for short periods during the collection; we found this collector works best in Portal.
-XX:SurvivorRatio 6
-XX:+UseParNewGC
By default concurrent low pause collector uses the default, single threaded young generation copying collector. Set this parameter to use parallel young generation collector for new area.
-XX:ParallelGCThreads 5 Reduces the number of garbage threads. On the Chip multithreading processor based system, we set the threads no higher than one quarter of the hardware threads. We also distribute the threads for 6 JVMs. Our system has 128 virtual processors, we set a total of (128/4)=32 GC threads across all the JVMs. So 5 or 6 GC threads per JVM.
-XX:+PrintGCDetails
Print more details at garbage collection. This does not improve performance, but it provides additional information related to garbage collection activity, which is useful in tuning garbage collection.
-XX:+PrintGCTimeStamps
Print timestamps at garbage collection.

 

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. A lower thinktime results in a heavier load on the system. We lowered the thinktime to decrease the number of virtual users required for this measurement. Our pool of LoadRunner virtual user licenses was inadequate to generate enough load with the higher think time. With a shorter think time than is used in the other measurements, the duration of each virtual user's interaction with the site is shorter by approximately 2 minutes. To compensate for this, and keep the sessions live on the server for the same period of time, we increased the session timeout by 2 minutes, to 12 minutes.

How To Set: In the WebSphere Administrative Console:

Servers | Application Servers | WebSphere Portal | Container Settings: Web Container Settings | Session Management | Session Timeout | Set Timeout

 

WEB CONTAINER THREAD POOL SIZE

Servlet engine thread pool size: Set this value and monitor the results. Increase this value if all the servlet threads are busy most of the time.

How To Set: In the WebSphere Administrative Console:

Servers | Application Servers | WebSphere Portal | Additional Properties: Thread Pools | Web Container | Thread Pool | Minimum size threads - Maximum size threads

 

BASE SECURITY ATTRIBUTE PROPAGATION

To reduce the Security Attribute Propagation (SAP) overhead...

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 SAP. SAP 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. To enable SAP for functional reasons, you can improve the performance with CallerList tuning mentioned below.

These settings apply to all platforms.

How to Set: In the WebSphere Administrative Console:

Security | Secure Administration, Applications, and Infrastructure | Custom properties

Name Value
com.ibm.CSI.disablePropagationCallerList true
com.ibm.CSI.rmiOutboundPropagationEnabled false
com.ibm.CSI.rmiInboundPropagationEnabled false
com.ibm.ws.security.webInboundPropagationEnabled false

For com.ibm.CSI.disablePropagationCallerList create a new property, for the other 3 properties, modify their value to "false".

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:

Security | Global Security | CustomProperties | New

 

VMM CONTEXT POOLING

Tune VMM Context Pooling to improve the performance of concurrent access to an LDAP server.

We changed Context Pooling settings in...

WP_PROFILE/config/cells//wim/config/wimconfig.xml

...by setting... 

<config:contextPool enabled="true" 
                    initPoolSize="10" 
                    maxPoolSize="0" 
                    poolTimeOut="0" 
                    poolWaitTime="3000" 
                    prefPoolSize="30"/>

You can also set them via the administrative console.

Context Pool Setting Default Value Value
initPoolSize 1 10
prefPoolSize 3 30

Number of open connections to maintain to LDAP server.

maxPoolSize 20 0

A value of 0 allows the pool to grow as large as needed. If access to the LDAP server is shared by many systems, this setting may allow an excessive number of connections to the LDAP server; in such a case, set the maximum pool size to a value appropriate to your environment.

 

ORB SERVICE TUNING FOR Z/OS

How to Set:

Servers | Application Servers | server1 | Orb Service | Pass by Reference
Servers | Application Servers | WebSphere_Portal | Orb Service | Pass by Reference

 

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/PortalServer/config/properties/xxxService.properties

  2. uncomment the line, then change the size.

  3. Run...

    WP_PROFILE/ConfigEngine/ConfigEngine.sh update-properties

    The changes should appear on...

    WAS Console | Resource Environment Providers | WP_xxxService | Custom properties

 

NAVIGATOR SERVICE

The navigator service manages the content model for unauthenticated users, which controls the pages those users are able to see. This content model is periodically reloaded by WebSphere Portal; new pages which are visible to unauthenticated users will not be available until the next reload occurs. Our environment assumes a low rate of change for pages, so we set this reload to only occur once per hour. In a production environment where new pages for unauthenticated users are rarely created, setting this reload time to an hour or more will give better performance. In a test or staging environment where updates to unauthenticated pages need to be seen more often, a lower reload time is more appropriate.

This service also controls the HTTP cache-control headers which will be sent on unauthenticated pages. While our environment did not exploit HTTP page caching, increasing these cache lifetimes in a production environment can reduce load on the portal.

NavigatorService.properties

Parameter Default Value (seconds) Value Used Definition
public.expires 60 3600 Cache expiration time for caches outside of WebSphere Portal and for unauthenticated portal pages. If the setting remote.cache.expiration is also set to a value greater than or equal to 0, the smaller one of the two values is used.
public.reload 60 3600 Cache expiration time for the portal internal cache for unauthenticated pages
remote.cache.expiration 60 28800 Cache expiration for caches outside of portal server for authenticated as well as for unauthenticated pages

 

REGISTRY SERVICE

WebSphere Portal maintains information about many resource types in its databases. Some of these resources are replicated into memory for faster access; this is provided by the registry service. This replicated information will be periodically reloaded from the database, thus picking up any changes which may have been made on a peer node in a clustered environment.

The registry service allows configuring a reload time, in seconds, for each type of data which it is managing. In a production environment, we expect this type of information changes very infrequently, so we used very long reload times for the registry service.

RegistryService.properties

Parameter Default Value Value Used Definition
default.interval 1800 28800 Reload frequency for any object types not explicitly specified in the file.
bucket.application.interval 600 28800 Reload frequency for application definitions
bucket.portlet.interval 600 28800 Reload frequency for portlet definitions
bucket.theme.interval 3000 28800 Reload frequency for theme definitions
bucket.skin.interval 3500 28800 Reload frequency for skin definitions
bucket.client.interval 19000 28800 Reload frequency for client definitions
bucket.markup.interval 20000 28800 Reload frequency for markup definitions
bucket.transformation application.interval 600 28800 Reload frequency for transformation application definitions
bucket.transformation.interval 600 28800 Reload frequency for transformation definitions

 

CACHE MANAGER SERVICE

The cache manager service in WebSphere Portal is used to cache a wide variety of types of information in memory. These caches are somewhat similar to the registries maintained by the registry service, as each type of information gets its own cache. The key differences are:

  • The information stored in the cache manager service's caches tends to be more dynamic than the information stored in the registry service's registries.

  • The caches used by the cache manager service are limited in size, and entries will be discarded when the caches become full. The registries used by the registry service are not size-limited; they contain all entries of the specific data type.

  • Expiry times are managed individually for each entry in the cache, managed by the cache manager service. In contrast, when the reload time is reached for a registry, the entire contents of that registry are reloaded.

Each cache has several configurable options. Size values below are specified in "number of objects" and lifetime values are specified in "seconds".

CacheManagerService.properties

Cache Name Default Value Value Used
com.ibm.wps.model.factory.ContentModelCache.live.size 1000 2500
com.ibm.wps.ac.ExplicitEntitlements Cache.USER_GROUP.size 1000 2000
com.ibm.wps.model.factory.Navigation SelectionModelCache.live.size 1000 2500
com.ibm.wps.ac.OwnedResourcesCache.enabled true false
com.ibm.wps.ac.ProtectedResourceCache.lifetime 5000 14400
com.ibm.wps.datastore.services.Identification.SerializedOidString Cache.size 2500 5000
com.ibm.wps.puma.DN_OID_Cache.size 500 5000
com.ibm.wps.puma.DN_User_Cache.size 500 3000
com.ibm.wps.puma.DN_Group_Cache.size 500 1500
com.ibm.wps.puma.OID_DN_Cache.size 1500 3000
com.ibm.wps.puma.OID_User_Cache.size 1500 3000
com.ibm.wps.puma.OID_Group_Cache.size 1500 5000
com.ibm.wps.ac.groupmanagement.NestedGroupCache.enabled true False
com.ibm.wps.ac.RolesCache.enabled true False
com.ibm.wps.ac.ChildResourcesCache.lifetime 7200 28800
com.ibm.wps.policy.services.PolicyCacheManager.lifetime 7780 43200

 

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...

Database Database name Datasource name
Release release reldbDS
Community community commdbDS
Customization custom cusdbDS
Feedback fdbkdb fdbkdbDS
Likeminds Lmdb lmdbDS
JCR jcrdb jcrdbDS

All datasources are configured in a similar manner by logging on to the WAS administrative console.

For the prepared statement cache size, the path is...

Resources | JDBC Providers | provider name | Data Sources | datasource name | Statement cache size

For the connection pool settings, the path in the WAS 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.

 

DB2 DATABASE SERVER TUNING

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.

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:

Release (release domain) Primary database domain used by the Base Portal and Many Pages Scenarios.
Customization (customization domain This database receives some light traffic in our scenarios.
Community (community domain This database receives some light traffic in our scenarios.
JCR (JCR domain) Used heavily in WCM Scenario. This database receives light traffic in all other scenarios measured in our Benchmark report.
Likeminds database Used for Likeminds enabled systems. This database is not used in the scenarios measured in our Benchmark report.
Feedback database Used by the feedback subsystem. This database is not used in the scenarios measured in this report.

 

DB2 ON AIX SETUP

We configure our DB2 database on AIX using the following setup,

  • 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 -o cio /portaldb

  • Increase AIX maximum number of processes per user to 4096.

    The default 500 processes per user is too low for database server, we increase it to 4096 in our AIX environment. To increase it,

    chdev -l sys0 -a maxuproc=.4096.

 

RECOMMENDED DATABASE MAINTENANCE FOR DB2 LUW

Two of the database attributes, which DB2 relies upon to perform optimally, are...

  • database catalog statistics
  • 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, IBM recommends performing this maintenance during off hours, periods of low demand, or when the portal is off-line. The DB2 runstats command is used to count and record the statistical details about tables, indexes and columns. We have used two techniques in our environment to recompute these statistics. The form IBM recommends is:

db2 runstats on table tableschema.tablename

...on all columns with distribution on all columns and sampled detailed indexes all allow write access

These options allow the optimizer to determine optimal access plans for complex SQL.

A simpler, more convenient technique for recomputing catalog statistics is:

db2 reorgchk update statistics on table all

Not only does this command count and record some of the same catalog statistics, it also produces a report that can be reviewed to identify table organization issues. However, we have found instances where this produces insufficient information for the optimizer to select an efficient access plan for complex SQL, particularly for queries of the JCR database.

We have determined a technique that has the same convenience of the reorgchk command and provides the detailed statistics preferred by the optimizer.

db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table ',concat(rtrim(tabSchema),concat('.',concat(rtrim(tabname),' on all columns with distribution on all columns and sampled detailed indexes all allow write access'))))) from syscat.tables where type='T'"
db2 -v -f "runstats.db2"

The first command is used to create a file, runstats.db2, which contains all of the runstats commands for all of the tables. The second command uses the db2 command processor to run these commands.

To determine which tables might benefit from reorganization, we use the command:

db2 reorgchk current statistics on table all > "reorgchk.txt"

For those tables which require reorganization, we use the command:

db2 reorg table tableschema.tablename

...to reorganize the table based upon its primary key.

You should also verify the 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 appserver 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.

 

PLANNING FOR ORACLE ENTERPRISE EDITION DATABASE

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.

Here are the key choices we have implemented in our Oracle database.

  • To avoid I/O contention and allow for better throughput, you should ensure your database server have adequate number of disks. Our database is on seven stripped disks.

  • For better management and performance of storage structures, Oracle-Managed Files are used for database, as well as redo logs, and control files.

  • Database block size: 8k

  • 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:

    SYSAUX 800MB
    SYSTEM 800MB
    TEMP 800MB
    UNDOTBS 1024MB
    USERS 2048MB

  • Redo log groups: 500MB each.

 

ORACLE ON AIX SETUP

We configure our Oracle database on AIX using the following setup,

  • Set the filesystem which will hold the Portal databases to be a Enhanced Journal File System (JFS2).

  • Turn on concurrent I/O (CIO) for database filesystem as this improves performance. Do not enable CIO for Oracle product filesystem, ie, /u01, as Oracle could fail to start.

    To enable CIO, use the following command to mount the database fileset.

    mount -o cio /u02

  • Increase AIX maximum number of processes per user to 4096.

    The default 500 processes per user is too low for database server, we increase it to 4096 in our AIX environment. To increase it,

    chdev -l sys0 -a maxuproc='4096'

  • Enable AIX async I/O, and increase MinServer to 5.

    smitty aio --> Change/Show Characteristics of Async I/O --> MinServers = 5

  • We also set in oracle user's profile as Oracle Installation Guide for AIX recommends, AIXTHREAD_SCOPE=S

 

ORACLE ENTERPRISE EDITION DATABASE PARAMETER TUNING

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

Command used:

Alter system set parameter scope=spfile;

Oracle Database Tuning...

Parameter Value
sessions 900
sga_target 1813M
pga_aggregate_target 604M
processes 750
open_cursors 1500
db_files 1024

 

RECOMMENDED ORACLE DATABASE MAINTENANCE

Optimizer statistics are a collection of data about the database and the objects in the database, these statistics are used by the query optimizer to choose the best execution plan for each SQL statement. Because the objects in a database can be constantly changing, statistics must be regularly updated so that they accurately describe these database objects, particularly after periods of heavy data modifications (inserts, updates, and deletes) such as a population phase. We have used the following commands in our environment to recompute these statistics:

execute dbms_stats.gather_database_stats(dbms_stats.auto_sample_size, method_opt=>'FOR ALL INDEXED COLUMNS SIZE AUTO',cascade=>TRUE);

 

OTHER DATABASE CONSIDERATIONS

WebSphere Portal maintains some information about users in its database tables, which grow when a user first logs in. We were interested in the steady-state performance of WebSphere Portal, not the performance of a user's first login to the site. Therefore our performance evaluates after all users logged in at least one time.

One of the most important database tuning factors is bufferpool sizing. It is important to evaluate the database's physical versus logical reads and size the bufferpools to achieve as much as a 95% logical read rate if possible.

 

Directory Server Tuning

Our measurements used IBM Tivoli Directory Server versions 6.0 as the directory server. These products use a database for storing user information; DB2 Enterprise Server was used for this database in our environment. This database is typically located on the same system as the directory server. If your workload involves creating, updating, or deleting users, then database maintenance described above may be needed on this database.

The following table shows the tuning values used for the directory servers in our Solaris Base Portal Scenario measurements

How-to-Set: These values are in...

/opt/IBM/ldap/V6.0/etc/SchemaV6.0/ibmslapd.conf

You must restart the LDAP server after changing these values.

Parameter Value
Ibm-slapdACLCacheSize 250000
Ibm-slapdEntryCacheSize 250000
Ibm-slapdFilterCacheSize 250000
Ibm-slapdFilterCacheBypassLimit 7500

The IBM Tivoli Directory Server uses IBM DB2 as the database server. The database instance and alias are named IDSLDAP. We applied the following tuning to this database:

db2 "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

 

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 appserver. If, during your monitoring, you notice insufficient processor capacity on the system when running the web server and the portal appserver on a single system, consider separating the servers onto different systems. We used the following tuning on our web servers:

Parameter AIX POWER5 Linux Windows 2003 z/Linux Additional Information
KeepAliveTimeout 5 5 5 5 This value is less than the think time defined in our scripts to ensure that testing is conservative. Each user is assumed to open a new TCP connection for each page view. However, in a live environment, it can be helpful to increase the KeepAlive Timeout. A higher timeout value can increase contention for HTTP server processes, if you are running out of HTTP processes, decrease this value.
ThreadsPerChild 25 25 2000 25 The higher number of threads per child on Windows is due to a different process model for IHS on Windows.
MaxKeepAliveRequests 0 0 0 0 Select 0 lets an unlimited number of requests on a single TCP connection.
MaxRequestsPerChild 0 0 0 0
StartServers 2 2 N/A 2
Access logging off off off off This was turned off by commenting out the following configuration line: CustomLog /usr/HTTPServer/logs/access_log common
ThreadLimit 25 25 2000 25
ServerLimit 150 120 N/A 180 Set it to: MaxClient/ThreadsPerChild.
MinSpareThreads 25 25 N/A 25
MaxSpareThreads 3750 4500 N/A 4500 Set it same as MaxClients.
MaxClients 3750 4500 N/A 4500

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.

 

AIX NETWORK TUNING

Use...

smitty | Performance and Resource Scheduling | Tuning Kernel and Network Parameters | Tuning Network Option Parameters | Change/Show Current Parameters

These will take effect immediately, improving the network layer performance in high volume environments.

Then remember to "Save current parameters for Next Boot".

Parameter Value
tcp_sendspace 131072
tcp_recvspace 131072
udp_sendspace 65536
udp_recvspace 655360
somaxconn 10000
tcp_nodelayack 1
rfc1323 1

 

LINUX - NETWORK TUNING

For Red Hat Linux and z/Linux (Suse Linux on zOS), we add the following settings to...

/etc/sysctl.conf

...then run the command...

sysctl -p

To inspect current TCP parameters, run...

sysctl -a | fgrep tcp

Parameter Value
net.ipv4.ip_forward 0
net.ipv4.conf.default.rp_filter 1
net.ipv4.conf.default.accept_source_route 0
net.core.rmem_max 16777216
net.core.wmem_max 16777216
net.ipv4.tcp_rmem 4096 87380 16777216
net.ipv4.tcp_wmem 4096 65536 16777216
net.ipv4.tcp_fin_timeout 30
net.core.netdev_max_backlog 3000
net.core.somaxconn 10000
net.ipv4.tcp_keepalive_intvl 15
net.ipv4.tcp_keepalive_probes 5

 

WINDOWS 2003 NETWORK TUNING

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.

Parameter Value
MaxFreeTcbs dword:00011940
MaxHashTableSize dword:0000ffff
MaxUserPort dword:0000fffe
TcpTimedWaitDelay dword:0000001e
TcpWindowSize dword:0000ffff (65535)

 

SOLARIS NETWORK TUNING

For Solaris, use the ndd command to set the following TCP layer parameters. These will take effect immediately, improving the network layer performance in high-volume environments. We use the following settings in Portal server running Solaris 10:

How-to-Set:

ndd -set /dev/tcp <PARAMETER> <VALUE>

Parameter Value
tcp_time_wait_interval 60000
tcp_keepalive_interval 15000
tcp_fin_wait_2_flush_interval 67500
tcp_conn_req_max_q 16384
tcp_conn_req_max_q0 16384
tcp_xmit_hiwat 400000
tcp_recv_hiwat 400000
tcp_cwnd_max 2097152
tcp_ip_abort_interval 60000
tcp_rexmit_interval_initial 4000
tcp_rexmit_interval_max 10000
tcp_rexmit_interval_min 3000
tcp_max_buf 4194304

 

KERNEL TUNING

Our Portal Server is running on Solaris 10. In Solaris 10, we use the following "projmod" commands to set system parameters. After making the changes, we must logout then login to take these changes into effect.

To examine your current settings...

cat /etc/project

projmod -s -K 'project.max-shm-memory=(privileged,4294967296,deny)' user.root
projmod -s -K 'project.max-shm-ids=(privileged,1024,deny)' user.root
projmod -s -K 'project.max-sem-ids=(privileged,1024,deny)' user.root
projmod -s -K 'process.max-sem-nsems=(privileged,4098,deny)' user.root
projmod -s -K 'process.max-sem-ops=(privileged,16384,deny)' user.root
projmod -s -K 'process.max-file-descriptor=(privileged,16384,deny)' user.root