3

アップデート

これは、ベンチマーク、またはノード対ルビーのことではありませんでした（申し訳ありませんが、質問でもっと明確にすべきです）。ポイントは、ブロッキングとノンブロッキングの違いと、ノンブロッキングを書くのがいかに簡単かを比較して実証することでした。例として EventMachine を使用して比較することもできますが、ノードにはこの組み込み機能があるため、当然の選択でした。

私は何人かの友人に、他のテクノロジーに対するnodejs（およびそのフレームワーク）の利点を実証しようとしています。これは、主にノンブロッキングIOのことを理解するのが非常に簡単な方法です。

そこで、Google で HTTP リクエストを実行し、結果の html の長さをカウントする (ごくわずかな) Expressjs アプリと Rails アプリを作成してみました。

予想どおり (私のコンピューターでは)、Expressjs は ab を介して Rails よりも 10 倍高速でした (以下を参照)。私の質問は、それが nodejs が他のテクノロジーよりも優れていることを実証する「有効な」方法であるかどうかです。(または、Expressjs/Connect で何らかのキャッシングが行われていますか?)

これが私が使用したコードです。

Expressjs

exports.index = function(req, res) {
    var http = require('http')
    var options = { host: 'www.google.com', port: 80, method: 'GET' }
    var html = ''
    var googleReq = http.request(options, function(googleRes) {
        googleRes.on('data', function(chunk) {
            html += chunk
        })
        googleRes.on('end', function() {
            res.render('index', { title: 'Express', html: html })
        })
    });
    googleReq.end();
};

レール

require 'net/http'

class WelcomeController < ApplicationController
  def index
    @html = Net::HTTP.get(URI("http://www.google.com"))
    render layout: false
  end
end

ABベンチマーク結果です

Expressjs

Server Software:        
Server Hostname:        localhost
Server Port:            3000

Document Path:          /
Document Length:        244 bytes

Concurrency Level:      20
Time taken for tests:   1.718 seconds
Complete requests:      50
Failed requests:        0
Write errors:           0
Total transferred:      25992 bytes
HTML transferred:       12200 bytes
Requests per second:    29.10 [#/sec] (mean)
Time per request:       687.315 [ms] (mean)
Time per request:       34.366 [ms] (mean, across all concurrent requests)
Transfer rate:          14.77 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:   319  581 110.6    598     799
Waiting:      319  581 110.6    598     799
Total:        319  581 110.6    598     799

Percentage of the requests served within a certain time (ms)
  50%    598
  66%    608
  75%    622
  80%    625
  90%    762
  95%    778
  98%    799
  99%    799
 100%    799 (longest request)

レール

Server Software:        WEBrick/1.3.1
Server Hostname:        localhost
Server Port:            3001

Document Path:          /
Document Length:        65 bytes

Concurrency Level:      20
Time taken for tests:   17.615 seconds
Complete requests:      50
Failed requests:        0
Write errors:           0
Total transferred:      21850 bytes
HTML transferred:       3250 bytes
Requests per second:    2.84 [#/sec] (mean)
Time per request:       7046.166 [ms] (mean)
Time per request:       352.308 [ms] (mean, across all concurrent requests)
Transfer rate:          1.21 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  180 387.8      0     999
Processing:   344 5161 2055.9   6380    7983
Waiting:      344 5160 2056.0   6380    7982
Total:        345 5341 2069.2   6386    7983

Percentage of the requests served within a certain time (ms)
  50%   6386
  66%   6399
  75%   6402
  80%   6408
  90%   7710
  95%   7766
  98%   7983
  99%   7983
 100%   7983 (longest request)
4

2 に答える 2

5

To complement Sean's answer:

Benchmarks are useless. They show what you want to see. They don't show real picture. If all your app does is proxy requests to google, then evented server is a good choice indeed (node.js or EventMachine-based server). But often you want to do something more than that. And this is where Rails is better. Gems for every possible need, familiar sequential code (as opposed to callback spaghetti), rich tooling, I can go on.

When choosing one technology over another, assess all aspects, not just how fast it can proxy requests (unless, again, you're building a proxy server).

于 2012-05-10T04:52:58.600 に答える
1

Webrick を使用してテストを行っています。Webrick は一度に要求に応じてしか処理できないため、すぐに結果は無効になります。一度に複数のリクエストを処理できる、eventmachine の上に構築された thin のようなものを使用する必要があります。すべての同時リクエストでのリクエストあたりの時間、転送速度、および接続時間は、その変更により劇的に改善されます。

また、Google へのネットワーク レイテンシが原因で、実行ごとにリクエスト時間が異なることにも注意してください。数値を数回見て、比較できる平均値を取得する必要があります。

最終的に、ベンチマークで Node と Rails の間に大きな違いが見られることはないでしょう。

于 2012-05-10T04:41:09.550 に答える