Hacker News Reader

Comment by superjared | Hacker News Reader

You don't need that either. The limitation is based on a tuple like this:

(incoming ip, outgoing ip, standard port, ephemeral port)

So yes, you're limited to 64k connections to a single MySQL port, for example.

Yeah, inbound connection to your service are not the issue the article is discussing. It's the outbound connection (for example, to memcached or mongodb) that your service makes in response to those potentially-greater-than-64k in bound connections that might trip you up. The site I'm working on right now makes 4 memcached requests for a logged in user hitting the homepage - that design may well fall apart at ~16k simultaneous connections if it's running on a shared host paas type host (or well before that if I'm sharing resources with another customer on the same paas hardware as my app)

Thinking more about it, while there is a limit here, I'm pretty sure it's one I don't need to care about.

My current project makes 4 outbound requests for some pretty common pages. That'd limit me to ~15k simultaneous page creations, which even at 250ms response times (I'm aiming for under 50ms) implies a limit of ~60,000 page views per second. (or 240,000 page views per second at my target 50ms page render time). If my app is getting 5billion pages views a day, I don't think I'm going to be worried about limits of shared paas hosting...

If you can get 5 billion page views a day on a single interface, I'd like to shake your hand.

This is not 1965, and we are not dropping punch cards with an operator and coming back hours or days later when our program has worked its way to the front of the queue. Five billion page views per day is irrelevant. Your peak traffic is what matters. Hitting 60,000 views in any given second is a lot easier than hitting 5 billion in a day.

That math is not quite correct. There is a timeout before the TCP stack will release the port for use in a new connection. That timeout can also be tuned, but just saying, not that simple...

Reply on news.ycombinator.com