Tại sao tôi nên sử dụng Restify?


101

Tôi có yêu cầu xây dựng API REST trong node.js và đang tìm kiếm một khung công tác nhẹ hơn express.js, có thể tránh các tính năng không mong muốn và sẽ hoạt động giống như một khung được xây dựng tùy chỉnh để xây dựng các API REST. Điều chỉnh từ phần giới thiệu của nó được khuyến nghị cho trường hợp tương tự.

Đọc Tại sao sử dụng restify và không express? có vẻ như thay đổi là một lựa chọn tốt.

Nhưng điều ngạc nhiên đã đến khi tôi thử cả hai với một tải.

Tôi đã tạo một API REST mẫu trên Restify và làm ngập nó với 1000 yêu cầu mỗi giây. Tôi ngạc nhiên là tuyến đường bắt đầu không phản hồi sau một thời gian. Cùng một ứng dụng được xây dựng trên express.js đã xử lý tất cả.

Tôi hiện đang áp dụng tải cho API qua

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

Kết quả tôi nhận được có vẻ hợp lý không? Và nếu như vậy thể hiện có hiệu quả hơn thay đổi trong kịch bản này? Hoặc có bất kỳ lỗi nào trong cách tôi kiểm tra chúng không?

cập nhật để trả lời các bình luận

hành vi điều chỉnh

  1. khi được cung cấp với tải hơn 1000 req.s, nó ngừng xử lý chỉ trong 1 giây nhận cho đến 1015 req.s và sau đó không làm gì cả. I E. bộ đếm mà tôi đã triển khai để đếm các yêu cầu đến đã ngừng tăng sau 10 giờ 15.

  2. khi được cung cấp với tải thậm chí 100 reqs. mỗi giây nó nhận được cho đến 10h15 và không phản hồi sau đó.


3
Bạn đã xem qua trang này chưa: blog.perfectapi.com/2012/… ? Nếu bạn tìm kiếm trên google, bạn sẽ nghe thấy rất nhiều người nghi ngờ về hiệu quả của nó.
Munim

3
Có thể thay đổi khối ở đâu đó trong khi phân tích cú pháp các tuyến đường hoặc yêu cầu dữ liệu và không thực hiện nó một cách hiệu quả, dẫn đến thời gian phản hồi tăng đột biến với tải cao. Express.js nhẹ nhưng có nhiều chức năng. Cách nó được tạo ra, vẫn làm cho nó nhẹ nhàng vì chức năng không được sử dụng không ảnh hưởng nhiều đến hiệu suất tổng thể. Ngoài ra, nó cũng được các công ty lớn duy trì và sử dụng, một trong những ví dụ: MySpace. Tôi không thể thấy bất kỳ nhược điểm nào của việc sử dụng Express.js cho API REST (tôi thực sự đã làm chính xác điều đó), nó thực sự cho phép bạn trong tương lai cải thiện API của mình như chức năng ở đó.
moka

1
@Munim: cảm ơn vì đồ thị. nhưng trang cho biết " lưu ý, biểu đồ này đã lỗi thời vì các vấn đề về hiệu suất Restify đã được giải quyết " .. Nhưng có vẻ như không có gì được giải quyết. !!
mithunsatheesh

1
@mithunsatheesh Tôi cũng nhận thấy những điều đó. Nhưng vì tác giả không tiến hành các nghiên cứu mới, nên tôi đã chấm nó với một chút muối. Vấn đề trên github vẫn có người phàn nàn về hiệu suất.
Munim

2
Bạn có thể cung cấp thêm (điều chỉnh) mã mẫu?
Adrian Heine

Câu trả lời:


50

Corrigendum : thông tin này hiện đã sai, hãy tiếp tục cuộn!

đã xảy ra sự cố với tập lệnh khiến kiểm tra Restify được tiến hành theo lộ trình không mong muốn. Điều này làm cho kết nối được duy trì hoạt động, cải thiện hiệu suất do giảm chi phí.


Đây là năm 2015 và tôi nghĩ tình hình đã thay đổi rất nhiều kể từ đó. Raygun.io đã đăng một điểm chuẩn gần đây so sánh hapi, express và restify .

Nó nói rằng:

Chúng tôi cũng xác định rằng Restify giữ cho các kết nối luôn tồn tại, giúp loại bỏ chi phí tạo kết nối mỗi khi nhận được cuộc gọi từ cùng một ứng dụng khách. Công bằng mà nói, chúng tôi cũng đã thử nghiệm Restify với cờ cấu hình là đóng kết nối. Bạn sẽ thấy thông lượng giảm đáng kể trong trường hợp đó vì những lý do rõ ràng.

Hình ảnh điểm chuẩn từ Raygun.io

Có vẻ như Restify là người chiến thắng ở đây để triển khai dịch vụ dễ dàng hơn. Đặc biệt nếu bạn đang xây dựng một dịch vụ nhận được nhiều yêu cầu từ cùng một khách hàng và muốn di chuyển nhanh chóng. Tất nhiên, bạn sẽ nhận được nhiều tiền hơn rất nhiều so với Node trần vì bạn có các tính năng như hỗ trợ DTrace.


1
bài đăng trên blog mà bạn đang đề cập là hữu ích, nếu tác giả tiết lộ chi tiết hơn về quy trình thử nghiệm mà anh ta đã tuân theo. Xem các bình luận bên dưới bài viết!
mithunsatheesh

1
Vâng, đó là sự thật, vì điểm chuẩn rất khó thực hiện một cách chính xác, sẽ thật tuyệt nếu tác giả đăng quy trình và mã. Vì vậy, tôi coi đây là muối bỏ bể và muốn chia sẻ với cộng đồng.
Masum

Theo tài liệu Restify, nó cũng hỗ trợ DTrace. mcavage.me/node-restify/#dtrace
Jeff Fairley


3
Vui lòng lưu ý Phụ lục trong cùng một bài báo đã đề cập trước khi đi vào kết luận.
Vignesh TV

26

Đây là năm 2017 và là bài kiểm tra hiệu suất mới nhất của Raygun.io so sánh hapi, express, restify và Koa.

Nó cho thấy Koa nhanh hơn các framework khác, nhưng vì câu hỏi này là về express và restify, Express nhanh hơn restify.

Và nó được viết trong bài

Điều này cho thấy rằng Restify thực sự chậm hơn so với báo cáo trong thử nghiệm ban đầu của tôi.

nhập mô tả hình ảnh ở đây


11

Theo mô tả của Node Knockout :

restify là một mục đích mô-đun node.js được xây dựng để tạo các dịch vụ web REST trong Node. restify làm cho rất nhiều vấn đề khó khăn khi xây dựng một dịch vụ như vậy, như tạo phiên bản, xử lý lỗi và thương lượng nội dung dễ dàng hơn. Nó cũng cung cấp các đầu dò DTrace tích hợp sẵn mà bạn nhận được miễn phí để nhanh chóng tìm ra vị trí các vấn đề về hiệu suất ứng dụng của bạn. Cuối cùng, nó cung cấp một API ứng dụng khách mạnh mẽ để xử lý việc thử lại / lùi lại cho bạn khi kết nối không thành công, cùng với một số tiện ích khác.

Các vấn đề về hiệu suất và lỗi có thể được khắc phục. Có thể mô tả đó sẽ là động lực thích hợp.


5

Tôi đã gặp sự cố tương tự khi đo điểm chuẩn nhiều khung trên OS X qua ab. Một số ngăn xếp đã chết, liên tục, sau khoảng yêu cầu thứ 1000.

Tôi đã vượt quá giới hạn đáng kể và vấn đề đã biến mất.

Bạn có thể kiểm tra tệp tối đa của mình đang ở mức ulimit , (hoặc giới hạn khởi chạyctl <chỉ dành cho OS X) và xem mức tối đa là bao nhiêu.

Hy vọng rằng sẽ giúp.


Hmm .. nghe có vẻ như nó có thể giống với sự cố connect.bodyParser (), nơi mọi kết nối đều mở các tệp tạm thời trên hệ thống tệp cục bộ?
Eric Elliott

Hệ điều hành thường có giới hạn có thể định cấu hình về số lượng bộ mô tả tệp mà một tiến trình, luồng và / hoặc hệ điều hành có thể xử lý đồng thời. Đối với Linux: stackoverflow.com/questions/760819/… Đối với MacOS X: stackoverflow.com/questions/7578594/…
AndreasPizsa

2

tôi đã nhầm lẫn với express hoặc restify hoặc perfectAPI. thậm chí đã thử phát triển một mô-đun trong tất cả chúng. yêu cầu chính là tạo RESTapi. nhưng cuối cùng đã kết thúc với express, kiểm tra bản thân của tôi với yêu cầu mỗi giây được thực hiện trên tất cả các khuôn khổ, express cho kết quả tốt hơn những người khác. Mặc dù trong một số trường hợp, reshines express nhưng express đường may để giành chiến thắng trong cuộc đua. Tôi thích thể hiện. Và vâng, tôi cũng đã xem qua js đầu máy, một số khuôn khổ MVC được xây dựng dựa trên tốc độ cao. Nếu bất kỳ ai đang tìm kiếm ứng dụng MVC hoàn chỉnh bằng cách sử dụng express và jade, hãy tìm đầu máy.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.