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.