Por que devo usar o Restify?


101

Eu tinha o requisito de construir uma API REST em node.js e estava procurando uma estrutura mais leve do que express.js, que provavelmente evita os recursos indesejados e funcionaria como uma estrutura customizada para construir APIs REST. Restify de sua introdução é recomendado para o mesmo caso.

Leitura Por que usar restify e not express? parecia que restify é uma boa escolha.

Mas a surpresa veio quando experimentei ambos com carga.

Eu fiz uma API REST de amostra no Restify e a sobrecarreguei com 1000 solicitações por segundo. Surpreendeu-me a rota que começou a não responder depois de um tempo. O mesmo aplicativo criado em express.js tratava de tudo.

Atualmente, estou aplicando a carga à API via

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

Os resultados que obtive parecem razoáveis? E em caso afirmativo, expressar é mais eficiente do que restificar neste cenário? Ou há algum erro na maneira como os testei?

atualizado em resposta aos comentários

comportamento de restificar

  1. quando alimentado com uma carga de mais de 1000 req.s, ele parou de processar em apenas 1 segundo recebendo até 1015 req.s e depois não fez nada. ie. o contador que implementei para contar as solicitações de entrada interrompeu o incremento após 1015.

  2. quando alimentado com uma carga de até 100 reqs. por segundo, ele recebeu até 1015 e não respondeu depois disso.


3
Você já passou por isso: blog.perfectapi.com/2012/… ? Se você pesquisar no google, vai ouvir muita gente duvidando de seu desempenho.
Munim

3
É possível que restificar o bloco em algum lugar ao analisar rotas ou solicitar dados, e não o faz de forma eficiente, o que leva a picos nos tempos de resposta com alta carga. Express.js é leve, mas rico em funcionalidades. A forma como é feito, ainda o torna leve porque a funcionalidade não utilizada não tem muito impacto no desempenho geral. Também é bem mantido e utilizado por grandes empresas, um dos exemplos: o MySpace. Não vejo nenhuma desvantagem em usar Express.js para API REST (na verdade eu fiz exatamente isso), na verdade, ele permite que você, no futuro, melhore sua API, pois a funcionalidade está lá.
moka

1
@Munim: obrigado pelos gráficos. mas a página diz " note, este gráfico está desatualizado porque os problemas de desempenho do Restify foram resolvidos " .. Mas parece que nada foi resolvido. !!
mithunsatheesh

1
@mithunsatheesh Eu também notei isso. Mas como o autor não fez novos estudos, aceitei com uma pitada de sal. O problema no github ainda tem pessoas reclamando de desempenho.
Munim

2
Você pode fornecer mais (restificar) código de amostra?
Adrian Heine

Respostas:


50

Correção : esta informação agora está errada, continue rolando!

houve um problema com o script que fez com que o teste Restify fosse conduzido em uma rota indesejada. Isso fez com que a conexão fosse mantida ativa, melhorando o desempenho devido à sobrecarga reduzida.


Estamos em 2015 e acho que a situação mudou muito desde então. Raygun.io postou um benchmark recente comparando hapi, express e restify .

Diz:

Também identificamos que o Restify mantém as conexões ativas, o que remove a sobrecarga de criar uma conexão cada vez que é chamado do mesmo cliente. Para ser justo, também testamos o Restify com o sinalizador de configuração de fechamento da conexão. Você verá uma diminuição substancial na taxa de transferência nesse cenário por razões óbvias.

Imagem de referência de Raygun.io

Parece que o Restify é um vencedor aqui para facilitar as implantações de serviço. Principalmente se você estiver construindo um serviço que recebe muitas solicitações dos mesmos clientes e quer ser mais rápido. Obviamente, você obtém muito mais rentabilidade do que o Node simples, já que possui recursos como o suporte ao DTrace.


1
a postagem do blog que você está mencionando será útil se o autor revelar mais detalhes sobre o processo de teste que ele seguiu. Veja os comentários abaixo da postagem!
mithunsatheesh de

1
Sim, é verdade, como o benchmarking é difícil de fazer corretamente, seria ótimo se o autor postasse o processo e os códigos. Então, tomei isso como um grão de sal e queria compartilhar com a comunidade.
Masum de

De acordo com a documentação do Restify, ele também suporta DTrace. mcavage.me/node-restify/#dtrace
Jeff Fairley


3
Observe o Adendo no mesmo artigo mencionado antes de tirar conclusões.
Vignesh TV de

26

Isto é 2017 e o teste de desempenho mais tardar até Raygun.io comparando hapi, expresso, restify e Koa.

Isso mostra que Koa é mais rápido que outros frameworks, mas como essa questão é sobre expressar e restificar, Express é mais rápido que restificar.

E está escrito no post

Isso mostra que, de fato, o Restify é mais lento do que o relatado no meu teste inicial.

insira a descrição da imagem aqui


11

De acordo com a descrição do nó Knockout :

restify é um módulo node.js desenvolvido para criar serviços da web REST no Node. O restify facilita muitos dos problemas difíceis de construir tal serviço, como controle de versão, tratamento de erros e negociação de conteúdo. Ele também fornece testes de DTrace integrados que você obtém gratuitamente para descobrir rapidamente onde estão os problemas de desempenho do seu aplicativo. Por último, ele fornece uma API de cliente robusta que lida com novas tentativas / retirada para você em conexões com falha, junto com algumas outras sutilezas.

Problemas de desempenho e bugs provavelmente podem ser corrigidos. Talvez essa descrição seja uma motivação adequada.


5

Eu me deparei com um problema semelhante ao comparar vários frameworks no OS X via ab. Algumas das pilhas morreram, de forma consistente, após cerca do milésimo pedido.

Eu ultrapassei o limite significativamente e o problema desapareceu.

Você pode verificar se seus maxfiles estão em com ulimit , (ou launchctl limit <apenas OS X) e ver qual é o máximo.

Espero que ajude.


Hmm .. parece que pode ser semelhante ao problema connect.bodyParser (), onde cada conexão abre arquivos temporários no sistema de arquivos local?
Eric Elliott,

Os sistemas operacionais geralmente têm limites configuráveis ​​no número de descritores de arquivo que um processo, thread e / ou o sistema operacional pode manipular simultaneamente. Para Linux: stackoverflow.com/questions/760819/… Para MacOS X: stackoverflow.com/questions/7578594/…
AndreasPizsa

2

eu estava confundido com express or restify ou perfectAPI. até tentei desenvolver um módulo em todos eles. o principal requisito era fazer um RESTapi. mas finalmente acabei com o expresso, testei-me com a requisição por segundo feito em todo o framework, o expresso deu melhor resultado que os outros. Embora em alguns casos reitere o brilho, mas expresse costuras para vencer a corrida. Eu faço um sinal positivo para expresso. E sim, eu também encontrei locomotive js, alguma estrutura MVC construída em cima do express Se alguém procura um aplicativo MVC completo usando expresso e jade, vá para locomotiva.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.