Identify the technical domain of your WebLogic Server environment, which will include WebLogic Server, deployed applications, hardware platform, operating system, databases, legacy systems, and so on. To perform this activity, you need to bring together a team of experts who can technically address each aspect of your WebLogic Server environment.

Have the team document the exact configuration of your WebLogic Server environment. For example, keep track of the following:

This exercise is essential because it documents a control environment for your WebLogic Server, which will serve as a baseline configuration for all your performance-tuning activities. It is also good practice to version-control all configuration files related to creating the WebLogic Server environment, which enables you to audit changes to the environment, as well as re-create the baseline configuration very easily.

Develop multiple repeatable test scenarios that simulate an end-to-end usage of the WebLogic Server environment in production. Ideally, these tests should encompass the following:

The performance of these scenarios will greatly affect the perception of the WebLogic Server application and contribute to its success or failure from the perspective of the sponsors, business customers, and, most importantly, the end users.

Run your test scenarios and measure (benchmark) the baseline performance of your WebLogic Server environment, collecting metrics related to WebLogic Server’s response time, throughput, and latency, as well as the metrics related to the memory management of your JVM. You will also need to leverage your performance-tuning team to collect other relevant performance metrics from the WebLogic Server environment, such as the latency of any database systems and the hardware resource consumption rates (memory and CPU). It is important to document what is being benchmarked and why. This understanding should be coherent across the performance tuning.

To benchmark your WebLogic Server environment in an automated manner, you need to use a performance analysis tool. A performance analysis tool should not only be able to simulate your test scenarios, but also be capable of collecting the desired performance metrics and possibly reveal the areas of the WebLogic Server environment where potential bottlenecks exist. Many performance analysis tools are available in the market. Some are free, and some provide more sophisticated testing mechanisms and options than others. Table 28.1 lists a few of these tools and links indicating where you can retrieve more information about them.

Most of the performance analysis tools are typically available for download so that you can test-drive them.

Using the benchmark results of your test scenarios, you and your team should be able to identify

After you determine which test scenarios do not meet their performance-tuning requirements, you and your team need to examine how those test scenarios can be tuned. Solving the performance-tuning issues in these important test scenarios will generally improve the performance of a WebLogic Server environment as a whole.

Performance tuning generally involves modifying one or more configuration properties—whether they are application related, WebLogic server related, JVM related, or hardware related. The J2EE programming code should be modified only for a test scenario, only if it is deemed to be inefficient by the J2EE developer in your performance-tuning team.

To resolve the identified bottlenecks in your test scenarios, you and your team need to coordinate the modification (tuning) of a single property of your WebLogic Server environment and benchmark the effects of modifying that specific property. For example, you can modify a property of WebLogic Server by modifying its associated parameter value in the server’s configuration file (config.xml).

Tuning more than a single property at a time can make the results difficult to analyze. This benchmark result should be compared to the baseline results to determine if tuning that property increased or decreased the performance of the test scenario.

If there is no effect on the performance of your test scenario, you should continue tuning and benchmarking the other relevant properties of your WebLogic Server environment until you see an increase in performance in your test scenario. When you see an increase in performance, the related benchmark results will become your baseline benchmark for comparing the benchmark results from tuning additional properties of your WebLogic Server environment.

After you exhaust your tuning options for one test scenario, resolve the performance bottlenecks in your remaining test scenarios using the same approach. This iterative process will help you to approach the optimum configuration for your WebLogic Server environment.

WebLogic Server provides two types of socket reader implementations:

For optimum socket reader performance, you should use the native socket readers. WebLogic Server comes bundled with a platform-specific performance pack, which allows the native socket readers to make use of platform-specific asynchronous system calls to read data. The Java-based socket reader implementation is synchronous and can be slow.

You can use native socket readers with all the primary platforms supported by WebLogic Server—for example, Windows, Solaris, HPUX, Linux, and AIX. On platforms where the performance pack is not available, you must use the Java-based socket reader implementation, which is discussed in detail later in the “Tuning the Java Socket Reader Threads” section.

You can verify if a performance pack is available for your hardware platform on the Certifications pages of the BEA documentation at the following URL:

http://e-docs.bea.com/wls/certifications/certifications/index.html

Even though the performance pack is enabled by default for those platforms that support the native socket multiplexor, as a WebLogic Server administrator, you should always ensure that the performance pack is enabled by following these steps:

The performance pack binary (wlntio.dll file on Windows, a libmuxer.so or libmuxer.sl file depending on the flavor of Unix) should be in your WebLogic Server’s PATH. Depending on the platform on which you are running WebLogic Server, the binary is set appropriately in the setWLSEnv.sh script on Unix platforms and setWLSEnv.cmd on the Windows platform. This script is present in the $WL_HOME/server/bin directory of your WebLogic server installation.

With the Native IO option enabled, you will notice the following log statements in your WebLogic Server’s log file.

For Windows:

<Dec 5, 2002 11:58:02 PM PST> <Info> <socket> <000406> <NTSocketMuxer was built
 on Jun 24 2002 17:35:19>
<Dec 5, 2002 11:58:02 PM PST> <Info> <socket> <000408> <Allocating 2 NT
 reader threads>

For Unix

<Nov 7, 2002 10:49:39 AM CST> <Info> <Posix Performance Pack> <devsun2>
 <adminserver> <ListenThread> <system> <> <000000> <System has file descriptor
 limits of - soft: '1024', hard: '1024'>
####<Nov 7, 2002 10:49:39 AM CST> <Info> <Posix Performance Pack> <devsun2>
 <adminserver> <ListenThread> <system> <> <000000> <Using effective file
 descriptor limit of: '1024' open sockets/files.>
####<Nov 7, 2002 10:49:39 AM CST> <Info> <Posix Performance Pack> <devsun2>
 <adminserver> <ListenThread> <system> <> <000000> <Allocating: '3' POSIX
 reader threads>

Hence, by default, when you use the performance pack on the Windows platform, the number of socket reader threads is twice the number of CPUs on that specific server machine. On a Unix platform, the number of socket reader threads is set to 3 by default.

WebLogic clients do not have performance packs and have to rely on the Java socket multiplexor implementation to read data. The following section discusses how you can tune the threads using the Java socket multiplexor implementation.

As mentioned earlier in this chapter, WebLogic Server is a multithreaded application server. The server maintains a pool of Java threads that do all the work. Using multiple threads allows the tasks to be executed in parallel and achieve high performance. These threads in WebLogic Server are called execute threads (or worker threads) because the tasks are executed by them.

The threads within WebLogic Server are partitioned into a set of queues called execute queues. Each queue has the responsibility of executing a specific type of task. The tasks can be application specific such as handling servlet/JSP requests, executing remote EJB methods, and establishing JDBC connections, or they can be server specific tasks such as handling Administration Console requests, handling transaction triggers, running dynamic garbage collection, handling replication requests, and so on. The execute threads are partitioned into execute queues so that one particular task does not take over all the thread resources and cause thread starvation for other types of tasks.

Examples of some of the execute queues in WebLogic Server include

As shown in Figure 28.2, work requests enter WebLogic Server through either the listen thread (listens on port 7001 by default) or the SSL listen thread (listens on port 7002 by default), depending on the protocol used for sending the request. These requests are read by the socket reader threads and then placed on an appropriate execute queue depending on the request type. If no custom execute queues are configured, the requests are placed on the default execute queue.

Figure 28.2. The internals of the WebLogic Server thread pool.

As execute threads (worker threads) within the specific queue become free, they pick up the requests from the execute queue, execute the task, and send back the response.

Determining the Appropriate Thread Count for an Execute Queue

WebLogic Server allows you to tune the number of execute threads (worker threads) within the default execute queue. You will need to tune this number if you want to control the degree of concurrency/parallelism possible within the server—for example, the number of simultaneous operations performed by the applications deployed on WebLogic Server. However, increasing this number does not necessarily guarantee better performance because more threads mean more context switching between threads and more memory usage, which could lead to a drop in performance.

Caution

Increasing the number of execute threads within the default execute queue inappropriately may degrade performance; therefore, you should be very careful while tuning the execute threads.

The optimum number of execute threads in your WebLogic Server’s default execute queue, from which you can derive performance value, is influenced by the following factors:

• The number of concurrent requests being handled by the server (throughput)

• The average response time for each request, which is specific to the type of application you have deployed to your server (response time)

• The number of work requests waiting to be executed by the worker threads (queue length)

• The number of idle worker threads during peak usage of your WebLogic Server application (idle threads)

• The number of CPUs and their utilization on your server machine (CPU usage)

• The amount of memory (RAM) dedicated to WebLogic Server on your machine (memory usage)

Taking into account these factors, the following sections describe how to tune your WebLogic Server’s execute thread count in the default execute queue.

Step 1: Start the Administration Server

Start your Administration Server. If you are not running the Administration Server in standalone mode, start the managed server(s) where your application(s) is deployed. By default, your WebLogic Server(s) will start with a default thread count of 15.

Step 2: Run and Monitor a Load Test Against Your WebLogic Server Application

To determine the ideal thread count for your default execute queue, you must run a load test against your WebLogic Server application and monitor the factors that can influence the queue’s performance, which were mentioned earlier (throughput, response time, queue length, idle threads, CPU usage, and memory usage). This load test must simulate the important functional areas of your application operating at peak usage, which should include access to Enterprise Information Systems, such as database and legacy systems.

You can perform a load test using a variety of performance analysis tools, as listed in Table 28.1. For example, a very easy performance analysis tool to use is the Web Benchmark tool, which you can download for free from BEA’s Dev2Dev Web site (http://dev2dev.bea.com). Load testing your WebLogic Server application using the Web Benchmark requires only a few configuration steps, as follows:

1. Download the Web Benchmark zip file (bench.zip) from the Dev2Dev Web site into a directory on your machine—for example, <drive>:benchmark.

2. Unzip the bench.zip file into its current directory.

3. Because the Web Benchmark tool is a Java client, you must include its directory in the CLASSPATH environment variable for your operating system. For example, you can set the CLASSPATH in Windows using the following command:

   set CLASSPATH=<drive>enchmark;%CLASSPATH%
   

After you configure the Web Benchmark tool, you can run a load test against your WebLogic Server application using the following command-line syntax:

java BenchClient <#threads> <host> <port> "<URI>" <#iterations>

where

• #threads—. The number of concurrent clients you want to simulate connecting with WebLogic Server

• host—. The IP address or DNS name of the target WebLogic Server to load test

• port—. The port WebLogic Server is listening on

• URI—. The virtual mapping, extra path information, and query string of the URL

• #iterations—. The number of requests each client will perform

For example, the following Web Benchmark command will simulate 15 clients, each performing 5,000 requests to the full URL of http://EINSTEIN:7001/HelloWorldApp/MyServlet:

java BenchClient 15 EINSTEIN 7001 "/HelloWorldApp/MyServlet" 5000

Note

The Web Benchmark tool allows you to hit Web pages in your application with multiple threads and multiple iterations. However, it does not support the use of POST requests or session tracking.

The output you get from running the Web Benchmark indicates the latency of each thread (client), listed from the shortest to the longest amount of time. The output of the Web Benchmark tool will be examined later in this section.

To monitor your load test, you can again use a performance analysis tool with built-in monitoring capabilities, or you can use the Administration Console’s monitoring capability, which should be sufficient for monitoring the influential performance tuning factors of the execute threads in the default execute queue.

To monitor the WebLogic Server environment, in conjunction with your performance analysis tool, you can also use the following system performance tools:

• The Windows Performance Tool, which can be used to monitor and capture the performance statistics on many system characteristics, including the following:

  • CPU utilization

  • Memory utilization

  • Operating system and application thread usage

  • Active processes running on the system

  • Network activity

  • I/O statistics

• Unix system performance monitoring utilities, such as the following:

  • sar—. System activity (Solaris)

  • mpstat—. Per-processor (Solaris)

  • vmstat—. Virtual memory statistics

  • netstat—. Network statistics

  • iostat—. I/O statistics

To showcase how you can use the Web Benchmark tool in conjunction with the Administration Console to load test and monitor the factors that can influence the execute queue’s performance, we’ll use a very simple example that will simulate 15 clients, each performing 10,000 requests to a simple URL. You can adjust the syntax of the Web Benchmark tool command according to your own WebLogic Server application pages.

Note

With the evaluation version of WebLogic Server, the maximum number of clients you can concurrently simulate is 15.

To monitor the load test using the Administration Console, follow these steps:

1. Access the Administration Console.

2. Click the Servers node in the left pane to display the servers configured in your domain.

3. Click the name of the server instance that you want to monitor.

4. Select the Monitoring, Performance tab, as shown in Figure 28.3.

   

   Figure 28.3. The Performance monitoring pane of the Administration Console.

From the Performance tab of the Administration Console, as shown in Figure 28.3, you can monitor the following factors during the load test:

• The number of idle threads assigned to the queue

• The time that the longest waiting request was placed in the queue

• The number of requests that have been processed by this queue

• The number of waiting requests in the queue

• The current amount of free memory (in bytes) in the JVM heap

Tip

You can adjust the refresh rate of the Administration Console and the polling interval (milliseconds) for graph data from the Console, Preferences tab. The polling interval will affect your displayed data because it will display the results based on your polling interval.

To monitor the CPU utilization doing the load test, you can use either the Windows Performance Monitoring tool or an appropriate Unix utility, such as mpstat.

Now that you know how to run and monitor a simple load test, the next step is to actually start the load testing and monitoring activities, which begins with running the Web Benchmark command. The command used for this simple showcase is

java BenchClient 15 EINSTEIN 7001 "/HelloWorldApp/MyServlet" 10000

Note

Because the purpose of this test is to simulate actual client interaction with WebLogic Server, it should be run from an actual client machine.

As the Web Benchmark simulates your client load test, you can monitor the activity of your test via the Administration Console and other system monitoring tools. After the Web Benchmark completes its load test on your WebLogic Server application, it will display the results of the latency of the client requests to complete their iterations in the shortest to the longest time, as shown in Figure 28.4.

Figure 28.4. The results of running the Web Benchmark tool in a simulated load test.

The results from the Administration Console, as shown in Figure 28.5, also provide valuable information, as follows:

Figure 28.5. The results of running the Web Benchmark tool through the Administration Console.

• The peak number of idle threads during the load test. However, you will need to refresh the Administration Console at multiple times during the load test to capture this value. From the test, there were a maximum of four idle threads.

• The peak number of requests executed at the polling interval of the performance graph. From the test, there was a peak of 1,237 requests executed.

• The peak number of requests waiting in the execute queue. From the test, there was a peak of 11 requests waiting to be executed in the queue.

• The maximum memory utilization during the test.

A Windows Performance Monitor tool also used during the load test indicated a maximum of 100% and a low of 84% CPU utilization on a dual CPU machine, as shown in Figure 28.6.

Figure 28.6. The CPU utilization results of running the Web Benchmark tool through the Windows Performance Monitoring tool.

You should perform your load test a number of times to a point where your results are relatively consistent, at which point you can analyze them.

In general, if the thread count is set too low, you will see the following results from your load test:

• The CPU is waiting to do work, but there is work that can be performed.

• The CPU utilization never consistently stays within the 85% to 95% optimal utilization range.

• There is a high percentage of requests waiting to be executed (queue length) in comparison to the throughput of the queue. This is dependent on the type of application and the functional area of that application being tested.

• The latency of the client requests is high based on the performance requirements for the functional areas of the WebLogic Server application being load tested.

In general, if the thread count is set too high, you will see the following results from your load test:

• The CPU utilization is consistently at 100% utilization.

• The latency of the client requests is still high based on the performance requirements for the functional areas of the WebLogic Server application being load tested.

• The throughput has greatly increased, but the peak number of requests in the queue remains relatively constant, and there is also an increase in the memory utilization.

The hard and fast way to validate whether you are running your WebLogic Server with high or low thread count is to increase the thread count and compare your results. If there is an increase in performance, you need to repeat your tests by incrementing the thread count by a small amount (two to five threads only) until you reach a point where you see a performance degradation in the throughput and latency of the client requests. This will narrow your execute thread count to a small range for fine-tuning. The following section describes how you can modify the thread count in the default execute queue.

However, if you increase your thread count and see an immediate performance degradation, you will have to take the same iterative test approach, but this time by decreasing the thread count by a small amount until you see a performance increase. This will also narrow your execute thread count to a small range for fine tuning.

Step 3: Modifying the Thread Count in the Default Execute Queue

You can modify the number of execute threads in the default execute queue using the ThreadCount attribute of the ServerMBean. To set this attribute via the Administration Console, follow these steps:

1. Start the Administration Server and access the Administration Console.

2. Click the Servers node in the left pane to display the servers configured in your domain.

3. Click the name of the server instance that contains the default execute queue you want to configure.

4. Select the Monitoring, General tab in the right pane.

5. Click the Monitor All Active Queues text link to display the active execute queues that the selected server uses, for example, as shown in Figure 28.7.

   

   Figure 28.7. The active execute queues in a default WebLogic Server installation.

   Tip

   You can use the screen shown in Figure 28.7 for monitoring the thread activity in an execute queue. However, the refresh rates for an Administration Console screen are much longer than the data presented via the graph (refer to Figure 28.5).

6. Click the Configure Execute Queue text link to display the execute queues that you can modify.

   Note

   You can modify only the default execute queue for a server or a user-defined execute queue.

7. In the table of configured execute queues, click the name of the default execute queue to display the Execute Queue Configuration tab, as shown in Figure 28.8.

   

   Figure 28.8. The default execute queue’s Configuration tab.

8. From the displayed Execute Queue Configuration tab, increase or decrease the default thread count of 15 by a small amount (2 to 5 threads).

9. Click Apply to apply your changes.

10. Shut down and restart the selected server to enable the new thread count settings for the default execute queue.

<Dec 5, 2002 4:59:08 PM PST> <Warning> <WebLogicServer> <000333> <Queue usage
is greater than QueueLengthThresholdPercent "5%" of the maximum queue size.
We will try to allocate ThreadsIncrease "2" thread(s) to help.>

<Dec 5, 2002 4:56:52 PM PST> <Warning> <WebLogicServer> <000337>
<ExecuteThread: '10' for queue: 'default' has been busy for "38" seconds
working on the request "Http Request: /sleep.jsp", which is more than the
configured time (StuckThreadMaxTime) of "30" seconds.>

<Dec 5, 2002 7:50:48 PM PST> <Info> <WebLogicServer> <000339> <ExecuteThread:
'27' for queue: 'default' has become "unstuck".>

WebLogic Server has a default queue to handle all the application-specific requests. However, it also allows you to configure execute queues on a per-application basis.

You may want to configure these additional execute queues to achieve the following advantages:

You need to be aware, however, that unnecessarily configuring custom execute queues for applications wastes resources. You can have a condition in which execute threads in a particular custom queue are idle, while there are no idle threads in another application-specific execute queue. In this case, the idle threads in one queue are wasted resources because they could have been used by the other application if the queues were not partitioned.

To configure custom execute queues using the Administration Console, follow these steps:

<servlet>
<servlet-name>SnoopServlet</servlet-name>
<jsp-file>/myapp/critical.jsp</jsp-file>

<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>CriticalAppQueue</param-value>
</init-param>
</servlet>

java weblogic.rmic -dispatchPolicy CriticalAppQueue examples.HelloImpl

java weblogic.ejbc -dispatchPolicy CriticalAppQueue std_AccountBean.jar
AccountBean.jar

To monitor the execute queues, execute threads, and their attributes in WebLogic Server, follow these steps:

The AcceptBackLog parameter allows you to configure the number of TCP connection requests that can be buffered in a wait queue before being accepted by the server. WebLogic Server, by default, listens on two ports: the plain-text port (default 7001) and the SSL port (default 7002). If work requests come to these ports at a rate faster than they are being processed, they will be buffered in a queue whose size is fixed by this parameter.

You will need to tune this parameter if either the connections are being dropped silently on the client side or the clients are receiving connection refused messages when trying to connect to WebLogic Server.

The default value of this parameter is 50, which means that a maximum of 50 connection requests can be buffered at any given time. If the queue becomes full, additional connection requests will be dropped and not accepted by the server.

To set this parameter, follow these steps:

To tune this parameter, start a realistic load test on the server. If you see connections being refused on the client side, increase the AcceptBackLog value by 25% and retest. Continue increasing the parameter by 25% until the queue size is large enough to buffer the connection requests generated by your load test.

You can configure a prepared statement cache for each connection pool in WebLogic Server. The size of the cache can be set using the Administration Console. The prepared statements are stored in the cache until the size reaches the maximum limit. If an application calls any of the prepared statements stored in the cache, WebLogic Server reuses it. This eliminates the need for parsing the prepared statement in the database each time, as well as improves the current statement’s performance.

WebLogic Server maintains a free pool of bean instances for every stateless session bean. When a remote method is called on a stateless session bean, the EJB container picks a bean instance from the free pool and executes the remote method on it. On completion of the method execution, the bean instance is returned to the free pool. Because all stateless session bean instances are equal and because they do not have any state, it does not matter which instance is picked from the free pool. The EJB container in WebLogic Server thus saves time that would be wasted in creating a new stateless session bean instance each time a remote method is called. Pooling allows the EJB container to serve a large number of clients using a small number of bean instances.

The behavior of the free pool is controlled by two parameters: initial-beans-in-free-pool and max-beans-in-free-pool. These parameters are defined within the weblogic-ejb-jar.xml file. You need to tune these parameters to get good performance for your stateless session beans.

The initial-beans-in-free-pool parameter defines the number of bean instances the EJB container will create when the stateless session EJB is deployed to the server. Creating the bean instances immediately after deployment allows the container to immediately service remote method requests without having to instantiate new bean instances.

The max-beans-in-free-pool parameter defines the maximum number of stateless session bean instances in the free pool. This parameter puts an upper limit on the number of bean instances and controls the amount of concurrency that can be achieved with stateless session beans. When a remote method request arrives at the EJB container, the container grabs a bean instance from the free pool. If there are no free instances in the pool, the container will create one until the number reaches the max-beans-in-free-pool limit. If this upper limit is reached, the EJB container will wait until another bean instance becomes free and is released back to the pool.

As the remote method of each bean instance is executed in a WebLogic Server execute thread, the maximum concurrency is actually controlled by the number of available execute threads. By default, there is no limit to the number of instances the container will create. In most cases, it is recommended that you not tune the max-beans-in-free-pool parameter, which will let the EJB container create new instances as needed.

Under certain circumstances, however, you might need to set this limit. If your stateless session bean has a member variable that holds a connection to an external legacy system, and if the number of connections that can be established with the external system is limited, you should set the max-beans-in-free-pool parameter to the maximum number of connections that can be created. In this case, the max-beans-in-free-pool parameter can be used to limit the use of resources.

When you’re using clustered stateless session beans, if the EJB contains idempotent methods, you should set the stateless-bean-methods-are-idempotent flag to true in the weblogic-ejb-jar.xml file. Idempotent methods are methods that can be called multiple times and produce the same result as if the methods were called only once. Setting this flag to true enables the smart EJB stub to fail over to another server hosting the bean in case the server that was executing the remote method failed.

A stateful session EJB instance maintains state and is associated with a client that created it. There is a one-to-one correspondence between the clients and the bean instances on the server. Because each client has a reference to a specific stateful session bean instance on the server, there is no concept of pooling in the case of stateful session EJBs.

Because each client has its own stateful session bean instance on the server, when the number of clients grows large, so does the number of bean instances on the server. It is not always feasible to maintain all the bean instances in memory for the lifetime of a client. The EJB container is thus required to manage an active set of stateful session beans through mechanisms known as activation and passivation.

For more information on the activation and passivation mechanisms for stateful session beans, see Chapter 20.

Activation and passivation mechanisms allow the EJB container to maintain a working set of stateful session bean instances in memory and thus conserve the server’s memory resources. The max-beans-in-cache parameter in the weblogic-ejb-jar.xml deployment descriptor is used to configure the maximum number of stateful session bean instances that can be held in the in-memory cache.

Setting the max-beans-in-cache parameter to a low value limits the maximum number of active bean instances that the EJB container can hold in the cache, thus leading to excessive activation and passivation as more beans are created. Activation and passivation of beans are expensive operations and can certainly slow down performance. Setting this parameter to a high value can put unnecessary strain on the server’s memory resources. You need to tune this parameter appropriately based on factors such as the maximum heap available for the server, average life period of the stateful session bean, as well as the maximum number of stateful session bean requests.

Entity beans are EJBs that provide an object view of data in the database. The state of an entity bean is transactional, and updates are persisted to the database only if the transaction commits. If the transaction rolls back, the bean returns to its last committed state.

To understand the process of tuning the JVM heap size, you need to understand what the JVM heap consists of, how it grows and shrinks, and how garbage collection is done. In this section, we explain these concepts. The Java heap consists of free memory, live objects (ones that are in use), and dead objects (ones that are not referenced). All the Java objects live in the Java heap. During the lifetime of a Java program, new objects may be created, and objects that were active earlier may become unused. The unused or dead objects cannot be reached from any pointer in a running program. During the execution of a Java program, more objects are created and the JVM starts running out of free memory in the heap. When the heap in use reaches a certain limit, the JVM initiates garbage collection. This process cleans up the unused objects and frees some memory. In the naïve garbage collection technique, also known as stop and run, when the garbage collection starts, the JVM stops execution. This is not good for server performance. The 1.3 Java HotSpot Virtual Machine provides another flavor known as generational garbage collection, which is better in performance.

Tuning the size parameter of the JVM heap is important because it controls the frequency of the garbage collection process as well as how long the garbage collection will run when the JVM starts it. If the heap size is large, the full garbage collection cycle will run longer but less frequently. If the heap size is smaller, the garbage collection will be much more frequent but run much faster. The heap size should be tuned such that the JVM spends less time doing the garbage collection and, at the same time, the server gives the maximum throughput.

java -ms256m -mx256m -verbosegc ..... weblogic.Server >> log.txt 2>&1

[GC 25299K->23266K(204544K), 0.0512523 secs]
[GC 25314K->23175K(204544K), 0.0039530 secs]
[GC 25222K->23179K(204544K), 0.0058421 secs]
[GC 25227K->23209K(204544K), 0.0045444 secs]
[Full GC 24838K->23271K(204544K), 0.8871415 secs]

Setting the JVM Heap Size Options

The most straightforward garbage collection algorithms examine every living object in the heap to check whether it is in use. This technique is prohibitively costly, especially for large Java applications, because the garbage collection algorithm takes time proportional to the number of living objects.

The 1.3 Java HotSpot VM uses a generational garbage collection algorithm that considers the lifetime of an object to avoid the extra collection work. It is based on the basic premise that a majority of objects die young and hence should not be considered for garbage collection at all. To do this, the JVM divides the heap into memory pools holding objects of different ages. The heap is divided into two areas: young and old. The young generation area is further divided into Eden and two survivor areas. There is also a portion of the heap called permanent generation, which holds the classes and method objects (see Figure 28.13).

Figure 28.13. Division of heap into young and old generational areas in the 1.3 Java HotSpot VM.

New objects are created in the Eden generational area. Because most objects are short lived, they die in this area. One survivor space is kept empty at any time, and it allows for moving objects when the Eden area or the other survivor space fills up. This causes a minor garbage collection. When the number of objects in the survivor space reaches a certain threshold, the objects are moved out from the survivor space into the old generational area. When the old generational area is filled, there is a major or full garbage collection cycle.

The memory management based on the lifetime of objects provides significant improvement in the garbage collection efficiency of the Java HotSpot VM.

Because the default garbage collection parameters were designed for small applications, they are not optimal for large server applications such as WebLogic Server. To achieve optimum performance for your application deployed on WebLogic Server, consider tuning the following parameters depending on your application, client load, and available RAM:

• Minimum heap size—. This is specified with the -Xms option—for example:

  -Xms=64M
  

  This sets the minimum heap with which the JVM starts.

• Maximum heap size—. This is specified with the -Xms option—for example:

  -Xmx=200M
  

  This sets the maximum heap size allocated for the JVM. As more Java objects are created, the heap size will be increased until it reaches this limit.

• NewRatio—. This is specified with the -XX:NewRatio option—for example:

  -XNewRatio=3
  

  This controls the ratio between the young and the old generational areas. In this example, the ratio between young and old areas is 1:3.

  Note

  Because the entire heap is divided into the young and old areas, the larger the young area, the smaller will be the old area. If the ratio divides the heap such that the older area is smaller, this will increase the frequency of the major garbage collection cycles. This ratio should be tuned based on the lifetime distribution of objects created by your application.

• New generation heap size—. This is specified with the -XX:NewSize option—for example:

  -XXNewSize=128M
  

  This sets the minimum young generation size. Increase the young generation heap size if your application creates a large number of short-lived objects.

• Maximum new generation heap size—. This is specified with the -XX:MaxNewSize option—for example:

  XXMaxNewSize=128M
  

  This sets the maximum young generation size.

• New heap size ratio—. This is specified with the -XX:SurvivorRatio option—for example:

  -XX:SurvivorRatio=6
  

  This option configures the ratio between the Eden and survivor spaces. If the ratio is set to 6, the ratio of survivor space to Eden space will be 1:6. Because there are two survivor spaces, each survivor space will be one eighth of the young generation space.

The Administration Console allows you to monitor the memory usage of WebLogic Server. To monitor the heap through the console, follow these steps:

To manually force garbage collection on the server, click the Force Garbage Collection button. If WebLogic Server was started with the -verbosegc option, you will see a Full GC cycle run in the server and the message printed to the stdout when the garbage collection is manually forced through the console.

WebLogic Server allows you to automatically detect and handle low memory conditions in the server. The server samples the available free memory over a period of time and, depending on the thresholds set, forces garbage collection if a low memory condition is detected.

To configure automatic detection of low memory, follow these steps: