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

16
number of TCP connections, as in the case with Web servers, may result in a large number of connections
staying in TIME_WAIT state before getting closed. Application server vendors may typically suggest tuning
this parameter related to TCP’s TIME_WAIT timer. With the default value of 60 seconds for
tcp_time_wait_interval on HP-UX, the HP-UX stack can track literally millions of TIME_WAIT
connections with no particular decrease in performance and only a slight cost in terms of memory. Please
refer to Appendix B for further discussion on this tunable parameter.
4.1.1.2 tcp_conn_request_max
Depending upon the configuration of a physical server, application servers typically need to accept a large
number of concurrent connections. The number of connections that can be queued by the networking stack
is the minimum of the listen backlog and this tunable parameter tcp_conn_request_max. Application
server vendors may suggest this tunable parameter to be set to 4096. On HP-UX the default value for this
tunable is 4096 so it may not need a change. Use netstat p tcp to monitor any dropped connections
due to listen queue full conditions and increase the value of this tunable parameter if necessary. Refer to
section 4.2.4 for a detailed description of this tunable parameter.
4.1.1.3 tcp_xmit_hiwater_def
This parameter controls the amount of unsent data that triggers the write side flow control. For typical OLTP
types of transactions (short request and short response) this parameter needs no tuning.
Increasing this tunable enables large buffer writes. For Decision Support System (DSS) workloads (i.e. small
query and large response), we recommend setting this tunable parameter to 65536 (default is 32768).
Please refer to Appendix B for further discussion on this tunable parameter.
4.1.1.4 tcp_ip_abort_interval
In certain deployment scenarios, backend database servers may be used in a highly available cluster
configuration. tcp_ip_abort_interval is the maximum amount of time a sending tcp will wait before
concluding the receiver is not reachable. Application servers may use this mechanism to detect node or link
failure and automatically switch the traffic over to a working database server in a cluster configuration. In a
typical deployment, application servers may be communicating with database servers and Web servers
which are physically close. To help faster detection and making use of fail-over features in such
environment, it may be desirable to set this tunable parameter to a lower value than the default value of 10
minutes. However, it is not recommended to set this parameter lower than tcp_time_wait_interval.
Please refer to Appendix B for further discussion on this tunable parameter.
4.1.1.5 tcp_keepalive_interval
When there is no activity on a connection and if the application requests that the keepalive timer be
enabled on the connection, then TCP sends keepalive probes at tcp_keepalive_interval intervals to
make sure that the remote host is still reachable and is responding. Application servers may make use of
this feature (SO_KEEPALIVE) to quickly fail over in cluster configurations when there is not much network
traffic. As application servers typically maintain a pool of long standing TCP connections open with both
Web servers and database servers, it is desirable to detect and fail over earlier in case of node or link
failures during very low network traffic. The default value is 2 hours; however some application server
vendors suggested tuning this tunable parameter to a much lower value (e.g. 900 seconds) than the default
value.