1. Overview of GlassFish Server Performance Tuning
3. Tuning the GlassFish Server
Using the GlassFish Server Performance Tuner
Use Pre-compiled JavaServer Pages
Disable Dynamic Application Reloading
Session Properties: Session Timeout
Manager Properties: Reap Interval
Overview of EJB Pooling and Caching
Pool and Cache Settings for Individual EJB Components
Determining the Best Commit Option
Monitoring the Transaction Service
Viewing Monitoring Information
Tuning the Transaction Service
Disable Distributed Transaction Logging
Recover On Restart (Automatic Recovery)
CacheEntries (CurrentCacheEntries / MaxCacheEntries)
Limit DNS Lookups to Asynchronous
File Cache Information (file-cache)
How a Client Connects to the ORB
Controlling Connections Between Client and Server ORB
Monitoring JDBC Connection Pools
Connection Validation Settings
Connector Connection Pool Settings
4. Tuning the Java Runtime System
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:
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.
The following settings on the HTTP tab can significantly affect performance:
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.
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 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.
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.
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 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.
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.