5 ms·

Isn't this a rehash of the C10K problem[1] from a decade ago? That was pretty much resolved in favour of single-threading and asynchronous IO, with Nginx and No

by cwp 11y ago

Isn't this a rehash of the C10K problem[1] from a decade ago? That was pretty much resolved in favour of single-threading and asynchronous IO, with Nginx and Node.js replacing Apache and Ruby as the platforms that the cool kids use. So, if threads are the way to go today, what has changed in the last 10 years to turn the conventional wisdom on it's head? 64-bit processors and servers with more memory? Hypervisors/containers? Are threads in Rust more practical than they are in C? (BTW, these aren't rhetorical questions, genuinely interested.) [1] http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html

girvo 11y ago
More cores, perhaps? Though I don't know if that's actually true in a server context.
dboreham 11y ago
No, backwards: the C10k techniques are the solution to the problem "how do I achieve my performance and scaling goals given the characteristics of the OS, languages, tools available to me today?". The current thread (sic) is asking the question "if we can change the language, tools (perhaps the OS too), what's the best approach?". And: I have to counterbalance the assertion that Node.js is in any way good for anything besides "I need to code in JS, but not in the browser". I'd rather use VAX assembler and the $QIO syscall, typing on a VT100.
- cwp 11y ago
  That's exactly the point. So my question remains: if threads are the right answer today, either the C10K folks were wrong or something has changed since then. What?
  - krenoten 11y ago
    Modern operating systems are better at handling many threads.
  - dboreham 11y ago
    The question is a different question, hence the answer is different. C10k wasn't considering the option of new languages, this thread is. The same question could have been asked back then (although most folks wouldn't have considered using anything other than C/C++ for high-scale servers then). Perhaps the thing that's changed is more memory and CPU power has made the option of new (and less efficient than C) languages a practical choice for new projects. I know that if, back then, I'd proposed the solution to my product's scaling issues with network I/O to be : "re-write all 500k loc in a different language", I'd have been laughed at.
jabl 11y ago
Disclaimer: I'm not an expert in this area, merely an interested bystander. So, AFAIU the C10K approach is still the correct approach. Although perhaps with current hw and Linux being able to decently handle quite a lot of threads since NPTL, one should nowadays call it the C100K problem? What has changed is a change in focus. Few people do entirely static sites anymore, and for static assets (images etc.) everybody uses nginx or other nonblocking approaches anyway. Perhaps also nginx/etc. as a reverse proxy. So there is no argument that nonblocking approaches are better for handling a lot of potentially slow connections. But for the "core" functionality of a network application, that people are actually spending times programming rather than using an off the shelf solution like nginx, nonblocking vs. threads doesn't matter that much, there's all kinds of DB calls, CPU intensive work to do, etc. So people are (correctly) asking whether we can create nonblocking code but with an easier to use programming model (to the extent it does matter for performance) or whether to just use threads.

by cwp 11y ago

girvo 11y ago

More cores, perhaps? Though I don't know if that's actually true in a server context.

dboreham 11y ago

No, backwards: the C10k techniques are the solution to the problem "how do I achieve my performance and scaling goals given the characteristics of the OS, languages, tools available to me today?". The current thread (sic) is asking the question "if we can change the language, tools (perhaps the OS too), what's the best approach?". And: I have to counterbalance the assertion that Node.js is in any way good for anything besides "I need to code in JS, but not in the browser". I'd rather use VAX assembler and the $QIO syscall, typing on a VT100.

cwp 11y ago
That's exactly the point. So my question remains: if threads are the right answer today, either the C10K folks were wrong or something has changed since then. What?
- krenoten 11y ago
  Modern operating systems are better at handling many threads.
- dboreham 11y ago
  The question is a different question, hence the answer is different. C10k wasn't considering the option of new languages, this thread is. The same question could have been asked back then (although most folks wouldn't have considered using anything other than C/C++ for high-scale servers then). Perhaps the thing that's changed is more memory and CPU power has made the option of new (and less efficient than C) languages a practical choice for new projects. I know that if, back then, I'd proposed the solution to my product's scaling issues with network I/O to be : "re-write all 500k loc in a different language", I'd have been laughed at.

jabl 11y ago

Disclaimer: I'm not an expert in this area, merely an interested bystander. So, AFAIU the C10K approach is still the correct approach. Although perhaps with current hw and Linux being able to decently handle quite a lot of threads since NPTL, one should nowadays call it the C100K problem? What has changed is a change in focus. Few people do entirely static sites anymore, and for static assets (images etc.) everybody uses nginx or other nonblocking approaches anyway. Perhaps also nginx/etc. as a reverse proxy. So there is no argument that nonblocking approaches are better for handling a lot of potentially slow connections. But for the "core" functionality of a network application, that people are actually spending times programming rather than using an off the shelf solution like nginx, nonblocking vs. threads doesn't matter that much, there's all kinds of DB calls, CPU intensive work to do, etc. So people are (correctly) asking whether we can create nonblocking code but with an easier to use programming model (to the extent it does matter for performance) or whether to just use threads.