On Thursday, March 24, 2016 at 7:51:35 AM UTC+5:30, Matt Sergeant wrote: > > On Wed, Mar 23, 2016 at 12:25 PM, Harry Simons <simon...@gmail.com > <javascript:>> wrote: > >> >> For example, if an isolated and primarily an I/O bound request takes, >> say, 3 seconds to get serviced (with no other load on the system), then if >> concurrently hit with 5000 such requests, won't Node take *a lot* of >> time to service them all, *fully*? >> > > What is taking 3 seconds? The answer, as with all technology is "it > depends". If you block the CPU for 3 seconds then yes of course, your app > will suck. If you're just sitting waiting on other I/O (e.g. a network > request) for 3 seconds, then lots can happen in the gaps. >
A CRUD operation against a large database could take well > 3 seconds. I was assuming the DB server being co-located with the Node server (on the same physical box) in my original question and was thus taking it to involve CPU+I/O processing instead of just network I/O; the latter would be the case if it were another physical server on the network (as in your response). Apparently, that's a bad idea even with an evented platform such as Node. Ben's response too assumes a remote DB server resulting in a pure I/O wait on the Node server. I get it now. > If this 3-second task happens to involve exclusive access to the disk, >> then it would take 5000 x 3 sec = 15000 seconds, or over 4 hours of wait to >> see the response for the last request coming out of the Node app. In such >> scenarios, would it be correct to claim that a single-process Node >> configuration can 'handle' 1000s of requests per second (granted, a >> thread-server like Apache would do a lot worse with 5000 threads) when all >> that Node may be doing is simply putting the requests 'on hold' till they >> get *fully* serviced instead of rejecting them outrightly on initial >> their arrival itself? I'm asking this because as I'm reading up on Node, >> I'm often hearing how Node can address the C10K problem without any >> co-mention of any specific application setups or any specific application >> types that Node can or cannot handle... other than the broad, CPU- vs >> I/O-bound type of application classification. >> > > I think you've just generally misread a lot of stuff about this, honestly. > Disk I/O is "complicated" in node (because async I/O to disk is complicated > in operating systems, it's not Node's fault). But not many web apps use the > "fs" module on their requests directly. Node uses a thread pool for the > filesystem requests on Unix-like OSs, so there are limits there, but it's > very rare to see that as an issue for developing node apps at scale. When > you talk to any of the DB modules you're using network I/O in Node, not > filesystem I/O. > I took up the specific case of the DB server co-located on the Node server. Apparently, even in a Node-based application this would be a bad idea - is what I'm hearing. Which is fine. I get it now. 2. What about the context switching overhead of the workers in the >> worker-thread pool? If C10K requests hit a Node-based application, won't >> the workers in the worker-thread pool end up context-switching just as much >> as the user threads in the thread pool of a regular, threaded-server (like >> Apache)...? >> > > No, because most of Node isn't threaded. Only a few parts of Node use a > thread pool. Any network I/O uses native OS async methods (epoll, kqueue, > and whatever Windows uses these days). So there's zero context switching > overhead - you're entirely in userspace. > For sake of completeness, I'm curious to know what ALL parts of Node are threaded. Filesystem I/O is apparently one, and network I/O apparently is not. -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: 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 unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. To post to this group, send email to nodejs@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/175fc285-e442-4e3a-a517-c81a5423c0b5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
