5 ms·

> 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 requireme

by 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.
- spion 10y ago
  > 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. Yes, you would have a load balancer in front of several instances running on several machines. Same as Haskell. > 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. I agree, in principle. But one, its not nearly as bad as this article makes it. And additionally, the given example is not convincing or very representative.
  - KirinDave 10y ago
    > Yes, you would have a load balancer in front of several instances running on several machines. Same as Haskell. If you do an internal N-M process fanout, will you also stop accepting connections on the individual box level if you're queueing? How tight are your health check timings to make sure this doesn't result in shitty performance when a pathological workload comes up? Will you disable the TCP connection queue here as well?
    - spion 10y ago
      > Will you also stop accepting connections on the individual box level if you're queueing? I would not. And I agree, it will be worse than Haskell, which will only choke if the cpu intensive processes are all calculating things without allocating memory or doing IO (as opposed to node where IO is the only yield point). And if the article talked about when Haskell green threads yield and compared that with node, as well as measured just how worse things are with a clustered setup, with several example problems, and by varying the parameters (such as number of processes)... then that would've been really awesome.
  - striking 10y ago
    It absolutely is as bad as 'KirinDave says it is, although the article does a bad job of showing it. Node shines at IO-bound applications, sure, but let's say you want to do one big computation on 16 cores all at once. With Node, you'd have to serialize data and pass it between child processes. And that really, really sucks. Haskell's parallelization story extends way past the "embarrassingly parallel" request handling. A good data point based on a less contrived example is how handily Haskell web frameworks demolish Node.js at JSON serialization... and not much else (https://www.techempower.com/benchmarks/#section=data-r13&hw=cl&test=json&l=4fthvj https://www.techempower.com/benchmarks/#section=data-r13&hw=...). Finally, if you're looking to do something truly and extremely CPU-bound, I'd tell you to write it in a C derivative and bind it to Node or Haskell, regardless of what your favorite language is. Optimize for speed in some places, and programmer happiness in others. A one-size-fits-all approach isn't usually appropriate.
    - 10y ago

by spion 10y ago

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.

spion 10y ago
> 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. Yes, you would have a load balancer in front of several instances running on several machines. Same as Haskell. > 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. I agree, in principle. But one, its not nearly as bad as this article makes it. And additionally, the given example is not convincing or very representative.
- KirinDave 10y ago
  > Yes, you would have a load balancer in front of several instances running on several machines. Same as Haskell. If you do an internal N-M process fanout, will you also stop accepting connections on the individual box level if you're queueing? How tight are your health check timings to make sure this doesn't result in shitty performance when a pathological workload comes up? Will you disable the TCP connection queue here as well?
  - spion 10y ago
    > Will you also stop accepting connections on the individual box level if you're queueing? I would not. And I agree, it will be worse than Haskell, which will only choke if the cpu intensive processes are all calculating things without allocating memory or doing IO (as opposed to node where IO is the only yield point). And if the article talked about when Haskell green threads yield and compared that with node, as well as measured just how worse things are with a clustered setup, with several example problems, and by varying the parameters (such as number of processes)... then that would've been really awesome.
- striking 10y ago
  It absolutely is as bad as 'KirinDave says it is, although the article does a bad job of showing it. Node shines at IO-bound applications, sure, but let's say you want to do one big computation on 16 cores all at once. With Node, you'd have to serialize data and pass it between child processes. And that really, really sucks. Haskell's parallelization story extends way past the "embarrassingly parallel" request handling. A good data point based on a less contrived example is how handily Haskell web frameworks demolish Node.js at JSON serialization... and not much else (https://www.techempower.com/benchmarks/#section=data-r13&hw=cl&test=json&l=4fthvj https://www.techempower.com/benchmarks/#section=data-r13&hw=...). Finally, if you're looking to do something truly and extremely CPU-bound, I'd tell you to write it in a C derivative and bind it to Node or Haskell, regardless of what your favorite language is. Optimize for speed in some places, and programmer happiness in others. A one-size-fits-all approach isn't usually appropriate.
  - 10y ago