Tuning Java Web Applications Performance

This section includes the following topics:

• Using Java Heap Tuning

• Using Precompiled JSPs

• Using Servlet/JSP Caching

• Configuring the Java Security Manager

• Configuring Class Reloading

• Avoiding Directories in the Classpath

• Configuring the Web Application’s Session Settings

• Configuring JDBC Connection Pooling

• JDBC Connection Pool Attributes

Using Java Heap Tuning

As with all Java programs, the performance of the web applications in the Sun Java System Web Server is dependent on the heap management performed by the virtual machine (VM). There is a trade-off between pause times and throughput. A good place to start is by reading the performance documentation for the Java HotSpot virtual machine, which can be found at the following location:

http://java.sun.com/docs/hotspot/index.html

Java VM options are specified using the JVMOPTIONS subelement of the JAVA element in server.xml. For more information, see the Sun Java System Web Server 6.1 SP6 Administrator’s Configuration File Reference.

Using Precompiled JSPs

Compiling JSPs is a resource-intensive and relatively time-consuming process. By default, the Web Server periodically checks to see if your JSPs have been modified and dynamically reloads them; this allows you to deploy modifications without restarting the server. The reload-interval property of the jsp-config element in sun-web.xml controls how often the server checks JSPs for modifications. However, there is a small performance penalty for that checking.

When the server detects a change in a .jsp file, only that JSP is recompiled and reloaded; the entire web application is not reloaded. If your JSPs do not change, you can improve performance by precompiling your JSPs before deploying them onto your server. For more information about jsp-config and about precompiling JSPs for Sun Java System Web Server, see the Sun Java System Web Server 6.1 SP6 Programmer’s Guide to Web Applications. Also see the following section, Configuring Class Reloading.

Using Servlet/JSP Caching

If you spend a lot of time re-running the same servlet/JSP, you can cache its results and return results out of the cache the next time it is run. For example, this is useful for common queries that all visitors to your site run: you want the results of the query to be dynamic because it might change day to day, but you do not need to run the logic for every user.

To enable caching, you configure the caching parameters in the sun-web.xml file of your application. For more details, see information about caching servlet results in the Sun Java System Web Server 6.1 SP6 Programmer’s Guide to Web Applications.

Configuring the Java Security Manager

Sun Java System Web Server 6.1 supports the Java Security Manager. The main drawback of running with the Security Manager is that it negatively impacts performance. The Java Security Manager is disabled by default when you install the product. Running without the Security Manager may improve performance significantly for some types of applications. Based on your application and deployment needs, you should evaluate whether to run with or without the Security Manager. For more information, see the Sun Java System Web Server 6.1 SP6 Programmer’s Guide to Web Applications.

Configuring Class Reloading

The dynamicreloadinterval of the JAVA element in server.xml and the dynamic-reload-interval of the class-loader element in sun-web.xml controls the frequency at which the server checks for changes in servlet classes. When dynamic reloading is enabled and the server detects that a .class file has changed, the entire web application is reloaded. In a production environment where changes are made in a scheduled manner, set this value to -1 to prevent the server from constantly checking for updates. The default value is -1 (that is, class reloading is disabled). For more information about elements in server.xml, see the Sun Java System Web Server 6.1 SP6 Administrator’s Configuration File Reference. For more information about elements in sun-web.xml, see the Sun Java System Web Server 6.1 SP6 Programmer’s Guide to Web Applications. Also see the previous section in this guide, Using Precompiled JSPs.

Avoiding Directories in the Classpath

For certain applications (especially if the Java Security Manager is enabled), you can improve the performance by ensuring that there are no directories in the classpath. To do so, ensure that there are no directories in the classpath elements in server.xml (serverclasspath, classpathprefix, classpathsuffix). For more information about these elements, see the Sun Java System Web Server 6.1 SP6 Administrator’s Configuration File Reference. Also, package the web application's .class files in a .jar archive in WEB-INF/lib instead of packaging the .class files as is in WEB-INF/classes, and ensure that the .war archive does not contain a WEB-INF/classes directory.

Configuring the Web Application’s Session Settings

If you have relatively short-lived sessions, try decreasing the session timeout by configuring the value of the timeOutSeconds property under the session-properties element in sun-web.xml from the default value of 10 minutes.

If you have relatively long-lived sessions, you can try decreasing the frequency at which the session reaper runs by increasing the value of the reapIntervalSeconds property from the default value of once every minute.

For more information about these settings, and about session managers, see the Sun Java System Web Server 6.1 SP6 Programmer’s Guide to Web Applications.

In multi-process mode when the persistence-type in sun-web.xml is configured to be either s1ws60 or mmap, the session manager uses cross-process locks to ensure session data integrity. These can be configured to improve performance as described below.

Tuning maxLocks (UNIX/Linux)

The implication of the number specified in the maxLocks property can be gauged by dividing the value of maxSessions with maxLocks. For example, if maxSessions = 1000 and you set maxLocks = 10, then approximately 100 sessions (1000/10) will contend for the same lock. Increasing maxLocks will reduce the number of sessions that contend for the same lock and may improve performance and reduce latency. However, increasing the number of locks also increases the number of open file descriptors, and reduces the number of available descriptors that would otherwise be assigned to incoming connection requests.

For more information about these settings, see the "Session Managers" chapter in the Sun Java System Web Server 6.1 SP6 Programmer’s Guide to Web Applications.

Tuning MMapSessionManager (UNIX/Linux)

The following example describes the effect on process size when configuring the persistence-type="mmap" using the manager-properties properties (documented for the MMapSessionManager in the Sun Java System Web Server 6.1 Programmer’s Guide to Web Applications):

maxSessions = 1000
maxValuesPerSession = 10
maxValueSize = 4096

This example would create a memory mapped file of size 1000 X 10 X 4096 bytes, or ~40 MB. As this is a memory mapped file, the process size will increase by 40 MB upon startup. The larger the values you set for these parameters, the greater will be the increase in process size.

Configuring JDBC Connection Pooling

A JDBC connection pool is a named group of JDBC connections to a database. These connections are created when the first request for connection is made on the pool when you start Sun Java System Web Server.

The JDBC connection pool defines the properties used to create a connection pool. Each connection pool uses a JDBC driver to establish a connection to a physical database at server start-up.

A JDBC-based application or resource draws a connection from the pool, uses it, and when no longer needed, returns it to the connection pool by closing the connection. If two or more JDBC resources point to the same pool definition, they will be using the same pool of connections at run time.

The use of connection pooling improves application performance by doing the following:

• Creating connections in advance. The cost of establishing connections is moved outside of the code that is critical for performance.

• Reusing connections. The number of times connections are created is significantly lowered.

• Controlling the amount of resources a single application can use at any moment.

  JDBC connection pools can be created and edited using the Administration interface, or by editing the attributes of the JDBCCONNECTIONPOOL element in the server.xml file. For more information, see the Sun Java System Web Server 6.1 SP6 Administrator’s Guideand the Sun Java System Web Server 6.1 SP6 Administrator’s Configuration File Reference, respectively.

Each defined pool is instantiated during web server startup. However, the connections are only created the first time the pool is accessed. It is recommended that you jump-start a pool before putting it under heavy load.

JDBC Connection Pool Attributes

Depending on your application’s database activity, you may need to size connection pool attributes. Attributes of a JDBC connection pool are listed below, along with considerations relating to performance.

• name

  The pool name.

• datasourceclassname

  The jdbc driver class that implements javax.sql.DataSource.

• steadypoolsize

  The size the pool will tend to keep during the life of the server instance. Also the initial size of the pool. Defaults to 8.

  This number should be as close as possible to the expected average size of the pool. Use a high number for a pool that is expected to be under heavy load. This will minimize creation of connections during the life of the application, and will minimize pool resizing. Use a lower number if the pool load is expected to be small. This will minimize resource consumption.

• maxpoolsize

  The maximum number of connections that a pool can have at any given time. Defaults to 32.

  Use this parameter to enforce a limit in the amount of connection resources that a pool or application can have. This limit is also beneficial to avoid application failures due to excessive resource consumption.

• poolresizequantity

  Number of connections to be removed when the idletimeout timer expires. Connections that have been idle longer than the timeout are candidates for removal. When the pool size reaches steady-pool-size, the connection removal stops. Defaults to 2.

  Keep this number low for pools that expect regular and steady changes in demand. A higher number is recommended for pools that expect infrequent and pronounced changes in the load.

• idletimeout

  The maximum amount in seconds that a connection is ensured to remain unused in the pool. Also the intervals at which the resizer task will be scheduled.

  Note that this does not control connection timeouts enforced at the database server side. Defaults to 300.

  Setting this attribute to 0 prevents the connections from being closed and causes the resizing task not to be scheduled. This is recommended for pools that expect continuous high demand. Otherwise, administrators are advised to keep this timeout shorter than the database server-side timeout (if such timeouts are configured on the specific vendor's database), to prevent accumulation of unusable connections in the pool.

• maxwaittime

  The amount of time in milliseconds that a request waits for a connection in the queue before timing out. Defaults to 60000.

  Setting this attribute to 0 causes a request for a connection to wait indefinitely. This could also improve performance by keeping the pool from having to account for connection timers.

• connectionvalidationrequired

  If set to true, the pool will always execute a call on the connection to verify its validity. Defaults to off.

  The overhead caused by this call can be avoided by setting the parameter to false.

• connectionvalidationmethod

  The method used for validation. Defaults to auto-commit.

  If validation is needed, the methods auto-commit and meta-data are less costly than the method table. The first two require a method call, but they might not be effective if the JDBC driver caches the result of the call. The third method is almost always effective, but it requires the execution of a SQL statement, and thus is less performance-friendly.

• validationtablename

  The user-defined table to be use for validation. Defaults to test.

  If this method is used, it is strongly recommended that the table used be dedicated only to validation, and the number of rows in the table be kept to a minimum.

• failallconnections

  Indicates whether all connection in the pool are re-created when one is found to be invalid or only the invalid one. Only applicable if connectionvalidationrequired is set to true. Defaults to off.

  If set to true, all of the re-creation work will be done in one step, and the thread requesting the connection will be heavily affected. If set to false, the load of re-creating connections will be distributed between the threads requesting each connection.

• transactionisolationlevel

  Specifies the Transaction Isolation Level on the pooled database connections. This setting is optional and has no default.

  If left empty, the default isolation level of the connection will be left intact. Setting it to any value will incur the small performance penalty cause by the method call.

• solationlevelguaranteed

  Only applicable if a transactionisolationlevel has been specified. Defaults to off.

  Leaving this as off or false will cause the isolation level to be set only when the connection is created. Setting this to true will set the level every time the connection is leased to an application. It is recommended that you leave this set to false.