Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Performance Tuning Guide

- Previous: Java Programming Guidelines
- Next: EJB Performance Tuning

# Java Server Page and Servlet Tuning

Many applications running on the Application Server use servlets or JavaServer Pages (JSP) technology in the presentation tier. This section describes how to improve performance of such applications, both through coding practices and through deployment and configuration settings.

## Suggested Coding Practices

This section provides some tips on coding practices that improve servlet and JSP application performance.

### General Guidelines

Follow these general guidelines to increase performance of the presentation tier:

- Minimize Java synchronization in servlets.

- Don’t use the single thread model for servlets.

- Use the servlet’s `init()` method to perform expensive one-time initialization.

- Avoid using `System.out.println()` calls.

### Avoid Shared Modified Class Variables

In the servlet multithread model (the default), a single instance of a servlet is created for each application server instance. All requests for a servlet on that application instance share the same servlet instance. This can lead to thread contention if there are synchronization blocks in the servlet code. So, avoid using shared modified class variables, since they create the need for synchronization.

### HTTP Session Handling

Follow these guidelines when using HTTP sessions:

- Create sessions sparingly. Session creation is not free. If a session is not required, do not create one.

- Use `javax.servlet.http.HttpSession.invalidate()` to release sessions when they are no longer needed.

- Keep session size small, to reduce response times. If possible, keep session size below seven KB.

- Use the directive `<%page session="false"%>` in JSP files to prevent the Application Server from automatically creating sessions when they are not necessary.

- Avoid large object graphs in an `HttpSession` `.` They force serialization and add computational overhead. Generally, do not store large objects as `HttpSession` variables.

- Don’t cache transaction data in `HttpSession`. Access to data in an `HttpSession` is not transactional. Do not use it as a cache of transactional data, which is better kept in the database and accessed using entity beans. Transactions will rollback upon failures to their original state. However, stale and inaccurate data may remain in `HttpSession` objects. The Application Server provides “read-only” bean-managed persistence entity beans for cached access to read-only data.

### Configuration and Deployment Tips

Follow these configuration tips to improve performance. These tips are intended for production environments, not development environments.

- To improve class loading time, avoid having excessive directories in the server `CLASSPATH`. Put application-related classes into JAR files.

- HTTP response times are dependent on how the keep-alive subsystem and the HTTP server is tuned in general. For more information, see HTTP Service Settings

- If you are using Solaris 8, optimize SSL by using the `mtmalloc` library that provides a collection of `malloc` routines for concurrent access to heap space. To use `mtmalloc`:

  - Get patch 111308-03 from SunSolve Onlineand install it.

  - Edit the `startserv` script located in `bin/startserv` for your domain, and define the LD_PRELOAD environment variable to be `/usr/lib/libmtmalloc.so`.

    The exact syntax to define an environment variable depends on the shell you use.

- Cache servlet results when possible. For more information, see Chapter 5, Developing Web Applications, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide.

- If an application does not contain any EJB components, deploy the application as a WAR file, not an EAR file.

#### Disable Security Manager

The security manager is expensive because calls to required resources must call the `doPrivileged()` method and must also check the resource with the `server.policy` file. If you are sure that no malicious code will be run on the server and you do not use authentication within your application, then you can disable the security manager.

To disable use of the `server.policy` file, use the Admin Console. Under Configurations > config-name > JVM Settings (JVM Options) delete the option that looks like this:

    -Djava.security.policy=${com.sun.aas.instanceRoot}/config/server.policy

- Previous: Java Programming Guidelines
- Next: EJB Performance Tuning

- © 2010, Oracle Corporation and/or its affiliates