test

Sun Java System Web Server 7.0 Update 3 Performance Tuning, Sizing, and Scaling Guide

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:

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:

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            0/1853/160032
Total Connections Queued                   11222922
Average Queue Length (1, 5, 15 minutes)    90.35, 89.64, 54.02
Average Queueing Delay                     4.80 milliseconds

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:

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:

ListenSocket ls1:
------------------------
Address                   https://0.0.0.0:2014
Acceptor Threads          1
Default Virtual Server    https-test

If you have created multiple HTTP listeners, perfdump displays all of them.

To edit an HTTP listener using the Admin Console, for the configuration, select the HTTP Listeners tab. Click the listener name to edit the listener.

To configure an HTTP listener using the command-line interface, use the command wadm set-http-listener-prop.

For more information about adding and editing listen sockets, see the Sun Java System Web Server 7.0 Update 3 Administrator’s Guide.

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:

KeepAliveInfo:
--------------------
KeepAliveCount        198/200
KeepAliveHits         0
KeepAliveFlushes      0
KeepAliveRefusals     56844280
KeepAliveTimeouts     365589
KeepAliveTimeout      10 seconds

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 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:

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:

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): 

./wadm set-http-prop --user=admin-user --password-file=admin-password-file 
--config=config-name output-buffer-size=16384
./wadm deploy-config --user=admin-user --password-file=admin-password-file
 --config=config-name

The following example shows setting the buffer size for the nsapi_test Service function:

<Object name="nsapitest">
 ObjectType fn="force-type" type="magnus-internal/nsapitest"
 Service method=(GET) type="magnus-internal/nsapitest" fn="nsapi_test"
 UseOutputStreamSize=12288
</Object>

Session Creation and Thread Information

Session (thread) creation statistics are displayed in perfdump as follows:

SessionCreationInfo:
------------------------
Active Sessions           128
Keep-Alive Sessions       0
Total Sessions Created    128/128

Active Sessions shows the number of sessions (request processing threads) currently servicing requests.

Keep-Alive Sessions shows the number of HTTP request processing threads serving keep-alive sessions.

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 perfdump Active 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.

For information about using SNCA, see Using the Solaris Network Cache and Accelerator (SNCA).

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:

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

CacheInfo:
------------------
File Cache Enabled       yes
File Cache Entries       141/1024
File Cache Hit Ratio     652/664 ( 98.19%)
Maximum Age              30
Accelerator Entries      120/1024
Acceleratable Requests   281/328 ( 85.67%)
Acceleratable Responses  131/144 ( 90.97%)
Accelerator Hit Ratio    247/281 ( 87.90%)

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:

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.

Example

<Object name=default>
...
NameTrans fn="pfx2dir" from="/myurl" dir="/export/mydir"
name="myname"
...
Service method=(GET|HEAD|POST) type=*~magnus-internal/*
fn=send-file
...
</Object>
<Object name="myname">
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file
nocache=""
</Object>

In the previous example, the server does not cache static files from /export/mydir/ when requested by the URL prefix /myurl. For more information on editing obj.conf, see Sun Java System Web Server 7.0 Update 3 Administrator’s Configuration File Reference.

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.

ProcedureTo Control and Monitor the File Cache

  1. Add a NameTrans directive to the default object:

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

  2. 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:


    Sun Java System File Cache Status (pid 3602)

The file cache is enabled.
Cache resource utilization

Number of cached file entries = 174968 (152 bytes each, 26595136 total bytes)
Heap space used for cache = 1882632616/1882632760 bytes
Mapped memory used for medium file contents = 0/1 bytes
Number of cache lookup hits = 47615653/48089040 ( 99.02 %)
Number of hits/misses on cached file info = 23720344/324195
Number of hits/misses on cached file content = 16247503/174985
Number of outdated cache entries deleted = 0
Number of cache entry replacements = 0
Total number of cache entries deleted = 0

Parameter settings

ReplaceFiles: false
ReplaceInterval: 1 milliseconds
HitOrder: false
CacheFileContent: true
TransmitFile: false
MaxAge: 3600 seconds
MaxFiles: 600000 files
SmallFileSizeLimit: 500000 bytes
MediumFileSizeLimit: 1000001 bytes
BufferSize: 8192 bytes

CopyFiles: false
Directory for temporary files: /tmp
Hash table size: 1200007 buckets

    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:

Native pools:
----------------------------
NativePool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0
my-custom-pool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0

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:

DNSCacheInfo:
------------------
enabled             yes
CacheEntries        4/1024
HitRatio            62854802/62862912 ( 99.99%)

AsyncDNS Data:
------------------
enabled             yes
NameLookups         0
AddrLookups         0
LookupsInProgress   0

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.

Another source of tuning information on the JVM is the package java.lang.management, which provides the management interface for monitoring and management of the JVM. For more information on this package, see http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/package-summary.html.

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.

Specific documents of interest include “Tuning Garbage Collection with the 5.0 Java Virtual Machine” and “Ergonomics in the 5.0 Java Virtual Machine”.

JVM options can be specified in the Admin Console on the configuration's Java tab ⇒ JVM Settings sub tab. In the CLI, use the wadm commands set-jvm-prop and set-jvm-profiler-prop.

Web Application Information

Web application statistics are displayed through the Admin Console, wadm get-config-stats command), and stats-xml only. They are not shown in perfdump.

ProcedureTo Access Web Application Statistics From the Admin Console

  1. From the Common Tasks page, choose the Monitoring tab.

  2. Click the configuration name to view web application statistics for the configuration. To view web application statistics for the instance, click the Instance sub tab and the instance name.

  3. On the Monitoring Statistics page, click Virtual Server Statistics.

  4. Click the virtual server name.

  5. On the Virtual Server Monitoring Statistics page, click Web Applications.

  6. Select the web application for which to view statistics from the Web Application pull-down menu.

Web Application Statistics

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

Table 2–8 Web Application Statistics

Number of JSPs Loaded 

1 

Number of JSPs Reloaded 

1 

Total Number of Sessions Serviced 

2 

Number of Sessions Active 

2 

Peak Number of Active Sessions 

2 

Number of Sessions Rejected 

0 

Number of Sessions Expired 

0 

Average Time (seconds) that expired sessions had been alive 

0 

Longest Time (seconds) for which an expired session was alive 

0 

For more information on tuning, see Tuning Java Web Application Performance. Also see Sun Java System Web Server 7.0 Update 3 Developer’s Guide to Java Web Applications.

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:

JDBC resources can be created and edited using the Admin Console's Java tab ⇒ Resources sub tab for the configuration. You can also use the wadm create-jdbc-resource and set-jdbc-resource-prop commands. For more information, see the Sun Java System Web Server 7.0 Update 3 Administrator’s Guide.

Note –

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.

JDBC Resource Connection Settings

Depending on your application’s database activity, you might need to size JDBC resource connection pool settings. Attributes of a JDBC resource which affect performance are listed below, along with performance considerations when setting values.