我为什么要使用Restify?

我需要在node.js中构build一个REST API,并且正在寻找一个比express.js更轻量级的框架,这可能会避免不必要的function,并且会像构buildREST API的定制框架那样工作。 对于同样的情况,推荐从其介绍中解脱。

阅读为什么使用restify而不是expression? 看起来像restify是一个不错的select。

但是,当我尝试了两个负载,这个惊喜来了。

我在Restify上创build了一个示例REST API,并以每秒1000个请求的速度进行泛滥。 我感到惊讶的是,一段时间后,这条路线开始没有响应。 构build在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(); } 

我得到的结果似乎是合理的吗? 如果是这样,expression更有效比在这种情况下解决? 还是在我testing他们的方式有任何错误?

根据意见更新

行为的尊重

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

  2. 当用100甚至100的负荷喂食时。 它每秒收到1015,并在此之后不响应。

在这篇博客中,我们对PerfectAPIExpress.jsRestify.js进行了比较,结果是Express对于大量的查询要好于Restify ,所以我用当前版本的Express和Restify做了一个简单的基准testing

以下是testingexpress的代码:

 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进行testing,这是一个简单的例子来使用它。

你可以用sudo apt-get install apache2-utils来安装它,然后你可以运行这个命令来testingab -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 

通过比较,您可以看到ExpressRestify快,但Restify没有阻止并响应所有请求。

任何人都可以尝试这个基准,你可以改变请求的数量和并发请求的数量,以查看对两者的影响。

更正 :这个信息现在是错误的,继续滚动!

导致Restifytesting的脚本在意外路线上出现了问题。 这导致连接保持活着状态,由于降低了开销而导致性能得到提高。


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

它说:

我们还发现,Restify保持连接活着,每次从同一个客户端调用时都会消除创build连接的开销。 公平地说,我们还用closures连接的configuration标志testing了Restify。 在这种情况下,您会看到显着的吞吐量下降。

来自Raygun.io的基准图像

看起来像Restify在这里是一个赢家更容易服务部署。 特别是如果你正在build立一个服务,接收来自同一客户的大量请求,并想快速移动。 因为您拥有像DTrace支持的function,所以您当然会比裸节点获得更多的回报。

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

这表明Koa比其他框架更快,但是由于这个问题是关于expression和尊重的, Express比速度更快。

这是写在post里

这表明确实Restify比我在最初的testing中报告的要慢。

在这里输入图像说明

根据Node Knockout的描述 :

restify是一个node.js模块,用于在Node中创buildREST Web服务。 restify使构build这样一个服务的许多难题成为可能,如版本控制,error handling和内容协商。 它还提供了内置的DTrace探针,可以免费获取,以快速找出应用程序的性能问题所在。 最后,它提供了一个强大的客户端API,可以处理失败连接上的重试/退避以及其他一些细节问题。

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

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

我大大地碰到了极限,问题就消失了。

你可以检查你的maxfiles是否在ulimit ,(或仅限于launchctl的限制 <OS X),看看最大值是多less。

希望有所帮助。

我很困惑与expression或resify或perfectAPI。 甚至尝试过开发一个模块。 主要的要求是做一个RESTapi。 但最后以明示结束,用所有框架上每秒做出的请求testing了我自己,expression的结果比其他的要好。 尽pipe在某些情况下,他们的performance不尽如人意。 我赞成快递。 是的,我也遇到了机车js,一些MVC框架build立在快车之上。 如果有人用快递和玉来寻找完整的MVC应用程序,那就去机车。