Areas to Tune

The performance of a WebLogic application is highly dependent on the environment it is running within. As Figure 25.2 depicts, this environment includes both hardware and software components. Each of these components has an effect on the performance of WebLogic applications. Performance, load, and stress testing can help determine the components that need to be configured or replaced to increase the performance of WebLogic applications.

The performance of a WebLogic application is highly dependent on the makeup of the machine (or machines, if you're using a cluster) it is executing on. As shown in Figure 25.3, WebLogic applications depend on multiple layers of hardware and software that can be modified to increase performance.

Operating System

Although WebLogic Server is written in Java (except for some native libraries to increase performance) and can theoretically run on any Java Virtual Machine, BEA has certified only specific hardware platforms, operating systems, and JVMs for use with WebLogic 8.1. The BEA WebLogic Server certifications page can be found at http://e-docs.bea.com/wls/certifications/index.html. It includes only configurations that have passed thorough testing by BEA. For many configurations, BEA lists known problems and tips to improve performance. For example, WebLogic Server running under Solaris can be hampered by a lack of available file descriptors. Also, there are certain Solaris TCP tuning parameters that can improve performance.

CPU and RAM

For every hardware platform and operating system, BEA recommends a minimum CPU type and speed and a minimum amount of RAM. In production, however, the CPU and RAM required depend on your WebLogic application and your acceptable performance levels.

In many cases, CPU availability or RAM availability binds the performance of WebLogic applications. In Windows, the available memory and bandwidth can be determined from the Task Manager as shown in Figure 25.4. Under Unix, the top command displays memory usage, CPU utilization, and disk access on a process-by-process basis.

Network Performance

The performance of your network can have a large effect on the performance of WebLogic applications. Internal and external clients depend on available bandwidth to connect with WebLogic applications. Additionally, these applications will need to connect with external resources, such as an RDBMS. If you are using WebLogic Server clustering, these instances will require network bandwidth for internal communication.

Work with your network administrator to identify network bottlenecks and to procure the network monitoring software available for your operating system. That software will help pinpoint when the performance of your WebLogic application is being diminished by your network.

The network media, network interface cards and their drivers, switches, hubs, and routers being utilized all have an effect on the network speed. In many cases, one or more network components will become a bottleneck and affect the entire performance of the network.

Choice of Java Virtual Machine

Many BEA-certified configurations of WebLogic Server offer a choice of multiple JVMs. This includes the Sun JDK 1.4 HotSpot JVM and BEA JRockit Virtual Machine. If you have a choice of JVMs for your configuration, it is prudent to performance test using multiple JVMs.

BEA JRockit is included in the WebLogic 8.1 products. It is a highly optimized JVM with many features that make it ideal for WebLogic Server, including scalability, multiple garbage collection options, high performance, and a management console for the JVM itself. More information about BEA JRockit can be found at http://www.bea.com/products/weblogic/jrockit/index.shtml.

Java Virtual Machine Options

Every JVM includes options that can affect performance—the most prevalent of which are the heap and garbage collection parameters. We will examine each of these options in detail.

The JVM Heap

The heap size is the amount of memory that the JVM has to work with. WebLogic server code and WebLogic application code create instances of Java classes that are held in this memory. By default, WebLogic Server executes with an initial heap size of 32MB and a maximum of 200MB, as set in the startWLS.cmd and startWLS.sh batch files found in the WL_HOME\weblogic81\server\bin directory.

The JVM allocates more memory for its heap until it reaches the maximum amount allowed. Setting the initial and maximum sizes to be equal relieves the JVM of having to decide when to increase the heap size and reduces the time spent on garbage collection. This can increase performance of the JVM. When the heap has run out of free memory, an attempt to allocate additional memory will result in a java.lang.OutOfMemoryError. (See Table 25.1, which shows the syntax for setting the initial and maximum heap sizes.)

The larger the heap, the better WebLogic Server will perform. However, if the heap becomes larger than available memory, your operating system will swap pages of information to disk. This will severely affect performance. You should set the initial and maximum heap to be 80%–85% of available RAM. It is recommended to run WebLogic Server on a separate machine than the database and other applications. If this is the case, allocate 80%–85% of the total RAM of the machine. If not, calculate how much RAM is available after the other applications' needs and allocate 80%–85% of it to WebLogic Server. The Administration Console contains performance graphs that include the current JVM heap size and its current usage, as shown in Figure 25.5. Garbage collection can be manually forced from this page as well.

Garbage Collection

A separate thread within the JVM manages garbage collection. Every so often, it looks through the heap and releases unused Java objects in a manner dependent on the garbage collection algorithm being used. Unless you are using an incremental garbage collector, all other threads within the JVM come to a halt when this occurs. Obviously, this is quite disruptive and has a severe effect on the performance of WebLogic applications. Reducing the amount of time spent in garbage collection can have a dramatic increase in WebLogic application performance. We want to limit how often garbage collection occurs and how long it takes to complete each time it occurs.

Conventional garbage collection examines every object in the heap to determine which objects are no longer being used. This can take a while, especially when many objects are on the heap. The Sun JDK 1.4 HotSpot JVM offers a generational garbage collector that takes advantage of the fact that most Java objects on the heap have very short lives. It allocates new objects in Eden in a contiguous manner in memory, which is faster to access. As shown in Figure 25.6, when garbage collection occurs, it removes dead objects from Eden and moves the few surviving objects to Survivor Space 1 or to Survivor Space 2 on the next garbage collection. On subsequent garbage collections, surviving objects are moved to the old object area of the heap. The HotSpot JVM also contains an incremental garbage collector that runs more often, but has less to do each time. This eliminates the long, user-detectable pauses associated with traditional garbage collection. Information on tuning garbage collection can be found at http://java.sun.com/docs/hotspot/gc/index.html.

Table 25.1 iterates some of the more commonly used tuning options for the Sun HotSpot JVM.

Table 25.1. Some Sun JDK HotSpot Tuning Options

Command-Line Option	Description
-hotspot	Run in client mode, this option provides quicker start times and a reduced memory footprint; ideal for client or GUI based applications.
-server	Run in server mode to provide long-running server applications with the fastest possible operating speeds. Check whether Server JVM is supported on your platform.
-verbose:gc	Display detailed information when garbage collection occurs. Use for profiling and turn off in production. Redirect output to a log file.
-Xmsn	Initial heap size where n is the size in bytes. Use k or K for kilobytes, m or M for megabytes, and g or G for gigabytes. Default is 2MB.
-Xmxn	Maximum heap size in bytes. Same syntax as -Xms. Default is 64MB.
-Xincgc	Enables incremental garbage collector. Runs run smaller, more frequent collections to avoid the longer, heavier, full garbage collections.

Java VM settings should be changed at the WebLogic domain level by modifying the startWebLogic.cmd or startWebLogic.sh file in the domain directory as shown in Listing 25.1.

Listing 25.1 Excerpt from startWebLogic.cmd in the Domain Directory

@rem Set JAVA_VM to the java virtual machine you want to run. For instance:
@rem set JAVA_VM=-server
set JAVA_VM=

@rem Set MEM_ARGS to the memory args you want to pass to java. For instance:
@rem set MEM_ARGS=-Xms32m -Xmx200m
set MEM_ARGS=

More information about the Sun HotSpot JVM is available at http://java.sun.com/docs/hotspot/index.html. Information there includes JVM command-line options, how to tune garbage collection, and how Java threads are matched to operating system threads.

Threading

Another important JVM option is determining the optimal threading model. JVMs have the capability to map Java threads to native threads on a one-to-one basis or a many-to-one basis. Having the capability to map multiple Java threads to one native thread can potentially increase throughput in your application. For more information about threading models under Sun HotSpot JVM, please refer to http://java.sun.com/docs/hotspot/threads/threads.html. For information about threading models under the WebLogic JRockit JVM, please refer to http://edocs.bea.com/wljrockit/docs81/tuning/index.html.