Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js cures cancer

blog.brianbeck.com

Post reply on HN
Print view View original

31–40 of 99 posts

Re: Node.js cures cancer

#31

Post by pork »

tedjdziuba wrote: post #12
j_baker wrote: post #9

Earlier quoted context omitted.

I would argue that heavily CPU-bound stuff shouldn't be run in a web app. It's much better to offload the task to a worker system via redis/zeromq/kestrel/etc. The majority of activity you see in every web app I've ever designed has been almost exclusively I/O bound.

That's cool and all but in the real world we gotta get it done.

That comment sort of destroyed all your credibility. Would you care to elaborate where in the "real world" there is ever a situation where a tight, asynchronous event-processing loop is required to do heavy CPU lifting?

Re: Node.js cures cancer

#32

Post by pork »

pshc wrote: post #4
pilif wrote: post #3

While node is doing the calculation, it won't be doing anything else (like serving the next request). If a more traditional server is doing the calculation, it will spin up another process to handle the next request. If all you do is calculating Fibonacci, you can get ~(amount of CPUs) times the performance. You could use multinode for the same effect, but this is additional work. In the end, it's a matter of the typ…

It's a troll article, but I'd like to point out that the "UNIX way" is alive and well in node.js. I spawn new processes to do heavy lifting (e.g. thumbnailing, hashing files) all the time. I put jobs into queues in redis and handle them in other node processes. Obviously in co-operative multitasking it's wrong to block the rest of the server.

> Obviously in co-operative multitasking it's wrong to block the rest of the server.

I think that obviousness is exactly what the author missed.

Re: Node.js cures cancer

#33

Post by rian »

IMHO i think node.js sucks because it forces you to manually pass callbacks around. can't it remember my call site for me and use coroutines or call/cc or yield or something? even fork() exists on UNIX (or pthread_create()). why is passing callbacks around the answer? it's like using GOTO.

Re: Node.js cures cancer

#35

Post by masklinn »

jeswin wrote: post #16
tedjdziuba wrote: post #5

I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the choice of fibonacci was arbitrary. Let's move on from that. What I was showing was that if your request handler does a nontrivial amount of CPU work, it will hold up the event loop and kill any "scalability" you think you're getting from Node. If you Node guys we…

The problem is that fibonacci was a bad choice in your example and it proved nothing. It is fairly easy to scale node with multiple processes. As long as you don't have a long running (such as fibonacci) operation. If you do have tasks like that, process outside node and check for completion. Like how Tasks work in Google App Engine. Also, most other web stacks will discourage you from running a 30s fib on a thread p…

> Also, most other web stacks will discourage you from running a 30s fib on a thread processing web requests. This isn't specific to node.

Difference being, with other stacks a request running for 30s will have little impact on the rest of the machine. With node, the whole server gets stuck, not just that precise request and the machine resources necessary to perform the computation (or whatever).

The fib example is extreme, but it's rooted into a real issue of cooperative multitasking: code does not always behave correctly and is not always perfect. You might have used a quadratic algorithm and it ran in 10ms on 10 items or so, but in production it happens a user is getting it to run on a hundred or a thousand items, and now other users are severely affected, in that their requests are completely frozen while the computation is going on. There are hundreds of other possibilities, small inefficiencies, shortcuts, plain bugs, etc... which are basically going to break your node application.

Re: Node.js cures cancer

#37

Post by exogen »

ricardobeat wrote: post #24

I'm getting 0.020s tops for that fibonacci code on node (time curl http://localhost/ ), even going up to `1.1210238130165696e+167` (800th number). OSX Lion on a C2d 2.3ghz. Python 2.7.1 took 1m25.259s (no server). Am I doing something wrong? Or is there some incredibly optimized code path for OSX? edit: even weirder, `time node fibonacci.js` without a server takes 0.090s.

Sure you're calling fibonacci(40) and not just defining the function?

Re: Node.js cures cancer

#38

Post by ryanpers »

tedjdziuba wrote: post #5

I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the choice of fibonacci was arbitrary. Let's move on from that. What I was showing was that if your request handler does a nontrivial amount of CPU work, it will hold up the event loop and kill any "scalability" you think you're getting from Node. If you Node guys we…

ted you're so cool be my friend pleaseeeee

Re: Node.js cures cancer

#39

Post by ryanpers »

xnxn wrote: post #27
tedjdziuba wrote: post #12

Earlier quoted context omitted.

That's cool and all but in the real world we gotta get it done.

Wait, I think I've missed something because that response seems overly dismissive. How is offloading CPU-intensive stuff to a worker system not getting it done?

because you dont fix everything with another layer of indirection. add in some more queuing (which as we know never has a problem) just to ger around 'no threads' seems stupid.

Re: Node.js cures cancer

#40

Post by bigiain »

j_baker wrote: post #9
tedjdziuba wrote: post #5

I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the choice of fibonacci was arbitrary. Let's move on from that. What I was showing was that if your request handler does a nontrivial amount of CPU work, it will hold up the event loop and kill any "scalability" you think you're getting from Node. If you Node guys we…

I would argue that heavily CPU-bound stuff shouldn't be run in a web app. It's much better to offload the task to a worker system via redis/zeromq/kestrel/etc. The majority of activity you see in every web app I've ever designed has been almost exclusively I/O bound.

Don't you think there's at least some validity to Ted's argument that the statement "Because nothing blocks, less-than-expert programmers are able to develop fast systems." from the node.js homepage is somewhat misleading?

As Ted points out, there are things like Fugue and Nginx which people who are not "less-that-expert-programmers" do, "experts" will be fine whether they've got magical behind the scenes async stuff going on or not. The question as I see it is - are the node.js docs/homepage misleading about how easy is is to "develop fast systems"?

Post reply on HN