Yes IPC is what I'd ideally like, to avoid hitting the throughput limitations of the TCP connection between the master process and a child process.
However, I don't want to use what are experimental features just yet in an architecture that is intended to be used in production healthcare environments. In any case, I've tested the throughput of EWD.js's current architecture on a variety of platforms and it appears to easily exceed what's needed for a typical VA (US Dept of Veterans Affairs) site - and as such will already satisfy the needs of most healthcare organisations. It's good to know that IPC is on the way, though, so that as/when/if traffic requirements increase, we have a means to address them. BTW note that an EWD.js architecture can also be scaled out via the EWD REST interface, whereby a redundant farm of EWD.js application servers can provide a front-end to another farm of EWD.js-based data servers. It's a very flexible and scalable architecture, specifically designed to meet the many demands of the VA (and therefore pretty much any other healthcare organisation). Rob On Tuesday, 4 March 2014 12:54:49 UTC, ajlopez wrote: > > A possible wrapper for child process, as a baby step: > > http://nodejs.org/api/cluster.html > > It uses child process, but IPC (inter process communication) for > bidirectional communication. I'm not sure about Windows status of this > experimental feature > > > > On Tue, Mar 4, 2014 at 9:30 AM, rtweed <[email protected] <javascript:>>wrote: > >> >> >> On Tuesday, 4 March 2014 12:12:44 UTC, ajlopez wrote: >>> >>> >>> Thanks! >>> >>> I mentioned the absent of acronym "translation" not for me, but for the >>> casual reader. It is a bit confused read a post with not defined acronyms. >>> >>> Ok, child process, but >>> >>> >>> - Node.js Child Processes handle a single user request at a time >>> - If no Child Process is available, incoming requests are queued >>> - Child Process Pool size is configurable to match demand >>> - Since a Child Process handles only on request, it can use blocking >>> I/O and synchronous JavaScript logic >>> >>> That is not the node.js way/world. You don't need a child process pool >>> in node.js, am I right? Nor in meteor, with fibers. >>> >> >> On the face of it, it might not appear to be the conventional Node.js >> approach, but the queue/pre-forked process pool is an architecture used >> frequently in message queue-based systems, and works extremely well and >> very fast in Node.js. Note that the Child Processes are pre-forked and >> remain running at all times - there's no startup / teardown overhead. >> >> >>> What is a Node.js Child Process, in your presentation? >>> >>> Google gave to me: >>> http://nodejs.org/api/child_process.html >>> A full OS process? >>> >>> >> See the Node.js documentation on Child Processes: >> http://nodejs.org/api/child_process.html >> >> They're a standard feature of Node.js >> >> >>> In your slide 24, you mention >>> "Node.js, but Synchronous Code!" >>> >>> But what if the code needs to make an http request, using >>> require('http')? The calls are async? >>> >>> My guess: you wrote sync code to access your mumps data. (like slide >>> 20). But you cannot do anything async in the back end function. Am I right? >>> >>> >> Correct - the side of EWD.js that handles incoming HTTP(s) and WebSocket >> requests and queueing them is fully async, adhering 100% to standard >> Node.js practice. It's just the logic that requires access to the Mumps >> data within the child processes that you write as synchronous code. Within >> that same logic you can, of course, make async calls out to other HTTP(s) >> services (or any other async APIs) - it's really not a problem or >> limitation. Take a look at the Google Drive Synchroniser application that >> I package with the installation - it calls out asynchronously to Google >> Drive's APIs from a Child Process. >> >> I'd recommend running the installer, trying it out and see for yourself >> how it works in practice. >> >> Rob >> >> -- >> -- >> 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]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> 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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- -- 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 --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
