Really surprised this article doesn't mention tcp_tw_reuse or tcp_tw_recycle. These have a more substantial impact that simply adjusting TW, as those ports will still be in a FIN_WAIT status for a long time before reuse as well.
I've been playing around with these settings on very loaded machines:
# Retry SYN/ACK only three times, instead of five
net.ipv4.tcp_synack_retries = 3
# Try to close things only twice
net.ipv4.tcp_orphan_retries = 2
# FIN-WAIT-2 for only 5 seconds
net.ipv4.tcp_fin_timeout = 5
# Increase syn socket queue size (default: 512)
net.ipv4.tcp_max_syn_backlog = 2048
# One hour keepalive with fewer probes (default: 7200 & 9)
net.ipv4.tcp_keepalive_time = 3600
net.ipv4.tcp_keepalive_probes = 5
# Max packets the input can queue
net.core.netdev_max_backlog = 2500
# Keep fragments for 15 sec (default: 30)
net.ipv4.ipfrag_time = 15
# Use H-TCP congestion control
net.ipv4.tcp_congestion_control = htcp
On 2.6.3x, someone posted a year or two ago to one of the linux mailing lists demoing an ipv6 stack hang under high traffic when tcp_tw_recycle is set to true.
tcp_tw_reuse and tcp_tw_recycle are dangerous. We have seen a significant number of connections from clients behind a NAT gateway being dropped with tcp_tw_recycle = 1.
Absolutely use with caution and test extensively. Everyone one of these tweaks are tuning things at a very granular level and may cause more problems than help.
Btw, the dropped clients has to do with recycle -- reuse is far 'safer', protocol speaking.
Excellent article on the subject.: http://www.speedguide.net/articles/linux-tweaking-121