Hi I've not done anything with Q-Oper8 in several years - quickl;y looking at the Q-Oper8 code, it appears that I removed the async callback logic that you're trying to test. I'm not actually sure why, but as I say, I've not played around with this code in many years, and I'm afraid you'll have to use/evaluate it on an as-is basis. Feel free to hack it around though if you're interested.
The concepts behind Q-Oper8 have formed the basis of the architecture of EWD.js which is what I spend my time on these days. See http://ewdjs.com Rob On Tuesday, 29 April 2014 05:05:48 UTC+1, matang dave wrote: > > 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.
