Tuning WebLogic Server


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| Download Documentation \| Contact \| Glossary

\| WebLogic Server Doc Home \| Performance and Tuning \| Previous Topic \| Next Topic \| Contents \| Index \| View as PDF

The following sections describe how to tune WebLogic Server to match your application needs.

Tuning config.xml File Parameters

Table 3-1 lists the config.xml file parameters that impact server performance:

Table 3-1 Performance-Related config.xml Elements

Element	Attribute	For more information
Server	NativeIOEnabled	See Using WebLogic Server Performance Packs.
ExecuteQueue	ThreadCount	See Setting Thread Count.
Server	ThreadPoolPercentSocketReaders	See Allocating Threads to Act as Socket Readers.
Server	AcceptBacklog	See Tuning Connection Backlog Buffering.
JDBCConnectionPool	InitialCapacity MaxCapacity	See Tuning JDBC Connection Pool Size.

Using WebLogic Server Performance Packs

Benchmarks show major performance improvements in WebLogic Server when you use the performance pack for your platform. Performance packs use a platform-optimized (native) socket multiplexor to improve server performance.

To use a performance pack, make sure the NativeIOEnabled attribute of the Server element is defined in your config.xml file. The default config.xml file shipped with your distribution enables this attribute by default: NativeIOEnabled=true.

Which Platforms Have Performance Packs?

To see which platforms currently have performance packs available:

Go to the Platform Support page.
Choose Edit—>Find to locate all instances of "performance pack included".

Enabling Performance Packs

To use the Administration Console to make sure performance packs are enabled:

Start the WebLogic Server Console.
Open the Servers folder in the navigation tree.
Select your server (myserver in a default installation) in the Servers folder.
Select the Configuration tab.
Select the Tuning tab.
If the Native IO Enabled check box is not selected, select the check box.
Click Apply.
Restart your sever.

Setting Thread Count

The value of the ThreadCount attribute of an ExecuteQueue element in the config.xml file equals the number of simultaneous operations that can be performed by applications that use the execute queue. As work enters a WebLogic Server instance, it is placed in an execute queue. This work is then assigned to a thread that does the work on it. Threads consume resources, so handle this attribute with care—you can degrade performance by increasing the value unnecessarily.

By default, a new WebLogic Server instance is configured with a default execute queue (named "default") that contains 15 threads. WebLogic Server instances also contain two built-in execute queues named __weblogic_admin_html_queue and __weblogic_admin_rmi_queue, but these queues are reserved for communicating with the WebLogic Administration Console. If you configure no additional execute queues, all Web applications and RMI objects use the default queue.

Note: For most applications, leave the default value unchanged.

Modifying Thread Count

Adding more threads to the default execute queue does not necessarily imply that you can process more work. Even if you add more threads, you are still limited by the power of your processor. You can degrade performance by increasing the value of the ThreadCount attribute unnecessarily. Threads consume memory. A high execute thread count causes more memory to be used and increases context switching, which can degrade performance.

The value of the ThreadCount attribute depends very much on the type of work your application does. Suppose your client application is thin and does a lot of its work through remote invocation. The time your thin client application spends connected will be greater than for a client application that does a lot of client-side processing.

If you do not need to use additional threads for your work, do not change the value of this attribute. The thread will not be held for the client application.

If your application makes database calls that take a long time to return, you need more execute threads than an application that makes calls that are short and turn over very rapidly. For the latter, you can use a small number of execute threads and improve performance.

Thread Count Scenarios

Table 3-2 shows some possible scenarios adjusting available threads in the default execute queue. These scenarios assume that all thread requests are satisfied by using the default execute queue. If you configure additional execute queues and assign applications to specific queues, results must be monitored on a pool-by-pool basis.

Table 3-2 Thread Count Scenarios

When...	Results	Do This:
Thread Count < number of CPUs	Results in an under-utilized CPU.	Increase the thread count.
(Thread Count == number of CPUs)	Theoretically ideal, but the CPUs are under-utilized.	Increase the thread count.
(Thread Count > number of CPUs) by a moderate number of threads	Practically ideal, resulting in a moderate amount of context switching and a high CPU utilization rate.	Tune the moderate number of threads and compare performance results.
(Thread Count > number of CPUs) by many threads	Results in too much context switching which could lead to significant performance degradation.	Reduce the number of threads. For example, if you have 4 processors, then 4 threads can be running concurrently. So, you want the execute threads to be 4 + (the number of blocked threads). This is very application-dependent. For instance, the length of time the application might block threads can invalidate the formula.

Symptoms: Thread Count Too Low

If your thread count is too low, these symptoms appear when WebLogic Server is running under maximum load:

The CPU is waiting to do work, but there is work that could be done.
The CPU never reaches 100% utilization.

Symptoms: Thread Count Too High

If your thread count is set too high when you run WebLogic Server under maximum load, your performance increases as you decrease the number of threads.

Assigning Applications to Execute Queues

Although you can configure the default execute queue to supply the optimal number threads for all WebLogic Server applications, configuring multiple execute queues can provide additional control for key applications. By using multiple execute queues, you can guarantee that selected applications have access to a fixed number of execute threads, regardless of the load on WebLogic Server. See Using Execute Queues to Control Thread Usage for more information on assigning applications to configured execute queues.

Allocating Threads to Act as Socket Readers

To set the maximum percentage of execute threads that read messages from a socket, use the ThreadPoolPercentSocketReaders attribute in the config.xml file. The optimal value for this attribute is application-specific. The default is value 33, and the valid range is 1-99.

The ThreadPoolPercentSocketReaders attribute sets the maximum percentage of execute threads that are set to read messages from a socket. Allocating execute threads to act as socket reader threads increases the speed and the ability of the server to accept client requests. It is essential to balance the number of execute threads that are devoted to reading messages from a socket and those threads that perform the actual execution of tasks in the server.

When the native performance packs are not being used, execute threads must be allocated to act as socket reader threads. If possible, use the Performance Pack for your platform. See Using WebLogic Server Performance Packs.

Note: Due to a known problem in WebLogic Server 6.1, if you are not using the Performance Pack for your platform, and are allocating threads to act as socket readers, you must set the desired thread pool size as a command line option when starting a Managed Server. For more information and instructions, see "CR179419" in WebLogic Server 6.1 Release Notes.

How Connection Pools Enhance Performance

Establishing a JDBC connection with a DBMS can be very slow. If your application requires database connections that are repeatedly opened and closed, this can become a significant performance issue. WebLogic connection pools offer an efficient solution to this problem.

When WebLogic Server starts, connections from the connection pools are opened and are available to all clients. When a client closes a connection from a connection pool, the connection is returned to the pool and becomes available for other clients; the connection itself is not closed. There is little cost to opening and closing pool connections.

How many connections should you create in the pool? A connection pool can grow and shrink according to configured parameters, between a minimum and a maximum number of connections. The best performance occurs when the connection pool has as many connections as there are concurrent users.

Tuning JDBC Connection Pool Size

The InitialCapacity attribute of the JDBCConnectionPool element allows you to set the number of physical database connections to create when configuring the pool. If the server is unable to create this number of connections, the creation of this connection pool will fail. See Tuning JDBC Connection Pool Initial Capacity.

The MaxCapacity attribute of the JDBCConnectionPool element allows you to set the maximum number of physical database connections in a connection pool. See Tuning JDBC Connection Pool Maximum Capacity.

For additional JDBC tuning information, see "Performance Tuning Your JDBC Application" in Programming WebLogic JDBC.

Tuning JDBC Connection Pool Initial Capacity

During development, it is convenient to set the value of the InitialCapacity attribute to a low number. This helps the server start up faster.

In production systems, consider setting InitialCapacity equal to the MaxCapacity so that all database connections are acquired during server start-up.

If InitialCapacity is less than MaxCapacity, the server then needs to create additional database connections when its load is increased. When the server is under load, all resources should be working to complete requests as fast as possible, rather than creating new database connections.

Tuning JDBC Connection Pool Maximum Capacity

The MaxCapacity attribute of the JDBCConnectionPool element allows you to set the maximum number of physical database connections that a connection pool can contain. Different JDBC drivers and database servers might limit the number of possible physical connections.

In production, it is advisable that the number of connections in the pool equal the number of concurrent client sessions that require JDBC connections. The pool capacity is independent of the number of execute threads in the server. There may be many more ongoing user sessions than there are execute threads.

Tuning Connection Backlog Buffering

The AcceptBacklog attribute of the Server element in the config.xml file allows you to set the number of connection requests the server will accept before refusing additional requests. The AcceptBacklog attribute specifies how many TCP connections can be buffered in a wait queue. This fixed size queue is populated with requests for connections that the TCP stack has received, but the application has not accepted yet. The default value is 50 and the maximum value is operating system dependant.

Select Server—>Configuration—>Tuning from the Administration Console to enter a value for the Accept Backlog attribute.

During operations, if many connections are dropped or refused at the client, and there are no other error messages on the server, the AcceptBacklog attribute might be set too low.

If you are getting "connection refused" messages when you try to access WebLogic Server, raise the value of the AcceptBacklog attribute from the default by 25%. Continue increasing the attribute's value by 25% until the messages cease to appear.

Tuning weblogic-ejb-jar.xml Parameters

Table 3-3 lists the weblogic-ejb-jar.xml file parameters that impact performance.

Table 3-3 Performance-Related weblogic-ejb-jar.xml Parameters

Element	For more information
max-beans-in-free-pool	See Setting EJB Pool Size.
initial-beans-in-free-pool	See Tuning Initial Beans in Free Pool.
max-beans-in-cache	See Setting EJB Caching Size.
concurrency-strategy	See Deferring Database Locking.
isolation-level	See Setting Transaction Isolation Level.

The following sections describe these elements.

Setting EJB Pool Size

WebLogic Server maintains a free pool of EJBs for every stateless session bean class. The max-beans-in-free-pool element of the weblogic-ejb-jar.xml file defines the size of this pool. By default, max-beans-in-free-pool has no limit; the maximum number of beans in the free pool is limited only by the available memory.

This section discusses the following topics:

See also:

max-beans-in-free-pool in Programming WebLogic Enterprise JavaBeans
"Using max-beans-in-free-pool" in Programming WebLogic Enterprise JavaBeans

Allocating Pool Size for Session and Message Beans

When EJBs are created, the session bean instance is created and given an identity. When the client removes a bean, the bean instance is placed in the free pool. When you create a subsequent bean, you can avoid object allocation by reusing the previous instance that is in the free pool. The max-beans-in-free-pool element can improve performance if EJBs are frequently created and removed.

The EJB container creates new instances of message beans as needed for concurrent message processing. The max-beans-in-pool element puts an absolute limit on how many of these instances will be created. The container may override this setting according to the runtime resources that are available.

For the best performance for stateless session and message beans, use the default setting max-beans-in-free-pool element. The default allows you to run beans in parallel, using as many threads as possible. The only reason to change the setting would be to limit the number of beans running in parallel.

Allocating Pool Size for Entity Beans

There is a pool of anonymous entity beans that are used for invoking finders, home methods, and creation of entity beans. The max-beans-in-free-pool element controls the size of this pool.

If you are running lots of finders or home methods or creating lots of beans, you may want to tune the max-beans-in-free-pool element so that there are enough beans available for use in the pool.

Tuning the Pool Size

Do not change the value of the max-beans-in-free-pool parameter unless you frequently create session beans, do a quick operation, and then throw them away. If you do this, enlarge your free pool by 25 to 50%, and see if performance improves. If object creation represents a small fraction of your workload, increasing this parameter will not significantly improve performance. For applications where EJBs are database intensive, do not change the value of this parameter.

Caution: Tuning this parameter too high uses extra memory. Tuning it too low causes unnecessary object creation. If you are in doubt about changing this parameter, leave it unchanged.

Tuning Initial Beans in Free Pool

Use the initial-beans-in-free-pool element of the weblogic-ejb-jar.xml file to specify the number of stateless session bean instances in the free pool at startup.

If you specify a value for initial-bean-in-free-pool, WebLogic Server populates the free pool with the specified number of bean instances at startup. Populating the free pool in this way improves initial response time for the EJB, since initial requests for the bean can be satisfied without generating a new instance.

initial-bean-in-free-pool defaults to 0 if the element is not defined.

The initial-beans-in-free-pool element is described in Programming WebLogic Enterprise JavaBeans.

Setting EJB Caching Size

WebLogic Server allows you to configure the number of active beans that are present in the EJB cache (the in-memory space where beans exist).

The max-beans-in-cache element of the weblogic-ejb-jar.xml file specifies the maximum number of objects of this class that are allowed in memory. When max-bean-in-cache is reached, WebLogic Server passivates some EJBs that have not been recently used by a client. The max-beans-in-cache element also affects when EJBs are removed from the WebLogic Server cache.

Using this element sets the cache size for stateful session and entity beans similarly.

For more information, see "Locking and Caching Services for Entity EJBs"

The max-beans-in-cache element is described in Programming WebLogic Enterprise JavaBeans.

Activation and Passivation of Stateful Session EJBs

Set the appropriate cache size with the max-beans-in-cache element to avoid excessive passivation and activation. Activation is the transfer of an EJB instance from secondary storage to memory. Passivation is the transfer of an EJB instance from memory to secondary storage. Tuning max-beans-in-cache too high consumes memory unnecessarily.

The EJB container performs passivation when it invokes the ejbPassivate() method. When the EJB session object is needed again, it is recalled with the ejbActivate() method. When the ejbPassivate() call is made, the EJB object is serialized using the Java serialization API or other similar methods and stored in secondary memory (disk). The ejbActivate() method causes the opposite.

The container automatically manages this working set of session objects in the EJB cache without the client's or server's direct intervention. Specific callback methods in each EJB describe how to passivate (store in cache) or activate (retrieve from cache) these objects. Excessive activation and passivation nullifies the performance benefits of caching the working set of session objects in the EJB cache —especially when the application has to handle a large number of session objects.

Deferring Database Locking

WebLogic Server supports database locking and exclusive locking mechanisms. The default and recommended mechanism for EJB 1.1 and EJB 2.0 is database locking.

Database locking improves concurrent access for entity EJBs. The WebLogic Server container does this by deferring locking services to the underlying database. Unlike exclusive locking, the underlying data store can provide finer granularity for locking EJB data, in most cases, as well as provide deadlock detection.

For details about database locking, see Locking Services for Entity EJBs.

You specify the locking mechanism used for an EJB by setting the concurrency-strategy deployment parameter in weblogic-ejb-jar.xml.

Setting Transaction Isolation Level

Data accessibility is controlled through the transaction isolation level mechanism. Transaction isolation level determines the degree to which multiple interleaved transactions are prevented from interfering with each other in a multi-user database system. Transaction isolation is achieved through use of locking protocols that guide the reading and writing of transaction data. This transaction data is written to the disk in a process called "serialization." Lower isolation levels give you better database concurrency at the cost of less transaction isolation.

For more information, see the description of theisolation-level element of the weblogic-ejb-jar.xml file, in Programming WebLogic Enterprise JavaBeans.

Refer to your database documentation for more information on the implications and support for different isolation levels.

Tuning Parameters for Starting WebLogic Server

Sample scripts are provided with the WebLogic distribution that you can use to start WebLogic Servers, as described in Starting and Stopping WebLogic Servers.

You will need to modify these scripts to fit your environment and applications. Separate sample scripts are provided for starting the Administration Server and the Managed Server. The scripts for starting the Administration Server are called startWebLogic.sh (UNIX) and startWeblogic.cmd (Windows). These scripts are located in the configuration subdirectory for your domain.

The important performance tuning parameters in these files are the JAVA_HOME parameter and the java heap size parameters:

Change the value of the variable JAVA_HOME to the location of your JDK. For example:
set JAVA_HOME=C:\bea\jdk131
For higher performance throughput, set the minimum java heap size equal to the maximum heap size. For example:
"%JAVA_HOME%\bin\java" -hotspot -ms512m -mx512m -classpath %CLASSPATH% -

See Specifying Heap Size Values for details about setting heap size options.

Setting Your Java Compiler

The standard Java compiler for compiling JSP servlets is javac. You can improve performance significantly by setting your server's java compiler to sj or jikes instead of javac. The following sections discuss this procedure and other compiler considerations.

Changing Compilers in the WebLogic Server Console

To change your compiler in the console:

Start the WebLogic Server Console.
Open the Servers folder in the navigation tree.
Select your server (myserver in a default installation) in the Servers folder.
Select the Configuration tab.
Select the Compilers tab and enter the full path of the compiler in the Java Compiler text box. For example:
c:\visualcafe31\bin\sj.exe
Enter the full path to the JRE rt.jar library in the Append to classpath text box. For example:
weblogic_home\jdk131\jre\lib\rt.jar
Click Apply.
Restart your server for the new Java Compiler and Append to classpath values to take effect.

Setting Your Compiler in weblogic.xml

In the weblogic.xml file, the jsp-descriptor element defines parameter names and values for servlet JSPs.

The compileCommand parameter specifies the Java compiler to use for compiling the generated JSP servlets.

The precompile parameter allows you to configure WebLogic Server to precompile your JSPs when WebLogic Server starts up.

For more information about setting your server's java compiler in the weblogic.xml file, see the jsp-descriptor element.

Compiling EJB Container Classes

WebLogic Server includes the weblogic.ejbc utility for compiling EJB 2.0 and 1.1 container classes. If you compile .jar files for deployment into the EJB container, you must use weblogic.ejbc to generate the container classes. By default, ejbc uses javac as a compiler. For faster performance, specify a different compiler (such as Symantec sj) using the -compiler flag.

For more information, see "WebLogic Server EJB Utilities".

Compiling on UNIX

If you receive the following error message received when compiling JSP files on a UNIX machine:

failed: java.io.IOException: Not enough space

Try any or all of the following solutions:

Add more RAM if you have only 256 MB.

Raise the file descriptor limit, for example:

set rlim_fd_max = 4096

set rlim_fd_cur = 1024

Use the -native flag to use native threads when starting the JVM.

WebLogic Server Clusters and Scalability

A WebLogic Server cluster is a group of WebLogic Servers that work together to provide fail-over and replicated services to support scalable high-availability operations for clients. A cluster appears to its clients as a single server but is in fact a group of servers acting as one.

Scalability is the ability of a system to grow in one or more dimensions as more resources are added to the system. Typically, these dimensions include (among other things), the number of concurrent users that can be supported and the number of transactions that can be processed in a given unit of time.

Given a well-designed application, it is entirely possible to increase performance by simply adding more resources. To increase the load handling capabilities of WebLogic Server, simply add another WebLogic Server to your cluster — without changing your application. Clusters provide two key benefits that are not provided by a single server: scalability and availability.

WebLogic Server clusters bring scalability and high-availability to J2EE applications in a way that is transparent to application developers. Scalability expands the capacity of the middle tier beyond that of a single WebLogic Server or a single computer. The only limitation on cluster membership is that all WebLogic Servers must be able to communicate by IP multicast. New WebLogic Servers can be added to a cluster dynamically to increase capacity.

A WebLogic Server cluster guarantees high-availability by using the redundancy of multiple servers to insulate clients from failures. The same service can be provided on multiple servers in a cluster. If one server fails, another can take over. The ability to have a functioning server take over from a failed server increases the availability of the application to clients.

For complete information about clusters, see "Using WebLogic Server Clusters".

Caution: Provided that you have resolved all application and environment bottleneck issues, adding additional servers to a cluster should provide linear scalability. When doing benchmark or initial configuration test runs, isolate issues in a single server environment before moving to a clustered environment.

Performance Considerations for Multi-CPU Machines

With multi-processor machines, additional consideration must be given to the ratio of clustered WebLogic Server instances to the number of available CPUs. Because WebLogic Server has no built-in limit to the number of server instances that reside in a cluster, large, multi-processor servers such as Sun Microsystems, Inc. Sun Enterprise 10000, can potentially host very large clusters or multiple clusters

Before determining the optimal ratio of servers to CPUs, thoroughly test your application to determine:

Network Requirements—If you discover that a web application is primarily network I/O-bound, then you should consider measures to increase network throughput before increasing the number of available CPUs. For truly network I/O-bound applications, installing a faster NIC may increase performance more than additional CPUs, because most CPUs would remain idle while waiting to read available sockets.
Disk I/O Requirements—If you discover that a web application is primarily disk I/O-bound, you should consider upgrading the number of disk spindles or individual disks and controllers before allocating additional CPUs.

In summary, you should ensure that a web application is truly CPU-bound, rather than network or disk I/O-bound, before allocating additional CPUs.

For CPU-bound applications, begin performance tests using a ratio of one WebLogic Server instance for every CPU. If CPU utilization is consistently at or near 100%, increase the ratio of CPUs to servers (for example, allocate one WebLogic Server instance for ever two CPUs). For production systems, keep in mind that some spare CPU cycles should always be available to perform administration tasks.

Although the processing needs of web applications varies, BEA has found that optimal results are generally obtained using a ratio of one Weblogic Server instance for every two CPUs.

Monitoring a WebLogic Server Domain

The tool for monitoring the health and performance of your WebLogic Server domain is the Administration Console. You use the Administration Console to view status and statistics for WebLogic Server resources such as servers, HTTP, the JTA subsystem, JNDI, security, CORBA connection pools, EJB, JDBC, and JMS.

For details, see "Monitoring a WebLogic Server Domain" .