Portal Performance

 

+
Search Tips   |   Advanced Search

 

  1. Use high performance skins
  2. Reducing LDAP calls
  3. Increasing performance during creation of credentials
  4. Improving JSP response time
  5. Disabling support for nested groups may improve login performance
  6. Perform a reorg check for databases
  7. Increasing the ping timeout values
  8. Tuning components for peak performance
  9. Set the fetch size of JDBC result sets
  10. Change the credential vault encryption

 

Use high performance skins

WebSphere Portal Version 5.0.2 introduces support for high performance skins. When you enable high performance skins, the Default and NoSkin skins are rendered in a way that provides faster aggregation. High performance skins cannot be as extensively customized as standard skins; however, you can still modify the images and colors.

A standard skin is composed of JSPs for each skin component. Standard skins can be extensively customized. High performance skins are are not generated by JSPs, so the markup for high-performance skins cannot be customized. High performance skins are generated by code that is compiled into WebSphere Portal and cannot be modified by portal users. If high-performance skins are used, the JSP files for the high-performance skins are ignored. The static content, such as graphics and style sheets, is still used. As a result, only the static content files can be customized. Altering the markup generated by high-performance skins is not possible.

At this time, only the Default and NoSkin skins can be converted to high performance skins. When you enable high performance skins, both the Default and NoSkin skin are converted to high performance skins. For example, you cannot convert only the Default skin to a high-performance skin. Enabling high performance skins affects only the Default and NoSkin skins.

Use high performance skins and standard skins on the same page. For example, some portlets on the page might use high performance skins, and other portlets might use standard skins.

High performance skins work best when... Do not use high performance skins when...

  • Performance is a high priority.
  • Customization of the Default and NoSkin skins is limited to changing style sheets and images.

  • The Default or NoSkin skins are extensively customized, especially if there are changes to the layout or structure of the skin. If you convert a highly customized skin to a high-performance skin, many of the customizations are ignored and will not function as designed.
  • You want to continue using the standard Default or NoSkin skins in some areas of the portal. Once you enable high performance skins, the behavior of the Default or NoSkins skins changes.

High performance skins are only supported for the HTML markup. Other markups, including WML and CHTML, are not supported.

 

Customize high performance skins

You can modify the following elements of high performance skins:

If you customize the NoSkins skin, the changes will affect administrative portlets in the portal. Administrative portlets use the NoSkins skin by default. Select a different skin for the administrative portlets if you do not want the changes to affect administrative portlets.

See Customizing the portal for more information about customizing style sheets and images.

 

Enabling high performance skins

Three parameters are used to enable high performance skins:

You receive the greatest performance improvements by enabling all three parameters; however, enabling only one of these parameters still provides some benefit. For example, if you require highly customized controls that prevent you from enabling high performance controls, you can still enable high performance containers and gain some performance benefit.

Do the following before enabling high performance skins:

Follow these steps to enable high performance skins:

  1. Open the ConfigService.properties file in...

    wp_root/shared/app/config/services

  2. If the file does not contain the skins.highperf.containers, skins.highperf.layeredcontainers, skins.highperf.controls, and skins.highperf.showself parameters, add these parameters to the file.

  3. Optional: Set the skins.highperf.containers value to true. This enables high performance unlayered containers.

  4. Optional: Set the skins.highperf.layeredcontainers value to true. This enables high performance layered containers.

  5. Optional: Set the skins.highperf.controls value to true. This enables high performance controls.

  6. Optional: Set the skins.highperf.showself value to true. This places an HTML comment in the code of each high performance component. Use this comment to verify that high performance skins are being used. See the Verifying high performance skins section below for more information.

  7. Save the changes and close the ConfigService.properties file.

  8. Restart WebSphere Portal.

    You can revert to standard skins at any time by setting the skins.highperf.containers, skins.highperf.layeredcontainers, and skins.highperf.controls values to false. Any changes you made to style sheets and images will persist.

 

Verifying high performance skins

Enabling high performance skins does not change the appearance of the portal in any way. High performance skins simply render components more quickly. This can make it difficult to confirm that high performance skins are being used by a particular component.

If you added the skins.highperf.showself=true parameter to the ConfigService.properties file as described above, you can verify high performance skins by viewing the source HTML of the rendered components:

  1. View the component in a browser.

  2. Use the browser to view the source HTML code for the component. If the component uses high performance skins, an HTML comment containing the term "fast skins" appears at the beginning of the code for the component. For example: <!-- Fast skins.html.LayeredContainer-->.



 

Reducing LDAP calls

All user attributes that are defined in the getuser.minimum.attributes property in the PumaService.properties file should be present in the LDAP entry for each portal user. The PumaService.properties file is located in...

<wp_root>/shared/app/config/services

...by default. If any of these attributes are not defined in the LDAP entry for a user, the login time for that user may increase.

User attributes used in the banner.jsp or other JSP's should be added to the getuser.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 the LDAP server, is configured. However, if you use dynamic groups, comment out the 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 WAS is not configured using the preloaded default LDAP filters for IBM Directory Server 4.1 or Version 5.1, Active Directory, or iPlanet 5.1, three LDAP calls are made when creating credentials. These calls do the following:

If you configured WAS security as part of the configuration of WebSphere Portal configuration tasks, these WAS 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 Directory Server 4.1 or 5.1, use the appropriate default filters for the LDAP server. These filters are preloaded with WAS. Follow the instructions below to configure WAS to use the default filter for IBM Directory Server. Refer to the WAS documentation for more information.

  1. From the WAS Administrative Console, select Security then click User Registries then click 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 then click 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 the JSPs before they are requested using WAS'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 in the was_root/bin directory and set the WAS_EXT_DIRS environment variable include the value of the portal server's wp_root/shared/app directory. This step allows the tool to access the necessary resources for WebSphere Portal JSPs. For example:

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

 

Disabling support for nested groups may improve login performance

User groups in the portal can be organized in different structures:

Flat structure with: Groups have no sub-groups.
Hierarchical with nested groups: Some groups are members of other groups.

If the portal uses a flat structure, you can disable support for nested groups in the access control component. This can significantly improve login performance for users who are members of many groups.

Disable support for nested groups by adding the following line...

accessControlDataManagement.enableNestedGroups=false

...to...

<wp_root>/shared/app/config/services/AccessControlDataManagement.properties

Do not disable support for nested groups if the portal uses a hierarchical group structure.

 

Perform a reorg check for databases

When you create database tables and insert data, a reorg check can help improve performance. See the database documentation for details.

 

Increasing the ping timeout values

The values of ping interval, ping timeout, and ping inital 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 WAS 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 the system with portal users, 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 portal database, you 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, 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 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
Informix JDBC driver Yes

Cloudscape

Yes

 

Change the credential vault encryption

WebSphere Portal supports different vault adapters for the storage and retrieval of credentials. The default vault adapater stores the credential passwords in the database. You can customize the encryption for the default vault.

  1. Write a class that implements the EncryptionExit interface: 
    package com.ibm.wps.sso.vaultservice;

public interface EncryptionExit 
{
 
   /**
    * Encrypt the password
    *
    * @param password Unencrypted Password
    * @return Encrypted password as a char[]
    */

   public char[] encryptPassword(char[] password);

   /**
    * Decrypt the password
    *
    * @param password Encrypted Password
    * @return Unencrypted Password as a char[]
    */

   public char[] decryptPassword(char[] password);
}

  2. Deploy the new class to the portal.

    • Create a jar file with the new encryption exit class and place it under...

      wp_root/shared/app

    • Use the WebSphere Application Server Administrative Console and navigate to...

      Environment -> Shared Libraries -> WPSlib

      You might have to start the server1 application server to access the admin console.

    • Enter the location of the new jar file under Classpath .

  3. Set the name of the adapter file properties in the file

    wp_root/shared/app/config/services/VaultService.properties

    ...to...

    default.config=defaultvault.properties

    Add the file...

    wp_root/shared/app/defaultvault.properties

    ...with the following contents:

    encryptionExit=com.yourcompany.YourEncryptionExit

  4. Restart the WebSphere Portal.