我为什么要使用Restify？

Question

我有要求在node.js中构建REST API,并且正在寻找比express.js更轻量级的框架,这可能避免了不需要的功能,并且就像构建REST API的定制框架一样.对于相同的情况,建议从其介绍中进行修改.

阅读为什么使用解决而不表达？看起来好像是一个很好的选择.

但是当我用负载尝试两者时,出乎意料的是.

我在Restify上制作了一个示例REST API,并且每秒充满1000个请求.给我一个惊喜,一段时间后路线开始没有响应.在express.js上构建的同一个应用程序处理所有.

我目前正在将负载应用于API

var FnPush = setInterval(function() {           
    for(i=0;i<1000;i++) 
        SendMsg(makeMsg(i));                
}, 1000);

function SendMsg(msg) {
    var post_data = querystring.stringify(msg);
    var post_options = {
        host: target.host,
        port: target.port,
        path: target.path,
        agent: false,
        method: 'POST',
        headers: {
                'Content-Type': 'application/x-www-form-urlencoded',
                'Content-Length': post_data.length,
                "connection": "close"
            }
    };

    var post_req = http.request(post_options, function(res) {});
    post_req.write(post_data);  
    post_req.on('error', function(e) {          
    }); 
    post_req.end();
}

结果我看起来合情合理吗？如果是这样表达的效率高于在这种情况下的解决方案？或者我测试它们的方式有任何错误吗？

更新以回应评论

改善的行为

1. 当负载超过1000 req.s时,它在1秒内停止处理,直到1015 req.s然后什么都不做.即.我计算的计数器用于计算1015之后停止递增的传入请求.

2. 当喂负载甚至100 reqs.它每秒钟收到1015并且之后没有响应.

Answer 1

在这个博客中有和之间的比较PerfectAPI和结果是比大量的查询更好,所以我使用当前版本的Express和Restify做了一个简单的基准测试Express.jsRestify.jsExpressRestify

这是测试快递的代码:

var express = require('express');
var app = express();

app.get('/hello/:name', function(req, res){
  res.send('hello ' + req.params.name);
});

app.listen(3000);
console.log('Listening on port 3000');

这是以下代码Restify:

var restify = require('restify');
var server = restify.createServer();

server.get('/hello/:name', function(req, res, next) {
    res.send('hello ' + req.params.name);
});

server.listen(3000, function() {
    console.log('Listening on port 3000');
});

我使用ApacheBench进行测试,这是一个使用它的简单示例.

您可以安装它,sudo apt-get install apache2-utils 然后您可以运行此命令进行测试ab -n 10000 -c 100 http://127.0.0.1:3000/.这将使用10000个请求命中服务器,并发度为100.

结果为 Restify

Server Hostname:        127.0.0.1
Server Port:            3000

Document Path:          /hello/mark
Document Length:        12 bytes

Concurrency Level:      100
Time taken for tests:   2.443 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1390000 bytes
HTML transferred:       120000 bytes
Requests per second:    4092.53 [#/sec] (mean)
Time per request:       24.435 [ms] (mean)
Time per request:       0.244 [ms] (mean, across all concurrent requests)
Transfer rate:          555.53 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       8
Processing:     5   24   4.5     23      40
Waiting:        5   24   4.5     23      40
Total:         12   24   4.5     23      40

并为Express:

Server Hostname:        127.0.0.1
Server Port:            3000

Document Path:          /hello/mark
Document Length:        10 bytes

Concurrency Level:      100
Time taken for tests:   2.254 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1890000 bytes
HTML transferred:       100000 bytes
Requests per second:    4436.76 [#/sec] (mean)
Time per request:       22.539 [ms] (mean)
Time per request:       0.225 [ms] (mean, across all concurrent requests)
Transfer rate:          818.89 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       7
Processing:    17   22   4.7     21      55
Waiting:       16   22   4.7     21      55
Total:         18   22   4.9     21      58

通过比较,您可以看到Express速度快Restify但Restify没有阻止并响应所有请求.

任何人都可以尝试此基准测试,您可以更改请求数和并发请求数,以查看对两者的影响.

Answer 2

勘误:这个信息现在错了,继续滚动!

该脚本存在问题导致Restify测试在非预期的路线上进行.这导致连接保持活动,从而降低了开销,从而提高了性能.

这是2015年,我认为情况发生了很大变化.Raygun.io最近公布了一项比较hapi,express和restify的基准.

它说:

我们还确定Restify保持连接活动,这消除了每次从同一客户端调用时创建连接的开销.公平地说,我们还使用关闭连接的配置标志测试了Restify.出于显而易见的原因,您会看到该场景中的吞吐量大幅下降.

看起来Restify在这里是一个赢家,可以更轻松地进行服务部署.特别是如果您正在构建一个服务,该服务接收来自相同客户端的大量请求并希望快速移动.你当然比裸节点获得更多的好处,因为你有像DTrace支持一样的功能.

Answer 3

这是2017年和Raygun.io最新的性能测试,比较了hapi,express,restify和Koa.

它表明Koa比其他框架更快,但由于这个问题是关于表达和解决,Express比快速更快.

它写在帖子中

这表明确实Restify比我初步测试中报告的要慢.

Answer 4

根据Node Knockout描述:

restify是一个node.js模块,用于在Node中创建REST Web服务.restify使构建此类服务的许多难题更容易,例如版本控制,错误处理和内容协商.它还提供内置的DTrace探针,您可以免费快速找到应用程序性能问题的位置.最后,它提供了一个强大的客户端API,可以在失败的连接上处理重试/退避,以及其他一些细节.

可能会修复性能问题和错误.也许这种描述将是充足的动力.

Answer 5

我遇到了类似的问题,通过ab对OS X上的多个框架进行基准测试.在第1000次请求之后,一些堆栈一直死亡.

我显着提高了限制,问题就消失了.

您可以检查maxfiles是否为ulimit(或者仅限启动限制 <OS X)并查看最大值.

希望有所帮助.

Answer 6

2021 年， Fastify ( https://www.fastify.io/benchmarks/ )进行的基准测试表明，Restify 现在比 Express 稍快。

用于运行基准测试的代码可以在这里找到：https://github.com/fastify/benchmarks/。