A response to Node.js is cancer - The Diagnosis • Hacker News Board

Re: A response to Node.js is cancer - The Diagnosis

#21

Post by josephg » Mon, Oct 03, 2011, 4:32 AM UTC

eurleif wrote: post #18

ender7 wrote: post #17

So, this may be a silly question, but what exactly are you doing that's going to use so much freakin' CPU? Situations where blocking is going to be an issue: 1. You have roughly equivalent CPU usage per request, which means that you just have too many requests. Threaded or evented will both get bogged down here. 2. Most requests use a small amount of CPU, but every once in a while a request will require an ENORMOUS a…

I don't think using, say, 500ms worth of CPU is all that unusual of a need. If you try to do that with node.js, everything in your program will be blocked completely for 500ms. It doesn't make node.js useless, or 'cancer', but it is a real limitation.

There are nodejs web worker implementations to help with that kind of problem:

https://github.com/pgriess/node-webworker

If you use webworkers for cpu-intensive tasks (like fib), nodejs will perform just as well as all the other web frameworks out there.

Re: A response to Node.js is cancer - The Diagnosis

#22

Post by jcampbell1 » Mon, Oct 03, 2011, 4:37 AM UTC

eurleif wrote: post #18

ender7 wrote: post #17

So, this may be a silly question, but what exactly are you doing that's going to use so much freakin' CPU? Situations where blocking is going to be an issue: 1. You have roughly equivalent CPU usage per request, which means that you just have too many requests. Threaded or evented will both get bogged down here. 2. Most requests use a small amount of CPU, but every once in a while a request will require an ENORMOUS a…

I don't think using, say, 500ms worth of CPU is all that unusual of a need. If you try to do that with node.js, everything in your program will be blocked completely for 500ms. It doesn't make node.js useless, or 'cancer', but it is a real limitation.

A billion front-end calculations to display a webpage sounds like a hell of a lot to me. If that is common, then you can only do 2 reqs/sec/core either threaded or evented. (point 1).

If the 500ms request is rare, then occasionally some requests will be delayed vs a threaded setup. Keep in mind, that V8 is about 1 order of magnitude faster than CPython/PHP.

Re: A response to Node.js is cancer - The Diagnosis

#23

Post by NullSet » Mon, Oct 03, 2011, 5:08 AM UTC

josegonzalez wrote: post #19

To be honest, most of his blog posts seem to be inflammatory in nature with a cute picture at the top. I wouldn't be surprised if Ted wrote it merely to get blog views.

That's how it came across to me as well after I looked through the rest of his blog.

Re: A response to Node.js is cancer - The Diagnosis

#24

Post by rodh257 » Mon, Oct 03, 2011, 5:27 AM UTC

mwill wrote: post #10

I strongly disagree with what Ted wrote, but I really wish he would come out and enter a dialog with the community. There's a thread on the mailing list, twitter, and blog responses floating around now, but no substantial effort by Ted to respond to or even acknowledge the replies he's received.

he's responded here: http://news.ycombinator.com/item?id=3065098 with the same attitude he displayed in his original blog post. Not sure there's much point entering a dialog with him.

Re: A response to Node.js is cancer - The Diagnosis

#25

Post by ricardobeat » Mon, Oct 03, 2011, 5:42 AM UTC

eurleif wrote: post #18

ender7 wrote: post #17

So, this may be a silly question, but what exactly are you doing that's going to use so much freakin' CPU? Situations where blocking is going to be an issue: 1. You have roughly equivalent CPU usage per request, which means that you just have too many requests. Threaded or evented will both get bogged down here. 2. Most requests use a small amount of CPU, but every once in a while a request will require an ENORMOUS a…

I don't think using, say, 500ms worth of CPU is all that unusual of a need. If you try to do that with node.js, everything in your program will be blocked completely for 500ms. It doesn't make node.js useless, or 'cancer', but it is a real limitation.

Just offload it to a child process/worker, or use a job queue.

How exactly would you avoid that 500ms block in other platforms?

Re: A response to Node.js is cancer - The Diagnosis

#26

Post by masklinn » Mon, Oct 03, 2011, 6:26 AM UTC

ricardobeat wrote: post #25

eurleif wrote: post #18

Earlier quoted context omitted.

I don't think using, say, 500ms worth of CPU is all that unusual of a need. If you try to do that with node.js, everything in your program will be blocked completely for 500ms. It doesn't make node.js useless, or 'cancer', but it is a real limitation.

Just offload it to a child process/worker, or use a job queue. How exactly would you avoid that 500ms block in other platforms?

The platform does it: other requests are handled by other threads or processes (pooled or not), one request is going to consume 500ms and the rest will keep on trucking concurrently. Unless you've gone above the capacities of the machine itself, other requests will be little to not affected.

Re: A response to Node.js is cancer - The Diagnosis

#27

Post by masklinn » Mon, Oct 03, 2011, 6:28 AM UTC

josephg wrote: post #21

eurleif wrote: post #18

Earlier quoted context omitted.

I don't think using, say, 500ms worth of CPU is all that unusual of a need. If you try to do that with node.js, everything in your program will be blocked completely for 500ms. It doesn't make node.js useless, or 'cancer', but it is a real limitation.

There are nodejs web worker implementations to help with that kind of problem: https://github.com/pgriess/node-webworker If you use webworkers for cpu-intensive tasks (like fib), nodejs will perform just as well as all the other web frameworks out there.

But it does not fix the issue of e.g. having used a quadratic algorithm which is breaking your server because in production a user is shoving an order of magnitude more data than you expected (or tested for): you used that algorithm in-request because it was fast. Now it's not fast anymore and your production is getting killed. That's all there is to it, until you fix your code the application is not degraded, it's DOS'd every time that user does something.

And if you do consider workers (because you don't have a better algorithm), what happens for the cheap version? Do you offload it to a worker as well, potentially incurring a spin-off cost greater than the cost of the computation itself, or do you end up with two different codepaths (one sync and one async, just to ensure you're getting as complex as you can) depending on the computation's expected duration?

Re: A response to Node.js is cancer - The Diagnosis

#28

Post by tomjen3 » Mon, Oct 03, 2011, 6:53 AM UTC

ender7 wrote: post #17

So, this may be a silly question, but what exactly are you doing that's going to use so much freakin' CPU? Situations where blocking is going to be an issue: 1. You have roughly equivalent CPU usage per request, which means that you just have too many requests. Threaded or evented will both get bogged down here. 2. Most requests use a small amount of CPU, but every once in a while a request will require an ENORMOUS a…

Frogbugz, Joels bug handling system, has a feature that uses a Montecarlo simulation to provided statistics for when you will be done with whatever software you are working on.

Re: A response to Node.js is cancer - The Diagnosis

#29

Post by christkv » Mon, Oct 03, 2011, 6:58 AM UTC

masklinn wrote: post #26

ricardobeat wrote: post #25

Earlier quoted context omitted.

Just offload it to a child process/worker, or use a job queue. How exactly would you avoid that 500ms block in other platforms?

The platform does it: other requests are handled by other threads or processes (pooled or not), one request is going to consume 500ms and the rest will keep on trucking concurrently. Unless you've gone above the capacities of the machine itself, other requests will be little to not affected.

just as in node where you run multiple processes against the same socket using something like https://github.com/LearnBoost/cluster

Re: A response to Node.js is cancer - The Diagnosis

#30

Post by IsaacSchlueter » Mon, Oct 03, 2011, 7:00 AM UTC

exogen wrote: post #13

eurleif wrote: post #6

I like node.js, but this post completely misunderstands "Node.js is Cancer". The point of that post isn't that node.js is slow; its point is that node.js does concurrency, but not parallelism; i.e., if your code is CPU-bound, it can only serve one request at a time.

It's a bit extreme to conclude that since Node's built-in HTTP server works this way, that it's "cancer." People still use it because it suits their purposes; there's nothing wrong with that. AFAIK, nothing's stopping anyone from writing a CGI module for Node. It took years for Python to come up with WSGI and Ruby to come up with Rack. People are fed up with CGI and I don't blame Node's developers for excluding it.

> AFAIK nothing's stopping anyone from writing a CGI module for Node.

Indeed, nothing has stopped several people from doing it:

    $ npm search cgi
    NAME            DESCRIPTION                                                   AUTHOR             KE
    cgi             A stack/connect layer to invoke and serve CGI executables.    =TooTallNate
    fastcgi-stream  Fast FastCGI Stream wrapper for reading/writing FCGI records. =samcday           fc
    koku            Node.js bindings for the Mac finance app Koku                 =cgiffard
    nodeCgi         A fastcgi-like server designed to accept proxied requests from a web server and exe
    scgi-server     SCGI (Simple Common Gateway Interface) server                 =yorick            SC