In Sun Java System Web Server 6.1, acceptor threads on a listen socket accept connections and put them onto a connection queue. Session threads then pick up connections from the queue and service the requests. The session threads post 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 if it is seen to be increasing over time, and if the increase is greater than the ThreadIncrement value, and the number of session threads minus the backlog is less than the ThreadIncrement value, then another ThreadIncrement number of threads are scheduled to be added.
The process of adding new session threads is strictly limited by the RqThrottle value.
To avoid creating too many threads when the backlog increases suddenly (such as the startup of benchmark loads), the decision whether more threads are needed is made only once every 16 or 32 times a connection is made based on how many session threads already exist.
This subsection lists the directives in magnus.conf that affect the number and timeout of threads, processes, and connections. They are:
Also see the section Native Thread Pools for directives for controlling the pool of native kernel threads.
For more information about performance tuning, see the Sun Java System Web Server 6.1 SP10 Performance Tuning, Sizing, and Scaling Guide.
Specifies the number of seconds the server waits for data to arrive from the client. If data does not arrive before the timeout expires then the connection is closed. By setting it to less than the default 30 seconds, you can free up threads sooner. However, you may also disconnect users with slower connections.
AcceptTimeout seconds
30 seconds for servers that don't use hardware encryption devices and 300 seconds for those that do.
Specifies the number of outstanding (yet to be serviced) connections that the web server can have. It is recommended that this value always be greater than the operating system limit for the maximum number of open file descriptors per process.
This setting can have performance implications. For more information, see the Sun Java System Web Server 6.1 SP10 Performance Tuning, Sizing, and Scaling Guide.
The default value is 4096.
The size (in bytes) of the buffer used by each of the request processing threads for reading the request data from the client. The maximum number of request processing threads is controlled by the RqThrottle setting.
The default value is 8192 (8 KB).
This directive specifies an upper limit to the time slept (in milliseconds) after polling keep-alive connections for further requests.
The default is 100.
On lightly loaded systems that primarily service keep-alive connections, you can lower this number to enhance performance. However doing so can increase CPU usage.
This directive specifies the desired keep-alive latency in milliseconds.
The default value of 100 is appropriate for almost all installations.
Note that CPU usage will increase with lower KeepAliveQueryMeanTime values.
This directive determines the number of threads in the keep-alive subsystem. It is recommended that this number be a small multiple of the number of processors on the system (for example, a 2 CPU system should have 2 or 4 keep alive threads). The maximum number of keep-alive connections allowed (MaxKeepAliveConnections) should also be taken into consideration when choosing a value for this setting.
1
This directive determines the maximum time that the server holds open an HTTP Keep-Alive connection or a persistent connection between the client and the server. The Keep-Alive feature for earlier versions of the server allows the client/server connection to stay open while the server processes the client request. The default connection is a persistent connection that remains open until the server closes it or the connection has been open for longer than the time allowed by KeepAliveTimeout.
The timeout countdown starts when the connection is handed over to the keep-alive subsystem. If there is no activity on the connection when the timeout expires, the connection is closed.
The default value is 30 seconds. The maximum value is 300 seconds (5 minutes).
Sun Java System Web Server can support both kernel-level and user-level threads whenever the operating system supports kernel-level threads. Local threads are scheduled by NSPR (Netscape Portable Runtime) within the process, whereas kernel threads are scheduled by the host operating system. Usually, the standard debugger and compiler are intended for use with kernel-level threads. By setting KernelThreads to 1 (on), you ensure that the server uses only kernel-level threads, not user-level threads. By setting KernelThreads to 0 (off), you ensure that the server uses only user-level threads, which may improve performance.
The default is 0 (off).
Specifies the maximum number of pending connections on a listen socket. Connections that time out on a listen socket whose backlog queue is full will fail.
The default value is platform-specific: 4096 (AIX), 200 (Windows), 128 (all others).
Specifies the maximum number of Keep-Alive and persistent connections that the server can have open simultaneously. Values range from 0 to 1048576 for the 64–bit server.
Specifies the maximum number of processes that the server can have running simultaneously. If you don’t include MaxProcs in your magnus.conf file, the server defaults to running a single process.
One process per processor is recommended if you are running in multi-process mode. In Sun Java System Web Server 6.1, there is always a primordial process in addition to the number of active processes specified by this setting.
Additional discussion of this and other server configuration and performance tuning issues can be found in the Sun Java System Web Server 6.1 Performance Tuning, Sizing, and Scaling Guide.
1
If this directive is set to 1 (on), the server checks whether the minimum number of threads are available at a listen socket, after accepting a connection but before sending a response to the request. Use this directive, when the server handles request that take a long time, such as those that perform long database connections. By default, this directive is set to 0 (off) and as a result, the server checks whether the minimum number of threads are available at a listen socket, only after sending a response to the request.
0 (off)
Specifies the size (in bytes) of the receive buffer used by sockets. Allowed values are determined by the operating system.
The default value is determined by the operating system. Typical defaults are 4096 (4K), 8192 (8K).
Specifies the maximum number of request processing threads that the server can handle simultaneously. Each request runs in its own thread.
This setting can have performance implications. For more information, see the Sun Java System Web Server 6.1 SP10 Performance Tuning, Sizing, and Scaling Guide.
Specifies the number of request processing threads that are created when the server is started. As the load on the server increases, more request processing threads are created (up to a maximum of RqThrottle threads).
Specifies the size (in bytes) of the send buffer used by sockets.
The default value is determined by the operating system. Typical defaults are 4096 (4K), 8192 (8K).
Determines the maximum stack size for each request handling thread.
The most favorable machine-specific stack size.
Controls strict HTTP header checking. If strict HTTP header checking is on, the server rejects connections that include inappropriately duplicated headers.
StrictHttpHeaders [on|off]
off
Specifies the time that the server waits for all existing connections to terminate before it shuts down.
30 seconds
The number of additional or new request processing threads created to handle an increase in the load on the server, for example when the number of pending connections (in the request processing queue) exceeds the number of idle request processing threads.
When a server starts up, it creates RqThrottleMin number of request processing threads. As the load increases, it creates ThreadIncrement additional request processing threads until RqThrottle request processing threads have been created.
The default value is 10.
Uses a platform-specific poll interface when set to 1(on). Uses the NSPR poll interface in the KeepAlive subsystem when set to 0 (off).
1 (on)