On problems with threads in Node.js • Hacker News Board

Re: On problems with threads in Node.js

#41

Post by laggyluke » Thu, Apr 23, 2015, 12:25 PM UTC

albertzeyer wrote: post #30

masklinn wrote: post #28

Earlier quoted context omitted.

> The result of that experiment however was mostly that the thread pool solution was simpler to code (I guess). and uniformly asynchronous (native async operations may not cover e.g. file copy or filesystem operations, furthermore filesystems may block during submission of IO ops which makes the operations effectively synchronous) and have higher throughput (they support read/write vectors).

We could use the thread pool for blocking primitives and otherwise use the native AIO primitives, couldn't we? And the higher throughput seemed only to be a problem on MacOSX, so we could fallback to the thread pool there, but use the async IO on Windows and Linux.

I thought that's basically what libuv does: it uses AIO on platforms that support it, falling back to thread pool on platforms that don't.

Edit: apparently I was wrong.

Re: On problems with threads in Node.js

#42

Post by cddotdotslash » Thu, Apr 23, 2015, 12:28 PM UTC

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 until the previous one is processed. I'm still trying to figure out a solution, after looking into worker threads, etc.

Re: On problems with threads in Node.js

#43

Post by spion » Thu, Apr 23, 2015, 12:48 PM UTC

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 benchmark shows about 60-80% improvement in served req/s)

https://www.npmjs.com/package/cookieparser

For very large post bodies, I use JSON in conjunction with OboeJS - http://oboejs.com/ . Its not too much slower than native JSON.parse (about 5-7 times) however its non-blocking. Still haven't found a solution that is close enough in speed to native JSON.parse

Re: On problems with threads in Node.js

#44

Post by draven » Thu, Apr 23, 2015, 12:49 PM UTC

spion wrote: post #35

Not sure if it was intentional, but the article is quite misleading. The thread pool in node is only used for a limited number of APIs. Pretty much all networking uses native async IO and is unaffected by the size of the thread pool. Things like Oracle's driver are rare exceptions: the typical MySQL/PostgreSQL/redis etc drivers all use native async IO and are unaffected by this. The author only glosses over this brie…

There's a whole section of the article covering which parts of node may be affected. If the article began by saying it only affects FS and DNS ops, and some drivers, people may be more tempted to stop reading.

Is there any reliable way to check if the libs you're using are subject to this issue?

Re: On problems with threads in Node.js

#45

Post by justincormack » Thu, Apr 23, 2015, 1:04 PM UTC

jrochkind1 wrote: post #38

justincormack wrote: post #22

Earlier quoted context omitted.

It is only for file system operations, and mostly these do not actually block, as the results are available in cache. So it is probably reasonable for casual use. Now if you want to get good performance on an SSD (ie the rated iops) you will need a decent queue depth, like 32 or so, so it wont work but thats a specialist use case.

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.

Re: On problems with threads in Node.js

#46

Post by spion » Thu, Apr 23, 2015, 1:06 PM UTC

draven wrote: post #44

spion wrote: post #35

Not sure if it was intentional, but the article is quite misleading. The thread pool in node is only used for a limited number of APIs. Pretty much all networking uses native async IO and is unaffected by the size of the thread pool. Things like Oracle's driver are rare exceptions: the typical MySQL/PostgreSQL/redis etc drivers all use native async IO and are unaffected by this. The author only glosses over this brie…

There's a whole section of the article covering which parts of node may be affected. If the article began by saying it only affects FS and DNS ops, and some drivers, people may be more tempted to stop reading. Is there any reliable way to check if the libs you're using are subject to this issue?

There is a pretty reliable way to make sure they don't: if they don't install any native modules and aren't filesystem or DNS related, they're not affected. If they do, you may grep the native module's source code for uv_queue_work but I don't know if that will catch everything.

Re: On problems with threads in Node.js

#47

Post by suprememoocow » Thu, Apr 23, 2015, 1:16 PM UTC

spion wrote: post #35

Not sure if it was intentional, but the article is quite misleading. The thread pool in node is only used for a limited number of APIs. Pretty much all networking uses native async IO and is unaffected by the size of the thread pool. Things like Oracle's driver are rare exceptions: the typical MySQL/PostgreSQL/redis etc drivers all use native async IO and are unaffected by this. The author only glosses over this brie…

It's a completely unscientific method, but searching through one of our large applications (`npm ls|wc -l` -> ~2000 dependencies), the only modules I can find using `uv_queue_work` are:

* kerberos, unused (dependency of mongodb)

* protobuf, for serializing data

* snappy, for compression

kerberos isn't actually used in our app, so it doesn't matter, but we send a lot of data through protobuf and snappy, so it may be worth us profiling this a little more.

Re: On problems with threads in Node.js

#48

Post by ryankshaw » Thu, Apr 23, 2015, 1:17 PM UTC

(noob question) why would the libuv threadpool choose to use a static 4 instead of something like matching the number of processor cores available by default?

Re: On problems with threads in Node.js

#49

Post by jasonlotito » Thu, Apr 23, 2015, 1:22 PM UTC

lordbusiness wrote: post #31

eklavya wrote: post #25

Earlier quoted context omitted.

Calm down man, nobody's breaking anything. Everyone is entitled to his/her opinion. You can express your thinking on the matter by up/down voting. Relax :)

Heh - maybe you're right, and I wish the world were as you describe. :-) There is however a deeper underlying issue; decorum is important and communities that exhibit genuine 'niceness' are nice. Communities that allow, or worse, overlook dark behaviour degenerate. Flagging and down voting is one part of the solution, but when the nastiness reaches a level that the nice people start to disengage and go elsewhere, it'…

> There's are differences between a down vote because one disagrees with the author, and a down vote because one believes the author is ill-informed and spreading misinformation, and a down vote because the author is being downright juvenile.

The difference is that the first two should not be voted down. If you vote down, you should not comment. If you comment, it means at the very least the comment added to the conversation, unless your comment is also not worth posting and you should be voted down as well.

It's fairly simple: does the comment bring value to the conversation? If it does so directly, vote up. If only indirectly, than don't. If it does not, vote down.

Whether you disagree or not is irrelevant. And someone being ill-informed should be corrected. At the very least, by writing an incorrect comment, they are presenting an opportunity to be corrected.

> I don't want people to be unable to express their views, but when the mean-spirited people who contribute nothing but nonsense start to represent a large percentage of a community, it's reasonable to see if anything can be done.

Things can already be done. Vote down and don't reply. That is the best way. Vote down and ignore.

Re: On problems with threads in Node.js

#50

Post by zwily » Thu, Apr 23, 2015, 1:57 PM UTC

ryankshaw wrote: post #48

(noob question) why would the libuv threadpool choose to use a static 4 instead of something like matching the number of processor cores available by default?

For things like filesystem access, you'd want more threads than CPUs because that's not CPU heavy. It still seems like they could choose a saner default though.