Live data from Hacker News

Old box, dumb code, few thousand connections, no big deal

rachelbythebay.com

11–20 of 288 posts

Re: Old box, dumb code, few thousand connections, no big deal

#11

But this isn’t engineering. This is the IT equivalent of building a bridge and driving successively larger trucks over it. In real engineering fields, you can do predictive analyses based on prior empiricism. There’s none of that in our fields until you’re talking about very small systems where, for example, the stack consumption can be determined in advance and the scheduler can give you guarantees about worst-case…

If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world.

We don’t. We built wind tunnel models, we taxi them around at higher and higher speeds, we put them in machines that wiggle the wings at high loads. The first flight is a little hop and then right back down. Months later there might be a big ceremony with VIPs where the new plane takes a lap around the airport as it’s “first flight”.

And there are mistakes song the way, giant ones that add years to the schedule and tiny ones that engineers argue over even telling their boss about.

Sure there’s planning and experience, just like she knew to use epoll and not select, and that Linux can handle thousands of threads per process. But there’s no magic to it, just lots and lots of human attention and testing along the way.

Re: Old box, dumb code, few thousand connections, no big deal

#12
post #3

The C10k problem was challenging around the turn of the century. I suppose it's now not. I wonder how much CPU would be saved using an event-based architecture.

C10k problem is now C10M, from wikipedia:

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

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

Re: Old box, dumb code, few thousand connections, no big deal

#13

But this isn’t engineering. This is the IT equivalent of building a bridge and driving successively larger trucks over it. In real engineering fields, you can do predictive analyses based on prior empiricism. There’s none of that in our fields until you’re talking about very small systems where, for example, the stack consumption can be determined in advance and the scheduler can give you guarantees about worst-case…

What is stress load testing then? Most large companies do perform something to this....

Most large companies do some stress load testing first for any new system. Then they release to few percent of the users (less than 10%) and gradually increase to the rest of the userbase.

I worked at Spotify, when Tidal was launched. They had failed to do proper capacity testing, and the service failed under the load the first week and it showed. But most mature large company tend to be really good on this.

It is remarkable how many tech companies have managed to stay mostly up with very few outages, given this whole pandemic situation, where everybody is online.

I'd say working in large scale deployment is proper engineering .... creating a simple webpage, maybe not. Deploying that webpage to millions of users, it is.

Also, don't forget that bridges have been made since the dawn of time, while tech and the internet are very very young in human terms.

Re: Old box, dumb code, few thousand connections, no big deal

#14
post #11

But this isn’t engineering. This is the IT equivalent of building a bridge and driving successively larger trucks over it. In real engineering fields, you can do predictive analyses based on prior empiricism. There’s none of that in our fields until you’re talking about very small systems where, for example, the stack consumption can be determined in advance and the scheduler can give you guarantees about worst-case…

If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world. We don’t. We built wind tunnel models, we taxi them around at higher and higher speeds, we put them in machines that wiggle the wings at high loads. The first flight is a little hop and then right back down. Months later there might be a big ceremony with VIPs where the new pla…

> If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world.

Didn’t Boeing just get caught trying that?.

Re: Old box, dumb code, few thousand connections, no big deal

#15
post #3

The C10k problem was challenging around the turn of the century. I suppose it's now not. I wonder how much CPU would be saved using an event-based architecture.

Yeah, the cutting edge is C10M now.

C10K was solved by switching to an event system like epoll or kqueue. This decreased the big O complexity of kerneluser information flow so that you don't pay more for listening on more sockets.

C10M seems to be solved by colocating the network stack and app stack data structures by running the driver and the app in the same context. This can be achieved via DPDK-like schemes or pushing more into the kernel like Netflix's work to push TLS into kernel sockets that you can sendfile to.

Re: Old box, dumb code, few thousand connections, no big deal

#16
post #4

Honest question: why go through the hassle of multiplexing waiting in a single thread only to dispatch to a thread per client anyway? Simply using blocking IO for the clients in those threads should be much simpler right?

I think it's basically just the equivalent of select(2)? Once upon a time, all network servers were written this way. They were pretty fast, too.

Re: Old box, dumb code, few thousand connections, no big deal

#17
post #16
post #4

Honest question: why go through the hassle of multiplexing waiting in a single thread only to dispatch to a thread per client anyway? Simply using blocking IO for the clients in those threads should be much simpler right?

I think it's basically just the equivalent of select(2)? Once upon a time, all network servers were written this way. They were pretty fast, too.

Most select(2) based servers were single threaded, however. Not that this is necessarily a bad thing.

Re: Old box, dumb code, few thousand connections, no big deal

#18
post #11

Earlier quoted context omitted.

If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world. We don’t. We built wind tunnel models, we taxi them around at higher and higher speeds, we put them in machines that wiggle the wings at high loads. The first flight is a little hop and then right back down. Months later there might be a big ceremony with VIPs where the new pla…

> If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world. Didn’t Boeing just get caught trying that?.

The problems were identified early on but the NTSB, FAA, and their own engineers were overruled by the business people: see e.g. https://www.nytimes.com/2019/10/02/business/boeing-737-max-c...

Re: Old box, dumb code, few thousand connections, no big deal

#19

But this isn’t engineering. This is the IT equivalent of building a bridge and driving successively larger trucks over it. In real engineering fields, you can do predictive analyses based on prior empiricism. There’s none of that in our fields until you’re talking about very small systems where, for example, the stack consumption can be determined in advance and the scheduler can give you guarantees about worst-case…

I'm glad someone else sees this the way I do. What the blog writer did was tinker with something. They didn't engineer it.

I was a mechanical engineer prior to switching to software. As a general rule, the things we do in software are very distant from engineering.

Post reply on HN