เหตุใดฉันจึงควรใช้ Restify


101

ฉันมีความต้องการที่จะสร้าง REST API ใน node.js และกำลังมองหาเฟรมเวิร์กที่มีน้ำหนักเบามากกว่า express.js ซึ่งอาจหลีกเลี่ยงคุณสมบัติที่ไม่ต้องการและจะทำหน้าที่เหมือนเฟรมเวิร์กที่สร้างขึ้นเองสำหรับการสร้าง REST API ขอแนะนำให้ Restify จาก Intro สำหรับกรณีเดียวกัน

อ่านทำไมต้องใช้ restify และไม่แสดงออก? ดูเหมือนว่า restify เป็นทางเลือกที่ดี

แต่ความประหลาดใจเกิดขึ้นเมื่อฉันลองใช้ทั้งสองอย่างด้วยการโหลด

ฉันสร้าง REST API ตัวอย่างใน Restify และมีคำขอ 1,000 คำขอต่อวินาที ทำให้ฉันประหลาดใจที่เส้นทางเริ่มไม่ตอบสนองหลังจากนั้นสักครู่ แอพเดียวกันที่สร้างขึ้นบน 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. เมื่อป้อนด้วยโหลดมากกว่า 1,000 req.s จะหยุดประมวลผลในเวลาเพียง 1 วินาทีรับจนถึง 1,015 req.s จากนั้นไม่ทำอะไรเลย กล่าวคือ. ตัวนับที่ฉันใช้สำหรับการนับคำขอที่เข้ามานั้นหยุดการเพิ่มขึ้นหลังจาก 1015

  2. เมื่อเลี้ยงด้วยโหลด 100 reqs ต่อวินาทีได้รับจนถึง 1,015 และไม่ตอบสนองหลังจากนั้น


3
คุณเคยอ่าน: blog.perfectapi.com/2012/…หรือไม่? หากคุณค้นหาใน google คุณจะได้ยินผู้คนมากมายตั้งข้อสงสัยเกี่ยวกับประสิทธิภาพของมัน
Munim

3
มีความเป็นไปได้ที่จะวางบล็อกไว้ที่ใดที่หนึ่งในขณะที่แยกวิเคราะห์เส้นทางหรือขอข้อมูลและไม่ได้ดำเนินการอย่างมีประสิทธิภาพซึ่งนำไปสู่การเพิ่มขึ้นอย่างรวดเร็วในเวลาตอบสนองที่มีภาระงานสูง Express.js มีน้ำหนักเบา แต่มีฟังก์ชันมากมาย วิธีการสร้างยังคงทำให้เบาเนื่องจากฟังก์ชันที่ไม่ได้ใช้งานไม่มีผลกระทบต่อประสิทธิภาพโดยรวมมากนัก นอกจากนี้ บริษัท ขนาดใหญ่ยังได้รับการดูแลและใช้งานเป็นอย่างดีหนึ่งในตัวอย่าง: MySpace ฉันไม่เห็นข้อเสียใด ๆ ของการใช้ Express.js สำหรับ REST API (ฉันทำอย่างนั้นจริง ๆ ) มันช่วยให้คุณสามารถปรับปรุง API ของคุณในอนาคตได้เนื่องจากมีฟังก์ชันการทำงานอยู่ที่นั่น
moka

1
@ มูนิม: ขอบคุณสำหรับกราฟ แต่หน้าขึ้นว่า " หมายเหตุแผนภูมินี้ล้าสมัยเนื่องจากได้รับการแก้ไขปัญหาการทำงานของ Restify แล้ว " .. แต่ดูเหมือนจะไม่มีอะไรแก้ไขได้ !!
mithunsatheesh

1
@mithunsatheesh ฉันสังเกตเห็นสิ่งเหล่านั้นเช่นกัน แต่เนื่องจากผู้เขียนไม่ได้ทำการศึกษาใหม่ฉันจึงหยิบเกลือเล็กน้อย ปัญหาใน github ยังคงมีคนบ่นเกี่ยวกับประสิทธิภาพ
Munim

2
คุณสามารถให้โค้ดตัวอย่างเพิ่มเติมได้หรือไม่?
Adrian Heine

คำตอบ:


50

Corrigendum : ข้อมูลนี้ไม่ถูกต้องเลื่อนต่อไป!

มีปัญหากับสคริปต์ที่ทำให้การทดสอบ Restify ดำเนินการบนเส้นทางที่ไม่ได้ตั้งใจ สิ่งนี้ทำให้การเชื่อมต่อยังคงมีชีวิตอยู่ทำให้ประสิทธิภาพดีขึ้นเนื่องจากค่าใช้จ่ายที่ลดลง


นี่คือปี 2015 และฉันคิดว่าสถานการณ์เปลี่ยนไปมากตั้งแต่นั้นมา Raygun.io ได้โพสต์มาตรฐานล่าสุดเปรียบเทียบ Hapi ด่วนและ restify

มันบอกว่า:

นอกจากนี้เรายังพบว่า Restify ช่วยให้การเชื่อมต่อมีชีวิตอยู่ซึ่งจะลบค่าใช้จ่ายในการสร้างการเชื่อมต่อทุกครั้งเมื่อถูกเรียกจากไคลเอนต์เดียวกัน เพื่อความเป็นธรรมเราได้ทดสอบ Restify ด้วยแฟล็กการกำหนดค่าของการปิดการเชื่อมต่อ คุณจะเห็นปริมาณงานลดลงอย่างมากในสถานการณ์นั้นด้วยเหตุผลที่ชัดเจน

ภาพเกณฑ์มาตรฐานจาก Raygun.io

ดูเหมือนว่า Restify จะเป็นผู้ชนะสำหรับการปรับใช้บริการที่ง่ายขึ้น โดยเฉพาะอย่างยิ่งหากคุณกำลังสร้างบริการที่ได้รับคำขอจำนวนมากจากลูกค้ารายเดิมและต้องการย้ายอย่างรวดเร็ว แน่นอนว่าคุณจะได้รับผลตอบแทนที่คุ้มค่ามากกว่า Node เปล่าเนื่องจากคุณมีคุณสมบัติเช่นการสนับสนุน DTrace


1
โพสต์บล็อกที่คุณกล่าวถึงมีประโยชน์หากผู้เขียนเปิดเผยรายละเอียดเพิ่มเติมเกี่ยวกับกระบวนการทดสอบที่เขาติดตาม ดูความคิดเห็นใต้โพสต์!
mithunsatheesh

1
ใช่นั่นเป็นความจริงเนื่องจากการเปรียบเทียบทำได้ยากจึงจะดีมากหากผู้เขียนโพสต์กระบวนการและรหัส ก็เลยเอาสิ่งนี้มาเป็นเกลือเม็ดและอยากจะแบ่งปันกับชุมชน
Masum

ตามเอกสาร Restify ยังรองรับ DTrace mcavage.me/node-restify/#dtrace
Jeff Fairley


3
โปรดสังเกตภาคผนวกในบทความเดียวกันที่กล่าวถึงก่อนที่จะได้ข้อสรุป
Vignesh TV

26

นี่คือปี 2017และการทดสอบประสิทธิภาพล่าสุดโดยRaygun.ioเปรียบเทียบ , express, restify และ Koa

แสดงให้เห็นว่า Koa เร็วกว่าเฟรมเวิร์กอื่น ๆ แต่เนื่องจากคำถามนี้เกี่ยวกับการแสดงออกและการปรับปรุงใหม่ Express จึงเร็วกว่าการปรับสภาพใหม่

และมีการเขียนไว้ในโพสต์

นี่แสดงให้เห็นว่าการ Restify ช้ากว่าที่รายงานในการทดสอบครั้งแรกของฉัน

ป้อนคำอธิบายภาพที่นี่


11

ตามคำอธิบาย Node Knockout :

restify เป็นจุดประสงค์ของโมดูล node.js ที่สร้างขึ้นเพื่อสร้างบริการเว็บ REST ใน Node restify ทำให้ปัญหาหนัก ๆ ในการสร้างบริการเช่นการกำหนดเวอร์ชันการจัดการข้อผิดพลาดและการเจรจาต่อรองเนื้อหาทำได้ง่ายขึ้น นอกจากนี้ยังมีหัววัด DTrace ในตัวที่คุณได้รับฟรีเพื่อค้นหาว่าปัญหาด้านประสิทธิภาพของแอปพลิเคชันของคุณอยู่ที่ใด สุดท้ายนี้มี API ไคลเอนต์ที่มีประสิทธิภาพซึ่งจัดการการลองใหม่ / ย้อนกลับสำหรับคุณในการเชื่อมต่อที่ล้มเหลวพร้อมกับรายละเอียดอื่น ๆ

ปัญหาด้านประสิทธิภาพและข้อบกพร่องอาจได้รับการแก้ไข บางทีคำอธิบายนั้นอาจเป็นแรงจูงใจที่เพียงพอ


5

ฉันพบปัญหาที่คล้ายกันในการเปรียบเทียบเฟรมเวิร์กหลาย ๆ เฟรมบน OS X ผ่าน ab สแต็คบางส่วนเสียชีวิตอย่างสม่ำเสมอหลังจากการร้องขอรอบที่ 1000

ฉันชนขีด จำกัด อย่างมากและปัญหาก็หายไป

คุณสามารถตรวจสอบว่า maxfiles ของคุณอยู่ที่ด้วยulimit (หรือlaunchctl ขีด จำกัด <OS X เท่านั้น) และดูว่าสูงสุดคือเท่าใด

หวังว่าจะช่วยได้


อืม .. ฟังดูเหมือนอาจจะคล้ายกับปัญหา connect.bodyParser () ที่ทุกการเชื่อมต่อจะเปิดไฟล์ชั่วคราวบนระบบไฟล์ภายในเครื่อง?
Eric Elliott

โดยปกติระบบปฏิบัติการจะมีขีด จำกัด ที่กำหนดได้เกี่ยวกับจำนวนตัวอธิบายไฟล์ที่กระบวนการเธรดและ / หรือระบบปฏิบัติการสามารถจัดการได้พร้อมกัน สำหรับ Linux: stackoverflow.com/questions/760819/… สำหรับ MacOS X: stackoverflow.com/questions/7578594/…
AndreasPizsa

2

ฉันสับสนกับ express หรือ restify หรือ perfectAPI แม้กระทั่งพยายามพัฒนาโมดูลในทุกโมดูล ข้อกำหนดหลักคือการสร้าง RESTapi แต่สุดท้ายลงเอยด้วยการด่วนทดสอบตัวเองของฉันด้วยการร้องขอต่อวินาทีในทุกเฟรมเวิร์กการแสดงผลที่ดีกว่าคนอื่น ๆ แม้ว่าในบางกรณีจะเน้นการแสดงออกที่ชัดเจน แต่แสดงตะเข็บเพื่อให้ชนะการแข่งขัน ฉันยกนิ้วให้ด่วน และใช่ฉันยังเจอหัวรถจักร js เฟรมเวิร์ก MVC บางตัวสร้างขึ้นบน Express หากใครที่กำลังมองหาแอป MVC ที่สมบูรณ์โดยใช้รถด่วนและหยกให้เลือกหัวรถจักร

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.