Tuning HTTP Listener Settings

Change HTTP listener settings in the Admin Console under Configurations > config-name > HTTP Service > HTTP Listeners > listener-name.

Network Address

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.

Acceptor Threads

The Acceptor Threads setting specifies how many threads you want in accept mode on a listen socket at any time. It is a good practice to set this to less than or equal to the number of CPUs in your system.

In the Application Server, acceptor threads on an HTTP Listener accept connections and put them onto a connection queue. Session threads then pick up connections from the queue and service the requests. The server posts more session threads if required at the end of the request.

The policy for adding new threads is based on the connection queue state:

• Each time a new connection is returned, the number of connections waiting in the queue (the backlog of connections) is compared to the number of session threads already created. If it is greater than the number of threads, more threads are scheduled to be added the next time a request completes.

• The previous backlog is tracked, so that n threads are added (n is the HTTP Service’s Thread Increment parameter) until one of the following is true:

  • The number of threads increases over time.

  • The increase is greater than n.

  • The number of session threads minus the backlog is less than n.

  To avoid creating too many threads when the backlog increases suddenly (such as the startup of benchmark loads), the server makes the decision whether more threads are needed only once every 16 or 32 connections, based on how many session threads already exist.

Configuring Grizzly

Grizzly is an HTTP Listener using Java's NIO technology and implemented entirely in Java. This re-usable, NIO–based framework can be used for any HTTP related operations (HTTP Listener/Connector) as well as non-HTTP operations, thus allowing the creation of any type of scalable multi-threaded server. The Grizzly HTTP Listener uses a keep-alive system based on the NIO Selector classes of the Java platform, which support connection monitoring and help prevent Denial-of-Service attacks. The Denial–of–Service systems will add basic support for IP validation, number of transactions completed per IP, detection of inactive connections, etc. in order to predict resource exhaustion or "flooding" attacks. All these services are performed in conjunction with the Keep-Alive systems. The Grizzly connector will forward requests for both static and dynamic resources to the servlet container, which processes requests for static resources via a dedicated, container-provided servlet (org.apache.catalina.servlets.DefaultServlet).

For more information about Grizzly, you can read the weblog at http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html

Grizzly is available as a replacement to NSAPI/WebCore in Application Server Enterprise Edition8.2. Application Server provides some special properties to support the configuration of Grizzly. To enable Grizzly, add the following property:

Dcom.sun.enterprise.web.httpservice.ee=false.

Currently, the implementation of Grizzly supports all the Application Server Enterprise Edition functionality, except dynamic configuration.

The following properties control the Grizzly configuration:

• -Dcom.sun.enterprise.web.connector.grizzly.keepAliveTimeoutInSeconds=30

• -Dcom.sun.enterprise.web.connector.grizzly.maxHttpHeaderSize=4096

• -Dcom.sun.enterprise.web.connector.grizzly.ssBackLog=4096

• -Dcom.sun.enterprise.web.connector.grizzly.queueSizeInBytes=-1

• -Dcom.sun.enterprise.web.connector.grizzly.maxKeepAliveRequests=250

• -Dcom.sun.enterprise.web.connector.grizzly.fileCache.isEnabled=false

• -Dcom.sun.enterprise.web.connector.grizzly.fileCache.maxEntrySize=1024

• -Dcom.sun.enterprise.web.connector.grizzly.fileCache.maxLargeFileCacheSize= 10485760

Like all Sun Java System Application Server 8.2 configurations, Grizzly also performs better when the Asynch Startup mechanism is disabled. You can disable it using this property: -Dcom.sun.enterprise.server.ss.ASQuickStartup=false

The following table brings out the corresponding properties of Grizzly and the production web container (PWC).