node.js - restify vs express
¿Por qué debería usar Restify? (6)
De acuerdo con la descripción Node Knockout :
restify es un nodo node.js creado para crear servicios web REST en Node. restify hace que muchos de los problemas más difíciles de construir un servicio como el control de versiones, el manejo de errores y la negociación de contenido sean más fáciles. También proporciona sondas integradas DTrace que puede obtener de forma gratuita para saber dónde se encuentran los problemas de rendimiento de su aplicación. Por último, proporciona una sólida API de cliente que maneja el reintentos / la desactivación para usted en las conexiones fallidas, junto con algunas otras sutilezas.
Los problemas de rendimiento y los errores probablemente se pueden solucionar. Tal vez esa descripción sea una motivación adecuada.
Tuve el requisito de crear una API REST en node.js y estaba buscando un marco más ligero que express.js, que probablemente evite las características no deseadas y que actúe como un marco personalizado para construir API REST. Restituir desde su introducción se recomienda para el mismo caso.
Lectura ¿Por qué usar restify y no express? Parecía que restify es una buena elección.
Pero la sorpresa llegó cuando probé ambos con una carga.
Hice una REST API de muestra en Restify y la inundé con 1000 solicitudes por segundo. Sorpréndame, la ruta comenzó a no responder después de un tiempo. La misma aplicación desarrollada 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 tengo parecen sensatos? Y si es así, ¿expresar es más eficiente 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
cuando se le alimentó con una carga de más de 1000 req.s, dejó de procesarse en solo 1 segundo recibiendo hasta 1015 req.s y luego no hizo nada. es decir. el contador que implementé para contar las solicitudes entrantes detuvo el incremento después de 1015.
cuando se alimenta con una carga de incluso 100 reqs. por segundo, recibió hasta 1015 y no respondió después de eso.
En este blog.perfectapi.com/2012/… hubo una comparación entre PerfectAPI y Express.js y Restify.js y el resultado fue que Express era mejor que Restify para un gran número de consultas, por lo que hice un punto de referencia simple usando las versiones actuales de Express y Restify.
Aquí está el código para probar express:
var express = require(''express'');
var app = express();
app.get(''/hello/:name'', function(req, res){
res.send(''hello '' + req.params.name);
});
app.listen(3000);
console.log(''Listening on port 3000'');
y aquí está el código para Restify :
var restify = require(''restify'');
var server = restify.createServer();
server.get(''/hello/:name'', function(req, res, next) {
res.send(''hello '' + req.params.name);
});
server.listen(3000, function() {
console.log(''Listening on port 3000'');
});
Utilicé ApacheBench para probar y este es un ejemplo simple para usarlo.
Puede instalarlo con sudo apt-get install apache2-utils luego puede ejecutar este comando para probar ab -n 10000 -c 100 http://127.0.0.1:3000/ . Esto golpeará al servidor con 10000 solicitudes, con una concurrencia de 100.
Los resultados para Restify
Server Hostname: 127.0.0.1
Server Port: 3000
Document Path: /hello/mark
Document Length: 12 bytes
Concurrency Level: 100
Time taken for tests: 2.443 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1390000 bytes
HTML transferred: 120000 bytes
Requests per second: 4092.53 [#/sec] (mean)
Time per request: 24.435 [ms] (mean)
Time per request: 0.244 [ms] (mean, across all concurrent requests)
Transfer rate: 555.53 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.5 0 8
Processing: 5 24 4.5 23 40
Waiting: 5 24 4.5 23 40
Total: 12 24 4.5 23 40
y para Express :
Server Hostname: 127.0.0.1
Server Port: 3000
Document Path: /hello/mark
Document Length: 10 bytes
Concurrency Level: 100
Time taken for tests: 2.254 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1890000 bytes
HTML transferred: 100000 bytes
Requests per second: 4436.76 [#/sec] (mean)
Time per request: 22.539 [ms] (mean)
Time per request: 0.225 [ms] (mean, across all concurrent requests)
Transfer rate: 818.89 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.5 0 7
Processing: 17 22 4.7 21 55
Waiting: 16 22 4.7 21 55
Total: 18 22 4.9 21 58
En comparación, puede ver que Express es más rápido que Restify pero Restify no bloqueó ni respondió a todas las solicitudes.
Cualquiera puede probar este punto de referencia y puede cambiar el número de solicitudes y el número de solicitudes concurrentes para ver el efecto en ambos.
Esto es 2017 y la última prueba de rendimiento de Raygun.io comparando hapi, express, restify y Koa.
Muestra que Koa es más rápido que otros frameworks, pero como esta pregunta es sobre express y restify, Express es más rápido que restify.
Y está escrito en la publicación
Esto muestra que, de hecho, Restify es más lento de lo que se informó en mi prueba inicial.
Me encontré con un problema similar de benchmarking frameworks múltiples en OS X vía ab. Algunas de las pilas murieron, consistentemente, después de la solicitud número 1000.
Golpeé el límite significativamente, y el problema desapareció.
Puede verificar que su maxfiles está en con ulimit (o launchctl limit <OS X solamente) y ver cuál es el máximo.
Espero que ayude.
me confundieron con express o restify o perfectAPI. incluso intenté desarrollar un módulo en todos ellos. el requisito principal era hacer un RESTapi. pero finalmente terminé con express, probé con la solicitud por segundo realizada en todo el framework, el express dio mejores resultados que otros. Aunque en algunos casos restify eclipsa el exprés pero expresa las costuras para ganar la carrera. Yo pulgares arriba para expresar. Y sí, también encontré locomotoras js, algunas MVC framework build además de express. Si alguien está buscando una aplicación MVC completa usando expreso y jade, opta por la locomotora.
Corrección : esta información ahora es incorrecta, sigue desplazándose!
hubo un problema con el script que causaba que la prueba Restify se realizara en una ruta no intencionada. Esto causó que la conexión se mantuviera activa, lo que mejoró el rendimiento debido a una sobrecarga reducida.
Esto es 2015 y creo que la situación ha cambiado mucho desde entonces. Raygun.io ha publicado un benchmark reciente que compara hapi, express y restify .
Dice:
También identificamos que Restify mantiene las conexiones activas, lo que elimina la sobrecarga de crear una conexión cada vez que recibe una llamada del mismo cliente. Para ser justos, también hemos probado Restify con el indicador de configuración para cerrar la conexión. Verá una disminución sustancial en el rendimiento en ese escenario por razones obvias.
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 dinero por dólar que un nodo desnudo porque tienes funciones como el soporte DTrace integrado.