On Thursday, March 24, 2016 at 6:43:50 AM UTC+1, Harry Simons wrote: > > 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> >> 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 you have a CRUD operation that takes well over 3 seconds, then this RDBMS would definitely benefit from its own dedicated box. And if you're serving that same query to those 10,000 concurrent users, then your _app_ processing time is probably irrelevant, be it Node, Python, Java or good old PHP. But you're talking scalability and comparing to apache, so let's compare: Node on its own - takes many requests. Apache - not so many. Database query duration time: lasts the same. That's where node defends its claim for "insta-scalability". > > > >> 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. > It's not necessarily a bad idea, but it most likely is if you're serving 10,000 or more concurrent users. Say you have some simple mostly-read database stored in memory. I'm thinking Redis which is commonly used. Node and this Redis instance can sit on the same server for those 10k requests - but we do not depend so much on Node here (provided the app was written relatively well) - we're depending on the server itself. And that is, I believe one of the huge benefits of Node. You basically lift any such concurrency limits from your runtime environment and from your app and move it outside, to the underlaying host OS. You can be certain that if you have problems, it's not your app or Node that's the bottleneck - it's the database system, disks or something similar. (Although, it often _is_ your app. Well, for me, at least, most of the scaling issues I've had were my bad design.) -- 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/852ec0e8-6863-4e91-9ffe-312c97480790%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
