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

On problems with threads in Node.js

future-processing.pl

Post reply on HN
Print view View original

61–66 of 66 posts

Re: On problems with threads in Node.js

#61

Post by irascible »

wppick wrote: post #57
spion wrote: post #53

Earlier quoted context omitted.

Not magic, but APIs like these: https://en.wikipedia.org/wiki/Epoll https://en.wikipedia.org/wiki/Kqueue Pretty much all event loop based programs work the same way: instead of blocking on a single request for IO, they use system calls (e.g. epool_wait) that block until any of the many descriptors (sockets) has some event (data to be read, client connecting, etc). It gets a bit complicated when there are queued tasks…

Don't most computer have separate processors for network, hard drive, etc. So, even if you have a single core processor, you are still running a multi-processor environment? Can anyone give me details on this? Someone told me something like this once and it has confused me ever since...

Yes. There are 100s of sub units that are complete processors on your motherboard. DSP, Ethernet controllers, Disk IO controllers, sound controllers, memory controllers.. and thats not counting the programmable controllers in every disk drive, sd card, reader, USB hub, peripheral, etc.

Re: On problems with threads in Node.js

#62

Post by wppick »

irascible wrote: post #61
wppick wrote: post #57

Earlier quoted context omitted.

Don't most computer have separate processors for network, hard drive, etc. So, even if you have a single core processor, you are still running a multi-processor environment? Can anyone give me details on this? Someone told me something like this once and it has confused me ever since...

Yes. There are 100s of sub units that are complete processors on your motherboard. DSP, Ethernet controllers, Disk IO controllers, sound controllers, memory controllers.. and thats not counting the programmable controllers in every disk drive, sd card, reader, USB hub, peripheral, etc.

Does this have an impact on writing concurrent software?

Re: On problems with threads in Node.js

#63

Post by imaginenore »

justincormack wrote: post #45
jrochkind1 wrote: post #38

Earlier quoted context omitted.

SSD's are a specialist use case these days? Or getting good performance on them is? What do you mean?

Getting full performance from them is a specialist requirement. Most people are not disk IO bound on SSD.

Isn't pretty much every DB that doesn't fit into RAM?

Re: On problems with threads in Node.js

#64

Post by babuskov »

amelius wrote: post #36
babuskov wrote: post #5

To sum it up: node.js runs only 4 background threads. Be aware of this. No big deal really. I have multiple servers running node.js under load for 3+ years and never had an issue with this. In fact, I found it helpful. If your database is under load and is already running 4 heavy queries, not giving it any more jobs is actually a good thing.

> If your database is under load and is already running 4 heavy queries, not giving it any more jobs is actually a good thing. User-interfaces 101: don't sacrifice the latency of short-lived jobs for finishing lengthy jobs. Also, let the OS figure it out. That's what it was made for.

There's a reason why queues are more performant than threads. See node.js and nginx for real-world examples.

The OS is dumb and does not understand the nature of load. If we applied your logic, everyone would still run Apache instead of nginx.

Your user-interfaces 101 fails flat on its face when you have hundreds of short-lived jobs that need to happen. Each one is insignificant on it's own, but if you overload the server will all of them at the same time just can starve system's RAM (forcing it to swap) or increase disk seeks by order of magnitude if short-lived jobs are asking for different data that is all over the place.

The only true answer here is: it depends.

Re: On problems with threads in Node.js

#65

Post by vinceyuan »

laggyluke wrote: post #39
vinceyuan wrote: post #37

Does it mean the async functions about file system operations are not really asynchronous in Node.js? The whole node.js server will be blocked if the number of file system operations is bigger than the thread pool size. :-(

Not the whole server - most of the networking IO will work just fine, only the operations that use libuv thread pool will be queued.

Got it. queued != blocked Thanks!

Re: On problems with threads in Node.js

#66

Post by kapv89 »

spion wrote: post #43
cddotdotslash wrote: post #42

I actually ran into an issue recently with CPU intensive tasks blocking my web server. It turns out that "querystring" (used to parse request bodies in web applications) is an asynchronous, blocking request. You'd never notice much slowness, until your request bodies are massive (think 50 nested JSON objects and some base64 image data for good measure) and you have multiple per second. Now, every request is blocked u…

I always use the following replacements written by petkaanotonov, the author of bluebird :) https://www.npmjs.com/package/querystringparser for query string parsing. Depending on content, you may get massive improvements (5x-20x) https://www.npmjs.com/package/fast-url-parser for url parsing (the built in url parser is the main reason why node is so far behind on the TechEmpower benchmark - with this replacement the b…

This comment in itself is probably more valuable than the OP
Post reply on HN