Question

更新

这不应该是一个基准，或节点与红宝石的事情（我应该在问题中更清楚，对不起）。重点是比较和演示阻塞和非阻塞之间的差异以及编写非阻塞的容易程度。我可以使用EventMachine来比较，但是node有内置，所以这是显而易见的选择。

我试图向一些朋友展示nodejs（及其框架）优于其他技术的优势，某种方式非常容易理解主要是非阻塞IO的事情。

所以我尝试创建一个（非常小的）Expressjs应用程序和一个可以在谷歌上执行HTTP请求并计算生成的html长度的Rails应用程序。

正如预期的那样（在我的电脑上）Expressjs比Rails通过ab快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)

Answer 1

补充肖恩的答案：

基准没用。他们展示了你想看到的东西。他们没有显示真实的图片。如果您的所有应用程序都是谷歌的代理请求，那么即使是服务器也是一个不错的选择（node.js或基于EventMachine的服务器）。但是，你经常想做更多的事情。这就是Rails更好的地方。宝石满足每一种可能的需求，熟悉的顺序代码（与回调意大利面相对），丰富的工具，我可以继续。

当选择一种技术而不是另一种技术时，评估所有方面，而不仅仅是代理请求的速度（除非您正在构建代理服务器）。

Answer 2

您正在使用Webrick进行测试。不管怎样，结果无效，因为Webrick一次只能按要求处理。您应该使用类似thin的东西，它构建在eventmachine之上，它可以一次处理多个请求。您在所有并发请求，传输速率和连接时间的每个请求的时间将大大改善，从而进行更改。

您还应该记住，由于Google的网络延迟，每次运行之间的请求时间会有所不同。您应该多次查看数字以获得可以比较的平均值。

最后，您可能不会在基准测试中看到Node和Rails之间的巨大差异。

这是展示Nodejs（expressjs）优于Rails / Django / etc的好方法吗？

2 个答案: