Hi. I am trying with some callback function to test the library.. 
Here is my code.

#!/usr/bin/env node
var qoper8 = require('qoper8');
var http = require('http');

var childProcess = qoper8.childProcess;

var callback = function(){
               
     return "Hellow world";
}
var actionMethod = function(action,callback) {

    var result = "Hello";
    callback(result);

};

childProcess.handler(actionMethod,true);

Why this always return "Hello" ??
why the code never goes to execute callback function ??



On Thursday, September 8, 2011 7:56:16 PM UTC+5:30, rtweed wrote:
>
> Interesting! 
>
> Q-Oper8 just uses the standard mechanism that's built into 
> child_process.fork() for message passing between the master and child 
> processes (ie send(message) and .on("message")) 
>
> I'm not sure whether this built-in mechanism presents an overhead that 
> can be significantly reduced by using alternatives - does anyone 
> know?  I'd prefer to stick to the standard mechanisms if I can. 
>
> I noticed that your benchmark was done on a 3.4GHz CPU, whereas I was 
> using a Ubuntu 11.04 server VM running inside Fusion on a 2.53GHz Mac, 
> so quite a bit lower spec than yours which *may* explain the 50% 
> faster throughput you get with wormhole.  Also remember that my 
> benchmark involves a complete 2-way round trip for each message: from 
> master to child and a response message sent back again from the child 
> to the master. 
>
> Cheers 
>
> Rob 
>
>
>
> On Sep 8, 3:03 pm, Aikar <[email protected]> wrote: 
> > You may want to look at what ever your using to send data to the child 
> > process. 
> > Wormhole (github.com/aikar/wormhole) may save you some time in 
> > performance. 
> > 
> > I'm getting a throughput of 150k messages/sec on my wormhole benchmark 
> > with 2 processes. 
> > 
> > On Sep 6, 1:16 pm, rtweed <[email protected]> wrote: 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > benchmark.js has been added to the /examples path in the Q-Oper8 repo: 
> > 
> > >https://github.com/robtweed/Q-Oper8 
> > 
> > > You'll need build 4 to run it (if you've already installed qoper8 
> > > using NPM, you'll need to get an update to 0.0.4) 
> > 
> > > BTW, one extra thing about my environment above - Mac Mini is running 
> > > OS X Lion 10.7.1 and VMWare Fusion 3.1.3 
> > 
> > > Rob 
> > 
> > > On Sep 6, 4:57 pm, rtweed <[email protected]> wrote: 
> > 
> > > > I've been running some tests with the Q-Oper8 module that I hope 
> folks 
> > > > might find interesting. 
> > 
> > > > First the environment, which isn't exactly turbo-powered: 
> > 
> > > > - a Ubuntu Linux 11.04 VMWare VM running on a Mac Mini (2.53GHz 
> Core2 
> > > > Duo + 4Gb memory) 
> > > > - the Linux VM is configured for just 1 CPU and 512 Mb memory 
> > > > - Node 0.5.5 
> > 
> > > > On a pretty much do-nothing exercise where a simple numeric action 
> > > > value is sent to the child process pool and a null handler function 
> is 
> > > > executed, I'm getting maximum throughput of 1 action per 9.5ms, or 
> > > > approx 10,500 requests/sec.  This is the rate at which the queue is 
> > > > being fed at the same rate as it's being consumed. 
> > 
> > > > Given the nature of the test (ie it's not really doing anything 
> apart 
> > > > from signalling between the master and child process), it's probably 
> > > > not surprising that the maximum throughput is with a poolsize of 1 - 
> > > > ie just one child Node process that is doing the work. 
> > 
> > > > Increasing poolsize gives the following max throughput figures: 
> > 
> > > > 2: 10,000/sec 
> > > > 3: 9430/sec 
> > > > 4: 9500/sec 
> > > > 5: 8300/sec 
> > 
> > > > and it progressively deteriorates with more processes. 
> > 
> > > > My assumption is that this is because: 
> > 
> > > > - there is only one CPU available and the processes compete for 
> > > > available resources 
> > > > - as the number of processes increase, the master process spends 
> more 
> > > > time searching for a free one to allocate a request to 
> > 
> > > > With more than 1 CPU and/or requests that required significant 
> > > > processing, I'm sure the balance would shift. 
> > 
> > > > My guess is that the primary limiting factor in my "do-nothing" test 
> > > > is the signalling time taken for the master process to pass a 
> message 
> > > > to a child process and for that child process to return a message to 
> > > > the master (remember in Q-Oper8 the child Node processes are 
> > > > persistent and already running) 
> > 
> > > > A more powerful CPU would, of course, yield better throughput 
> > > > results.  I'd be interested if anyone else wants to try out the 
> tests 
> > > > - I'll make the benchmark application available in the Github repo 
> for 
> > > > Q-Oper8 
> > 
> > > > 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]
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/d/optout.

Reply via email to