Re:Http2 explained
by bwross on Thursday February 12, 2015 @03:34PM
(#9041223)
Additionally, a TCP connection is essentially an operating system resource; you need to set aside a port and space for a send and receive buffer. It might seem fine for a client to open hundreds connections, but imagine being a server with thousands of clients all opening hundreds of connections to you. You very quickly run out of resources and either have to close connections or reject new connections.
[ Parent
| on HN ]
That hasn't been a practical problem in many years. Most servers have gigabytes of RAM and a 64-bit kernel nowadays.
Linux starts to act weird around 200,000 concurrent connections in my experience, even with aggressive sysctl tuning. You end up with weird edge cases like netstat literally taking 15 minutes of CPU time (in kernel) before it dumps the list of connections to stdout.
Not sure about FreeBSD or any other OSes.
Not saying netstat isn't slow, but:
# time sh -c 'netstat -tn | wc -l' 486206
real 0m13.538s user 0m1.698s sys 0m10.380s
It still works with a whole lost of connections. (in fairness, only about 130k were connected)
The problem is that it doesn't scale linearly. There's some O(n4) algorithm being used in netstat or some kernel syscalls or something. Once you go over 250k, things get _really_ weird.
Re:Http2 explained
by patrickmcmanus on Sunday February 15, 2015 @09:55AM
(#9052732)
try ss -nt instead.. it uses netlink sockets instead of /proc and generally scales much better