¿Por qué debería usar Restify?


101

Tenía el requisito de crear una API REST en node.js y estaba buscando un marco más liviano que express.js que probablemente evita las características no deseadas y actúa como un marco personalizado para construir API REST. Se recomienda Restify de su intro para el mismo caso.

Lectura ¿Por qué usar restify y no express? parecía que restify es una buena opción.

Pero la sorpresa vino cuando probé ambos con una carga.

Hice una API REST de muestra en Restify y la inundé con 1000 solicitudes por segundo. Para mi sorpresa, la ruta comenzó a no responder después de un tiempo. La misma aplicación construida en express.js manejó todo.

Actualmente estoy aplicando la carga a la API a través de

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

¿Los resultados que obtuve parecen razonables? Y si es así, ¿es más eficiente express que restify en este escenario? ¿O hay algún error en la forma en que los probé?

actualizado en respuesta a los comentarios

comportamiento de restify

  1. cuando se alimenta con una carga de más de 1000 solicitudes, deja de procesar en solo 1 segundo, recibe hasta 1015 solicitudes y luego no hace nada. es decir. el contador que implementé para contar las solicitudes entrantes detuvo el incremento después de 1015.

  2. cuando se alimenta con una carga de incluso 100 reqs. por segundo recibió hasta 1015 y dejó de responder después de eso.


3
¿Has pasado por esto: blog.perfectapi.com/2012/… ? Si busca en Google, escuchará a mucha gente que tiene dudas sobre su rendimiento.
Munim

3
Es posible que restaure algún bloque al analizar rutas o solicitar datos, y no lo haga de manera eficiente, lo que genera picos en los tiempos de respuesta con alta carga. Express.js es liviano pero rico en funcionalidades. La forma en que está hecho, aún lo hace liviano porque la funcionalidad no utilizada no tiene mucho impacto en el rendimiento general. Además, está bien mantenido y utilizado por grandes empresas, uno de los ejemplos: MySpace. No veo ninguna desventaja de usar Express.js para la API REST (en realidad hice exactamente eso), en realidad le permite en un futuro mejorar su API ya que la funcionalidad está ahí.
moka

1
@Munim: gracias por los gráficos. pero la página dice " nota, este gráfico está desactualizado desde que se resolvieron los problemas de rendimiento de Restify " ... ¡¡Pero parece que no se ha resuelto nada !!
mithunsatheesh

1
@mithunsatheesh También los noté. Pero como el autor no realizó estudios nuevos, lo tomé con una pizca de sal. El problema en github todavía tiene personas quejándose del rendimiento.
Munim

2
¿Puede dar más código de muestra (restify)?
Adrian Heine

Respuestas:


50

Corrección : esta información ahora es incorrecta, ¡sigue desplazándote!

Hubo un problema con la secuencia de comandos que provocó que la prueba de Restify se realizara en una ruta no deseada. Esto provocó que la conexión se mantuviera activa y mejorara el rendimiento debido a la reducción de la sobrecarga.


Estamos en 2015 y creo que la situación ha cambiado mucho desde entonces. Raygun.io ha publicado un punto de referencia reciente que compara hapi, express y restify .

Dice:

También identificamos que Restify mantiene vivas las conexiones, lo que elimina la sobrecarga de crear una conexión cada vez que se recibe una llamada del mismo cliente. Para ser justos, también hemos probado Restify con la bandera de configuración de cerrar la conexión. Verá una disminución sustancial en el rendimiento en ese escenario por razones obvias.

Imagen de referencia de Raygun.io

Parece que Restify es un ganador aquí para implementaciones de servicios más fáciles. Especialmente si está creando un servicio que recibe muchas solicitudes de los mismos clientes y desea moverse rápidamente. Por supuesto, obtienes mucho más por tu dinero que un Node desnudo, ya que tienes funciones como la compatibilidad con DTrace incorporadas.


1
la publicación del blog que está mencionando es útil, si el autor revela más detalles sobre el proceso de prueba que siguió. ¡Mira los comentarios debajo de la publicación!
mithunsatheesh

1
Sí, eso es cierto, ya que la evaluación comparativa es difícil de hacer correctamente, sería genial si el autor publicara el proceso y los códigos. Así que lo tomé como un grano de sal y quería compartirlo con la comunidad.
Masum

Según los documentos de Restify, también es compatible con DTrace. mcavage.me/node-restify/#dtrace
Jeff Fairley


3
Tenga en cuenta el Apéndice en el mismo artículo mencionado antes de llegar a conclusiones.
Vignesh TV

26

Esta es 2017 y la última prueba de rendimiento por Raygun.io comparando HAPI, expresar, restify y Coa.

Muestra que Koa es más rápido que otros marcos, pero como esta pregunta se trata de express y restify, Express es más rápido que restify.

Y esta escrito en el post

Esto muestra que, de hecho, Restify es más lento de lo que se informó en mi prueba inicial.

ingrese la descripción de la imagen aquí


11

Según la descripción de Node Knockout :

restify es un módulo node.js diseñado específicamente para crear servicios web REST en Node. restify facilita muchos de los problemas difíciles de crear un servicio de este tipo, como el control de versiones, el manejo de errores y la negociación de contenido. También proporciona sondas DTrace integradas que puede obtener de forma gratuita para descubrir rápidamente dónde se encuentran los problemas de rendimiento de su aplicación. Por último, proporciona una API de cliente robusta que maneja el reintento / retroceso por usted en conexiones fallidas, junto con algunas otras sutilezas.

Los problemas de rendimiento y los errores probablemente se puedan solucionar. Quizás esa descripción sea una motivación adecuada.


5

Me encontré con un problema similar al comparar varios marcos en OS X a través de ab. Algunas de las pilas murieron, de manera constante, después de aproximadamente la solicitud número 1000.

Superé el límite de manera significativa y el problema desapareció.

Puede verificar que su maxfiles está en con ulimit , (o launchctl limit <solo OS X) y ver cuál es el máximo.

Espero que ayude.


Hmm ... parece que podría ser similar al problema connect.bodyParser (), donde cada conexión abre archivos temporales en el sistema de archivos local.
Eric Elliott

Los sistemas operativos generalmente tienen límites configurables en el número de descriptores de archivos que un proceso, subproceso y / o el sistema operativo puede manejar simultáneamente. Para Linux: stackoverflow.com/questions/760819/… Para MacOS X: stackoverflow.com/questions/7578594/…
AndreasPizsa

2

Me confundieron con express o restify o perfectAPI. incluso intenté desarrollar un módulo en todos ellos. el principal requisito era hacer un RESTapi. pero finalmente terminé con express, me probé con la solicitud por segundo realizada en todo el marco, el express dio mejor resultado que otros. Aunque en algunos casos restify eclipsa express pero express costuras para ganar la carrera. Doy un pulgar hacia arriba por expreso. Y sí, también me encontré con locomotora js, un marco MVC construido sobre express. Si alguien busca una aplicación MVC completa que use express y jade, busque locomotora.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.