So, correct me if I'm wrong, but your initial benchmark results were skewed 
because of how you've implemented your HTTP module.

That said, you do see to get some performance boost over the standard net 
module, I'm guessing this may be because you're not communicating over 
STDOUT/STDIN pipes to child processes, but instead directly to the 
individual threads?

– Micheil

On 24/08/2012, at 4:05 PM, Robert L wrote:

> Hi Micheil,
> 
> You have mentioned me what I have miss.
> I was only focused on the performance of http service.
> After I have done the benchmark with cluster using `net`. I was surprised 
> that `net` are not that slow as`http`.
> 
> Here is the result:
> >ab -n 200000 -c xxxx 127.0.0.1:8080/
>               200client       1000client      2000client
> node_cluster  21001.89        19000.00         18717.28
> tj wite node  23792.30        23175.49         22707.17
> tj simple     24220.45        23182.52         22709.86
> 
> 
> >ab -n 200000 -c xxxx -k 127.0.0.1:8080/ 
>               200client       1000client      2000client
> node_cluster  21001.89        136077.29        18717.28
> tj wite node  23792.30        109830.13        22707.17
> tj simple     24220.45        105600.24        22709.86
> 
> 
> >weighttp -n 200000 -c xxxx -t 8 127.0.0.1:8080/
>               200client       1000client      2000client
> node_cluster  48644           41211           43047
> tj wite node  78133           76878           72929
> tj simple     78061           73478           72209
> 
> 
> >weighttp -n 200000 -c xxxx -t 8 -k 127.0.0.1:8080/
>               200client       1000client      2000client
> node_cluster  168867          163490          161464
> tj wite node  179399          195751          178095
> tj simple     289362          281941          256841
> 
> 
> Thread.js get a bigger advantage when benchmark with weighttp that get multi 
> thread support.
> Currently I implement a simply http service in javascript and it can achieve 
> 60,000+  both connections/sec and requests/sec.
> I will try to implement a method for programs to register their protocol. 
> When that time, I'll do another benchmark base on http service.
> 
> Sincerely,
> Robert
> 
> 
> 
> Micheil Smith於 2012年8月24日星期五UTC+8上午5時20分08秒寫道:
> Hi Robert, 
> 
> How's this compare to a Node.js server running with Cluster (API in 0.8)? 
> 
> I expect it to certainly be better than just a single node process running a 
> net.Server, 
> but if that process has been setup with Cluster, then you'd have one server 
> per core 
> to deal with the shared socket (or, at least, that's my understanding of it). 
> 
> Kind Regards, 
> Micheil Smith 
> -- 
> BrandedCode.com 
> 
> On 23/08/2012, at 5:40 PM, Robert L wrote: 
> 
> > Hi everybody, 
> > 
> > I have worte a node.js addon, to support multi thread with v8, and act as a 
> > ipv4/v6 server, please give it a try. 
> > Your feedback is very welcome. 
> > 
> > Thread.js support: 
> > 1. Act as a network layer of node.js. 
> > 2. Register a file to thread - you then run javascript file within the 
> > thread along with the network layer. Thread.js support require(), 
> > console.log, events.Emitter, net.createConnection and typedarray in thread 
> > mode for now. 
> > 
> > Benchmark is done by using weighttp on a Ubuntu 12.04 LTS 64bits server 
> > with a i7 2.67G 4cores cpu. 
> > Performance of a simple 'Hello world' server: 
> > 60K+ concurrent connections per second. 
> > 150K~200K concurrent requests per second. 
> > And it's scale mainly by cpu core number. You can get higher benchmark by 
> > adding more cpu power. 
> > 
> > Throughout of 50Kbytes response server: 
> > using typedarray: 1.7Gbytes per second. 
> > using javascript string: 290Mbytes per second. 
> > 
> > Stability: 
> > Each connection object is reused, thus the memory allocation is just at new 
> > age, don't need to face gc problem, and it can run days to weeks without 
> > restart the program. 
> > You can prove it by running node with v8 flag '--trace_gc 
> > --trace_gc_verbose' 
> > 
> > Detail benchmark output and test script is supported. 
> > Because it's written with the support of pthread and epoll , thread.js is 
> > Linux only. 
> > 
> > And please support me if it make some useful for your application. Thanks 
> > very much. 
> > 
> > homepage: http://rob333.github.com/thread.js/ 
> > github: https://github.com/rob333/thread.js 
> > 
> > 
> > 
> > -- 
> > 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 
> 
> 
> -- 
> 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

-- 
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

Reply via email to