Old box, dumb code, few thousand connections, no big deal
rachelbythebay.com
Old box, dumb code, few thousand connections, no big deal
1–10 of 288 posts
Re: Old box, dumb code, few thousand connections, no big deal
#2> I get the impression that a lot of us (myself included) hit a certain point, get tired of this crap, and just want to be free of it.
Preach it, sister!
Re: Old box, dumb code, few thousand connections, no big deal
#3The 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.
Re: Old box, dumb code, few thousand connections, no big deal
#4Honest 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?
Re: Old box, dumb code, few thousand connections, no big deal
#5Honest 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?
[deleted]
Re: Old box, dumb code, few thousand connections, no big deal
#6Honest 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 the answer is in the previous article about Python linked in this article: to show that you can serve more requests with less resources if you avoid the Python/Gunicorn way and do it her way instead.
Re: Old box, dumb code, few thousand connections, no big deal
#7But 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 performance.
And this is to the detriment of all of us. That’s why you’ll never hear me call myself an engineer.
Re: Old box, dumb code, few thousand connections, no big deal
#8Honest 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?
If you get stuck in read(), you can't do neat things like waking up when it's time to kick a client for being idle, doing other housekeeping, or cleanly shutting down the whole thing in a timely fashion. When I ^C the server, it sends the same wake condvar-poke but it twiddles the flags so the worker shuts down instead.
Re: Old box, dumb code, few thousand connections, no big deal
#9Would love to see the code.
Re: Old box, dumb code, few thousand connections, no big deal
#10The 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.
Even in 2007 when I was starting to cut my teeth on larger web traffic there was a lot of discussion around serving 10k concurrent connections. I remember being blown away by a graph showing high throughput at 70k concurrent by a YAWS server, and started following Erlang as a result.