HP-UX TCP/IP Performance White Paper, March 2008

23
On the other hand, if the system is found to be operating at full capacity, and yet clients are not being
turned away, and if a high proportion of those clients experience long waiting times before service, then
one may consider one of the following courses of action:
Limit the number of requests that are accepted into the listen queue, and cause the excess requests
to be turned away.
Upgrade the system hardware to provide extra capacity.
Replace or modify the application to enable it to process requests more efficiently.
Usually it will be desirable in such cases to upgrade the system or application, but here we consider only
the case where the administrator chooses to address the problem by limiting the load on the system.
4.2.4.3 Tuning the Listen Backlog
The limit on the listen backlog is primarily determined by the application program. Thus the application
documentation (in this case, the Web server documentation) should be consulted for information on how the
listen backlog can be configured for that program.
However, HP-UX 11i provides the ability to control the maximum backlog value that applications are
allowed to select for themselves. This parameter is the ndd tunable tcp_conn_request_max, which by
default has a value of 4096. If connection requests are being dropped and the application is using a
backlog limit larger than 4096, then the system administrator can configure a larger listen queue by
increasing the value of the ndd tunable tcp_conn_request_max. Or, if the system is overloaded and the
application does not permit configuration of a lower backlog limit, then the value of the ndd tunable
tcp_conn_request_max may be set to a lower value than the one used by the application, and it will
lower the backlog limit that the application will be able to use.
Note that while changes to the ndd tunable tcp_conn_request_max take effect in the system
immediately, the value is only applied to listening sockets created after the value is changed. Therefore the
Web server or other applications affected should be shut down and restarted after making changes to this
parameter.
4.2.4.4 Monitoring Listen Backlog Usage
The system administrator may use the TCP statistics reported by netstat -s or netstat -p tcp to
decide whether the system may benefit from changing the backlog.
...
447144 connection accepts
...
21118 connect requests dropped due to full queue
From this output one learns the number of connections that have been accepted by all "server" applications
(including the Web server). Monitoring the growth of this count will give an indication of the rate at which
client requests are being serviced.
The other thing one learns from this is the number of connections dropped due to full queue. This
shows how many connection attempts were received at a time when the target listen queue was already
full. The rate at which this number grows will indicate the number of client connection attempts which are
failing. If this number is growing at a substantial rate, and if examination of the overall system workload
shows that the system has additional available processing capacity, then the Web server can benefit from
increasing the listen backlog -- first by seeing if the web server provides a way to configure this, and then
by looking at the value of the ndd tunable tcp_conn_request_max.