undefined | Better HN

0 pointsspion9y ago0 comments

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

0 comments

4 comments · 1 top-level

KirinDave9y ago· 3 in thread

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

spionOP9y 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.

striking9y 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=...).

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.

2 more replies

KirinDave9y 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?

1 more reply

j / k navigate · click thread line to collapse