ryah ([info]four) wrote,
@ 2009-09-06 18:03:00
Previous Entry  Add to memories!  Share this!  Next Entry
Entry tags:benchmark, node

Combined benchmark
node v0.1.9
thin v1.2.1, ruby 1.8.7, em 0.12.8
v8cgi v0.6.0, apache 2.2.8 (Ubuntu)
narwhal/Rhino d147c160f11fdfb7f3c0763acf352b2b0e2713f7

The setup is similar to the last two benchmarks.

The point I want to make with these benchmarks is that Node is on the same order of magnitude in speed as production systems like EventMachine/Thin. Furthermore that at least two of the other proposed javascript systems are not on that order.

I think more can be done to clean up these numbers for Node. I haven't tried to optimize anything much yet.

1 concurrent client
completed requests:
node 23782
thin 22606
v8cgi 1990
narwhal 1234

> summary(node1$ttime)
    Min.  1st Qu.   Median     Mean  3rd Qu.     Max. 
  0.0000   0.0000   1.0000   0.7437   1.0000 106.0000 

> summary(thin1$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  0.000   1.000   1.000   1.122   1.000  74.000 

> summary(narwhal1$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  15.00   22.00   23.00   23.74   24.00   88.00 

> summary(v8cgi1$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  12.00   13.00   13.00   14.49   18.00   39.00






5 concurrent clients
completed requests:
thin 36899
node 34303
narwhal 2553
(v8cgi falls apart with more than one concurrent client)

> summary(node5$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
   1.00    2.00    3.00    3.79    4.00  142.00 

> summary(thin5$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  2.000   3.000   3.000   3.633   3.000 179.000 

> summary(narwhal5$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  16.00   42.00   51.00   58.12   63.00 5079.00





30 concurrent clients
completed requests:
thin 40575
node 35928
narwhal 2438

> summary(node30$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
   2.00   13.00   22.00   24.48   32.00  169.00 

> summary(thin30$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  10.00   18.00   19.00   21.64   20.00  133.00 

> summary(narwhal30$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  215.0   303.0   362.0   366.1   422.0   674.0





300 concurrent clients

completed requests:
thin 36045
node 35668
narwhal 2921

> summary(node300$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
   12.0    66.0   112.0   239.4   157.0 12200.0 

> summary(thin300$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
   71.0    84.0    87.0   208.7   107.0 23950.0 

> summary(narwhal300$ttime)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
    928    2837    2935    2921    3018    8759




(raw data, scripts)

(5 comments) - (Post a new comment)

highly impressive
(Anonymous)
2009-09-07 05:25 am UTC (link)
very cool. with a grain of salt, would it be worth comparing with some other scripting languages. *cough* python *cough* php. the async nature probably makes it less useful, but would be entertaining :)

(Reply to this) (Thread)
Re: highly impressive
(Anonymous)
2009-11-23 04:43 pm UTC (link)
If we are talking about concurrency, how about Erlang & Scala?

BTW Node looks fantastic, how production ready would you say it was?

Jason

(Reply to this) (Parent)
Re: highly impressive
(Anonymous)
2010-01-02 02:00 am UTC (link)
These tests were very cool, but I think it is too soon to compare node.js with another languages/platforms.

@ryah: could you poste your testing code?

(Reply to this) (Parent)
When I compute the req/sec it's more comparable
(Anonymous)
2009-11-10 04:48 am UTC (link)
And not faster than benchmarks with Tornado (Python).

(Reply to this)

A good start, but ...
[info]dreadedhill
2010-01-09 01:55 am UTC (link)
I fully expect node.js to win the response-time benchmarks by a large margin. (I also much prefer the node.js programming model.) On the other hand, I care a lot more about throughput (number of requests processed per second), as long as the response time is decent (say < 0.1 seconds). Super-fast response times may be useful for a (very small) set of intranet applications. Otherwise we should be more interested in overall throughput.

I would expect node.js to also win the overall throughput measurements, though the result might be a lot closer to the FastCGI numbers.

My preliminary benchmarks have the v8-via-FastCGI numbers clocking in at 80-90% of the node.js numbers for overall throughput (for a simple benchmark). Got a ways to go before I publish results, but the difference in overall throughput may be a *lot* less than indicated in the original article.

(Reply to this)

(5 comments) - (Post a new comment)

Image by [info]delightedly. Join the contest in [info]remixed!
Create an Account
Forgot your login or password?
Log in with OpenID
English • Español • Deutsch • Русский…