it-swarm.dev

لماذا يجب علي استخدام Restify؟

كان لديّ مطلب لبناء REST API في node.js وكنت أبحث عن إطار عمل خفيف الوزن أكثر من express.js والذي ربما يتجنب الميزات غير المرغوب فيها ويتصرف كإطار عمل مصمم خصيصًا لـ بناء REST واجهات برمجة التطبيقات. Restify من مقدمة يوصى لنفس الحالة.

قراءة لماذا استخدام restify وليس صريح؟ بدا وكأنه restify هو خيار جيد.

لكن المفاجأة جاءت عندما جربتها مع حمولة.

لقد تقدمت بعينة REST واجهة برمجة التطبيقات (API) عن "Restify" وأغرقتها 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 توقفت عن المعالجة في ثانية واحدة فقط تلقي حتى 1015 req.s ثم لا تفعل شيئا. أي. توقف العداد الذي نفذته لحساب الطلبات الواردة الزيادة بعد 1015.

  2. عندما تتغذى مع حمولة من حتى 100 reqs. في الثانية التي تلقاها حتى 1015 وذهب غير مستجيبة بعد ذلك.

95
mithunsatheesh

في هذا blog كانت هناك مقارنة بين PerfectAPI و Express.js و Restify.js وكانت النتيجة أن Express كان أفضل من Restify لعدد كبير من الاستعلامات ، لذلك قمت بإجراء اختبار بسيط باستخدام الإصدارات الحالية البسيطة من Express وإعادة

إليك رمز الاختبار السريع:

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 لم تحظر جميع الطلبات ولا تستجيب لها.

يمكن لأي شخص تجربة هذا المعيار ويمكنك تغيير عدد الطلبات وعدد الطلبات المتزامنة لمعرفة التأثير على كليهما.

72
Tareq Salaheldeen

تصويب : هذه المعلومات خاطئة الآن ، استمر في التمرير!

حدثت مشكلة في البرنامج النصي تسبب في إجراء اختبار Restify على مسار غير مقصود. تسبب هذا في الحفاظ على الاتصال على قيد الحياة مما تسبب في تحسين الأداء بسبب انخفاض الحمل.


هذا هو عام 2015 وأعتقد أن الوضع قد تغير كثيرا منذ ذلك الحين. قام Raygun.io بنشر مؤخرًا مقارنة بين hapi و Express و restify .

انها تقول:

لقد حددنا أيضًا أن Restify تبقي الاتصالات على قيد الحياة مما يزيل النفقات العامة لإنشاء اتصال في كل مرة عند الاتصال من نفس العميل. لكي نكون منصفين ، لقد اختبرنا Restify مع علامة التكوين لإغلاق الاتصال. سترى انخفاضًا كبيرًا في الإنتاجية في هذا السيناريو لأسباب واضحة.

Benchmark image from Raygun.io

يبدو أن Restify هو الفائز هنا لنشر خدمة أسهل. خاصة إذا كنت تقوم بإنشاء خدمة تتلقى الكثير من الطلبات من نفس العملاء وترغب في التحرك بسرعة. بالطبع ، ستحصل على المزيد من الدوافع مقابل باك من Node العارية لأن لديك ميزات مثل دعم DTrace المخبوزات.

49
Masum

هذا هو 2017 وأحدث اختبار أداء بواسطة Raygun.io مقارنة hapi ، والتعبير ، واستعادة ، و Koa.

إنه يوضح أن Koa أسرع من الأُطُر الأخرى ، لكن بما أن هذا السؤال يتعلق بالتعبير والتعديل ، Express أسرع من الاستعادة.

وكتب في بعد

هذا يدل على أن Restify هو بالفعل أبطأ مما ورد في الاختبار الأولي.

 enter image description here 

24
Puneet Singh

وفقًا لـ وصف عقدة خروج المغلوب :

restify هو الغرض من الوحدة النمطية node.js الذي تم إنشاؤه لإنشاء REST خدمات الويب في Node. restify يجعل الكثير من المشاكل الصعبة لبناء مثل هذه الخدمة ، مثل الإصدار ، ومعالجة الأخطاء والتفاوض على المحتوى أسهل. كما يوفر تحقيقات DTrace المضمنة التي يمكنك الحصول عليها مجانًا لمعرفة بسرعة أين تقع مشاكل أداء التطبيق الخاص بك. أخيرًا ، يوفر واجهة برمجة تطبيقات قوية للعميل تتولى إعادة المحاولة/التراجع عنك في الاتصالات الفاشلة ، جنبًا إلى جنب مع بعض التفاصيل الأخرى.

ربما يمكن إصلاح مشاكل الأداء والأخطاء. ربما هذا الوصف سيكون الدافع الكافي.

10
Eric Elliott

واجهت مشكلة مماثلة في تقييم أطر عمل متعددة على OS X عبر ab. ماتت بعض الكدسات ، بثبات ، بعد الطلب رقم 1000.

أنا صدم الحد بشكل كبير ، واختفت المشكلة.

يمكنك التحقق من أن maxfiles موجودة عند ulimit ، (أو launchctl limit <OS X فقط) ومعرفة ما هو الحد الأقصى.

امل ان يساعد.

5
craigwaterman

كنت في حيرة من أمري مع صريح أو استعادة أو perfectAPI. حتى حاول تطوير وحدة في كل منهم. وكان الشرط الرئيسي لجعل RESTAPI. ولكن في النهاية انتهى الأمر بـ express ، اختبر نفسي مع طلب في الثانية قدم على كل الإطار ، أعطى التعبير نتيجة أفضل من الآخرين. على الرغم من أنه في بعض الحالات يعيد إلى الظهور السريع التعبير عن اللحامات السريعة للفوز بالسباق. اعترضت التعبير عن. ونعم ، لقد صادفت أيضًا شبيبة قاطرة ، فبعض إطارات MVC مبنية على قمة صريحة. إذا كان أي شخص يبحث عن تطبيق MVC كامل باستخدام Express و jade ، فانتقل إلى القاطرة.

2
kushvarma