Comment by nnq | Hacker News Reader

Comment by nnq | Hacker News Reader

Parent Full thread

> Since Node.js runs on a single thread, everything that will block the event loop will block everything. That means that if you have a web server with a thousand connected clients and you happen to block the event loop, every client will just...wait. Read more at https://www.airpair.com/node.js/posts/top-10-mistakes-node-d...

This kind of thing would be big enough for me to just recommend to most average developers to just stick with PHP or whatever they are using now. At least the one-thread/process-per-request shared-nothing architecture successfully mitigates the effects of unavoidable developer stupidity (or of "code you've pushed to production without review after more than a couple beers" if you want to put it more 1st person...).

Simply because: 1. bad code will inevitably be written, 2. bad code will inevitably end up, among other things, blocking the event loop, and 3. the application will need to keep working speedly, form the user's perspective, despite having bad code sprinkled in it.

Isn't there any "automagic" way to prevent this from happening with node? ...something like, if a request takes more than XXX ms, than at least start handling new requests in new threads?

I don't think it's fair to blame developer stupidity. Formulating something asynchronously makes your code quite a bit harder to read, test, etc, so it's only natural that developers would avoid that - and builtins like JSON.parse further encourage that. Note that the author of that post doesn't really give solutions for the problems he mentions, he just tells you how to detect it.

Meanwhile there are actually nice solutions for the problem of handling many concurrent computations with low overhead readily available (e.g. Go).

You can use Node's cluster API[1] directly or use a wrapping module such as Recluster[2]. With these, node will spawn a few children that get replaced when they die or time out (a little extra code is needed for the latter).

One can even do rolling upgrades with this for zero downtime releases.

If there is a known workload that will block for a while, one could 1) run the work in a child process, 2) consider using streams to process the data in chunks, or 3) break the work up by chaining smaller operations using "process.nextTick" to put the next operation at the end of the event loop (allows other pending operations to resume before continuing the slow/blocking work).

[1] http://nodejs.org/api/cluster.html [2] https://www.npmjs.com/package/recluster

> block the event loop

This is one of the problems Erlang solves: its internal scheduler keeps things running even if some code ends up in an infinite loop or otherwise misbehaves.

Infinite loops aren't necessarily a form of misbehavior in Erlang. It is how you keep Erlang processes up after all - just spawn a function that calls itself at the end. Though the vast majority of those have a receive statement so that they're not always running.

Clearly I was not talking about the normal kind of "infinite loop", but the "malicious" sort.

Most developers don't know if they are average.

I sure don't know what kind of developer I am.

FWIW that's why Meteor, which is nodejs based, is using fibers to have thread per request.

Also hot pushes give automatic restart and browser updates out of the box.

Also having optional synchronous api on server, makes a lot of things easier to write.

I like NodeJs, but a lot of aspects will likely prevent it became a mainstream platform.

> I like NodeJs, but a lot of aspects will likely prevent it became a mainstream platform.

Node is already a mainstream platform.

If a dev really writes code that blocks the event loop, is not tested and not reviewed, I'm not sure he should work on professional projects ...

Anyway with one nodejs process it's not possible, but you can detect a stuck node and use some load balancing with a cluster of node processes (2 is usually enough), and simply reload a process if it gets stuck (while sending an email to ops of course). You need to use such an architecture to get zero-downtime deployments in any case .

What would you suggest for this situation:

a low priority admin page renders a 3000 row, 30 col table on the server using react. The query and resulting page size are pretty small < 2MB but this takes 5s for react to render.

I didn't expect it to be this slow and can't use client side rendering.

Those type of frameworks are great, but they all have performance limitations. The typical solutions are either find a faster framework or write it by hand. If the issue is that it is blocking the event loop rather than the literal performance, then you could spawn a process to do the React work.

Thanks. Are there no background worker process packages for nodejs that might be able to queue up some tasks?

You want to search for "web worker" or "background task" in NPM.

One example: https://github.com/audreyt/node-webworker-threads

You could break it up so that it processes the 3000 rows in chunks of say.. 500, and use process.nextTick() between each chunk to ensure node is handling other events too.

That would block a server for 500ms six times which is still unacceptable let alone being a hack that would mean rewriting the react page to support partial evaluation.

Your suggestion is basically to write your own event loop and write any cpu bound task to manually yield to the single-threaded node event loop. Crazy given we have been using multithreaded servers for decades that would do this automatically and generalise for any cpu-bound task.

"You're too stupid to handle this, just stick to PHP" - really?

If a developer can't grasp Node well enough to avoid blocking the event loop, I certainly wouldn't want them trying to handle a thousand connected clients with PHP!

Anyway, to answer your question - within a single node process no, not really. If something on the event loop goes into an infinite loop, timeouts will be of no use, and all other open requests are gonna be toast. This is just a downside to cooperative multitasking.

Some problems might be easier to solve in one language than in another. If you can't solve quicksort in ASM, does that mean people would be correct in wanting to refrain you from solving it in Python? It's a bit grotesque but completely analogous to your objection.

It is the opinion of many that cooperative multitasking is not the way to go if you want to solve problems which require massive concurrency.

PS: In Racket, you could defend against threads going into infinite loops with custodians.

http://docs.racket-lang.org/more/#%28part._.Terminating_.Con...

Seriously. Blocking the event loop isn't "an accident that can happen" in node - it's a pretty fundamental mistake.

Using any CPU is a fundamental mistake?

People are talking about accidentally blocking the event-loop, e.g. accidentally creating an infinite loop, not 'using any CPU'.

Except they don't have the normal option available to them that event loop systems do: start another thread.

Reply on news.ycombinator.com