web-dev-qa-db-ja.com

なぜRestifyを使用する必要があるのですか？

Node.jsでREST AP​​Iを作成する必要があり、express.jsよりも軽量なフレームワークを探していました。おそらく、不要な機能を回避し、 REST AP​​Iを構築しています。同じ場合には、そのイントロからの再構築が推奨されます。

なぜresifyを使用し、表現しないのか は、resifyが良い選択のように思えます。

しかし、両方を負荷で試してみると、驚きがありました。

RestifyでREST AP​​Iのサンプルを作成し、1秒あたり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();
}

私が得た結果は理にかなっていますか？そして、もしそうなら、このシナリオでresifyよりもExpressの方が効率的ですか？または、それらをテストした方法にエラーがありますか？

コメントに応じて更新

restifyの動作

  1. 1000 req.sを超える負荷が供給されると、1015 req.sまで受信してから何もせずに、わずか1秒で処理を停止しました。すなわち。着信要求をカウントするために実装されたカウンタiは、1015以降にインクリメントを停止しました。

  2. 100 reqsの負荷を与えられた場合。 1秒あたり1015まで受信し、その後応答しなくなりました。

node.jsexpressrestify
95
mithunsatheesh

これで blogPerfectAPIと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 をテストに使用しましたが、これは 単純な例 を使用しています。

Sudo apt-get install Apache2-utilsでインストールでき、このコマンドを実行してab -n 10000 -c 100 http://127.0.0.1:3000/をテストできます。これは、同時実行数が100の10000リクエストでサーバーにヒットします。

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はすべての要求をブロックして応答しなかったことがわかります。

誰でもこのベンチマークを試すことができ、リクエスト数と同時リクエスト数を変更して、両方への影響を確認できます。

72
Tareq Salah

正誤表：この情報は間違っています。スクロールを続けてください！

スクリプトに問題があり、意図しないルートでRestifyテストが実行されました。これにより、接続が維持され、オーバーヘッドが削減され、パフォーマンスが向上しました。

これは2015年であり、それ以来状況は大きく変わったと思います。 Raygun.ioは hapi、express、restifyを比較する最近のベンチマーク を投稿しました。

それは言います：

また、Resifyが接続を維持しているため、同じクライアントから呼び出されるたびに接続を作成するオーバーヘッドがなくなります。公平を期すために、接続を閉じるという構成フラグを使用してRestifyをテストしました。明らかな理由から、このシナリオではスループットが大幅に低下します。

Benchmark image from Raygun.io

サービスの展開を容易にするために、ここではRestifyが勝者のようです。特に、同じクライアントから多くのリクエストを受け取り、すばやく移動したいサービスを構築している場合。もちろん、DTraceサポートなどの機能が組み込まれているため、裸のNodeよりも多くの費用を支払うことができます。

49
Masum

これは2017とRaygun.ioによる最新のパフォーマンステストです。 、エクスプレス、リストファイト、コア。

Koaは他のフレームワークよりも高速であることを示していますが、この質問はExpressとRestifyについてであるため、ExpressはRestifyよりも高速です。

そして、それは post

これは、実際にRestifyが最初のテストで報告されたよりも遅いことを示しています。

enter image description here

24
Puneet Singh

Node Knockout description によると：

restifyは、NodeでREST Webサービスを作成するために構築されたnode.jsモジュールです。 restifyは、バージョン管理、エラー処理、コンテンツのネゴシエーションなど、このようなサービスを構築する際の多くの困難な問題を容易にします。また、組み込みのDTraceプローブを提供します。これを無料で入手して、アプリケーションのパフォーマンスの問題の場所をすばやく見つけることができます。最後に、接続に失敗したときに再試行/バックオフを処理する堅牢なクライアントAPIを提供します。

パフォーマンスの問題とバグはおそらく修正できます。たぶんその説明が十分な動機付けになるでしょう。

10
Eric Elliott

私は、abを介してOS X上の複数のフレームワークをベンチマークする同様の問題に遭遇しました。スタックの一部は、1000回目のリクエストの前後で一貫して死亡しました。

私は限界を大幅に突破し、問題は消えました。

Maxfilesがlimit（またはlaunchctl limit <OS Xのみ）にあることを確認し、最大値を確認できます。

お役に立てば幸いです。

5
craigwaterman

express、Resify、またはPerfectAPIと混同さ​​れました。それらすべてでモジュールを開発してみました。主な要件はRESTapiを作成することでした。最終的に速達になり、すべてのフレームワークで行われた1秒あたりの要求で自己をテストし、速達は他よりも良い結果をもたらしました。場合によっては、outshinesエクスプレスを再修正しますが、レースに勝つために縫い目を表現します。私は速達に賛成です。そして、はい、私は機関車jsに出くわしました、いくつかのMVCフレームワークはexpressの上に構築されます。エクスプレスとヒスイを使用した完全なMVCアプリをお探しの方は、機関車をお勧めします。

2
kushvarma