Installing and configuring WebSphere Portal V6.0 Servers for development with Rational Application Developer V7.0 and Rational Software Architect V7.0

How to optimize performance and reduce resources consumed

IBM® Rational® Application Developer V7.0 and IBM® Rational® Software Architect V7.0 are the first products in the IBM® Rational® Software Delivery Platform range of products to include full-featured support for IBM® WebSphere® Portal V6.0 development. This means that you can develop with the convenience of WebSphere Portal V5 test environments but without any of their limitations. However it also means that you have a full Portal 6.0 instance running on your development machine, which can drain your resources. This article provides tips on how to reduce the amount of resources that WebSphere Portal 6.0 consumes on your machine, as well as how to optimize its performance for your development requirements.

Donal Riordan (driordan@ie.ibm.com), Software Development Engineer, IBM 

Donal Riordon is an IBM Sofware Engineer working on Portal server tools.



27 March 2007

Also available in Chinese

How these applications work together

The WebSphere Portal V6.0 server support does not follow the same design as the WebSphere Portal Version 5 support. For Portal 6.0, there is no slimmed-down test environment that is intended to be used within the Rational products. It uses a full Portal 6.0 server, instead.

When installed on the same machine, the behavior of the Version 5 test environment is enabled (automatic reloading of artifacts, hot code swapping, and so forth). This means that you can develop with the convenience of the Portal V5 test environment but without any of their limitations. However, it also means that you have a full Portal 6.0 instance running on your development machine, which can drain your resources.

The intention of this article is to provide tips on how to reduce the amount of resources that Portal 6.0 consumes on your machine as well as how to optimize its performance based on your development requirements. It also covers other setup and configuration information that is useful if you intend to use the Rational products for developing WebSphere Portal 6.0 solutions.

Terminology in this article

To avoid repetition of long names, this article uses the following shortened terms:

  • Rational software means either Rational Application Developer V7.0 or Rational Software Architect V7.0, or both.
  • Portal or portal, unless otherwise stated, refers to WebSphere Portal V6.0.
  • WebSphere, unless otherwise stated, refers to the IBM® WebSphere® Application Server V6.0, which runs the portal (WAS in screen code).
  • Linux® refers to Linux operating systems and any other UNIX®-like operating system supported by WebSphere Portal V6.0, such as IBM® AIX® or Sun® Solaris™.

When referring to disk locations, the following designations apply:

  • WAS_HOME: The directory where WebSphere Application Server V6.0 is installed.
  • WPS_HOME: The directory where WebSphere Portal Server V6.0 is installed.
  • WP_PROFILE: The directory for the WebSphere Portal WebSphere server profile.

Installation tips

Host name

If the portal that you are installing will be used by developers on other machines, then the value that you enter for Host name must be resolvable on all of those machines. Therefore, it is best to use a fully qualified host name or IP address, as Figure 1 shows.

Figure 1. Properties for the WebSphere Application Server
Figure 1. Properties for the WebSphere Application Server

To test whether the value that you have chosen is satisfactory, you can try pinging the exact value that is entered in the wizard from one of the development machines. If you can successfully ping the server machine, then you can use this value.

In the local server case, where the portal and Rational software will be on the same machine, the default value in the wizard should always be acceptable.

WebSphere business process support

WebSphere business process support is enabled or disabled at installation time (see Figure 2) through the WebSphere Process Server. In WebSphere Portal V6.0, you cannot disable or enable it after installation. Therefore, if you need to change it, you need to reinstall the portal server.

Figure 2. Option to install business process support during installation
Figure 2. Shows option to install business process support

Installing business process support incurs a significant performance penalty in server startup time. Although the Portal 6.0 development tools are designed to work without the need for server restarts, there may still be occasions when a developer needs to restart the server. Therefore, it is best not to install business process support unless it is actually required.

Reducing startup time

Note: Options mentioned under this section should not be used in the production environment, as they are not supported. They are only meant to help the developer on a local machine for faster development cycles.

The portal configuration that is installed by the normal portal installation is optimized primarily for long-term runtime performance rather than startup time, which is more likely to be of interest to developers. As stated earlier, Rational software's support for Portal 6.0 is designed to work without requiring server restarts, but there still may be occasions when a developer needs to restart the server. Fortunately, there are ways to significantly reduce the amount of time that the portal takes to start.

How to enable development mode

The first step that you can take is to enable the development mode in the Administrative Console. If you intend to start the server through Rational software, then this step is unnecessary, because the software does this automatically. If there is no Rational software on the portal server machine, then you will need to do this manually through the Administrative Console by following these steps:

  1. Open the Administrative Console and navigate to Application Servers > WebSphere_Portal, and select the Run in development mode check box (see Figure 3).
Figure 3. Check the option to run in development mode
Figure 3. Check box for option to run in development mode
  1. Next, unzip the StartupPerformanceConfig.zip file--see Download--to WPS_HOME/config. This zip file contains scripts that can disable some of the nonessential portal components.
  2. Before you can run these scripts, you must properly configure the WPS_HOME/config/wpconfig.properties file. Open this file with a standard text editor and ensure that the following fields have the correct values assigned to them (you choose all of these values during portal installation):
    • WasUserid: WebSphere Application Server security authentication user ID
    • WasPassword: WebSphere Application Server security authentication password
    • PortalAdminId: WebSphere portal administrator ID
    • PortalAdminPwd: WebSphere portal administrator password
  1. When these values are correctly set, you can run the following command to disable a component:
    • Microsoft® Windows®: WPS_HOME\config\WPSconfig.bat <target>
    • Linux: WPS_HOME/config/WPSconfig.sh <target>

Where <target> is one of the following:

  • action-disable-target-mapping-portlets: All portlet applications provided by the portal
  • action-disable-target-mapping-pzn: Disables all personalization applications
  • action-disable-target-mapping-caiwcm: Disables all computer-aided instruction (CAI) and WCM applications
  • action-disable-target-mapping-misc: A few miscellaneous applications

It is always possible to re-enable these components by running the same command but replacing disable with enable in the target name. So, for example, to disable the personalization applications, you would run the following command (in Windows):
WPS_HOME\config\WPSconfig.bat action-disable-target-mapping-pzn

If you later wanted to re-enable personalization, you would use this command:
WPS_HOME\config\WPSconfig.bat action-enable-target-mapping-pzn

Note:
If you disable personalization, CAI and WCM or the miscellaneous applications, then they are no longer available on the server. In contrast, disabling the portlet applications does not make them unavailable. It simply defers loading them until they are actually needed.

Debug mode

Starting the server in debug mode is required if you want to be able to debug your applications from Rational software but running in debug mode results in a performance hit especially in the startup time. As well as the generic startup improvements of the previous section there is another step you can take which improves the startup time when running in debug mode. If you intend on starting the server in debug from Rational software then you may skip this section as Rational software automatically performs this optimization. If the server is on a remote machine which does not have a Rational software installation then you should use this.

  1. To configure a server to start in debug mode, click the Debugging Service properties link in the Application servers > WebSphere_Portal panel (see Figure 4).
Figure 4. Setting Debugging Service properties
Figure 4. Path for setting Debugging Service properties
  1. Then select the Enable service at server startup check box (see Figure 5).
Figure 5. Enabling the Debugging Service
Figure 5. Shows enabling the Debugging Service
  1. When you have done this, you can optimize the debug mode startup by tweaking the Java™ Virtual Machine (JVM) arguments for the portal, as Figure 6 shows:
    1. First expand the Java™ and Process Management item in the WebSphere_Portal panel.
    2. Then and click Process Definition.
Figure 6. Optimizing debug mode startup
Figure 6. Shows settings for optimizing debug mode startup

Tip: Notice that the ‘Run in development mode’ checkbox is selected as per the instructions in the previous section).

  1. In the Process Definition panel (Figure 7), click the link for Java Virtual Machine properties:
Figure 7. Process Definition panel
Figure 7. Process Definition panel screen capture
  1. In the Debug arguments field, add the argument –Xj9 so that the field value is as Listing 1 shows (assuming defaults for other arguments).
Listing 1. Adding a debug argument
-Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=
n,address=7777 -Xj9
  1. The –Xj9 switch improves performance, but it interferes with two arguments in Generic JVM arguments. To remedy this, you need to remove the –Xp???k,??k and –Xk????? arguments, which by default are: -Xp128k,64k -Xk40000. This makes the field value for Generic JVM arguments what you see in Listing 2, assuming defaults for other arguments. (See Figure 8 also.)
Listing 2. Adding a debug argument
${WPS_JVM_ARGUMENTS_EXT} -Ddb2j.system.home=${WPS_HOME}/cloudscape
Figure 8. Deleting debug mode arguments
Figure 8. Screen view of deleting debug mode arguments
  1. After you have done this, save your configuration to the master configuration and restart the server. The server will now be in debug mode, and its startup will have taken less time than if you had not tweaked the JVM settings.

Backup and recovery

Rational software operates directly on the portal server. Therefore, it may be useful to be able to save a particular configuration and to be able to restore it if your server becomes unstable or if you want to restore the portal to a certain state.

Backing up and restoring the portal

It is important that you make backups of two directories in your portal installation.

  • The first is the WebSphere profile directory for the portal profile. On Windows. this defaults to the C:\ibm\WebSphere\profiles\wp_profile, and on Linux, it defaults to the WAS_HOME/profiles/wp_profile. A WebSphere profile defines the runtime environment for the server, such as what applications to run, what the security settings are, and what data sources are defined.
  • The second useful backup directory is the portal database directory, which defaults to WPS_HOME/cloudscape on both Windows and Linux. This directory contains the database that defines the layout of the portal.

When restoring either of these backups, you will need to stop your server, delete the current contents of the directory, and then copy the contents of the backup into the now empty directory. After doing this, you can start your server again, and the portal that you backed up should be restored. You can backup and restore these directories individually, but it is far better that you backup and restore both of them together and at the same time, because there are certain elements in each that rely on elements in the other.

Reinstalling the portal

You should use the Portal uninstaller to remove a Portal installation from the machine but in certain cases such as an aborted installation this may not work. If you want to make sure that your machine is clean before reinstalling Portal and then take the following steps:

  1. If the WPS_HOME directory exists then delete it and its contents.
  2. If the WAS_HOME directory exists then delete it and its contents.
  3. If your profiles directory is not stored under WAS_HOME then you need to delete this directory as well. This is likely to occur on Windows where the default location is C:\ibm\WebSphere\profiles irrespective of where you have installed Portal or WebSphere.
  4. Windows only: Open the Registry Editor and delete these keys:
    • HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphere Portal Server\6.0.0.0
    • HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphere Application Server Network Deployment\6.0.0.0
  5. Locate the vpd.properties file. In Windows, this is in C:\Windows or C:\WinNT, and in Linux, it is in /root. Edit this file to remove any entries that refer to a location in WPS_HOME or WAS_HOME for the portal that you are trying to uninstall. Alternatively, you can just delete this file, but that advisable only if you have no other portal installations of any version on this machine.
  6. In your home directory (for example, /root on Linux or C:\Documents And Settings\<username> on Windows), delete these three files if they exist. Note that on Linux these files may be hidden, because they start with a period. Ensure that this is not the case.
    • .ITLMRegistry
    • ._cie.trace.xml.lck
    • .WebSphereRegistry

Other ways to optimize performance

There are various other changes or tweaks that can improve stability and functionality. Among the most important to know about are how to switch the wps.ear file and how to control caches to boost performance.

Change the JAR file

Rational software requires the main portal enterprise application, wps.ear, to be running for its tools to work. In cases where this application is not working or has become corrupt, the software attempts to automatically restore it from the wps.ear file in WPS_HOME/installableApps/wps.ear. Part of this wps.ear archive is a Java™ Archive (JAR) file that the portal uses, wp.scheduler.ejb.jar. The version of this JAR in the wps.ear file in installableApps has not been prepared for deployment in Portal 6.0. Therefore, when Rational software needs to restore the portal from this file, this Enterprise JavaBeans™ (EJB™ technology will not get correctly deployed, so you may see console exceptions or odd behavior from the portal.

To fix this wps.ear file, replace the version of the wp.scheduler.ejb.jar file with the version of the file that you find in the WP_PROFILE/installedApps/wps.ear directory.

  • On Windows, WP_PROFILE is, by default, C:\ibm\WebSphere\profiles\wp_profile.
  • On Linux, it is WAS_HOME/profiles/wp_profile.

You can distinguish a prepared version of this JAR from an unprepared version by their file sizes. The prepared version of the JAR, which you find in the installedApps directory, should be 104 KB, and the unprepared version in the wps.ear file in installableApps is 44 KB.

Control caches

WebSphere Portal 6 contains many caching services that help to boost long-term performance when the server is being used in a production environment. In a development environment, long-term performance of the server is not likely to be a priority, and content will change more frequently, thus the caches can become a hindrance rather than a help.

You can control which caches are enabled by editing the CacheManagerService.properties file, which is contained within the WPS_HOME/shared/app/wp.services.properties.jar file. The first group of settings in this file are the global cache settings. (See Listing 3.)

Listing 3. Sample code listing at maximum width
#######################################################
######################
#
# Global settings. These can be overridden for individual caches.
# The evaluation order for parameters is:
#       1. Parameters given when requesting a cache (in the program code)
#       2. Parameters for the cache given in this files (see last part of file)
#       3. The following list of default values.
#
#######################################################
######################

# Is caching enabled? [specify true, yes (or false, no)]
#
# Default: true
cacheglobal.enabled=true

# Default cache size, in number of entries
#
# Default: 1000
cacheglobal.size=1000

# Cache sharing
# 
# Default: false
cacheglobal.shared=false

# Shall cacheinstances use java.lang.ref.SoftReferences to hold
# cacheentries or not. This can be turned on/off for each individual instance
#
# Default: false
cacheglobal.softref=false

These settings are used to specify the settings for caches that do not have their own entries in the file. Because, by default, all caches have entries, modifying this has no effect unless you delete the cache entries later on in the file. To enable or disable a cache, locate its cache entry and set the enabled value to false. Listing 4 shows an example.

Listing 4. Sample code listing at maximum width
cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.shared=true
cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.enabled=true
cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.lifetime=1200
cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.size=8000
cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.replacement=moderate
cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.admit-threshold=0

Please note that you should not disable the caches on servers that will be used in a production environment, because this will result in a performance penalty. You can find more information about configuring caches in the WebSphere Portal InfoCenter (see Resources).


Download

DescriptionNameSize
Sample scripts for this articleStartupPerformanceConfig.zip5KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Rational
ArticleID=203675
ArticleTitle=Installing and configuring WebSphere Portal V6.0 Servers for development with Rational Application Developer V7.0 and Rational Software Architect V7.0
publish-date=03272007