On Mar 2, 2012, at 2:14 PM, Erik Dubbelboer wrote: > On Thursday, March 1, 2012 11:50:21 PM UTC+1, Ben Noordhuis wrote: > On Thu, Mar 1, 2012 at 22:16, Erik Dubbelboer <[email protected]> wrote: > > Hi Everyone, > > > > I was wondering what the status is for this API. I couldn't find anything in > > the current documentation so I'm guessing it hasn't been implemented yet? > > > > If this is the case I guess I could take a look at it since it would really > > be nice to have this for machines with a lot of cores in them. > The relevant code moved out of node and into libuv (and it's something > of an implementation detail there, uv-win has its own thread pool). > > I'd be interested in benchmarks that show (or don't show as the case > may be) when the number of threads is a bottleneck and what the sweet > spot is. Farming out I/O to a thread pool definitely hurts performance > but there's not enough data to make reasoned guesses about the actual > impact or the best remedy. Is that something you feel like taking on? > > > I think it's very hard to do any meaningful benchmarks. > > I did some simple testing. I wrote a module that does an usleep(1000 * > (rand() % 10)); to simulate doing some work. Then I wrote a simple script > that starts a webserver that does 3 calls to the module before finishing the > request. > > Then I ran the following command to see how fast it would run (only > interested in the total time). > ab -n 1000 -c 10 http://localhost:9090/ > > The results are quite obvious: > - with 4 threads around 3.5 seconds total > - with 8 threads around 1.7 seconds total > > With twice as many threads it gets twice as fast because in this simple > benchmark the blocking calls are the bottleneck. > > My company runs a real life node application which handles nearly 1000 > requests per second. It uses only redis-node and > https://github.com/kuno/GeoIP as C modules but I'll see if I can do some > benchmarks on this to see if the number of threads make any difference. > Probably not since geoip is very fast and redis itself it single threaded and > blocking. But we'll see.
Please note that time passes in parallel (N threads doing usleep()s in parallel are always going to be faster than M<<N threads running N usleep()s), but real disk I/O jobs even when ran in parallel in separate threads tend to be executed sequentially (unless you happen to hit the disk caches, a disk usually can do no more than an i/o operation at a time). So unless I'm misunderstanding (quite likely), istm that that test is flawed. Also note that on a Mac (on darwin), there's a mutex in libeio (https://github.com/joyent/node/blob/master/deps/uv/src/unix/eio/eio.c#L402 and https://github.com/joyent/node/blob/master/deps/uv/src/unix/eio/eio.c#L2171) that prevents parallel execution of write()s, even to different file descriptors, so they won't ever run in parallel, due to a bug in OSX's read() 2 and write() 2, both of which happen to be not fully thread-safe, unlike in Linux. So on a Mac, you'd gain ~ nothing using more (libeio) threads for io. -- Jorge. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
