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

У меня было требование создать 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 и после этого перестал отвечать.

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

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

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

Он говорит:

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

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

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

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

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

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

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

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

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

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

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

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

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

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