JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1 Performance Tuning Guide
search filter icon
search icon

Document Information


1.  Overview of GlassFish Server Performance Tuning

2.  Tuning Your Application

Java Programming Guidelines

Avoid Serialization and Deserialization

Use StringBuilder to Concatenate Strings

Assign null to Variables That Are No Longer Needed

Declare Methods as final Only If Necessary

Declare Constants as static final

Avoid Finalizers

Declare Method Arguments final

Synchronize Only When Necessary

Use DataHandlers for SOAP Attachments

Java Server Page and Servlet Tuning

Suggested Coding Practices

General Guidelines

Avoid Shared Modified Class Variables

HTTP Session Handling

Configuration and Deployment Tips

Optimize SSL

Disable Security Manager

EJB Performance Tuning


Monitoring EJB Components

Monitoring Individual EJB Components

General Guidelines

Use High Performance Beans

Use Caching

Use the Appropriate Stubs

Remove Unneeded Stateful Session Beans

Cache and Pool Tuning Tips

Using Local and Remote Interfaces

Prefer Local Interfaces

Using Pass-By-Reference Semantics

Improving Performance of EJB Transactions

Use Container-Managed Transactions

Do Not Encompass User Input Time

Identify Non-Transactional Methods

Use TX_REQUIRED for Long Transaction Chains

Use Lowest Cost Database Locking

Use XA-Capable Data Sources Only When Needed

Configure JDBC Resources as One-Phase Commit Resources

Use the Least Expensive Transaction Attribute

Using Special Techniques

Version Consistency

Request Partitioning

Tuning Tips for Specific Types of EJB Components

Entity Beans

Stateful Session Beans

Checkpoint only when needed

Stateless Session Beans

Read-Only Entity Beans

Refresh Period

Pre-Fetching Container Managed Relationship (CMR) Beans

JDBC and Database Access

Use JDBC Directly

Encapsulate Business Logic in Entity EJB Components

Close Connections

Minimize the Database Transaction Isolation Level

Tuning Message-Driven Beans

Use getConnection()

Tune the Message-Driven Bean's Pool Size

Cache Bean-Specific Resources

Limit Use of JMS Connections

3.  Tuning the GlassFish Server

4.  Tuning the Java Runtime System

5.  Tuning the Operating System and Platform


Java Programming Guidelines

This section covers issues related to Java coding and performance. The guidelines outlined are not specific to GlassFish Server, but are general rules that are useful in many situations. For a complete discussion of Java coding best practices, see the Java Blueprints.

The following topics are addressed here:

Avoid Serialization and Deserialization

Serialization and deserialization of objects is a CPU-intensive procedure and is likely to slow down your application. Use the transient keyword to reduce the amount of data serialized. Additionally, customized readObject() and writeObject() methods may be beneficial in some cases.

Use StringBuilder to Concatenate Strings

To improve performance, instead of using string concatenation, use StringBuilder.append().

String objects are immutable – that is, they never change after creation. For example, consider the following code:

String str = "testing";
str = str + "abc";
str = str + "def";

The compiler translates this code as:

String str = "testing";
StringBuilder tmp = new StringBuilder(str);
str = tmp.toString();
StringBulder tmp = new StringBuilder(str);
str = tmp.toString();

This copying is inherently expensive and overusing it can reduce performance significantly. You are far better off writing:

StringBuilder tmp = new StringBuilder("testing");
String str = tmp.toString();

Assign null to Variables That Are No Longer Needed

Explicitly assigning a null value to variables that are no longer needed helps the garbage collector to identify the parts of memory that can be safely reclaimed. Although Java provides memory management, it does not prevent memory leaks or using excessive amounts of memory.

An application may induce memory leaks by not releasing object references. Doing so prevents the Java garbage collector from reclaiming those objects, and results in increasing amounts of memory being used. Explicitly nullifying references to variables after their use allows the garbage collector to reclaim memory.

One way to detect memory leaks is to employ profiling tools and take memory snapshots after each transaction. A leak-free application in steady state will show a steady active heap memory after garbage collections.

Declare Methods as final Only If Necessary

Modern optimizing dynamic compilers can perform inlining and other inter-procedural optimizations, even if Java methods are not declared final. Use the keyword final as it was originally intended: for program architecture reasons and maintainability.

Only if you are absolutely certain that a method must not be overridden, use the final keyword.

Declare Constants as static final

The dynamic compiler can perform some constant folding optimizations easily, when you declare constants as static final variables.

Avoid Finalizers

Adding finalizers to code makes the garbage collector more expensive and unpredictable. The virtual machine does not guarantee the time at which finalizers are run. Finalizers may not always be executed, before the program exits. Releasing critical resources in finalize() methods may lead to unpredictable application behavior.

Declare Method Arguments final

Declare method arguments final if they are not modified in the method. In general, declare all variables final if they are not modified after being initialized or set to some value.

Synchronize Only When Necessary

Do not synchronize code blocks or methods unless synchronization is required. Keep synchronized blocks or methods as short as possible to avoid scalability bottlenecks. Use the Java Collections Framework for unsynchronized data structures instead of more expensive alternatives such asjava.util.HashTable.

Use DataHandlers for SOAP Attachments

Using a javax.activation.DataHandler for a SOAP attachment will improve performance.

JAX-RPC specifies:

As a result, send an attachment (.gif or XML document) as a SOAP attachment to an RPC style web service by utilizing the Java type mappings. When passing in any of the mandated Java type mappings (appropriate for the attachment’s MIME type) as an argument for the web service, the JAX-RPC runtime handles these as SOAP attachments.

For example, to send out an image/gif attachment, use java.awt.Image, or create a DataHandler wrapper over your image. The advantages of using the wrapper are: