Performance tips for WebSphere Studio Application Developer

Introduction

This document describes some ways to improve the performance of WebSphere Studio Application Developer (Application Developer).

Prevent or reduce thrashing

One of the powerful features of Application Developer is its WebSphere test environment. The test environment allows you to test and debug your application on your local machine.  

Because the test environment often involves running a database manager (for example DB/2), WebSphere, and Application Developer on the same machine, the hardware resources of that machine might be stressed. In particular the default configuration might require more physical memory than what is available. If that happens the operating system might end up spending too much time handling page faults, and not enough time doing meaningful work. For example, WebSphere Application Server steals a page from Application Developer, but Application Developer needs that page so it steals a page from DB/2 which then steals a page from WebSphere Application Server and the cycle continues. This is known as thrashing, and when it happens the performance of your computer degrades dramatically.  If you notice that your hard disk light is on a lot, this may be happening to you. The goal of this section is you show you ways to prevent or at least reduce trashing.  

When the test environment is running, there are two large Java processes running, Application Developer and WebSphere test environment. The WebSphere test environment is not a stripped down version of WebSphere Application Server, but rather it is the full WebSphere Application Server, Advanced Single Server Edition. A Java process by its nature does not have good locality of reference, which means that the data and code that it needs is scattered across its address space. If a page gets swapped out, often it will not be very long before that page is needed again. Because of this characteristic, it is important to keep your active Java processes running inside of physical memory.

 A large part of the memory that is needed by a Java process is the Java heap. When you allocate an object it ends up in the Java heap. The maximum size of the Java heap can be  set with a tuning parameter. The trick is to make this big enough so that your application continues to run, but also small enough so that the Java process fits inside of physical memory.

The following figure shows a configuration where thrashing could be a problem.

Reducing the size of the Java Heap could allow both of the Java processes to fit in physical memory and thus reduce paging.

For the IBM Java virtual machines (JVMs) the size of the Java heap is controlled by the -Xmx parameter. So for example to limit the Java heap to a maximum size of 128 MB, you would add the following startup parameter -Xmx128M. 

If this parameter is not supplied, the default behavior for an IBM JVM is to set the maximum Java heap size to one half of the size of physical memory. If your computer had 512MB of physical memory, the Java heap for each Java process could grow to 256MB. Since the Java process requires memory for things other than the Java heap, like for storing byte codes, stack frames, native code, etc, the memory requirements for the entire Java process could exceed 256MB. This other memory is depicted as "Java Other" in the figures above, and it is not affected by the -Xmx parameter.

Tuning involves two steps:

  1. Determining what the Java heap limits should be.
  2. Setting the limits.

Determining the limits

The first step is to determine the working set of your normal applications and the operating system. You can get this number from the Windows Task Manager.

n this example, if the system has 512 MB of physical memory, there would be left 325 MB (that is, 512 - 187) for Application Developer and the WebSphere test environment. You could try limiting the Java heap for Application Developer to 128MB and the WebSphere test environment to 96MB. The next section shows you how to do that. If you find that you are encountering out- of- memory errors then increase the limit.

Setting limits

To set the Java heap limit in Application Developer edit the wsappdev.ini file. This file is found in the root installation directory of Application Developer. For example c:\Program Files\WebSphere Studio. In that file there will be a line that starts with VMArgs, for example:

VMArgs=-Xms64M -Xquickstart -Xgcpolicy:optavgpause

Add the parameter -Xmx128M to this line. If there was already an -Xmx parameter then update it. Adding parameters to the VMArgs line is how you control the JVM that runs Application Developer. To learn more about other -X parameters, run the command java -X

To set the Java heap for the WebSphere test environment, in Application Developer open up the Server Configuration editor, and update the Java VM Arguments parameter on the Environment page. 

Again, you may have to experiment a bit to get these parameters just right for your environment.

Other ways to conserve memory

If you have processes that do not need to be active, a word processor for example, you could consider closing them to conserve memory.

Divide and conquer. If you cannot limit the Java heaps because of out- of- memory problems, and if installing more memory is not an option (because you have already reached the motherboard limit), you could consider running your WebSphere test environment on a different machine. Application Developer has very good facilities for debugging and deploying to remote WebSphere test environments. 

Other performance tips

Saving resources and incremental build

You may find that you do not need all of the validators running all of the time. They can be turned off. This is controlled from the preferences page (Windows -> Preferences).

Starting up Application Developer

Another preference that may affect your startup performance is label decorations. These are also controlled from the Preferences page, under the Workbench entry.

The code that has to run as part of the startup phase determines how long it will take to start Application Developer. Application Developer is composed of a set of plug-ins, and the startup process only initializes the plug-ins that are needed for the first screen to come up. The active perspective and the active editor (if there is one) help determine which plug-ins need to be initialized, in the startup phase.

If you closed your workspace and you were in the Java perspective and you had a Java editor active, your next startup would be faster than if you closed the workspace from the J2EE perspective and had the Page Designer as the active editor. This is because Application Developer restores your previous state and the J2EE perspective requires more initialization, and is dependent on more plug-ins than the Java perspective. Likewise the Page Designer has a higher initialization cost than the Java editor. 

The reason that label decorations may affect startup time is that they are initialized as part of the startup phase, and they may cause additional plug-ins to be initialized.

Starting up the WebSphere test environment

Only start the WebSphere test environment in debug mode when you plan to use the debugger. For normal unit testing start the test environment in normal mode.

Debug mode causes the just- in-time Compiler (the JIT) to be disabled. Because all of the Java code is now interpreted this causes the startup time to be be longer and causes your application to run slower.

Debug mode also causes JSPs to be handled differently. In addition to being compiled they are post-processed.

Many times you can avoid restarting the WebSphere test environment by restarting a module instead. Restarting a module (or a project) is much quicker than restarting a server. The Restart Project menu item is available from the context menu.    

Return to the main readme file