Hacker News Reader

Comment by markandrewj | Hacker News Reader

Normally benchmarks for things like this are measured in how many concurrent requests can be handled, i.e the C10K problem, not by how many requests you are able to serve in a day. It's also well known that you can serve a large amount of requests on limited hardware.

https://en.wikipedia.org/wiki/C10k_problem

"By the early 2010s millions of connections on a single commodity 1U rackmount server became possible: over 2 million connections (WhatsApp, 24 cores, using Erlang on FreeBSD),[6][7] 10–12 million connections (MigratoryData, 12 cores, using Java on Linux).[5][8]"

Although I do understand the boxes listed above have more resources then the VPS you are using. I am also not criticizing your write up, or results, bench-marking is in general interesting to do. I just wanted to provide some additional information.

View on HN

Yes, handling 50 requests per second doesn't mean the server can handle 4.2 million a day. That can only happen if they are uniformly distributed throughout the day, which isn't the case for most website traffic.

Right. I calculated what 5m/day converts into. And it's like 60 req/sec. Considering non even distribution and spikes, I would assume its like 200req/sec.

unrelated but 4x increase isn't really a spike

How does a single server run millions of active connections?

Wouldn't you run out of TCP sockets?

What am I missing?

A connection isn't just a dest_port, it's the unique combination of 4 components: source_ip:source_port:dest_ip:dest_port

socket multiplexing

I would guess they may be muxed over fewer sockets, by their LBs, but that's not strictly necessary.

I'm not sure exactly what you mean by "run out of TCP sockets", but theoretically speaking, the only limitation is how much memory is available to store the necessary info about the socket (like address/protocol info and process info).

In practice, OS's do have a "max socket" or "max FD" limit, but that's usually configurable and (with enough RAM) could easily be set to "millions".

> I'm not sure exactly what you mean by "run out of TCP sockets", but theoretically speaking, the only limitation is how much memory is available to store the necessary info about the socket (like address/protocol info and process info).

Probably the 65k port limit since each connection will get assigned a remote port, which can be solved by binding to multiple local ports and using a load balancer in front or using multiple network interfaces.

You can have more than one connection per port, so you don't even need the load balancer or more interfaces! :)

The 65k limit is per client address and port. Each client can have 65,535 connections to a single port on your server from each and every 65,535 of their own ports. (65,536? I dunno what would actually happen if you tried to use port 0.)

That would be the end of the Internet.

On my default Ubuntu install, the hard limit for open files of a process is 1048576 (ulimit -Hn). So you you have to run a handful of processes.

Reply on news.ycombinator.com