Hacker Read

jiggawatts | karma 26854 | avg karma 5.63 · 2022-04-30 04:59:48

There's always trade-offs. It would be very rare for any server to reach even 100K concurrent connections, let alone 5M. Optimising for that would be optimising for the 0.000001% case at the expense of the common case.

Some back of the envelope maths: https://www.wolframalpha.com/input?i=100+Gbps+%2F+5+million

If the server had a 100 Gbps Ethernet NIC, this would leave just 20 kbps for each TCP connection.

I could imagine some IoT scenarios where this might be a useful thing, but outside of that? I doubt there's anyone that wants 20 kbps throughput in this day and age...

It's a good stress test however to squeeze out inefficiencies, super-linear scaling issues, etc...

reply

Koffiepoeder | karma 535 | avg karma 5.35 · 2022-04-30 05:20:43

Open, idle websockets can be a use case for a large amount of tcp connections with a small data footprint.

jeffbee | karma 21041 | avg karma 2.25 · 2022-04-30 11:53:07

Also IMAP has this unfortunate property.

jeroenhd | karma 24884 | avg karma 4.06 · 2022-04-30 05:33:49

20kbps should be sufficient for things like chat apps if you have the CPU power to actually process chat messages like that. Modern apps also require attachments and those will require more bandwidth, but for the core messaging infrastructure without backfilling a message history I think 20kbps should be sufficient. Chat apps are bursty, after all, leaving you with more than just the average connection speed in practice.

henrydark | karma 423 | avg karma 2.49 · 2022-04-30 05:48:45

I have a memory of some chat site, maybe discord, sending attachments to a different server, thus exchanging the bandwidth problem with extra system complexity

jeroenhd | karma 24884 | avg karma 4.06 · 2022-04-30 05:53:25

That's how I'd solve the problem. The added complexity isn't even that high, give the application an endpoint to push an attachment into a distributed object store of your choice, submit a message with a reference to the object and persist it the moment the chat message was sent. This could be done with mere bytes for the message itself and some very dumb anycast-to-s3 services in different data centers.

I'm sure I'm skipping over tons of complexity here (HTTP keepalives binding clients to a single attachment host for example) because I'm no chat app developer, but the theoretical complexity is still relatively low.

reply