Performance improvements

Content

  1. Reduce LDAP calls
  2. Increasing performance during creation of credentials
  3. Improving JSP response time
  4. Increasing the ping timeout values
  5. Tuning components for peak performance
  6. Set the fetch size of JDBC result sets
  7. Self-registered users

 

Reduce LDAP calls

The user.base.attributes property in...

<wp_root>/shared/app/config/services/PumaService.properties
...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 will load all attributes defined in the User Repository, which may increase user login time.

User attributes used in banner.jsp or other JSP's should be added to the user.minimum.attributes property in the PumaService.properties file. If any of these attributes are missing from the PumaService.properties file, login performance may suffer.

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

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

 

Increasing performance during creation of credentials

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

  • Get DN

  • Get display name

  • Get group memberships

If you configured WebSphere Application Server security as part of the configuration of WebSphere Portal 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 4.1 or 5.1, 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 IBM Tivoli Directory Server. Refer to the WebSphere Application Server documentation for more information.

  1. From the WebSphere Application Server Administrative Console, select Security > User Registries > LDAP.

  2. Select Ignore Case, and click OK.

  3. Click Advanced LDAP Settings.

  4. Enter ibm-allGroups:member;ibm-allGroups:uniqueMember in the Group Member ID Map field and click OK.

  5. Select Security > Global Security, and click OK to validate the changes.

 

Improving JSP response time

The first time a portlet or portal 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 WebSphere Application Server's JSP batch compiler.

The JSP batch compiler is a command line tool in the was_root/bin directory. Follow these steps to run the JSP batch compiler for WebSphere Portal.

  1. Edit...

    was_root/bin/setupCmdLine.{sh|bat}

    ...and set the WAS_EXT_DIRS environment.

    For AIX, HP-UX, Linux, and Solaris: 

    JAVA_HOME=/WebSphere/AppServer/java

    WAS_HOME=/WebSphere/AppServer

    WP_ROOT=/WebSphere/PortalServer

    set WAS_EXT_DIRS=$JAVA_HOME/lib:$WAS_HOME/classes:$WP_ROOT/shared/app

    For Windows: 

    SET WAS_EXT_DIRS=%JAVA_HOME%/lib;%WAS_HOME%/classes;%WP_HOME%\shared\app;

  2. Run the JSP batch compiler... 

    JspBatchCompiler.sh -enterpriseapp.name wps -server.name WebSphere_Portal

 

Increasing 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 on the Advanced tab.

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

  6. Click Apply.

 

Tuning components for peak performance

After WebSphere Portal is installed and configured, and you are ready to test your system with portal users, monitor the resources used by each component. These components can include, but are not limited to:

  • WebSphere Application Server

  • Front end Web servers

  • Database software

    This includes databases used by WebSphere Application Server, WebSphere Portal, LDAP, or Member Manager, as well as database and backend components used by portal applications. Some tuning may be required for DB2 and Oracle to ensure that adequate resources are available to handle the requests from portal users.

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 portal database, you can tune the overall performance of your portal system. This is because WebSphere Portal 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 system, you can potentially achieve considerable performance improvements by tuning this setting.

The optimal value depends on the size of the portal database and the usage patterns of the portal system.

To enable this feature, you have to set an additional property in the DataStoreService.properties file:

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

Cloudscape

Yes

 

Self-registered users using Domino

After a user self-registers through WebSphere Portal, they are successfully created but they are not listed in the names.nsf file. In PortalServer/shared/app/wmm, edit the wmm.xml file with the following information: 

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

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

 

See also

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.