Performance improvements

 

+
Search Tips   |   Advanced Search

 

  1. Have Welcome page snap to attention
  2. Reduce LDAP calls
  3. Increase performance during creation of credentials
  4. Improve JSP response time
  5. Increase the ping timeout values
  6. Tune components for peak performance
  7. Set the fetch size of JDBC result sets
  8. Self-registered users using Domino
  9. Set the JVM max heap size to enable file importing
  10. Disable Personalization background tasks

 

Have Welcome page snap to attention

The Welcome page is the first page that all users will hit when coming to the Portal. In order for the page to load , you should minimize the number of resources that need to be rendered. Navigation is not available until all resources have loaded, which means that those users with twitchy fingers might try to access portal material before the page is ready, leading to possible exceptions.

  • Do not put slow loading portlets onto the Welcome page. For example, avoid RSS and My News type portlets, which require a trip to an outside server in order to obtain the requisite information.

  • Do not hang child menus under the Welcome page. Navigation URLs to those child menus will need to be generated, eating up CPU cycles, before the Welcome page can be rendered.

  • Eliminate non-essential theme resources. For example, you might want to remove the Portlet Palette option by setting ContentPalette to false for the chosen theme policy.

 

Reduce LDAP calls

The user.base.attributes property in Puma service should contain the set of attributes needed by most of the 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 the portlet applications, WebSphere Portal will load all attributes defined in the User Repository, which might increase user login time.

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 Set 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 the 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, check out the file before editing, and check it in to the Deployment Manager configuration repository after editing. 

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

 

Increasing performance during creation of credentials

If IBM WAS 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 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, 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.

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

    Security | Global 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 | 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, we can compile the JSPs before they are requested using WebSphere Application Server 's JSP batch compiler. The JSP batch compiler is a command line tool in the following directory:

To run the JSP batch compiler for WebSphere Portal.

  1. Edit the setupCmdLine.{sh | bat} script in the above directory and set the WAS_EXT_DIRS environment variable, include the value of the portal server directories that you want to include; for example, but not limited to, the following directories:

    This step allows the tool to access the necessary resources for WebSphere Portal JSPs. For example:

    • UNIX:

      SET WAS_EXT_DIRS=$JAVA_HOME$/lib:$WAS_HOME$/classes:... /opt/WebSphere/PortalServer/shared/app:/opt/WebSphere/PortalServer/shared/app/contentLib:/opt/WebSphere/PortalServer/shared/app/oiexport:/opt/WebSphere/PortalServer/shared/app/scripting:/opt/WebSphere/PortalServer/shared/app/wpai;

    • Windows:

      SET WAS_EXT_DIRS=%JAVA_HOME%/lib;%WAS_HOME%/classes;... C:\WebSphere\PortalServer\shared\app;C:\WebSphere\PortalServer\shared\app\contentLib;C:\WebSphere\PortalServer\shared\app\oiexport;C:\WebSphere\PortalServer\shared\app\scripting;C:\WebSphere\PortalServer\shared\app\wpai;

    • i5/OS:

      SET WAS_EXT_DIRS=$WAS_INSTALL_ROOT/lib:${WAS_INSTALL_ROOT}/classes:... /QIBM /UserData/WebSphere/AppServer/V6/Base/profiles/profile/PortalServer/shared/app:/QIBM /UserData/WebSphere/AppServer/V6/Base/profiles/profile/PortalServer/shared/app:/QIBM /UserData/WebSphere/AppServer/V6/Base/profiles/profile/PortalServer/shared/app/contentLib:/QIBM /UserData/WebSphere/AppServer/V6/Base/profiles/profile/PortalServer/shared/app/oiexport:/QIBM /UserData/WebSphere/AppServer/V6/Base/profiles/profile/PortalServer/shared/app/:/QIBM /UserData/WebSphere/AppServer/V6/Base/profiles/profile/PortalServer/shared/app/scripting:/QIBM /UserData/WebSphere/AppServer/V6/Base/profiles/profile/PortalServer/shared/app/wpai

  2. Run the JSP batch compiler with the following parameters:

    • UNIX:

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

    • Windows:

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

    • i5/OS:

      JspBatchCompiler -enterpriseapp.name wps -server.name WebSphere_Portal -profileName profile_root

      ...where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.

 

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

 

Tuning components for peak performance

Establish a baseline. Begin monitoring after configure the portal and setting up the first set of portal users.

Monitor resources for such components as...

  • WebSphere Application Server
  • Front end Web servers
  • Database software

Database software includes databases used by...

  • WebSphere Application Server
  • WebSphere Portal
  • LDAP
  • Member Manager
  • portal applications

Some tuning might be required for DB2 and Oracle to ensure that adequate resources are available to handle requests.

One immediately available tool we can use for monitoring portal and the application server is Tivoli Performance Viewer.

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, we can tune the overall performance of the 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, we 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 DataStoreService:

datasource.fetchsize=10

The value of 10 is a recommended start value. The optimal value for the 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
DB2 UDB for iSeries Native (com.ibm.db2.jdbc.app.UDBXADataSource) Yes
DB2 UDB for iSeries Toolbox (com.ibm.as400.access.AS400JDBCXADataSource) 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 portal_server_root/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 only shows users with the dominoPerson objectclass within its views. Nothing is lost as dominoPerson inherits inetOrgPerson.

 

Set the JVM max heap size to enable file importing

If you import files and run indexing at the same time, the portal might crash; the portal stops unexpectedly and with no error logs. 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.

    Notes:

    • 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. Perform the following steps to restart the WebSphere Portal server in a Windows or UNIX environment:

    1. Open a command prompt and change to the appropriate directory as indicated here.

    2. Enter the stop server command as indicated here.

    3. Enter the start server command as indicated here.

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

Note the following about heap sizes:

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

    • For Windows operating systems we can find information at Microsoft Support -- many have a 2 GB limit

    • Many 32-bit Linux kernels default to a 2 GB limit for processes

  • 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 the application (for example, applications which use large native code libraries might need smaller JVM heap sizes to stay under that limit).

  • When using the Cloudscape database, the JVM heap size should not exceed 1024 MB.

 

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 may 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 may disable this function by stopping the pznscheduler.ear that is installed with Personalization.

 

Related information

For additional tips to improve WebSphere Portal performance, see the WebSphere Portal Tuning Guide.

 

Parent topic:

Tuning

 

Related tasks

Improve response time of Directory Search