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 (
WASin 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.
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
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
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:
- 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
- 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.
- 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
- When these values are correctly set, you can run the following command to disable a component:
- Microsoft® Windows®:
- Microsoft® Windows®:
<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
enable in the target name. So, for example, to disable the personalization applications, you would run the following command (in Windows):
If you later wanted to re-enable personalization, you would use this command:
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.
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.
- 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
- Then select the Enable service at server startup check box (see Figure 5).
Figure 5. Enabling the Debugging Service
- 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:
- First expand the Java™ and Process Management item in the WebSphere_Portal panel.
- Then and click Process Definition.
Figure 6. Optimizing debug mode startup
Tip: Notice that the ‘Run in development mode’ checkbox is selected as per the instructions in the previous section).
- In the Process Definition panel (Figure 7), click the link for Java Virtual Machine properties:
Figure 7. Process Definition panel
- In the Debug arguments field, add the argument
–Xj9so 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
–Xj9switch improves performance, but it interferes with two arguments in Generic JVM arguments. To remedy this, you need to remove the
–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
Figure 8. Deleting debug mode arguments
- 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:
- If the WPS_HOME directory exists then delete it and its contents.
- If the WAS_HOME directory exists then delete it and its contents.
- 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.
- Windows only: Open the Registry Editor and delete these keys:
HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphere Portal Server\188.8.131.52
HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphere Application Server Network Deployment\184.108.40.206
- 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.
- 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.
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.
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).
|Sample scripts for this article||StartupPerformanceConfig.zip||5KB|
- Stay current with developerWorks technical events and Webcasts.
- IBM Rational Application Developer product page: Find technical documentation, how-to articles, education, downloads, and product information about Rational Application Developer.
- Visit IBM's Pattern Solutions and find out what IBM is doing around patterns and reusable assets.
- Browse the technology bookstore for books on these and other technical topics.
- WebSphere Portal InfoCenter, where you can find more information about configuring caches.
Get products and technologies
- Download a free trial version of Rational Application Developer.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- Participate in developerWorks blogs and get involved in the developerWorks community.
- Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Application Developer.
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.