
Analternative way to make this change is using the ulimit –n "value"command. Using this
commanddoes not require a system restart. However, this command only changes the login
shell,while editing the etc/system le aects all shells.
Failureto Connect to HTTP ServerIfusers are experiencing connection timeouts from a browser to Web Server when the server is
heavilyloaded, you can increase the size of the HTTP listener backlog queue. To increase this
setting,edit the HTTP listener's listen queue value.
Inaddition to this setting, you must also increase the limits within the Solaris TCP/IP
networkingcode. 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
Thesetwo settings increase the maximum number of two Solaris listen queues that can ll up
withwaiting connections. tcp_conn_req_max_q increases the number of completed
connectionswaiting to return from an accept() call. tcp_conn_req_max_q0 increases the
maximumnumber of connections with the handshake incomplete. The default values are 128
and1024 respectively. To automatically have these ndd commands executed after each system
reboot,place them in a le called /etc/init.d/network-tuning and create a link to that le
named/etc/rc2.d/S99network-tuning.
Youcan monitor the eect of these changes by using the netstat -s command and looking at
thetcpListenDrop,tcpListenDropQ0, and tcpHalfOpenDrop values. Review them before
adjustingthese values. If they are not zero, adjust the value to 2048 initially, and continue to
monitorthe netstat output.
TheWeb Server HTTP listener's listen queue setting and the related Solaris
tcp_conn_req_max_qand tcp_conn_req_max_q0 settings should match the throughput of the
WebServer. These queues act as a "buer"to manage the irregular rate of connections coming
fromweb users. These queues allow Solaris to accept the connections and hold them until they
areprocessed by the Web Server.
Youdon't want to accept more connections than the Web Server is able to process. It is better to
limitthe size of these queues and reject further connections than to accept excess connections
andfail to service them. The value of 2048 for these three parameters typically reduces
connectionrequest failures, and improvement has been seen with values as high as 4096.
Thisadjustment is not expected to have any adverse impact in any web hosting environment, so
youcan consider this suggestion even if your system is not showing the symptoms mentioned.
SolarisPlatform-SpecicIssues
SunJavaSystem Web Server 7.0 Update 1 Performance Tuning,Sizing, and Scaling Guide •90