3 ms·
> 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 somethin
by 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 agoIt 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.
- spion 10y agoThats parallelism, and node is as bad as it gets, yes. However, it pretty good at streaming all the necessary data to another service that will do the number crunching, as well as getting the results out to the client (with light transformation if necessary)
- spion 10y agoI just spawned a least-latency load balancer in front of a cluster of N processes (one per core) for the benchmark. https://github.com/spion/fpco-article-examples https://github.com/spion/fpco-article-examples Now it gives the same results as the Haskell solution. (Which only means this concrete benchmark doesn't reflect real world performance)