WebSphere

 

Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows

 

Performance improvements

 

+

Search Tips   |   Advanced Search

 

  1. Reduce LDAP calls
  2. Increase performance during creation of credentials
  3. Improve JSP response time
  4. Increase the ping timeout values
  5. Tune components for peak performance
  6. Set the fetch size of JDBC result sets
  7. Self-registered users using Domino
  8. Set the JVM max heap size
  9. Disable Personalization background tasks
  10. WebSphere Portal Express Tuning Guide

 

Reduce LDAP calls

The user.base.attributes property in Puma service should contain the set of attributes needed by most of your portlet applications. All attributes defined there are loaded during the login phase of a user. If an attribute that is not already loaded is requested by one of your portlet applications, WebSphere Portal Express will load all attributes defined in the User Repository, which might increase user login time. See Puma and Puma Validation services for information.

User attributes used in the banner.jsp or other JSP's should be added to the user.minimum.attributes property in Puma service, as described in Setting configuration properties. If any of these attributes are missing from WP Pumaservice, login performance might suffer.

By default the following section of wmmLDAPAttributes_XX.xml, where XX is your LDAP server, is configured. However, if you use dynamic groups, you should comment out the following section in the wmmLDAPAttributes_XX.xml file as shown below:

If running in a cluster, you need to check out the file before editing, and check it in to the Deployment Manager configuration repository after editing. For further information, see Managing the cluster. 

  <!--  <attributeMap   wmmAttributeName="groupMemberURL"
                            pluginAttributeName="memberURL"
                            applicableMemberTypes="Group"
                            dataType="String"
                            valueLength="1024"
                            multiValued="true" />  -->

 

Increase performance during creation of credentials

If IBM WebSphere Application Server is not configured using the preloaded default LDAP filters for Tivoli Directory Server, Active Directory, or Sun Java System Directory Server, three LDAP calls are made when creating credentials. These calls do the following:

If you configured WebSphere Application Server LDAP security as part of the configuration of WebSphere Portal Express configuration tasks, these WebSphere Application Server LDAP filters will not be configured for optimal performance.

 

To reduce these calls: To reduce these three calls to a single LDAP call and improve performance when using IBM Tivoli® Directory Server, use the appropriate default filters for the LDAP server. These filters are preloaded with WebSphere Application Server. Follow the instructions below to configure WebSphere Application Server to use the default filter for Tivoli Directory Server.

Refer to the WebSphere Application Server documentation for more information.

  1. From the WebSphere Application Server Administrative Console, select...

    Security | Global Security | User Registries | LDAP | Ignore Case | OK

  2. Click Advanced LDAP Settings.

  3. In the Group Member ID Map field enter...

    ibm-allGroups:member;ibm-allGroups:uniqueMember

    ...and click OK.

  4. Select...

    Security | Global Security OK

 

Improve JSP response time

The first time a JSP file is requested, the user is forced to wait while the JSP is compiled. For better response times, you can compile your JSPs before they are requested using a configuration task.

For more information about the JSP batch compiler:

The JSP batch compiler is a command line tool in...

To run:

Example for i5/OS:

  1. cd /QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/wp_profile/PortalServer/config
  2. WPSconfig.sh -profileName wp_profile action-precompile-jsp

 

Increase the ping timeout values

The values of ping interval, ping timeout, and ping initial timeout should be increased in order to avoid ping errors. The defaults are 60 seconds for ping interval, 200 for ping timeout, and 600 for ping initial timeout.

Complete the following steps to increase the ping timeout values:

  1. Log in to the WebSphere Application Server administrative console.

  2. Click on Nodes view, and choose the appropriate host name.

  3. Click on the Application Servers tab. You will complete the next three steps for each server listed.

  4. Click Process definition.

  5. Click Monitoring policy.

  6. You will see the ping timeout values displayed. Enter the increased values over the old ones.

  7. Click Apply.

 

Tune components for peak performance

After installing and configuring your system and when you are ready to test your system with users, you should monitor the resources used by each component.

These components can include, but are not limited to:

Failure to monitor the resource consumption of each component can lead to poor performance and possibly generate exceptions in one or more components.

 

Set the fetch size of JDBC result sets

By setting the number of database rows fetched in one call to the database, you can tune the overall performance of your system. This is because WebSphere Portal Express uses JDBC to access its database. The JDBC API offers a way to specify how many rows of a table are retrieved in one single call to the database. Because selecting data from the database is the most frequent database operation in a WebSphere Portal Express system, you can potentially achieve considerable performance improvements by tuning this setting. The optimal value depends on the size of the database and the usage patterns of the system.

To enable this feature, you have to set an additional property in DataStoreService: datasource.fetchsize=10

The value of 10 is a recommended start value. The optimal value for your system might vary significantly. Perform stress tests with different values and look at the overall performance to identify the optimal setting.

The following JDBC drivers support this feature. The list shows if they support customizable fetch sizes.

JDBC driver Supports customizable fetch sizes
DB2 type 2 driver (COM.ibm.db2.jdbc.DB2Driver) No, setting is ignored
DB2 JCC driver (com.ibm.jcc.DB2Driver) Yes
Microsoft JDBC type 4 drivers for SQL Server 2000 Yes
Oracle Thin JDBC driver Yes
IBM Cloudscape™ Yes
IBM DB2® for i5/OS® Native (com.ibm.db2.jdbc.app.UDBXADataSource) Yes
DB2 for i5/OS Toolbox (com.ibm.as400.access.AS400JDBCXADataSource) Yes

 

Self-registered users using Domino

After a user self-registers through WebSphere Portal Express, they are successfully created but they are not listed in the names.nsf file.

In portal_server_root/wmm, edit the wmm.xml file per the following example with information that is relevant to your system: 

         <supportedLdapEntryType name="Person"
                  rdnAttrTypes="cn" 
                  objectClassesForRead="inetOrgPerson"
                  objectClassesForWrite="dominoPerson"
                   searchBases="o=yourldapsuffix"/>
              <supportedLdapEntryType name="Group"
                  rdnAttrTypes="cn" 
                   objectClassesForRead="groupOfNames"
                   objectClassesForWrite="dominoGroup"
                   searchBases=""/>

Domino only shows users with the dominoPerson objectclass within its views. Nothing is lost as dominoPerson inherits inetOrgPerson.

 

Set the JVM max heap size

Your system might crash, unexpectedly and with no error logs, under the following circumstances:

To avoid this crash, follow these steps to set the JVM max heap size limit:

  1. From the WebSphere Application Server Administration Console, select...

    Servers | Application Servers | WebSphere_Portal | Server Infrastructure | Java and Process Management | Process Definition | Java Virtual Machine | Maximum Heap Size

    ...to set the JVM heap size.

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

    On i5/OS, the JVM max heap size is set to 0 by default, indicating that there is no maximum. This setting should not be changed on i5/OS.

  3. Restart the WebSphere Portal Express server.

  4. After tuning the heap sizes, monitor the system to make sure that paging does not occur.

32-bit operating systems have an address space limit of 4 GB, regardless of the amount of physical memory in the system. This limits the maximum size of each individual process in the system. In addition, some operating systems restrict the size of processes to even less than this limit:

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 might terminate unexpectedly.

On operating systems which impose a 2 GB limit on process size, use a heap size no larger than 1430 MB. The heap size might need to be smaller than this depending on your application (for example, applications which use large native code libraries might need smaller JVM heap sizes to stay under that limit).

 

Disabling Personalization background tasks

LikeMinds checks for new events to process once a day by default.

This function consumes a small amount of system resources. If you do not use the LikeMinds recommendation engine, you can disable this function by stopping the PZN_Utilities.ear that is installed with Portal Personalization.

Once an hour, Personalization checks if there are new e-mail campaigns or rule events which need to be run. This function also consumes a small amount of system resources, especially while processing.

If you do not use Personalization e-mail campaigns or rule events, you can disable this function by stopping the pznscheduler.ear that is installed with Personalization.

 

Related information

 

Parent topic:

Tuning