Чому я повинен використовувати Restify?


101

У мене була вимога створити API REST в node.js і шукав більш легкий фреймворк, ніж express.js, який, ймовірно, уникає небажаних функцій і діяв би як створена на замовлення рамка для побудови API REST. Відмовитися від її введення рекомендується в тому ж випадку.

Читання Чому слід використовувати рестифікувати, а не висловлювати? здавалося, що відпочити - це хороший вибір.

Але сюрприз стався, коли я спробував обидва з вантажем.

Я зробив зразок 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 п.к. він припинив обробку всього за 1 секунду, отримуючи до 1015 екв., і потім нічого не робив. тобто. лічильник, який я застосував для підрахунку вхідних запитів, припинив приріст після 1015 року.

  2. при харчуванні з вантажем навіть 100 док. за секунду він отримував до 1015 і після цього не відповідав.


3
Чи проходили ви через це: blog.perfectapi.com/2012/… ? Якщо ви шукаєте в Google, ви почуєте, як багато людей сумніваються в його продуктивності.
Мунім

3
Цілком можливо, що дестиліфікувати десь блок під час розбору маршрутів або запиту даних, і це не робити ефективно, що призводить до сплеску часу відгуку з високим навантаженням. Express.js - легкий, але багатий функціоналом. Те, як вона зроблена, все ще робить її легкою, оскільки невикористана функціональність не має великого впливу на надмірну продуктивність. Він також добре підтримується та використовується великими компаніями, один із прикладів: MySpace. Я не бачу жодних недоліків використання Express.js для API REST (я фактично робив саме це), він фактично дозволяє вам в майбутньому вдосконалити API, оскільки функціональність є.
moka

1
@Munim: дякую за графіки. але на сторінці написано " зауважте, ця діаграма застаріла з моменту усунення проблем з продуктивністю ". Але, схоже, нічого не вирішено. !!
mithunsatheesh

1
@mithunsatheesh Я теж помітив їх. Але оскільки автор не проводив свіжих досліджень, я взяв його із щіпкою солі. Випуск у Github все ще має скарги на продуктивність.
Мунім

2
Чи можете ви надати більше (відхилити) зразок коду?
Адріан Гейне

Відповіді:


50

Виправлення : ця інформація зараз помилкова, продовжуйте прокручувати!

виникла проблема зі сценарієм, який спричинив тест Restify на ненавмисному маршруті. Це призвело до збереження зв’язку в живих, що спричинило покращення продуктивності завдяки зменшенню накладних витрат.


Це 2015 рік, і я думаю, що ситуація сильно змінилася. Raygun.io опублікував нещодавній показник порівняння hapi, express та restify .

Він говорить:

Ми також визначили, що Restify підтримує з'єднання в живих, що видаляє накладні витрати на створення з'єднання кожного разу при виклику від одного клієнта. Справедливості ми також перевірили Restify за допомогою прапора конфігурації закриття з'єднання. Ви побачите значне зниження пропускної здатності в цьому сценарії з очевидних причин.

Зображення еталону від Raygun.io

Схоже, Restify є переможцем тут для більш легкого розгортання сервісу. Особливо, якщо ви будуєте службу, яка отримує багато запитів від тих самих клієнтів і хочете швидко переїхати. Звичайно, ви отримаєте набагато більше грошей на долар, ніж голий Вузол, оскільки у вас є такі функції, як підтримка DTrace.


1
публікація блогу, яку ви згадуєте, є корисною, якщо автор розкриє більш детальну інформацію про процес, який він дотримувався. Дивіться коментарі під публікацією!
mithunsatheesh

1
Так, це правда, оскільки тестування складно зробити правильно, було б чудово, якби автор розмістив процес та коди. Тож я сприйняв це як зерно солі і хотів поділитися з громадою.
Масум

Згідно з документами Restify, він також підтримує DTrace. mcavage.me/node-restify/#dtrace
Джефф Ферлі


3
Будь ласка, зверніть увагу на додаток у тій же статті, про яку йдеться, перш ніж приймати висновки.
Vignesh TV

26

Це 2017 рік і останній тест на продуктивність Raygun.io, який порівнює hapi, express, restify та Koa.

Це показує, що Коа швидше, ніж інші рамки, але оскільки це питання стосується експрес-рестифікації, Експрес швидше, ніж рестифікація.

І це написано в дописі

Це свідчить про те, що дійсно Restify повільніше, ніж повідомлялося в моєму початковому тесті.

введіть тут опис зображення


11

Відповідно до опису Node Knockout :

restify - це мета модуля node.js, створена для створення веб-служб REST в Node. restify полегшує безліч важких проблем побудови такої послуги, як версії версій, керування помилками та узгодження контенту. Він також надає вбудовані зонди DTrace, які ви отримуєте безкоштовно, щоб швидко дізнатися, де лежать проблеми в роботі програми. Нарешті, він забезпечує надійний клієнтський API, який обробляє повторний / перешкодний зв’язок для вас при невдалих з'єднаннях, а також деякі інші смакові якості

Проблеми з продуктивністю та помилки, ймовірно, можуть бути виправлені. Можливо, цей опис буде достатньою мотивацією.


5

Я зіткнувся з аналогічною проблемою, в якій зіставлено декілька рамок для OS X через ab. Деякі з пачок загинули послідовно після 1000-го запиту.

Я суттєво наткнувся на межу, і проблема зникла.

Ви можете перевірити MAXFILES знаходиться з усіма обмеженнями , (або launchctl межа <OS X тільки) , і подивитися , що максимум.

Сподіваюся, що це допомагає.


Хм .. здається, це може бути схоже на проблему connect.bodyParser (), де кожне з'єднання відкриває тимчасові файли в локальній файловій системі?
Ерік Елліотт

ОС зазвичай мають налаштовані обмеження щодо кількості дескрипторів файлів, якими процес, нитка та / або ОС можуть одночасно оброблятись. Для Linux: stackoverflow.com/questions/760819 / ... для MacOS X: stackoverflow.com/questions/7578594 / ...
AndreasPizsa

2

Мене плутали з експрес-рестифікацією або досконалимAPI. навіть спробував розробити модуль у всіх. головна вимога полягала в тому, щоб зробити RESTapi. але, нарешті, закінчився експресом, випробував себе з проханням за секунду, зробленим у всіх рамках, експрес дав кращий результат, ніж інші. Хоча в деяких випадках ухиляються відтінки, але висловлюють шви, щоб виграти гонку. Я палець для експресу. І так, я також натрапив на локомотив js, якийсь каркас MVC будується на вершині експресу. Якщо хтось шукає повний додаток MVC, використовуючи експрес та нефрит, вирушайте на локомотив.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.