これはRails/Django /などよりもNodejs（expressjs）の利点を実証する良い方法ですか？

Question

UPDATE

これは、（私は申し訳ありませんが、問題のより明確なことをすべきである左）、ベンチマーク、またはルビーの事対ノードのはずはなかったです。ポイントは、ブロッキングと非ブロッキングの違いと、非ブロッキングの書き込みがどれほど簡単かを比較して示すことでした。私はEventMachineを使って比較することができますが、ノードにはこの組み込み関数があります。

---

私は、他の技術の上に何人かの友人にnodejs（およびそれのフレームワーク）の利点を実証するために、主に非ブロックIOの事を理解することは非常に簡単で、いくつかの方法をしようとしています。

私は非常に小さなExpressjsアプリと、GoogleでHTTPリクエストを行い、結果のhtmlの長さを数えるRailsを作成しようとしました。

私のコンピュータ上で予想されたように、Expressjはraからabまで（以下を参照）よりも10倍高速でした。私の欲求は、nodejが他の技術よりも優れている主な利点を実証する "有効な"方法であるかどうかです。 （または、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) 

あなたがテストを行うにはWEBrickにを使用しているRailsの

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) 

Answer 1

。バットを外した場合、Webrickは一度に要求に応じて処理できるだけなので、結果は無効です。あなたは一度に複数の要求を処理できるイベントマシンの上に構築されたthinのようなものを使うべきです。すべての同時リクエスト、転送レート、および接続時間での1リクエストあたりの時間が大幅に向上し、その変更が可能になります。

Googleに対するネットワークの遅延のため、実行ごとにリクエスト時間が異なることにも注意してください。あなたは比較できる平均を得るために数字を数回見るべきです。

最終的には、ベンチマークでNodeとRailsの大きな違いは見られません。

Answer 2

Seanの答えを補完する：

ベンチマークは役に立たない。彼らはあなたが見たいものを示しています。彼らは実際の画像を表示しません。あなたのすべてのアプリケーションがgoogleにプロキシリクエストをするならば、evented serverは本当に良い選択です（node.jsまたはEventMachineベースのサーバー）。しかし、しばしばそれ以上のことをしたいと思っています。これがRailsの方が良い場所です。すべての可能な必要性のための宝石、おなじみのシーケンシャルコード（コールバックスパゲティとは対照的に）、豊富なツーリング、私は続けることができます。

1つのテクノロジを選択する場合は、プロキシ要求の処理速度だけでなく、すべての側面を評価します（プロキシサーバーを構築している場合を除きます）。