14 ms·

For starvation there is also clustering, which can shift the load towards worker processes that aren't busy with cpu-intensive tasks, as well as simple modules

• KirinDave 10y ago
  Personally I think this is a total non-answer to the question. It enormously complicates the concurrency and data sharing story for a solution that literally every programming language has access to. Nodejs has a poor story for compute-intensive loads. People need to be comfortable saying that, because it's reality.
  • spion 10y ago
    First of all, there is no enormous complication. Clustering in node is super-easy, and file descriptors of requests are sent automatically to one of the processes in the process pool. This benchmark should have at least done that. Secondly, the service presented there doesn't even need to take advantage of shared memory concurrency at all. This is the case for a vast majority of web service problems too: they either talk a lot to each other or do a bunch of cpu-intensive work, but rarely both. Finally, when you use shared memory concurrency/parallelism to solve web service problems, there is a risk that the resources of a single machine will not be enough. And then you are back to serialising things and sending them through an even slower channel. Haskell also has poor facilities for compute-intensive stuff, although they are different facilities. For example, laziness makes reasoning about performance more difficult. Space leaks are fairly easy to create unless you know the common gotchas. Most naive/idiomatic Haskell code performs several orders of magnitude worse than whats possible with optimized code. Etc etc.
    • KirinDave 10y ago
      > But those are not web-server problems. I disagree. Totally and utterly. API servers are webservers, and in fact a pretty big subgroup of them. API servers can often run into computational requirements in mid request, and it sucks that ONE slow request can cause latency ripples across your entire process. > Haskell also has poor facilities for compute-intensive stuff, although they are different facilities. For example, laziness makes reasoning about performance more difficult. This is changing the subject, and ultimately a non-sequitur. "This also has problems which are different" is not actually an answer to the criticism that nodejs is bad at these workloads. Say it with me. It's okay to say. "Nodejs is bad at compute-intensive workloads."
      • spion 10y ago
        > I disagree. Totally and utterly. API servers are webservers, and in fact a pretty big subgroup of them. API servers can often run into computational requirements in mid request, and it sucks that ONE slow request can cause latency ripples across your entire process. Or it doesn't cause ripples, since the cluster master doesn't send requests to it, and instead redirects them to the other processes. That, plus a process pool for known compute-intensive stuff is often good enough.
        • KirinDave 10y ago
          > Or it doesn't cause ripples, since the cluster master doesn't send requests to it, and instead redirects them to the other processes. A methodology that doesn't scale well across boxes, so only buys you so much. Demo code might benefit from this approach, but production code will do something totally different to give an API or server actual durability and uptime. > That, plus a process pool for known compute-intensive stuff is often good enough. To make it "good enough" for production workloads for anything less than a trickle of traffic requires an entirely different and probably queue-based architecture. While this is often in good style, it is (I restate) a tool available to every language environment. If everyone has this technique, you cannot say that Node is given a pass because "if you just totally re-architect this code" then it's okay. Nodejs's scheduler and execution model fundamentally make it worse at compute-heavy workloads. THIS IS AN ACCEPTABLE TRADEOFF. But denying it exists only misleads engineers and leads you to bad decisions.