If users are experiencing connection timeouts from a browser to Sun Java System Web Server when the server is heavily loaded, you can increase the size of the HTTP listener backlog queue. To increase this setting, edit the file ListenQ parameter in the magnus.conf file:
In addition to this setting, you must also increase the limits within the Solaris TCP/IP networking code. There are two parameters that are changed by executing the following commands:
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 8192 /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 8192
These two settings increase the maximum number of two Solaris listen queues that can fill up with waiting connections. tcp_conn_req_max_q increases the number of completed connections waiting to return from an accept() call. tcp_conn_req_max_q0 increases the maximum number of connections with the handshake incomplete. The default values are 128 and 1024 respectively. To automatically have these ndd commands executed after each system reboot, place them in a file called /etc/init.d/network-tuning and create a link to that file named /etc/rc2.d/S99network-tuning.
You can monitor the effect of these changes by using the netstat -s command and looking at the tcpListenDrop, tcpListenDropQ0, and tcpHalfOpenDrop values. Review them before adjusting these values. If they are not zero, adjust the value to 2048 initially, and continue to monitor the netstat output.
The Sun Java System Web Server ListenQ setting and the related Solaris tcp_conn_req_max_q and tcp_conn_req_max_q0 settings should match the throughput of the Sun Java System Web Server HTTP server. These queues act as a "buffer" to manage the irregular rate of connections coming from web users. These queues allow Solaris to accept the connections and hold them until they are processed by the Sun Java System Web Server HTTP server application.
You do not want to accept more connections than the Sun Java System Web Server HTTP server will be able to process. It is better to limit the size of these queues and reject further connections than to accept excess connections and fail to service them. The value of 2048 for these three parameters will typically reduce connection request failures, and improvement has been seen with values as high as 4096.
This adjustment is not expected to have any adverse impact in any web hosting environment, so you can consider this suggestion even if your system is not showing the symptoms mentioned.