Chapter 2 Tuning Sun Java System Web Server

This chapter describes specific adjustments you can make that might
improve Sun Java System Web Server performance. It provides an overview of
Web Server's connection-handling process so that you can better understand
the tuning settings. The chapter includes the following topics:

Be very careful when tuning your server. Always back up your configuration
files before making any changes.

General Tuning Tips

As you tune your server, it is important to remember that your specific
environment is unique. The impacts of the suggestions provided in this guide
will vary, depending on your specific environment. Ultimately you must rely
on your own judgement and observations to select the adjustments that are
best for you.

As you work to optimize performance, keep the following guidelines in
mind:

Work methodically

As much as possible, make one adjustment at a time. Measure your performance
before and after each change, and rescind any change that doesn’t produce
a measurable improvement.

Adjust gradually

When
adjusting a quantitative parameter, make several changes in succession,
rather than trying to make a drastic change all at once. Different systems
face different circumstances, and you might pass by your system’s
best setting if you change the value too rapidly.

Start fresh

At
each major system change, be it a hardware or software upgrade or deployment
of a major new application, review all previous adjustments to see whether
they still apply. After a Solaris upgrade, you should start over with an unmodified /etc/system file.

Understanding Threads, Processes, and Connections

Before tuning your server, you should understand the connection-handling
process in Web Server. Request
processing threads handle Web Server connections. You can configure Request
handling threads from the Admin Console or by editing the server.xml configuration
file. This section includes the following topics:

Connection-Handling Overview

In Web Server, acceptor threads on a listen socket accept connections
and put them into a connection queue. Request processing threads in a thread
pool then pick up connections from the queue and service the requests.

Figure 2–1 Web Server Connection Handling

A request is not
thread-safe
if processing the request requires interaction between a number of threads.
A part of the request which is not thread-safe is transferred to a NativePool,
which is a collection of threads which can interact with each other. The NativePool
processes the request and communicates the request back to the request processing
thread.

At startup, the server only creates the number of threads defined in
the thread pool minimum threads, by default set to number of processors. As the load
increases, the server creates more threads. The policy for adding new threads
is based on the connection queue state.

Each time a new request
is created, the number of requests waiting in the queue, often considered the backlog
of connections, is compared to the number of request processing
threads already created. If the number of requests is greater than the
number of threads, more threads are created.

You can change the settings that affect the number and timeout of threads,
processes, and connections in the Admin Console, on the configuration's Performance
tab (HTTP settings), and on the HTTP listener. You can also use the wadm commands set-thread-pool-prop and set-http-listener-prop and set-keep-alive-prop.

Low Latency and High Concurrency Modes

The server can run in one of two modes, depending upon the load. It
changes modes to accommodate the load most efficiently.

In
high concurrency mode, after finishing the request, session threads give the
connection to the keep-alive subsystem. In high concurrency mode, the keep-alive
subsystem polls for new requests for all keep-alive connections.

When the server is started, it starts in low latency mode. When the
load increases, the server moves to high concurrency mode. The decision to
move from low latency mode to high concurrency mode and back again is made
by the server, based on connection queue length, average total sessions, average
idle sessions, and currently active and idle sessions.

Disabled Thread Pools

If a thread pool is disabled, no threads are created in the pool, no
connection queue is created, and no keep-alive threads are created. When the
thread pool is disabled, the acceptor threads themselves process the request.

Connection–Handling magnus.conf Directives
for NSAPI

In addition to the settings discussed above, you can edit the following
directives in the magnus.conf file to configure additional
request-processing settings for NSAPI plug-ins:

For the safest way to edit configuration files such as magnus.conf, use the wadm commands get-config-file and set-config-file to pull a local copy for editing and push it back
to the Web Server. For more information on these commands, see the help for
these commands.

Custom Thread Pools

By default, the connection queue sends requests to the default thread
pool. However, you can also create your own thread pools in magnus.conf using a thread pool Init function. These custom
thread pools are used for executing NSAPI Service Application Functions (SAFs),
not entire requests.

If the SAF requires the use of a custom thread pool, the current request
processing thread queues the request, waits until the other thread from the
custom thread pool completes the SAF, then the request processing thread completes
the rest of the request.

The request processing thread, referred to as A1 in this example, picks
up the request and executes the steps before the NameTrans directive.

If the URI starts with /testmod, the A1
thread queues the request to the my-custom-pool queue.
The A1 thread waits.

A different thread in my-custom-pool, called
the B1 thread in this example, picks up the request queued by A1. B1 completes
the request and returns to the wait stage.

The A1 thread wakes up and continues processing the request.
It executes the ObjectType SAF and moves on to the Service function.

Because the Service function must be processed by a thread
in my-custom-pool2, the A1 thread queues the request to my-custom-pool2.

A different thread in my-custom-pool2,
called C1 in this example, picks up the queued request. C1 completes the request
and returns to the wait stage.

The A1 thread wakes up and continues processing the request.

In this example, three threads, A1, B1, and C1 work to complete the
request.

Additional thread pools are a way to run thread-unsafe plug-ins. By
defining a pool with a maximum number of threads set to 1, only one request
is allowed into the specified service function. In the previous example, if testmod_service is not thread-safe, it must be executed by a single
thread. If you create a single thread in the my-custom-pool2,
the SAF works in a multi-threaded Web Server.

The Native Thread Pool

On Windows, the native thread pool (NativePool) is used internally by
the server to execute NSAPI functions that require a native thread for execution.

Web Server uses Netscape Portable Runtime (NSPR), which is an underlying portability layer providing access
to the host OS services. This layer provides abstractions for threads that
are not always the same as those for the OS-provided threads. These non-native
threads have lower scheduling overhead, so their use improves performance.
However, these threads are sensitive to blocking calls to the OS, such as
I/O calls. To make it easier to write NSAPI extensions that can make use of
blocking calls, the server keeps a pool of threads that safely support blocking
calls. These threads are usually native OS threads. During request processing,
any NSAPI function that is not marked as being safe for execution on a non-native
thread is scheduled for execution on one of the threads in the native thread
pool.

If you have written your own NSAPI plug-ins such as NameTrans, Service, or PathCheck functions, these execute by default
on a thread from the native thread pool. If your plug-in makes use of the
NSAPI functions for I/O exclusively or does not use the NSAPI I/O functions
at all, then it can execute on a non-native thread. For this to happen, the
function must be loaded with a NativeThread="no" option,
indicating that it does not require a native thread.

For example,
add the following to the load-modulesInit line
in the magnus.conf file:

The NativeThread flag affects all functions in the funcs list,
so if you have more than one function in a library, but only some of them
use native threads, use separate Init lines. If you set NativeThread to yes, the thread maps directly
to an OS thread.

Process Modes

Multi-process mode is deprecated for Java technology-enabled servers.
Most applications are now multi-threaded, and multi-process mode is usually
not needed. However, multi-process mode can significantly improve overall
server throughput for NSAPI applications that do not implement fine-grained
locking.

Single-Process Mode

In the single-process mode, the server receives requests from web clients
to a single process. Inside the single server process, acceptor threads are
running that are waiting for new requests to arrive. When a request arrives,
an acceptor thread accepts the connection and puts the request into the connection
queue. A request processing thread picks up the request from the connection
queue and handles the request.

Because the server is multi-threaded, all NSAPI extensions written to
the server must be thread-safe. This means that if the NSAPI extension uses
a global resource, like a shared reference to a file or global variable, then
the use of that resource must be synchronized so that only one thread accesses
it at a time. All plug-ins provided with the Web Server are thread-safe and
thread-aware, providing good scalability and concurrency. However, your legacy
applications might be single-threaded. When the server runs the application,
it can only execute one at a time. This leads to server performance problems
when put under load. Unfortunately, in the single-process design, there is
no real workaround.

Multi-Process Mode

You can configure the server to handle requests using multiple processes
with multiple threads in each process. This flexibility provides
optimal performance for sites using threads, and also provides backward compatibility
to sites running legacy applications that are not ready to run in a threaded
environment. Because applications on Windows generally already take advantage
of multi-thread considerations, this feature applies to UNIX and Linux platforms.

The advantage of multiple processes is that legacy applications that
are not thread-aware or thread-safe can be run more effectively in Sun Java
System Web Server. However, because all of the Sun Java System extensions
are built to support a single-process threaded environment, they might not
run in the multi-process mode. The Search plug-ins fail on startup if the
server is in multi-process mode, and if session replication is enabled, the
server will fail to start in multi-process mode.

In the multi-process mode, the server spawns multiple server processes
at startup. Depending
on the configuration, each process contains one or more threads, that
receive incoming requests. Since each process is completely independent, each
one has its own copies of global variables, caches, and other resources. Using
multiple processes requires more resources from your system. Also, if you
try to install an application that requires shared state, it has to synchronize
that state across multiple processes. NSAPI provides no helper functions for
implementing cross-process synchronization.

When you specify a MaxProcs value greater than 1, the server relies on the operating
system to distribute connections among multiple server processes (see MaxProcs (UNIX/Linux) for information about the MaxProcs directive). However, many modern operating systems do not
distribute connections evenly, particularly when there are a small number
of concurrent connections.

Because Sun
Java System Web Server cannot guarantee that load is distributed evenly among
server processes, you might encounter performance problems if you set Maximum Threads to 1 and MaxProcs greater
than 1 to accommodate a legacy application that is not thread-safe. The problem
is especially pronounced if the legacy application takes a long time to respond
to requests, for example, when the legacy application
contacts a back-end database. In this scenario, it might be preferable to use the default value
for Maximum Threads and serialize access to the legacy application using thread
pools. For more information about creating a thread pool, see thread-pool-init in Sun Java System Web Server 7.0 Update 4 Administrator’s Configuration File Reference.

If you are not running any NSAPI in your server, you should use the
default settings: one process and many threads. If you are running an application
that is not scalable in a threaded environment, you should use a few processes
and many threads, for example, 4 or 8 processes and 128 or 512 threads per
process.

MaxProcs (UNIX/Linux)

To run a UNIX or Linux server in multi-process mode, set the MaxProcs
directive to a value that is greater than 1. Multi-process mode might provide
higher scalability on multi-processor machines and improve the overall server
throughput on large systems such as the Sun FireTM T2000
server. If you set the value to less than 1, it is ignored and the default
value of 1 is used.

Use the MaxProcs directive to improve overall server throughput for
the following types of applications:

NSAPI applications that do not implement fine-grained locking

Java applications that do not require session management

Do not use the MaxProcs directive when the Sun
Java System Web Server performs session management for Java applications.

You can set the value for MaxProcs by editing the MaxProcs parameter in magnus.conf.

Note –

You will receive duplicate startup messages when running your
server in MaxProcs mode.

Mapping Web Server 6.1 Tuning Parameters
to Web Server 7.0

Many of the tuning parameters that were tunable by editing the magnus.conf and nsfc.conf files in Web Server 6.1 have
moved to the server.xml file. These tuning parameters
are now tunable through the Admin Console and command-line interface. The
following table shows selected tuning parameters, including the Web Server
6.1 parameter, the new server.xml element used for tuning,
and the way to change the parameters through the user interface. Editing the server.xml file directly can be error-prone, so using the user
interface to set values is preferable. For a complete list of all elements
in server.xml, see Chapter 3, Elements in server.xml, in Sun Java System Web Server 7.0 Update 4 Administrator’s Configuration File Reference.

Table 2–1 Parameter Mapping to server.xml

Web Server 6.1 parameter

Web Server 7.0 server.xml element or attribute

Admin Console Location

wadm command

AcceptTimeout in magnus.conf

io-timeout element of the http element

Configuration's Performance tab ⇒ HTTP Settings page

set-http-prop command's io-timeout property

ACLGroupCacheSize in magnus.conf

max-groups-per-user element of the acl-cache element

Configuration's Performance tab ⇒ Cache Settings page

set-acl-cache-prop command's max-groups-per-user property

ACLUserCacheSize in magnus.conf

max-users element of the acl-cache element

Configuration's Performance tab ⇒ Cache Settings page

set-acl-cache-prop command's max-users property

ConnQueueSize in magnus.conf

queue-size element of the thread-pool element

Configuration's Performance tab ⇒ HTTP tab

set-thread-pool-prop command's queue-size property

dns-cache-initInit SAF

enabled element of the dns-cache element

Configuration's Performance tab ⇒ DNS tab

set-dns-cache-prop command's enabled property

dns-cache-initInit SAF cache
size

max-entries element of the dns-cache element

Configuration's Performance tab ⇒ DNS tab

set-dns-cache-prop command's max-entries property

FileCacheEnabled in nsfc.conf

enabled element of the file-cache element

Configuration's Performance tab ⇒ Cache tab

set-file-cache-prop command's enabled property

KeepAliveThreads in magnus.conf

threads element of the keep-alive element

Configuration's Performance tab ⇒ HTTP tab

set-keep-alive-prop command's threads property

KeepAliveTimeout in magnus.conf

timout element of the keep-alive element

Configuration's Performance tab ⇒ HTTP tab

set-keep-alive-prop command's timeout property

KernelThreads in magnus.conf (Windows
only)

Unchanged

ListenQ in magnus.conf

listen-queue-size element of the http-listener element

Configuration's HTTP Listeners tab

set-http-listener-prop command's listen-queue-size

LogVerbose in magnus.conf

log-level element of the log element

Configuration's General Tab ⇒ Log Settings

set-error-log-prop command's log-level property

MaxAge in nsfc.conf file

max-age element of the file-cache element

Configuration's Performance tab ⇒ Cache tab

set-file-cache-prop command's max-age property

MaxFiles in nsfc.conf file

max-entries element of the file-cache element

Configuration's Performance tab ⇒ Cache tab

set-file-cache-prop command's max-entries property

MaxKeepAliveConnections in magnus.conf

max-connections element of the keep-alive element

Configuration's Performance tab ⇒ HTTP tab

set-keep-alive-prop command's max-connections property

MaxProcs in magnus.conf

Deprecated for Java technology-enabled servers

NativePoolMaxThreads in magnus.conf

Unchanged

NativePoolMinThreads in magnus.conf

Unchanged

NativePoolQueueSize in magnus.conf

Unchanged

NativePoolStackSize in magnus.conf

Unchanged

RqThrottle in magnus.conf

max-threads element of the thread-pool element

Configuration's Performance tab ⇒ HTTP tab

set-thread-pool-prop command's max-threads property

RqThrottleMin in magnus.conf

min-threads element of the thread-pool element

Configuration's Performance tab ⇒ HTTP tab

set-thread-pool-prop command's min-threads property

TerminateTimeout in magnus.conf

Unchanged

Using Monitoring Data to Tune Your Server

This section describes the performance information available through
the Admin Console, perfdump, the command-line interface,
and stats-xml. It discusses how to analyze that information
and tune parameters
to improve your server’s performance.

Web Server automatically selects many
server defaults based on the system resources. The number of acceptor threads
and keep-alive threads defaults to the number of CPUs. The server/thread-pool/max-threads defaults to greater of
128 or the number of CPUs. The server/thread-pool/min-threads defaults to lesser the value of server/thread-pool/max-threads or the number of CPUs.
The server/access-log-buffer/max-buffers-per-file defaults to the number of CPUs. The server configures the connection
queue size, maximum number of keep-alive connections, and the maximum number
of open files in the file cache, based on the total number of available file
descriptors in the system. The values for these are obtained from the server
log file when the log level is set to fine. All the server chosen defaults
are tunable.

The default tuning parameters are appropriate for all sites except those
with very high volume. The only settings that large sites might regularly
need to change are the
thread pool and keep alive settings. Tune these settings at the configuration
level in the Admin Console or using wadm commands. It is
also possible to tune the server by editing the elements directly in the server.xml file, but editing the server.xml file
directly can lead to complications.

perfdump monitors statistics in the following categories,
which are described in the following sections. In most cases these statistics
are also displayed in the Admin Console, command-line interface, and stats-xml output. The following sections contain tuning information for all
these categories, regardless of which method you use to monitor the data:

In addition, the statistics information displayed through the Admin
Console, the command-line interface, and stats-xml contains
other categories not contained in the perfdump output.
Tuning these statistics is discussed in the following sections:

Once you have viewed the statistics you need, you can tune various aspects
of your server’s performance at the configuration level using the Admin
Console's Performance tab. The Admin Console Performance tab includes settings
for many performance categories, including:

HTTP Settings (includes Thread Pool and Keep Alive)

DNS Settings

SSL and TLS Settings

Cache Settings

CGI Settings

Access Log Buffer Settings

You can also view and set tuning parameters using the appropriate wadm commands. When you set tuning properties using wadm commands,
the names of the properties are the same as displayed in stats.xml.

Connection Queue Information

In Web Server, a connection is first accepted by acceptor threads associated
with the HTTP listener. The acceptor threads accept the connection and put
it into the connection queue. Then, request processing threads take the connection
in the connection queue and process the request. For more information, see Connection-Handling Overview.

Connection queue information shows the number of sessions
in the connection queue, and the average delay before the connection is accepted
by the request processing thread.

The following is an example of how these statistics are displayed in perfdump:

The same information is displayed in a different format through the
Admin Console or command-line interface, with some slight differences. The
following table shows the information displayed in the Admin Console when
accessing monitoring information for the server instance:

Table 2–2 Connection Queue Statistics

Present Number of Connections Queued

0

Total Number of Connections Queued

11222922

Average Connections Over Last 1 Minute

90.35

Average Connections Over Last 5 Minutes

89.64

Average Connections Over Last 15 Minutes

54.02

Maximum Queue Size

160032

Peak Queue Size

1853

Number of Connections Overflowed

0

Ticks Spent

5389284274

Total Number of Connections Added

425723

Current /Peak /Limit Queue Length

Current/Peak/Limit queue length shows, in order:

The number of connections currently in the queue.

The largest number of connections that have been in the queue
simultaneously.

Tuning

If the peak queue length, also known as the maximum queue size, is close to the limit,
you can increase the maximum connection queue size to avoid dropping connections
under heavy load.

You can increase the maximum connection queue size in the Admin Console
by changing the value of the thread pool Queue Size field on the configuration's
Performance tab ⇒ HTTP sub tab. The default is selected based on the total number of available
file descriptors in the system.

To change the queue size using the command-line interface, use the wadm set-thread-pool-prop command's queue-size property.

Total Connections Queued

Total Connections Queued is the total number of times
a connection has been queued. This number includes newly-accepted connections
and connections from the keep-alive system.

This setting is not tunable.

Average Queue Length

The Average Queue Length shows the average number of connections in
the queue over the most
recent one-minute, five-minute, and 15–minute intervals.

This setting is not tunable.

Average Queuing Delay

The Average Queueing Delay is the average amount of time a connection
spends in the connection queue. This represents the delay between when a request
connection is accepted by the server and when a request processing thread
begins servicing the request. It is the Ticks Spent divided by the Total Connections
Queued, and converted to milliseconds.

This setting is not tunable.

Ticks Spent

A tick is a system-dependent value and provided by the tickPerSecond attribute of the server element in stats.xml. The ticks spent value is the total amount of time that connections
spent in the connection queue and is used to calculate the average queuing delay.

This setting is not tunable.

Total Number of Connections Added

The new connections added to the connection queue. This setting is not
tunable.

HTTP Listener (Listen Socket) Information

The following HTTP listener information includes
the IP address, port number, number of acceptor threads, and the default virtual
server. For tuning purposes, the most important field in the HTTP listener
information is the number of acceptor threads.

You can have many HTTP listeners enabled for virtual
servers, but at least one is enabled for your default server instance (usually http://0.0.0.0:80). The monitoring information available through
the Admin Console does not show the HTTP listener information, because that
information is available in the Admin Console on the configuration's HTTP
Listeners tab.

The following is an example of how the HTTP listeners information appears
in perfdump:

Address

The Address field contains the base address on which
this listen socket is listening. A host can have multiple network interfaces
and multiple IP addresses. The address contains the IP address and the port
number.

If your listen socket listens on all network interfaces for the host
machine, the IP part of the address is 0.0.0.0.

Tuning

This setting is tunable when you edit an HTTP listener. If you specify
an IP address other than 0.0.0.0, the server makes one less system call per
connection. Specify an IP address other than 0.0.0.0 for best possible performance.

Acceptor Threads

Acceptor threads are threads that wait for connections. The threads
accept connections and put them in a queue where they are then picked up by
worker threads. For more information, see Connection-Handling Overview.

Ideally, you want to have enough acceptor threads so that there is always
one available when a user needs one, but few enough so that they do not burden the system.
A good rule is to have one acceptor thread per CPU on your system. You can
increase this value to about double the number of CPUs if you find indications
of TCP/IP listen queue overruns.

Tuning

This setting is tunable when you edit an HTTP listener. The number of acceptor threads defaults to the
number of CPUs on your system.

Other HTTP listener settings that affect performance are the size of
the send buffer and receive buffer. For more information regarding these buffers,
see your operating system documentation.

Default Virtual Server

Virtual servers work using the HTTP 1.1 Host header. If the end user’s
browser does not send the Host header, or if the server cannot find the virtual
server specified by the Host header, Web Server handles the request using
a default virtual server. You can configure the default virtual server to
send an error message or serve pages from a special document root.

Tuning

This setting is tunable when you edit an HTTP listener.

Keep-Alive Information

This section provides information about the server’s HTTP-level
keep-alive system.

Note –

The name keep alive should not be confused with TCP keep-alives. Also, note that the name keep-alive was changed to PersistentConnections in HTTP 1.1, but Web Server continues to refer to these connections as keep-alive
connections. Most modern
browsers request a web page from the server through persistent connections
with the web server. The connection is kept alive even after processing a
request, so that it will be easier to process a similar request.

The following example shows the keep-alive statistics displayed by perfdump:

The following table shows the keep-alive statistics displayed in the
Admin Console:

Table 2–3 Keep-Alive Statistics

Number of Connections Processed

0

Total Number of Connections Added

198

Maximum Connection Size

200

Number of Connections Flushed

0

Number of Connections Refused

56844280

Number of Idle Connections Closed

365589

Connection Timeout

10

Both HTTP 1.0 and HTTP 1.1 support the ability to send multiple requests
across a single HTTP session. A web server can receive hundreds of new HTTP
requests per second. If every request is allowed to keep the connection open
indefinitely, the server can become
overloaded with connections. On UNIX and Linux systems, this can lead to a file table
overflow very easily.

To resolve this problem, the
server maintains a counter for the maximum number of waiting keep-alive connections.
A waiting keep-alive connection has fully completed processing the previous
request, and is now waiting for a new request to arrive on the same connection.
If the server has more than the maximum waiting connections open when a new
connection waits for a keep-alive request, the server closes the oldest connection.
This algorithm keeps an upper bound on the number of open waiting keep-alive
connections that the server can maintain.

Sun Java System Web Server does not always honor a keep-alive request
from a client. The following conditions cause the server to close a connection,
even if the client has requested a keep-alive connection:

The keep alive timeout is set to 0.

The keep alive maximum connections count is exceeded.

Dynamic content, such as a CGI, does not have an HTTP content-length header
set. This applies only to HTTP 1.0 requests. If the request is HTTP 1.1, the
server honors keep-alive requests even if the content-length is
not set. The server can use chunked encoding for these requests if the client
can handle them (indicated by the request header transfer-encoding:
chunked).

The request is not HTTP GET or HEAD.

The request was determined to be bad. For example, if the
client sends only headers with no content.

The keep-alive subsystem in Web Server is designed to be massively scalable.
The out-of-the-box configuration can be less than optimal if the workload
is non-persistent (that is, HTTP 1.0 without the KeepAlive header),
or for a lightly loaded system that’s primarily servicing keep-alive
connections.

Keep-Alive Count

This section in perfdump has two numbers:

Number of connections in keep-alive mode, also known as the total
number of connections added

Maximum number of connections allowed in keep-alive mode simultaneously, also known as the maximum
connection size

Tuning

You can tune the maximum number of connections
that the server allows to wait at one time before closing the oldest connection
in the Admin Console by editing the Maximum Connections field on the configuration's
Performance tab ⇒ HTTP tab, under Keep Alive Settings. The default is based on the number of available
file descriptors in the system. In the command-line interface,
use the max-connections property in the wadm set-keep-alive-prop command.

Note –

The number of connections specified by the maximum connections
setting is divided equally among the keep-alive threads. If the maximum connections
setting is not equally divisible by the keep-alive threads setting, the server
might allow slightly more than the maximum number of simultaneous keep-alive
connections.

Keep-Alive Hits

The keep-alive hits,
or the number of connections processed, is the number of times
a request was successfully received from a connection that was kept alive.

This setting is not tunable.

Keep-Alive Flushes

The number of times the server had to close a connection because the
total number of connections added exceeded the keep-alive maximum connections
setting. The server does not close existing connections when the keep-alive
count exceeds the maximum connection size. Instead, new keep-alive connections
are refused and the number of connections refused count is incremented.

Keep-Alive Refusals

The number of times the server could not complete the connection
to a keep-alive thread, possibly due to too many persistent connections (or
when total number of connections added exceeds the keep-alive maximum connections
setting). The suggested tuning is to increase the keep-alive maximum connections.

Keep-Alive Timeouts

The number of times the server closed idle keep-alive connections because client connections
timed out without any activity. This statistic is useful to monitor; no specific
tuning is advised.

Keep-Alive Timeout

The time, measured in seconds, before
idle keep-alive connections are closed. Set this value in the Admin Console
in the Timeout field on the configuration's Performance tab ⇒ HTTP tab,
under Keep Alive Settings. The default is 30 seconds, meaning the connection
times out if idle for more than 30 seconds. The maximum is 3600 seconds (60
minutes). In the command-line interface, use the timeout property
in the wadm set-keep-alive-prop command.

Keep-Alive Poll Interval

The keep-alive poll interval specifies the interval in seconds at which the system polls
keep-alive connections for further requests. The default is 0.001 second,
the lowest value allowed. It is set to a low value to enhance performance
at the cost of CPU usage.

To tune the poll interval, edit the Poll Interval field on the configuration's
Performance tab ⇒ HTTP tab, under Keep Alive Settings. In the command-line
interface, use the poll-interval property in the wadm
set-keep-alive-prop command.

Keep-Alive Threads

You can configure the number of threads used in the keep-alive system
in the Admin Console by editing the Threads field on the configuration's Performance
tab ⇒ HTTP tab, under Keep Alive Settings. The default is set to the number of processors
in the system. In the command-line interface, use the threads property in the wadm set-keep-alive-prop command.

Tuning for HTTP 1.0-Style Workload

Since HTTP 1.0 results in a large number of new incoming connections,
the default acceptor threads of 1 per listen socket would be suboptimal. Increasing
this to a higher number should improve performance for HTTP 1.0-style workloads.
For instance, for a system with 2 CPUs, you might want to set it to 2. You
might also want to reduce the keep-alive connections, for example, to 0.

HTTP 1.0-style workloads can have many connections established and
terminated.

If users are experiencing connection timeouts from a browser to Web
Server when the server is heavily loaded, you can increase the size of the
HTTP listener backlog queue by setting the HTTP listener listen queue size
to a larger value, such as 8192.

The HTTP listener listen queue specifies the maximum number of pending
connections on a listen socket. Connections that time out on a listen socket
whose backlog queue is full fail.

Tuning for HTTP 1.1-Style Workload

While tuning server-persistent connection handling, balancing
throughput and latency is a challenge. The keep-alive poll
interval and timeout control latency. Lowering the value of these settings
is intended to lower latency on lightly loaded systems, for example, to reduce page load times. Increasing
the values of these settings is intended to raise aggregate throughput on
heavily loaded systems, for example, by increasing
the number of requests per second the server can handle. However, if there's
too much latency and too few clients, aggregate throughput suffers as the
server sits idle unnecessarily. As a result, the general
keep-alive subsystem tuning rules at a particular load are as follows:

If there's idle CPU time, decrease the poll interval.

If there's no idle CPU time, increase the poll interval.

Also, chunked encoding could affect the performance
for HTTP 1.1 workload. Tuning the response buffer size can positively affect the
performance. A higher response buffer size in the configuration's Performance
tab ⇒ HTTP tab would result in sending a Content-length: header,
instead of chunking the response. To set the buffer size using the CLI, use
the wadm set-http-prop command's output-buffer-size property.

You can also set the buffer size for a Service-class function in the obj.conf file, using the UseOutputStreamSize parameter. UseOutputStreamSize overrides the value set using the output-buffer-size property. If UseOutputStreamSize is not set,
Web Server uses the output-buffer-size setting. If the output-buffer-size is not set, Web Server uses the output-buffer-size default value of 8192.

The following example shows using the CLI to increase the output buffer
size, then deploying the configuration (used if UseOutputStreamSize is
not specified in obj.conf):

Total Sessions Created in perfdump shows
both the number of sessions that have been created and the maximum threads. Web Server can also service certain
type of requests such as cached static content from the keep alive threads.
Therefore, the maximum threads is the sum of the maximum threads configured
in the thread-pool element in the server.xml file and
the number of keep alive threads. For more information, see Accelerator Hit Ratio.

The equivalent information as the Total Number of Threads is available
through the Admin Console from the Monitoring tab ⇒ Instances sub tab,
under General Statistics. To see the maximum threads allowed, see the Maximum
Threads field on the configuration's Performance tab ⇒ HTTP sub tab,
under Thread Pool Settings.

To get the equivalent of the perfdumpActive
Sessions, you can subtract the Number of Idle Threads from the Total
Number of Threads.

Maximum Threads (Maximum Simultaneous Requests)

The maximum
threads setting specifies the maximum number of simultaneous transactions
that the Web Server can handle. The default value is greater of 128 or the number of processors in the system. Changes
to this value can be used to throttle the server, minimizing latencies for
the transactions that are performed. The Maximum Threads value acts across
multiple virtual servers, but does not attempt to load balance. It is set
for each configuration.

Reaching the maximum number of configured threads is not necessarily
undesirable, and you do not need to automatically increase the number of threads
in the server. Reaching this limit means that the server needed this many
threads at peak load, but as long as it was able to serve requests in a timely
manner, the server is adequately tuned. However, at this point connections
queue up in the connection queue, potentially overloading it. If you monitor your server's
performance regularly and notice that total sessions created number is often
near the maximum number of threads, consider increasing your thread
limits.

To compute the number of simultaneous requests, the server counts the
number of active requests, adding one to the number when a new request arrives,
subtracting one when it finishes the request. When a new request arrives,
the server checks to see if it is already processing the maximum number of
requests. If it has reached the limit, it defers processing new requests until
the number of active requests drops below the maximum amount.

In theory, you can set
the maximum threads to 1 and still have a functional server. Setting this
value to 1 would mean that the server could only handle one request at a time,
but since HTTP requests for static files generally have a very short duration. Response time can be as
low as 5 milliseconds.
Processing one request at a time still allows you to process up to
200 requests per second.

However, in actuality, Internet clients frequently connect to the server
and then do not complete their requests. In these cases, the server waits
30 seconds or more for the data before timing out. You can define this timeout
period using the IO Timeout setting on the configuration's Performance tab
⇒ HTTP Settings page. You can also use the command wadm set-http-prop and set the io-timeout property. The default
value is 30 seconds. By setting the default value to less than 30 seconds you can free
up threads sooner, but you might also disconnect users with slower connections.
Also, some sites perform heavyweight transactions that take minutes to complete.
Both of these factors add to the maximum simultaneous requests that are required.
If your site is processing many requests that take many seconds, you might
need to increase the number of maximum simultaneous requests.

Suitable maximum threads values range from 100-500, depending on the
load. Maximum Threads represents a hard limit for the maximum number of active
threads that can run simultaneously, which can become a bottleneck for performance.

The thread pool minimum threads is the minimum number of threads the
server initiates upon startup. The default is set to number of processors.

Note –

When configuring Web Server to be used with the Solaris Network
Cache and Accelerator (SNCA), setting the maximum threads and the queue size
to 0 provides better performance. Because SNCA manages the client connections,
it is not necessary to set these parameters. These parameters can also be
set to 0 with non-SNCA configurations, especially for cases in which short
latency responses with no keep-alives must be delivered. It is important to
note that the maximum threads and queue size must both be
set to 0.

Tuning

You can increase your thread limits in the Admin Console by editing
the Maximum Threads field on the configuration's Performance tab ⇒ HTTP
tab, under Thread Pool Settings. In the command-line interface, use the wadm set-thread-pool-prop command's max-threads property.
The default value is greater
of 128
or the number of processors in the system.

File Cache Statistics Information

The cache information section provides statistics on how
your file cache is being used. The file cache caches static content so that
the server handles requests for static content quickly. The file cache contains
information about files and static file content. The file cache also caches
information that is used to speed up processing of server-parsed HTML. For
servlets and JSPs, other kinds of caching are used.

For sites with scheduled updates to content, consider shutting down
the cache while the content is being updated, and starting it again after
the update is complete. Although performance slows down, the server operates
normally when the cache is off.

For performance reasons, Web Server caches as follows:

For small files, it caches the content in memory (heap).

For
medium files, it caches the content using mmap.

For large files, it caches the open file descriptors to avoid opening and closing
files.

The following is an example of how the cache statistics are displayed
in perfdump:

The following table shows the file cache statistics as displayed in
the Admin Console:

Table 2–4 File Cache Statistics

Total Cache Hits

46

Total Cache Misses

52

Total Cache Content Hits

0

Number of File Lookup Failures

9

Number of File Information Lookups

37

Number of File Information Lookup Failures

50

Number of Entries

12

Maximum Cache Size

1024

Number of Open File Entries

0

Number of Maximum Open Files Allowed

1024

Heap Size

36064

Maximum Heap Cache Size

10735636

Size of Memory Mapped File Content

0

Maximum Memory Mapped File Size

0

Maximum Age of Entries

30

Accelerator Entries

The number of files that have been cached in the accelerator cache.

Tuning

You can increase the maximum number of accelerator cache entries by
increasing the number of file cache entries as described in File Cache Entries. Note that this number will typically
be smaller than the File Cache Entries number because the accelerator cache
only caches information about files and not directories. If the number is
significantly lower than the File Cache Entries number, you can improve the
accelerator cache utilization by following the tuning information described
in Acceleratable Requests and Acceleratable Responses.

Acceleratable Requests

The number of client requests that were eligible for processing by the
accelerator cache. Only simple GET requests are processed by the accelerator
cache. The accelerator cache does not process requests that explicitly disable
caching, for example, requests sent when a user clicks Reload in the browser
and requests that include a query string, that is, requests for URLs that
include a ? character.

Tuning

To maximize the number of acceleratable requests, structure your web
sites to use static files when possible and avoid using query strings in requests
for static files.

Acceleratable Responses

The number of times the response to an acceleratable request was eligible
for addition to the accelerator cache.

Tuning

When the server serves a static file from the file cache, the accelerator
cache may be able to cache the response for faster processing on subsequent
requests. To maximize performance, maximize the number of responses
that can be accelerated. In the default configuration, all responses to requests for static
files can be cached in the accelerator cache. The following configuration
changes may prevent a response from being accelerated:

ACLs that deny read access

Additional directives in the default object of the obj.conf file, including third party plug-ins

Using <Client> or <If> in
the default object of the obj.conf file

Custom access log formats

Java Servlet filters

To maximize the number of responses that can be accelerated, avoid
such configurations.

Accelerator Hit Ratio

The number of times the response for a request that can be accelerated was
found in the accelerator cache.
Web Server can also serve requests from the accelerator cache asynchronously
directly from the keep-alive threads thereby bypassing the connection queue
altogether. This leads to improved performance for these requests and at the
same time reduces contention on the connection queue.

Tuning

Higher hit ratios result in better performance. To maximize the hit
ratio, see the tuning information for Acceleratable Responses.

File Cache Enabled

If the cache is disabled, the rest of this section is not displayed
in perdump. In the Admin Console, the File Cache Statistics
section shows zeros for the values.

Tuning

The cache is enabled by default. You can disable it in the Admin Console
by deselecting the File Cache Enabled box on the configuration's Performance
tab ⇒ Cache sub tab, under File Cache. To disable it using the command-line-interface,
use wadm set-file-cache-prop and set the enabled property
to false.

File Cache Entries

The number of current cache entries and the maximum number of cache
entries are both displayed in perfdump. In the Admin Console,
they are called the Number of Entries and the Maximum Cache Size. A single
cache entry represents a single URI.

Tuning

The optimal file
cache size is dependent on whether you are running a 32-bit or a 64-bit server.
The available address space for a 32–bit server is limited to 4GB. The max-entries for file cache is based on the amount of Java heap, the number of
threads (as specified by thread-pool/max-threads),
and the connection queue size. It is recommended to cache small, frequently
accessed static files in the file cache and use perfdump to
ensure that the file cache hit ratio is close to 100%. To achieve this, you
may increase file cache size and fine tune the max-entries for
optimal performance. In a 64-bit server, due to the increased availability
of address space, you can cache more static content in the file cache.

You can set the maximum number of cached entries in the Admin Console
in the Maximum Entries field on the configuration's Performance tab ⇒
Cache tab, under File Cache. In the command-line interface, use wadm
set-file-cache-prop and set the max-entries property.
The default is 1024. The range of values is 1-1048576.

File Cache Hit Ratio (Cache Hits / Cache Lookups)

The hit ratio available through perfdump gives you the number of file cache hits compared to cache lookups.
Numbers approaching 100% indicate that the file cache is operating effectively,
while numbers approaching 0% indicate that the file cache is not
serving many requests.

To figure this number yourself using the statistics provided through
the Admin Console, divide the Total Cache Hits by the sum of the Total Cache
Hits and the Total Cache Misses.

This setting is not tunable.

Maximum Age

This field displays the maximum age of a valid cache entry. The parameter
controls how long cached information is used after a file has been cached.
An entry older than the maximum age is replaced by a new entry for the same
file.

Tuning

Set the maximum age based on whether the content is updated (existing
files are modified) on a regular schedule. For example, if content is updated
four times a day at regular intervals, you can set the maximum age to 21600 seconds
(6 hours). Otherwise, consider setting the maximum age to the longest time
you are willing to serve the previous version of a content file after the
file has been modified. If your web site’s content changes infrequently,
you might want to increase this value for improved performance.

Set the maximum age in the Admin Console in the Maximum Age field on
the configuration's Performance tab ⇒ Cache tab, under File Cache. In
the command-line interface, use wadm set-file-cache-prop and
change the max-age property. The default value is 30 seconds.
The range of values is 0.001-3600.

Maximum Heap Cache Size

The optimal cache heap size depends upon how much system memory is free.
A larger heap size means that the Web Server can cache more content and therefore obtain a better hit ratio.
However, the heap size should not be so large that the operating system starts
paging cached files.

Tuning

Set the maximum heap size in the Admin Console in the Maximum Heap Space
Size field on the configuration's Performance tab ⇒ Cache tab, under
File Cache. In the command-line interface, use wadm set-file-cache-prop and
change the max-heap-space property. The default value is
10485760 bytes. The range of values is 0-9223372036854775807. In a 32–bit
Web Server, since processes have four GBs of address space for the file cache,
the value should be well under four GB.

Using the nocache Parameter

You can use the parameter nocache for the Service function send-file to specify that
files in a certain directory are not cached. Make this
change by editing obj.conf. For example, if you have
a set of files that changes too rapidly for caching to be useful, you can
put them into a directory and instruct the server not to cache files in that
directory by editing obj.conf.

Using
sendfile-size to Pace Large Files

When file-cache/sendfile is set
to true, Web Server uses the operating system sendfile call to service
large static files from the file cache. The performance of serving such files
from the file cache can be improved by limiting the number of bytes sent by
a single sendfile call. Using a non zero value for file-cache/sendfile-size will send the file in chunks,
where the chunk size is at the most the size of sendfile-size.

Tuning

While serving large files, for example, movie files, consider tuning the file-cache/sendfile-size. A sendfile-size of
1MB can provide improved
performance compared to the default sendfile-size of zero.
You can set the sendfile-size in Admin Console by editing
Sendfile Size field on the configuration's Performance tab ⇒ Cache tab,
under File Cache. In the command-line interface, use wadm set-file-cache-prop command's sendfile-size property.

File Cache Dynamic Control and Monitoring

File Cache stores
file contents in the memory. You can add an object to obj.conf to dynamically
monitor and control the file
cache while the server is running.

To Control and Monitor the File Cache

Add a NameTrans directive to the default object:

NameTrans fn="assign-name" from="/nsfc" name="nsfc"

Add an nsfc object definition:

<Object name="nsfc">
Service fn="service-nsfc-dump"
</Object>

This configuration enables the file cache control and monitoring function (nsfc-dump) to be accessed through the URI /nfsc. To use
a different URI, change the from parameter in the NameTrans directive.

The following is an example
of the information you receive when you access the URI:

You can include a query string when you access the URI. The following
values are recognized:

?list: Lists the files in the cache.

?refresh=n: Causes the client to reload the page
every n seconds.

?restart: Causes the cache to be shut down and
then restarted.

?start: Starts the cache.

?stop: Shuts down the cache.

If you choose the ?list option, the file listing
includes the file name, a set of flags, the current number of references to
the cache entry, the size of the file, and an internal file ID value.
The flags are as follows:

C: File contents are cached.

D: Cache entry is marked for delete.

E: PR_GetFileInfo() returned an error for this
file.

I: File information including size and modification date is cached.

M: File contents are mapped into virtual
memory.

O: File descriptor is cached (when TransmitFile is set to true).

P: File has associated private data and appears on shtml files.

T: Cache entry has a temporary file.

W: Cache entry is locked for write access.

Thread Pool Information

If you are using the default settings, threads from the default thread
pool process the request. However, you can also create custom thread pools
and use them to run custom NSAPI functions. By default, Web Server creates
one additional pool, named NativePool. In most cases, the
native thread pool is only needed on the Windows platform. For more information
on thread pools, see Understanding Threads, Processes, and Connections.

Native Thread Pool

The following example shows native thread pool information as it appears
in perfdump:

If you have defined additional custom thread pools, they are shown under
the Native Pools heading in perfdump.

The following table shows the thread pool statistics as they appear
in the Admin Console. If you have not defined additional thread pools, only
the NativePool is shown:

Table 2–5 Thread Pools Statistics

Name

NativePool

Idle Threads

1

Threads

1

Requests Queued

0

Peak Requests Queued

0

Idle /Peak /Limit

Idle, listed as Idle Threads in the Admin Console,
indicates the number of threads that are currently idle. Peak indicates
the peak number of threads in the pool. Limit, listed as
Threads in the Admin Console, indicates the maximum number of native threads
allowed in the thread pool, and for NativePool is determined by the setting
of NativePoolMaxThreads in the magnus.conf file.

Tuning

You can modify the maximum threads for NativePool by editing the NativePoolMaxThreads parameter in magnus.conf. For more information,
see NativePoolMaxThreads Directive.

Work Queue Length /Peak /Limit

These numbers refer to a queue of server requests that are waiting for
the use of a native thread from the pool. The Work Queue Length is
the current number of requests waiting for a native thread, which is represented
as Requests Queued in the Admin Console.

Peak indicates peak requests queued
in the Admin Console and is the highest number of requests
that were ever queued up simultaneously for the use of a native thread since
the server was started. This value can be viewed as the maximum concurrency
for requests requiring a native thread.

Limit is the maximum number of requests that
can be queued at one time to wait for a native thread, and is determined by
the setting of NativePoolQueueSize.

Tuning

You can modify the queue size for NativePool by editing the NativePoolQueueSize directive in magnus.conf. For more information,
see NativePoolQueueSize Directive.

NativePoolStackSize Directive

The NativePoolStackSize determines the stack size
in bytes of each thread in the native (kernel) thread pool.

Tuning

You can modify the NativePoolStackSize by editing
the NativePoolStackSize directive in magnus.conf.

NativePoolQueueSize Directive

The NativePoolQueueSize determines the number of
threads that can wait in the queue for the thread pool. If all threads in
the pool are busy, then the next request-handling thread that needs to use
a thread in the native pool must wait in the queue. If the queue is full,
the next request-handling thread that tries to get in the queue is rejected,
with the result that it returns a busy response to the client. It is then
free to handle another incoming request instead of being tied up waiting in
the queue.

Setting the NativePoolQueueSize lower than the maximum threads value causes the server to execute a busy function
instead of the intended NSAPI function whenever the number of requests waiting
for service by pool threads exceeds this value. The default returns a “503
Service Unavailable” response and logs a message, depending on your
log level setting. Setting the NativePoolQueueSize higher
than the maximum threads causes the server to reject connections before a
busy function can execute.

This value represents the maximum number of concurrent requests for
service that require a native thread. If your system is unable to fulfill
requests due to load, allowing more requests queue up increases the latency for requests, and
could result in all available request threads waiting for a native thread.
In general, set this value to be high enough to avoid rejecting requests by
anticipating the maximum number of concurrent users who would execute requests
requiring a native thread.

The difference between this value and the maximum threads is the number
of requests reserved for non-native thread requests, such as static HTML and
image files. Keeping a reserve and rejecting requests ensures that your server
continues to fill requests for static files, which prevents it from becoming
unresponsive during periods of very heavy dynamic content load. If your server
consistently rejects connections, this value is either set too low, or your
server hardware is overloaded.

Tuning

You can modify the NativePoolQueueSize by editing
the NativePoolQueueSize directive in magnus.conf.

NativePoolMaxThreads Directive

NativePoolMaxThreads determine the maximum number
of threads in the native (kernel) thread pool.

A higher value allows more requests to execute concurrently, but has
more overhead due to context switching, so bigger is not always better. Typically,
you do not need to increase this number, but if the CPU is not saturated and you see requests
queue up, then increase this number.

Tuning

You can modify the NativePoolMaxThreads by editing
the NativePoolMaxThreads parameter in magnus.conf.

NativePoolMinThreads Directive

Determines the minimum number of threads in the native (kernel) thread
pool.

Tuning

You can modify the NativePoolMinThreads by editing
the NativePoolMinThreads parameter in magnus.conf.

DNS Cache Information

The DNS cache caches IP addresses and DNS names. Web Server uses DNS
caching for logging and for access control by IP address. DNS cache is enabled
by default. The following example shows DNS cache information as displayed
in perfdump:

The following example shows the DNS Cache information as displayed in
the Admin Console:

Table 2–6 DNS Cache Statistics

Total Cache Hits

62854802

Total Cache Misses

6110

Number of Asynchronous Lookups

0

Lookups in Progress

4

Asynchronous Lookups Enabled

1

Number of Asynchronous Address Lookups Performed

0

Enabled

If the DNS cache is disabled, the rest of this section is not displayed
in perfdump. In the Admin Console, the page displays zeros.

Tuning

By default, the DNS cache is on. You can enable or disable DNS caching
in the Admin Console on the configuration's Performance tab ⇒ DNS sub
tab, under DNS Cache Settings and selecting or deselecting the DNS Cache Enabled
box. To enable or disable it using the command-line-interface, use wadm
set-dns-cache-prop and set the enabled property.

Cache Entries (Current Cache Entries / Maximum Cache
Entries)

This section in perfdump shows the number of current
cache entries and the maximum number of cache entries. In the Admin Console
the current cache entries are shown as Total Cache Hits. A single cache entry
represents a single IP address or DNS name lookup. The cache should be as
large as the maximum number of clients that access your web site concurrently.
Note that setting the cache size too high wastes memory and degrades performance.

Tuning

You can set the maximum size of the DNS cache in the Admin Console in
the Maximum Cache Size field on the configuration's Performance tab ⇒
DNS sub tab, under DNS Cache Settings. To set it using the command-line-interface,
use wadm set-dns-cache-prop and set the max-entries property.
The default cache size is 1024. The value range is 2-32768.

Hit Ratio of Cache Hits and Lookups

The hit ratio in perfdump displays the number of
cache hits compared to the number of cache lookups. You can compute this number
using the statistics in the Admin Console by dividing the Total Cache Hits
by the sum of the Total Cache Hits and the Total Cache Misses.

This setting is not tunable.

Async DNS Enabled/Disabled

Async DNS enabled/disabled displays whether the server uses its own
asynchronous DNS resolver instead of the operating system's synchronous resolver.
By default, Async DNS is disabled. If it is disabled, this section does not
appear in perfdump. To enable it using the Admin Console,
on the configuration's Performance tab ⇒ DNS tab, under DNS Lookup Settings,
select Asynchronous DNS. To enable it using the command-line interface, use wadm set-dns-prop and set the async property
to true.

Java Virtual Machine (JVM) Information

JVM statistics are displayed through the Admin Console, the CLI, and stats-xml only. They are not shown in perfdump.

The following table shows an example of the JVM statistics displayed
in the Admin Console:

Table 2–7 Java Virtual Machine (JVM) Statistics

Virtual Machine Name

Java HotSpotTM Server VM

Virtual Machine Vendor

Sun Microsystems Inc.

Virtual Machine Version

1.5.0_06-b05

Heap Memory Size

5884856

Elapsed Garbage Collection Time (milli seconds)

51

Present Number of Classes Loaded

1795

Total Number of Classes Loaded

1795

Total Number of Classes Unloaded

0

Number of Garbage Collections Occurred

3

Number of Live Threads

8

Number of Started Threads

9

Peak Live Thread Count

8

Most of these statistics are not tunable. They provide information about
the JVM's operation.

Java Heap Tuning

As with all Java programs, the performance of the web applications in
the Web Server is dependent on the heap management performed by the JVM. Balancing times and throughput is a challenge. For more
information, read the performance documentation for the Java HotSpot virtual machine,
which can be found at http://java.sun.com/docs/hotspot/index.html.

JDBC Resource Information

A JDBC resource is a named group of JDBC connections to a database.
A JDBC resource defines the properties used to create a connection pool. Each
JDBC resource uses a JDBC driver to establish a connection to a physical database
when the server is started. A pool of connections is created when the first
request for connection is made on the pool after you start Web Server.

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 use 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.

Each defined pool is instantiated during Web Server startup. However,
the connections are only created the first time the pool is accessed. Jump-start a pool before
putting it under heavy load.

JDBC resource statistics are available through the Admin Console, CLI,
and stats.xml only. They are not shown in perfdump.
Some of the monitoring data is unavailable through the Admin Console and can
only be viewed through the CLI using wadm get-config-stats and
through the stats.xml output.

A pool is created on demand, that is, it is created the first time it
is used. The monitoring statistics are not displayed until the first time
the pool is used.

JDBC Resource Statistics Available Through the Admin
Console

The following table shows an example of the JDBC resource statistics
displayed through the Admin Console:

Table 2–9 JDBC Resource Statistics

Connections

32

Free Connections

0

Leased Connections

32

Average Queue Time

1480.00

Queued Connections

40

Connection Timeout

100

To change the settings for a JDBC resource through the Admin Console,
for the configuration, choose the Java tab ⇒ Resources sub tab. Select
the JDBC resource. The settings are available on the Edit JDBC Resource page.
To change the JDBC resource through the command-line-interface, use wadm
set-jdbc-resource-prop.

Connections

This number shows the current JDBC connections, including both free
and busy connections.

Tuning – This setting cannot
be tuned, but it is a good indicator of recent pool activity. If the number
of connections is consistently higher than the minimum number of connections,
consider increasing the minimum number of connections to be closer to the
number of current JDBC connections. To change the minimum connections for
a JDBC resource through the Admin Console, on the Edit JDBC Resources page,
edit the Minimum Connections setting. To change the JDBC resource's minimum
connections through the command-line-interface, use wadm set-jdbc-resource-prop and change the min-connections property.

Free Connections

This number shows the current number of free connections in the pool.
All free connections over the minimum pool size are closed if they are idle
for more than the maximum idle timeout. The free connections are not tunable.

Leased Connections

This number shows the current number of connections in use.

Tuning – If number of leased
connections is consistently lower than the minimum connections, consider reducing
the minimum connections for the JDBC resource. If number of leased connections
is consistently higher than minimum connections, consider increasing the minimum
connections. If number of leased connections is consistently at the JDBC resource's
maximum number of connections, consider increasing the maximum number of connections.
The upper limit for the number of leased connections is the number of maximum
connections.

To change the minimum or maximum connections for a JDBC resource through
the Admin Console, on the Edit JDBC Resource page, edit the Minimum Connections
or Maximum Connections fields. To change the JDBC resource's minimum or maximum
connections through the command-line-interface, use wadm set-jdbc-resource-prop and change the min-connections or max-connections properties.

Queued Connections

This number shows the current number of requests for connections that
are waiting to receive a connection from the JDBC pool. Connection requests
are queued if the current number of leased connections has reached the maximum
connections.

Tuning – If this number is
consistently greater than zero, consider increasing the JDBC resource's maximum
connections. To change the maximum connections for a JDBC resource through
the Admin Console, edit the Maximum Connections
field on the Edit JDBC
Resource page. To change the JDBC resource's maximum connections
through the command-line-interface, use wadm set-jdbc-resource-prop and
change the max-connections property.

JDBC Resource Statistics Not Available in the Admin
Console

Some JDBC statistics are available through the wadm get-config-stats command using the --node option, through stats-xml,
and through SNMP, but not through the Admin Console.

maxConnections – The
configured maximum size of the pool. Use as a reference for other statistics.
To change the maximum connections for a JDBC resource through the Admin Console,
on the Edit JDBC Resource page, edit the Maximum Connections field. To change
the JDBC resource's maximum connections through the command-line-interface,
use wadm set-jdbc-resource-prop and change the max-connections property.

peakConnections – The
highest number of connections that have been leased concurrently during the
history of the pool. This number is a good indication on the upper limit on
pool usage. It is limited by the maximum connections setting.

countTotalLeasedConnections –
The total number of times a connection has been handed out by the pool. Indicates
total pool activity. Not tunable.

countTotalFailedValidationConnections –
If connection validation is enabled, shows the number of times a connection
has been detected as invalid by the pool. If this number is relatively high,
it could signal database or network problems. Not tunable.

peakQueued – The highest number
of connection requests that have been queued simultaneously at any time during
the lifetime of the pool. Not tunable.

millisecondsPeakWait – The
maximum time in milliseconds that any connection request has been in the wait
queue. A high number is an indication of high pool activity. The upper limit
is the JDBC resource setting wait timeout.

countConnectionIdleTimeouts –
The number of free connections that have been closed by the pool because they
exceeded the configured JDBC idle timeout. To change the idle timeout for
a JDBC resource through the Admin Console, on the Edit JDBC Resource page,
edit the Idle Timeout field. To change the JDBC resource's idle timeout through
the command-line-interface, use wadm set-jdbc-resource-prop and
change the idle-timeout property.

The size
the pool keeps during the life of the server instance, and 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, to minimize creation of connections during
the life of the application and minimize pool resizing. Use a lower number
if the pool load is expected to be small, to minimize resource consumption.

Maximum connections

The maximum
number of connections that a pool can have at any given time. Defaults to
32. Use this setting 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.

Idle timeout

The maximum amount
in seconds that a connection is ensured to remain unused in the pool. After
the idle timeout, connections are automatically closed. If necessary, new
connections are created up to the minimum number of connections to replace
the closed connection. Note that this setting does not control connection
timeouts enforced at the database server side. Defaults to 60 seconds.

Setting this attribute to –1 prevents the connections from being
closed. This setting is used for pools that expect continuous high demand. Otherwise, keep this
timeout shorter than the database server-side timeout (if such timeouts are
configured on the specific vendor database), to prevent accumulation of unusable
connections in the pool.

Wait timeout

The amount of time
in seconds that a request waits for a connection in the queue before timing
out. After this timeout, the user sees an error. Defaults to 60.

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

Validation method

The method used by the pool to determine the health of a connections
in the pool. Defaults to off.

If a validation method is used,
the pool executes a sanity check on a connection before leasing it to an application.

The effectiveness and performance impact depends on the method selected:

meta-data is less expensive than table in
terms of performance, but usually less effective as most drivers cache the
result and do not use the connection, providing false results.

table is almost always effective, as it forces
the driver to perform an SQL call to the database, but it is also the most
costly.

auto-commit can provide the best balance of
effectiveness and performance cost, but a number of drivers also cache the
results of this method.

Validation Table Name

The
user-defined table to use for validation when the validation method is table. Defaults to test.

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

Fail All Connections

Indicates
whether all connections in the pool are re-created when one is found to be
invalid, or only the invalid one. Only applicable if you have selected a connection
validation method. Disabled by default.

If enabled, all of the
re-creation is done in one step, and the thread requesting the connection
is heavily affected. If disabled, the load of re-creating connections is
distributed between the threads requesting each connection.

Transaction Isolation Level

Specifies the Transaction Isolation Level on the pooled database connections.

By default, the default isolation level of the connection is
left intact. Setting it to any value does incur the small performance penalty
caused by the method call.

Guarantee Isolation

Only applicable
if a transaction isolation level is specified. Defaults to disabled.

Leaving this setting disabled causes the isolation level to be set only
when the connection is created. Enabling sets the level every time the connection
is leased to an application. In most cases, leave this setting disabled.

Tuning the ACL User Cache

The ACL user cache is active by default. Because
of the default size of the cache (200 entries), the ACL user cache can be
a bottleneck, or can simply not serve its purpose on a site with heavy traffic.
On a busy site, more than 200 users can hit ACL-protected resources in less
time than the lifetime of the cache entries. When this situation occurs, Web
Server must query the LDAP server more often to validate users, which impacts
performance.

This bottleneck can be avoided by increasing the maximum users
of the ACL cache on the configuration's Performance tab ⇒ Cache sub tab.
You can also set the number of users by setting the max-users property
using the command wadm set-acl-cache-prop. Note that increasing
the cache size uses more resources; the larger you make the cache, the more
RAM you'll need to hold it.

There can also be a potential (but much harder to hit) bottleneck with
the number of groups stored in a cache entry (four by default). If a user
belongs to five groups and hits five ACLs that check for these different groups
within the ACL cache lifetime, an additional cache entry is created to hold
the additional group entry. When there are two cache entries, the entry with
the original group information is ignored.

While it would be extremely unusual to hit
this possible performance problem, the number of groups cached in a single
ACL cache entry can be tuned with Maximum Groups setting on the configuration's
Performance tab ⇒ Cache sub tab. Or you can use the max-groups-per-user property of the wadm set-acl-cache-prop command.

The maximum age setting of the ACL cache determines the number
of seconds before the cache entries expire. Each time an entry in the cache
is referenced, its age is calculated and checked against the maximum age setting.
The entry is not used if its age is greater than or equal to the maximum age.
The default value is 120 seconds. If your LDAP is not likely to change often,
use a large number for the maximum age. However, if your LDAP entries change
often, use a smaller value. For example, when the value is 120 seconds, the
Web Server might be out of sync with the LDAP server for as long as two minutes.
Depending on your environment, that might or might not be a problem.

Tuning Java Web Application Performance

This section contains information to help you improve the performance
of your Java Web Applications. This section includes the following topics:

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 don't change, you can improve performance by pre-compiling your JSPs.

When adding a web application, either through the Admin Console or CLI,
choose the precompile JSPs option. Enabling precompiled JSPs allows all the
JSPs present in the web application to be pre-compiled, and their corresponding
servlet classes are grouped in the web application's WEB-INF/lib or WEB-INF/classes directory. When a JSP is accessed, it is not compiled
and instead, its pre-compiled servlet is used. For more information on JSPs, see Sun Java System Web Server 7.0 Update 4 Developer’s Guide to Java Web Applications.
Also see 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. This
is useful for common queries that all visitors to your site run: you want
the results of the query to be dynamic because the results might change daily, but you
don't need to run the logic for every user.

Configuring the Java Security Manager

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

Configuring Class Reloading

The dynamic
reload interval of the servlet container and the dynamic-reload-interval of the class-loader element in sun-web.xml control 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.

Set the dynamic reload interval on the configuration's Java tab ⇒
Servlet Container sub tab, or using the wadm set-servelt-container-props command. In a production environment where changes are made in
a scheduled manner, set this value to 0 to prevent the server from constantly
checking for updates. The default value is 0 (that is, class reloading is
disabled). For more information about elements in sun-web.xml,
see Sun Java System Web Server 7.0 Update 4 Developer’s Guide to Java Web Applications.

Avoiding Directories in the Classpath

For certain applications and especially if the Java Security Manager
is enabled
you can improve performance by ensuring that there are no unneeded directories
in the classpath. To do so, change the Server Class Path, Class Path Prefix,
and Class Path Suffix fields on the configuration's Java tab ⇒ General
sub tab for the configuration or use the command wadm set-jvm-prop.
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 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 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.

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

Note –

For Java technology-enabled servers, multi-process mode is deprecated
and included for backward-compatibility only.

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) contend for the
same lock. Increasing maxLocks reduces the number of sessions
that contend for the same lock and might 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.

This example creates 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 the
increase in process size.

Tuning CGI Stub Processes (UNIX/Linux)

In Web Server, the CGI engine creates CGI stub processes as needed.
On systems that serve a large load and rely heavily on CGI-generated content,
it is possible for the CGI stub processes to consume all system resources.
If this happens on your server, the CGI stub processes can be tuned to restrict
how many new CGI stub processes can be spawned, their timeout value, and the
minimum number of CGI stub process that run at any given moment.

Note –

If you have an init-cgi function
in the magnus.conf file running in multi-process mode,
you must add LateInit
= yes to the init-cgi line.

Tune the following settings to control CGI stubs. These settings are
on the configuration's Performance Tab ⇒ CGI sub tab.

Minimum Stubs Size: Controls the number of processes that
are started by default. The first CGI stub process is not started until a
CGI program has been accessed. The default value is 0. If you have an init-cgi directive in the magnus.conf file, the minimum
number of CGI stub processes are spawned at startup.

Maximum Stub Size: Controls the maximum number of CGI stub
processes the server can spawn. This is the maximum concurrent CGI stub processes
in execution, not the maximum number of pending requests. The default value
is 16 and should be adequate for most systems. Setting this value too high might actually
reduce throughput.

CGI Stub Timeout: Causes the server to kill any CGI stub processes
that have been idle for the number of seconds set by this directive. Once
the number of processes is at the minimum stubs size, it does not kill any
more processes. The default is 30.

CGI Timeout: Limits the maximum time in seconds that CGI processes
can run. The default is –1, which means there is no timeout.

Using find-pathinfo-forward

The find-pathinfo-forward parameter used in obj.conf can help improve performance. It is used with the PathCheck function find-pathinfo and the NameTrans functions pfx2dir and assign-name.
The find-pathinfo-forward parameter instructs the server
to search forward for PATH_INFO in the path after ntrans-base, instead of backward from the end
of the path in the server function find-pathinfo. The find-pathinfo-forward parameter
is not supported within the Admin GUI. So, users need to manually edit the
corresponding obj.conf file and upload the changes to
the admin config repository.

Note –

The server ignores the find-pathinfo-forward parameter
if the ntrans-base parameter
is not set in rq->vars when the server function find-pathinfo is called. By default, ntrans-base is set.

This feature can improve performance for certain URLs by doing fewer
stats in the server function find-pathinfo. On the Windows platform, you can also
use this feature to prevent the server from changing "\\" to "/" when using
the PathCheck server function find-pathinfo.

In the previous example, the server does not obtain statistics for path /ntrans-base/nsfc and /ntrans-base/nsfc/* if ntrans-base is
set. If ntrans-base is not set, the server does
not obtain statistics for URLs /nsfc and /nsfc/*. By default, ntrans-base is set. The example assumes the default PathCheck server
functions are used.

When you use nostat= virtual-path in
the assign-nameNameTrans, the server
assumes that the statistics on the specified virtual-path will fail.
Therefore, use nostat only when the path of the virtual-path does not exist on the system, for example, in NSAPI plug-in
URLs. Using nostat on those URLs improves performance by
avoiding unnecessary statistics on those URLs.

Using Busy Functions

The default busy function returns a "503 Service Unavailable" response
and logs a message depending upon the log level setting. You might want to
modify this behavior for your application. You can specify your own busy functions
for any NSAPI function in the obj.conf file by including
a service function in the configuration file in this format:

busy="my-busy-function"

For example, you could use this sample service function:

Service fn="send-cgi" busy="service-toobusy"

This function allows different responses if the server become too busy in the
course of processing a request that includes a number of types (such as Service, AddLog, and PathCheck). Note
that the busy function
applies to all functions that require a native thread to execute when the
default thread type is non-native.

To use your own busy function instead of the default busy function for
the entire server, you can write an NSAPI init function
that includes a func_insert call as shown below:

Busy functions are never executed on a pool thread, so you must be careful
to avoid using function calls that could cause the thread to block.

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:

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.

Java Server Page and Servlet Tuning

This section describes how to improve performance of web 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.

Do not 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 which is 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.

This section describes how to improve performance of web applications,
through deployment and configuration settings.

Deployment Settings

Deployment settings can have significant impact on performance. Follow
these guidelines when configuring deployment settings for best performance:

Use Pre-compiled JavaServer Pages

Disable Dynamic Application Reloading

Use Pre-compiled JavaServer Pages

Compiling JSP files is resource intensive and time consuming. Precompiling
JSP files before deploying applications on the server will improve application
performance. When you compile
in advance, only the resulting servlet class files
will be deployed.

You can specify on
the server to pre-compile JSP files when you deploy an application
through the Admin Console,through CLI
or GUI.
You can also specify on
the server to pre-compile JSP files for an already deployed
application with the Admin Console.

Disable Dynamic Application Reloading

If dynamic reloading is enabled, the server periodically checks for
changes in deployed applications and automatically reloads the application
with the changes. Dynamic reloading is intended for development environments
and is also incompatible with session persistence. To improve performance,
disable dynamic class reloading.

Disable dynamic class reloading for an application

Remove .reload from the web application directory.

Disable Dynamic JSP Reloading

On a production system, improve web container performance by disabling
dynamic JSP reloading. To do so, edit the default-web.xml file in the config
directory for each instance. Change the servlet definition for a JSP file
to look like this:

The suggested manual changes requires you to run either pull-config through the CLI or the Admin Console.

Logger Settings

The Server produces writes log messages and exception stack trace output
to the log file in the logs directory of the instance, Naturally, the volume
of log activity can impact server performance; particularly in benchmarking
situations.

Managing Memory and Garbage Collection

The efficiency of any application depends on how well memory and garbage
collection are managed. The following sections provide information on optimizing
memory and allocation functions:

Goals

Tracing Garbage Collection

Other Garbage Collector Settings

Tuning the Java Heap

Re-basing DLLs on Windows

Tuning the Garbage Collector

Monitoring the Garbage Collection (GC) activity at the development server
and accordingly tuning JVM and GC settings before deploying the server into
production is necessary. The GC settings vary depending on the application
you are running.

Garbage collection reclaims the heap space previously allocated to objects
no longer needed. The process of locating and removing the dead objects can
stall any application and consume as much as 25 percent throughput.

Other Garbage Collector Settings

Almost all Java Runtime Environments come with a generational object
memory system and sophisticated GC algorithms. A generational memory system
divides the heap into a few carefully sized partitions called generations.
The efficiency of a generational memory system is based on the observation
that most of the objects are short lived. As these objects accumulate, a low
memory condition occurs forcing GC to take place.

Tuning the Java Heap

The heap space is divided into old and the new generations. The new generation includes
the new object space (eden), and two survivor spaces. The JVM allocates new
objects in the eden space, and moves longer lived objects from the new generation
to the old generation. Keep the heap size low, so that customers
can increase the heap size depending on their needs. To increase the heap
size, refer to the link, http://www.devx.com/tips/Tip/5578

The young generation uses a fast copying garbage collector which employs
two semi-spaces (survivor spaces) in the eden, copying surviving objects from
one survivor space to the second. Objects that survive multiple young space
collections are tenured, meaning they are copied to the tenured generation.
The tenured generation is larger and fills up less quickly. Garbage is collected less frequently;
and each collection takes longer than a young space only collection. Collecting
the tenured space is also referred to as doing a full generation collection.

The frequent young space collections are quick, lasting only a few milliseconds, while the full generation
collection takes a longer, tens
of milliseconds to a few seconds, depending upon the heap size. Other GC algorithms,
such as the Concurrent Mark Sweep (CMS) algorithm, are incremental. They divide
the full GC into several incremental pieces. This provides a high probability
of small pauses. This process comes with an overhead and is not required for
enterprise web applications.

When the new generation fills up, it triggers a minor collection in
which the surviving objects are moved to the old generation. When the old
generation fills up, it triggers a major collection which involves the entire
object heap.

Both HotSpot and Solaris JDK use thread local object allocation pools
for lock-free, fast, and scalable object allocation. So custom object pooling
is not often required. Consider pooling only if object construction cost is
high and significantly affects execution profiles.

The -Xms and -Xmx parameters define the minimum and maximum heap size. As collections
occur when generations fill up, throughput is inversely proportional to the
available memory. By default, JVM grows or shrinks the heap at each collection.
This helps maintain the proportion of free space to living object at each
collection within a specific range. The range is set as a percentage by the
parameters -XX:MinHeapFreeRatio=<minimum> and -XX:MaxHeapFreeRatio=<maximum>; and the total size is bound by -Xms and -Xmx.

JVM heap setting for Web Server should be based on
the available memory on the system and frequency and duration of garbage collection.
You can use -verbose:gc jvm option or the J2SE 5.0 monitoring
tools to determine the frequency of garbage collection. For more information
on J2SE 5.0 monitoring tools, see J2SE 5.0 Monitoring Tools. The maximum heap size should be determined based on the process
data model (32-bit or 64-bit) and availability of virtual and physical memory
on the system. Excessive use of physical memory for Java heap may cause paging
of virtual memory to disk during garbage collection, resulting in poor performance.
For more information on Java tuning, see http://java.sun.com/performance/reference/whitepapers/tuning.html.

Choosing the Garbage Collection Algorithm

This section describes how to use different garbage collector within
Web Server.

CMS Collector

Use the CMS collector as the GC algorithm. This collector can cause
a drop in throughput for heavily utilized systems, because it is running constantly, but it prevents the long
pauses that can occur when the garbage collector runs infrequently.

Procedure to use the CMS collector:

Shut down the server.

Configure the CMS collector in the server instance.

add
the following JVM options either using the Admin Console or by using the CLI:

-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=1

Use the jvmstat utility to monitor HotSpot garbage
collection.

For detailed information on tuning the garbage collector, see Tuning
Garbage Collection with the 5.0 Java Virtual Machine. See .

Tracing Garbage Collection

The two primary measures of garbage collection performance are throughput
and pauses. Throughput is the percentage of the total time spent on other
activities apart from GC. Pauses are times when an application appears unresponsive
due to GC.

Two other considerations are footprint and promptness. Footprint is
the working size of the JVM process, measured in pages and cache lines. Promptness
is the time between when an object becomes dead, and when the memory becomes
available.

This is an important consideration for distributed systems. A particular
generation size makes a trade-off between these four metrics. For example,
a large young generation likely maximizes throughput, but at the cost of footprint
and promptness.

J2SE
5.0 Monitoring Tools

J2SE 5.0 supports tools that can be used to provide information on performance
and resource consumption for running applications. Two commonly used tools, jconsole and jstat, are discussed in this section.

The binary is available in $JAVA_HOME/bin directory.
Specify the pid in the command line when invoking the tool.
The pid of the Web Server process is obtained either from
the log file or by locating the child webservd process.

You may also invoke jconsole without the pid argument
and then select the appropriate VM from the window displaying available VMs.

jstat

Thejstat utility can be used to tune the Java heap
size and diagnose performance issues related to heap and garbage collection.
This utility can be used without any server configuration changes as the VM
instrumentation is enabled by default. For more information, see http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html.

Log Levels

Set the log level for the server and its subsystems in the Admin Console
Logger Settings page, Log Levels tab.

Log levels vary from FINEST, which provides maximum log information,
through SEVERE, which logs only events that interfere with normal program
execution. The default log level is INFO.