Зачем мне использовать Restify?


101

У меня было требование создать REST API в node.js, и я искал более легкий фреймворк, чем express.js, который, вероятно, избегал бы нежелательных функций и действовал бы как специально созданный фреймворк для создания REST API. 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();
}

Кажутся ли мне разумными полученные результаты? И если да, то в этом сценарии экспресс более эффективен, чем restify? Или есть ошибка в том, как я их тестировал?

обновлено в ответ на комментарии

поведение restify

  1. при загрузке более 1000 запросов он прекращал обработку всего за 1 секунду, получая до 1015 запросов, а затем ничего не делал. т.е. счетчик, который я реализовал для подсчета входящих запросов, остановился после 1015.

  2. при кормлении с нагрузкой даже 100 треб. в секунду он получил до 1015 и после этого перестал отвечать.


3
Вы прошли через это: blog.perfectapi.com/2012/… ? Если вы выполните поиск в Google, вы услышите, что многие люди сомневаются в его производительности.
Munim

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

1
@Munim: спасибо за графики. но на странице написано « обратите внимание, эта диаграмма устарела, так как проблемы с производительностью Restify были решены » .. Но похоже, что ничего не решено. !!
mithunsatheesh

1
@mithunsatheesh Я тоже это заметил. Но поскольку автор не проводил свежих исследований, я отнесся к этому с недоверием. Проблема на github по-прежнему вызывает жалобы на производительность.
Munim

2
Можете ли вы дать еще (обновить) образец кода?
Adrian Heine

Ответы:


50

Исправление : теперь эта информация неверна, продолжайте прокручивать!

возникла проблема со сценарием, из-за которой тест Restify проводился по непредусмотренному маршруту. Это привело к тому, что соединение осталось активным, что привело к повышению производительности из-за снижения накладных расходов.


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

Он говорит:

Мы также определили, что Restify поддерживает соединения, что устраняет накладные расходы на создание соединения каждый раз при вызове от одного и того же клиента. Честно говоря, мы также протестировали Restify с флагом конфигурации закрытия соединения. В этом сценарии по очевидным причинам вы увидите существенное снижение пропускной способности.

Тестовое изображение от Raygun.io

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


1
сообщение в блоге, о котором вы упоминаете, полезно, если автор более подробно рассказывает о процессе тестирования, которому он следил. Смотрите комментарии под публикацией!
mithunsatheesh

1
Да, это правда, так как бенчмаркинг сложно провести правильно, было бы здорово, если бы автор опубликовал процесс и коды. Поэтому я воспринял это как недовольство и хотел поделиться с сообществом.
Масум

Согласно документам Restify, он также поддерживает DTrace. mcavage.me/node-restify/#dtrace
Джефф Фэйрли,


3
Пожалуйста, обратите внимание на Дополнение к той же статье, упомянутой перед тем, как делать выводы.
Vignesh TV

26

Это 2017 год и последний тест производительности от Raygun.io, сравнивающий hapi, express, restify и Koa.

Это показывает, что Koa быстрее, чем другие фреймворки, но поскольку этот вопрос касается express и restify, Express быстрее, чем restify.

И это написано в посте

Это показывает, что действительно Restify работает медленнее, чем было указано в моем первоначальном тесте.

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


11

Согласно описанию Node Knockout :

restify - это модуль node.js, специально созданный для создания веб-сервисов REST в Node. restify упрощает многие сложные проблемы создания такой службы, такие как управление версиями, обработка ошибок и согласование содержимого. Он также предоставляет встроенные зонды DTrace, которые вы получаете бесплатно, чтобы быстро выяснить, где лежат проблемы с производительностью вашего приложения. Наконец, он предоставляет надежный клиентский API, который обрабатывает повторные попытки / откат при неудачных соединениях, а также некоторые другие тонкости.

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


5

Я столкнулся с аналогичной проблемой при тестировании нескольких фреймворков на OS X через ab. Некоторые из стеков постоянно умирали примерно после 1000-го запроса.

Я значительно превысил лимит, и проблема исчезла.

Вы можете проверить, есть ли ваши maxfiles, с помощью ulimit (или launchctl limit <только для OS X) и посмотреть, каков максимум.

Надеюсь, это поможет.


Хм ... похоже, это может быть похоже на проблему connect.bodyParser (), где каждое соединение открывает временные файлы в локальной файловой системе?
Эрик Эллиотт

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

2

меня смущали экспресс, restify или perfectAPI. даже пробовал разработать модуль во всех из них. основным требованием было сделать RESTapi. но в итоге закончил экспрессом, проверил себя с запросом в секунду, сделанным на всех фреймворках, экспресс дал лучший результат, чем другие. Хотя в некоторых случаях restify затмевает экспресс, но выражает швы для победы в гонке. Я поднимаю палец вверх за экспресс. И да, я также наткнулся на locomotive js, некоторые фреймворки MVC построены поверх Express. Если кто-то ищет полное приложение MVC, используя экспресс и нефрит, выбирайте локомотив.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.