Pourquoi devrais-je utiliser Restify?

Je devais créer une API REST dans node.js et recherchais un framework plus léger que express.js, qui évite probablement les fonctionnalités indésirables et agirait comme une infrastructure personnalisée pour la construction d’API REST. Restify de son intro est recommandé pour le même cas.

Lecture Pourquoi utiliser restify et pas exprimer? semblait être un bon choix.

Mais la surprise est venue quand j’ai essayé les deux avec une charge.

J’ai créé un exemple d’API REST sur Restify et l’ai inondé de 1000 requêtes par seconde. Surpris moi la route a commencé à ne plus répondre après un moment. La même application construite sur express.js gérait tout.

J’applique actuellement la charge à l’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(); } 

Est-ce que les résultats que j’ai obtenus semblent raisonnables? Et si oui, est-il plus efficace que de le redéfinir dans ce scénario? Ou y a-t-il une erreur dans la façon dont je les ai testés?

mis à jour en réponse aux commentaires

comportement de restify

  1. Lorsqu’elle est alimentée avec une charge de plus de 1000 demandes, elle a cessé de traiter en 1 seconde seulement jusqu’à 1015 demandes, puis n’a plus rien fait. c’est à dire. le compteur que j’ai implémenté pour compter les demandes entrantes s’est arrêté après 1015.

  2. avec une charge de 100 reqs. par seconde, il a reçu jusqu’à 10h15 et est devenu non recevable après cela.

Dans ce blog, il y avait une comparaison entre PerfectAPI et Express.js et Restify.js et le résultat était Express était mieux que Restify pour un grand nombre de requêtes, donc j’ai fait un simple test en utilisant les versions actuelles d’Express et Restify

Voici le code pour tester 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'); 

et voici le code pour 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'); }); 

J’ai utilisé ApacheBench pour tester et c’est un exemple simple pour l’utiliser.

Vous pouvez l’installer avec sudo apt-get install apache2-utils puis vous pouvez exécuter cette commande pour tester ab -n 10000 -c 100 http://127.0.0.1:3000/ . Cela va bash le serveur avec 10000 requêtes, avec une concurrence de 100.

Les résultats pour 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 

et pour 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 comparaison, vous pouvez voir Express est plus rapide que Restify mais Restify n’a pas bloqué et répondu à toutes les demandes.

N’importe qui peut essayer ce benchmark et vous pouvez modifier le nombre de requêtes et le nombre de requêtes simultanées pour voir l’effet sur les deux.

Corrigendum : cette information est maintenant fausse, continuez à défiler!

Il y avait un problème avec le script à l’origine du test Restify sur une route involontaire. La connexion a donc été maintenue en vie, ce qui a amélioré les performances grâce à la réduction des frais généraux.


Nous sums en 2015 et je pense que la situation a beaucoup changé depuis. Raygun.io a publié un benchmark récent comparant hapi, express et restify .

Ça dit:

Nous avons également identifié que Restify garde les connexions en vie, ce qui supprime la surcharge liée à la création d’une connexion à chaque appel du même client. Pour être juste, nous avons également testé Restify avec l’indicateur de configuration de la fermeture de la connexion. Vous verrez une diminution substantielle du débit dans ce scénario pour des raisons évidentes.

Image de référence de Raygun.io

On dirait que Restify est un gagnant ici pour faciliter les déploiements de services. Surtout si vous créez un service qui reçoit beaucoup de demandes de la part des mêmes clients et qui veut évoluer rapidement. Bien sûr, vous obtenez bien plus que des nœuds nus, car vous avez des fonctionnalités comme le support de DTrace.

Nous sums en 2017 et le dernier test de performance de Raygun.io comparant hapi, express, restify et Koa.

Cela montre que Koa est plus rapide que les autres frameworks, mais comme cette question concerne l’expression et la restauration, Express est plus rapide que la restauration.

Et c’est écrit dans le post

Cela montre que Restify est en effet plus lent que ce qui est indiqué dans mon test initial.

entrer la description de l'image ici

Selon la description du nœud Knockout :

restify est un module node.js conçu pour créer des services Web REST dans Node. Restify simplifie beaucoup la construction d’un tel service, comme la gestion des versions, la gestion des erreurs et la négociation de contenu. Il fournit également des sondes DTrace intégrées que vous obtenez gratuitement pour identifier rapidement les problèmes de performances de votre application. Enfin, il fournit une API client robuste qui gère les tentatives de réessai / suppression pour vous sur les connexions ayant échoué, ainsi que d’autres subtilités.

Les problèmes de performances et les bogues peuvent probablement être résolus. Peut-être que cette description sera une motivation adéquate.

J’ai rencontré un problème similaire en comparant plusieurs frameworks sous OS X via ab. Certaines des stacks sont mortes systématiquement après la 1000ème requête.

J’ai dépassé la limite de manière significative et le problème a disparu.

Vous pouvez vérifier que votre maxfiles est avec ulimit (ou launchctl limit

J’espère que cela pourra aider.

J’ai été confondu avec express ou restify ou perfectAPI. même essayé de développer un module dans chacun d’eux. l’exigence principale était de fabriquer un RESTapi. mais finalement fini avec express, testé moi-même avec la demande par seconde faite sur tout le cadre, l’express a donné un meilleur résultat que d’autres. Bien que dans certains cas, restaure les tendances expresses mais exprime des raisons de gagner la course. Je le pouce pour exprimer. Et oui, je suis aussi tombé sur des locomotives js, des frameworks MVC construits sur des express. Si vous recherchez une application MVC complète utilisant express et jade, optez pour la locomotive.