Tuning Your Web Application

This section provides information on tuning applications for maximum performance. A complete guide to writing high performance Java and Java 2 EE Web applications is beyond the scope of this document.

Java Programming Guidelines

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

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 StringBuffer to Concatenate Strings

To improve performance, instead of using string concatenation, use StringBuffer.append(). String objects are immutable; they never change after creation. For example, consider the following code:

tring str = "testing";
str = str + "abc";

The compiler translates this code as:

String str = "testing";
StringBuffer tmp = new StringBuffer(str);
tmp.append("abc");
str = tmp.toString();

Therefore, copying is inherently expensive and overusing it can reduce performance significantly.

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 can 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 as java.util.HashTable.

Use DataHandlers for SOAP Attachments

Using a javax.activation.DataHandler for a SOAP attachment improves performance.

JAX-RPC specifies:

• A mapping of certain MIME types to Java types.

• Any MIME type is mappable to a javax.activation.DataHandler .

As a result, send a SOAP attachment as a .gif or XML file to an RPC style web service by utilizing the Java type mappings. When passing in any of the mandated Java type mappings which are 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 or a gif attachment, use java.awt.Image, or create a DataHandler wrapper over your image. The advantages of using the wrapper are:

• Reduced coding: You can reuse generic attachment code to handle the attachments because the DataHandler determines the content type of the contained data automatically. This feature is especially useful when using a document style service. Since the content is known at runtime, there is no need to make calls to attachment.setContent (stringContent, "image/gif"), for example.

• Improved Performance: Informal tests have shown that using DataHandler wrappers doubles throughput for image or GIF MIME types, and multiplies throughput by approximately 1.5 for text and XML or java.awt.Image for image/* types.