I need to study on this, why `tj simple` get that much compares to `tj with node` before I can be certain about it. But I can say, after writeing thread.js, c/c++ module make the most difference by comparing to javascript code and this is relate to using threads. Then, reusing javascript objects is second the most issue to take care of.
Best Regards, Robert Micheil Smith於 2012年8月24日星期五UTC+8下午11時12分20秒寫道： > > 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]<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 > > -- 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
