JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1 Performance Tuning Guide
search filter icon
search icon

Document Information

Preface

1.  Overview of GlassFish Server Performance Tuning

2.  Tuning Your Application

3.  Tuning the GlassFish Server

Using the GlassFish Server Performance Tuner

Deployment Settings

Disable Auto-Deployment

Use Pre-compiled JavaServer Pages

Disable Dynamic Application Reloading

Logger Settings

General Settings

Log Levels

Web Container Settings

Session Properties: Session Timeout

Manager Properties: Reap Interval

Disable Dynamic JSP Reloading

EJB Container Settings

Monitoring the EJB Container

Tuning the EJB Container

Overview of EJB Pooling and Caching

Tuning the EJB Pool

EJB Pool Settings

Tuning the EJB Cache

EJB Cache Settings

Pool and Cache Settings for Individual EJB Components

Commit Option

Determining the Best Commit Option

Java Message Service Settings

Transaction Service Settings

Monitoring the Transaction Service

Viewing Monitoring Information

Tuning the Transaction Service

Disable Distributed Transaction Logging

Recover On Restart (Automatic Recovery)

Keypoint Interval

HTTP Service Settings

Monitoring the HTTP Service

DNS Cache Information (dns)

Enabled

CacheEntries (CurrentCacheEntries / MaxCacheEntries)

HitRatio

Caching DNS Entries

Limit DNS Lookups to Asynchronous

Enabled

NameLookups

AddrLookups

LookupsInProgress

File Cache Information (file-cache)

Keep Alive (keep-alive)

Connection Queue

HTTP Service Access Logging

Network Listener Settings

General Settings

HTTP Settings

Max Connections

DNS Lookup Enabled

Timeout

Header Buffer Length

File Cache Settings

Max File Count

Max Age

Transport Settings

Thread Pool Settings

Max Thread Pool Size

Min Thread Pool Size

ORB Settings

Overview

How a Client Connects to the ORB

Monitoring the ORB

Connection Statistics

Thread Pools

Tuning the ORB

Tunable ORB Parameters

ORB Thread Pool Parameters

Client ORB Properties

Controlling Connections Between Client and Server ORB

Load Balancing

Thread Pool Sizing

Examining IIOP Messages

Resource Settings

JDBC Connection Pool Settings

Monitoring JDBC Connection Pools

Tuning JDBC Connection Pools

Pool Size Settings

Timeout Settings

Isolation Level Settings

Connection Validation Settings

Connector Connection Pool Settings

Transaction Support

Load Balancer Settings

4.  Tuning the Java Runtime System

5.  Tuning the Operating System and Platform

Index

Network Listener Settings

You can tune Network Listener settings from the command line by using the instructions in Administering HTTP Network Listeners in Oracle GlassFish Server 3.1 Administration Guide.

If using the Administration Console, navigate to the Configurations ->configuration-name->Network Config->Network Listeners->listener-name node, and then click the tab for the desired configuration page. Refer to the online help for complete instructions about the options on these tabs.

GlassFish Server Network Listener performance can be enhanced by modifying settings on the following Edit Network Listener tabs in the Administration Console:

General Settings

For machines with only one network interface card (NIC), set the network address to the IP address of the machine (for example, 192.18.80.23 instead of default 0.0.0.0). If you specify an IP address other than 0.0.0.0, the server will make one less system call per connection. Specify an IP address other than 0.0.0.0 for best possible performance. If the server has multiple NIC cards then create multiple listeners for each NIC.

HTTP Settings

The following settings on the HTTP tab can significantly affect performance:

Max Connections

Max Connections controls the number of requests that a particular client can make over a keep-alive connection. The range is any positive integer, and the default is 256.

Adjust this value based on the number of requests a typical client makes in your application. For best performance specify quite a large number, allowing clients to make many requests.

The number of connections specified by Max Connections is divided equally among the keep alive threads. If Max Connections is not equally divisible by Thread Count, the server can allow slightly more than Max Connections simultaneous keep alive connections.

DNS Lookup Enabled

This setting specifies whether the server performs DNS (domain name service) lookups on clients that access the server. When DNS lookup is not enabled, when a client connects, the server knows the client’s IP address but not its host name (for example, it knows the client as 198.95.251.30, rather than www.xyz.com). When DNS lookup is enabled, the server will resolve the client’s IP address into a host name for operations like access control, common gateway interface (CGI) programs, error reporting, and access logging.

If the server responds to many requests per day, reduce the load on the DNS or NIS (Network Information System) server by disabling DNS lookup. Enabling DNS lookup will increase the latency and load on the system, so modify this setting with caution.

Timeout

Timeout determines the maximum time (in seconds) that the server holds open an HTTP keep alive connection. A client can keep a connection to the server open so that multiple requests to one server can be serviced by a single network connection. Since the number of open connections that the server can handle is limited, a high number of open connections will prevent new clients from connecting.

The default time out value is 30 seconds. Thus, by default, the server will close the connection if idle for more than 30 seconds. The maximum value for this parameter is 300 seconds (5 minutes).

The proper value for this parameter depends upon how much time is expected to elapse between requests from a given client. For example, if clients are expected to make requests frequently then, set the parameter to a high value; likewise, if clients are expected to make requests rarely, then set it to a low value.

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

The GlassFish Server’s Keep Alive system, which is affected by the Timeout setting, addresses this problem. A waiting keep alive connection has completed processing the previous request, and is waiting for a new request to arrive on the same connection. The server maintains a counter for the maximum number of waiting keep-alive connections. 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 limits the number of open waiting keep-alive connections.

If your system has extra CPU cycles, incrementally increase the keep alive settings and monitor performance after each increase. When performance saturates (stops improving), then stop increasing the settings.

Header Buffer Length

The size (in bytes) of the buffer used by each of the request processing threads for reading the request data from the client.

Adjust the value based on the actual request size and observe the impact on performance. In most cases the default should suffice. If the request size is large, increase this parameter.

File Cache Settings

The GlassFish Server uses a file cache to serve static information faster. The file cache contains information about static files such as HTML, CSS, image, or text files. Enabling the HTTP file cache will improve performance of applications that contain static files.

The following settings on the File Cache tab can significantly affect performance:

Max File Count

Max File Count determines how many files are in the cache. If the value is too big, the server caches little-needed files, which wastes memory. If the value is too small, the benefit of caching is lost. Try different values of this attribute to find the optimal solution for specific applications—generally, the effects will not be great.

Max Age

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

If your Web site’s content changes infrequently, increase this value for improved performance. Set the maximum age by entering or changing the value in the Maximum Age field of the File Cache Configuration page in the web-based Admin Console for the HTTP server node and selecting the File Caching Tab.

Set the maximum age based on whether the content is updated (existing files are modified) on a regular schedule or not. For example, if content is updated four times a day at regular intervals, you could 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.