BEA WebLogic Server Tuning Guide

BEA describes WebLogic Server performance tuning in the WebLogic Service Performance Tuning page available

at http://edocs.bea.com/wls/docs81/perform/index.html.

HP recommends a default minimum and maximum of 256 MB for the Java heap. The maximum for the Java heap

can be 256 MB or greater depending on need. As specified in this document, when determining the Java heap

space, take care that the address space requirements of other native components linked to the JVM and used by the

application are also considered and heap sized accordingly.

Also, using a large Java heap space requires that the QIO segment be moved to KSEG2 or otherwise reduced from

the default sizes, if possible.

5.8 JMX-Based Custom Monitoring

WebLogic Server has a JMX-based management interface. All the runtime state and configuration of WebLogic

Server components and objects can be managed using the JMX interfaces. It is possible to create a custom JMX

object for managing application components and objects and register it with WebLogic Server.

It is also possible to create notification listeners for various management attributes. For example, a notification

listener can be registered such that whenever the number of JDBC connections in use reaches a threshold. For

additional details, see the WebLogic JMX Programming information available at

http://edocs.bea.com/wls/docs81/jmx/index.html.

Many third party products are available, which present the JMX information in useful formats while providing many

value additions.

6.0 Additional Tuning Considerations

6.1 Improving Instance Startup Time

When an instance of the WebLogic Server starts, several things happen. The WebLogic Server loads its own Java

classes and then proceeds to deploy applications that are configured in the config.xml file. Part of this deployment

is CPU-bound; typically, the compilation of Java bytecode into machinecode is CPU-intensive. Another part of the

deployment is I/O intensive. Applications are typically deployed as archives; Enterprise Archives (archive.ear) and

Web Archives (archive.war) are examples of such archives. An application archive is extracted into a server

instance-specific directory. This directory will also contain library archives EJB cache and other files that an instance

requires. It is the latter part that can be optimized drastically. The goal therefore is to minimize file creates and

copying of files.

Every application uses some general purpose archives. An example is tdmext.jar, when the Java Toolkit is used.

When these jar files are put into the application library, they end up in the application archive. Upon deployment,

these files are copied to two locations in the .wlnotdelete directory. This copy is not necessary, and can even be

dangerous, because it is unknown which version of the jar (that of the system or that of the originating workstation)

will be used when the application is running. You would typically have common jars defined in the WLS server

startup CLASSPATH. The jars need not be included in the EAR when the application is built.

Application archives are great to transport applications from one system to another. However, WLS needs to extract

the application into a server-instance specific directory called .wlnotdelete under the server’s root directory. This

process is performed upon deployment of an application and when a server is started.

In addition to deploying from an archive, WLS provides deployment from a directory that contains the extracted

contents of the archive. When WLS deploys the directory, it does not need to copy all the files from the archive.