Question

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

阅读Why use restify and not express?似乎是一个很好的选择。

但是，当我尝试使用负载时，出乎意料的是。

我在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();
}

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

更新以回应评论

改善行为

当装载超过1000 req.s的负载时，它在1秒内停止处理，直到1015 req.s然后什么都不做。即。我计算的计数器用于计算在1015之后停止递增的传入请求。
当喂负载甚至100 reqs。它每秒钟收到1015，之后没有响应。

Answer 1

在此blog中，PerfectAPI与Express.js和Restify.js进行了比较，结果是Express优于Restify对于大量的查询，所以我使用当前版本的Express和Restify

制作了一个简单的基准
以下是测试快递的代码：

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进行测试，使用它是simple example。

您可以使用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发布了一个recent benchmark comparing hapi, express and restify。

它说：

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

Benchmark image from Raygun.io

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

Answer 3

2017 以及 Raygun.io 的最新性能测试，比较hapi，express，restify和Koa。

它表明Koa比其他框架更快，但由于这个问题是关于表达和解析， Express比解析更快。

它写在post

中

这表明确实Restify比我最初报道的要慢测试

Answer 4

根据Node Knockout description：

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

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

Answer 5

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

我显着提高了限制，问题就消失了。

您可以使用 ulimit ，（或 launchctl限制＆lt;仅限OS X）检查您的maxfiles是否处于最佳状态。

希望有所帮助。

Answer 6

我对表达或改善或完美的API感到困惑。甚至尝试在所有这些模块中开发模块。主要要求是制作RESTapi。但最终以快递方式结束，用所有框架上的每秒请求测试我的自我，快递给出了比其他人更好的结果。虽然在某些情况下，表现出色的表现，但表达接缝以赢得比赛。我竖起大拇指快递。是的，我也遇到了机车js，一些MVC框架建立在快递之上。如果有人使用快递和玉器寻找完整的MVC应用程序，请选择机车。

Answer 7

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

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

我为什么要使用Restify？

更新以回应评论

7 个答案: