Avant de mettre en production un nouveau site internet, surtout lorsque celui-ci est destiné à accueillir un grand nombre de visiteurs, il est préférable de voir recommandé de réaliser un test de charge. Ce test de charge permettra de s'assurer du bon dimensionnement de l'hébergement du site internet. Cela permettra ainsi de déterminer si un hébergement mutualisé où sera nécessaire. Cela permet également de tester la bonne conception du site internet.
Les différents types de tests de charge
Il existe 2 types de tests de charge.
1 – Les tests de charge simples
Cela consiste à faire un nombre de requêtes élevé sur une même page afin de déterminer le temps de réponse. Ce test peut se réaliser facilement à l'aide d'outils en ligne de commande. Pour cela, il suffit de déterminer une ou plusieurs pages de référence, qui seront amenées à générer le plus de trafic, et aller tester une à un avec différents niveaux de requêtes simultanées. Il existe des outils gratuits pour cela, dont le plus connu est très certainement Apache bench . Ici nous allons voir comment réaliser ce test avec l'outil LoadTest développé en NodeJS.
2 – Les "tests de charge"
Le 2e type de test est considéré comme « test de charge », consiste à définir un ou plusieurs scénarios de navigation, puis à atteindre finalement nous déterminé le nombre de requêtes que le hébergement est capable de supporter.
Installer et utiliser LoadTest
Exécutez un test de charge sur l'URL HTTP ou WebSockets sélectionnée. L'API permet une intégration facile dans vos propres tests.
Installation
Installer globalement en tant que root :
# npm install -g loadtest
Sur les systèmes Ubuntu ou Mac OS X, installez-vous en utilisant sudo :
$ sudo npm install -g loadtest
Pour accéder à l'API, il suffit d'ajouter le paquet loadtest à votre package.json
{…"devDependencies" : {"test de charge" : "*"},…}
Compatibilité
Les versions 5 et suivantes doivent être utilisées au moins avec Node.js v10 ou plus :
- Node.js v10 ou plus récent : ^5.0.0
- Node.js v8 ou ultérieur : 4.xy
- Node.js v6 ou antérieur : ^3.1.0.
Pourquoi l'utiliser
loadtest vous permet de configurer et d'affiner les requêtes pour simuler des charges réelles.
Utilisation de base
Exécuter en tant que script pour tester le chargement d'une URL :
$ loadtest [-n requests] [-c concurrency] [-k] URL
L'URL peut être "http://", "https://" ou "ws://". Définissez le nombre maximal de requêtes avec -n et le niveau de concurrence souhaité avec le paramètre -c Utilisez des connexions -k avec -k chaque fois que cela a du sens, ce qui devrait toujours être le cas, sauf lorsque vous testez des connexions d'ouverture et de fermeture. Les paramètres à tiret unique (par exemple -n ) sont conçus pour être compatibles avec Apache ab , sauf qu'ici vous pouvez ajouter les paramètres après l'URL. Pour obtenir de l'aide en ligne, exécutez loadtest sans paramètres :
$ loadtest
Dos d'utilisation
L'ensemble d'options de base est conçu pour être compatible avec Apache ab. Mais alors qu'il ne peut pas définir qu'un niveau de concurrence et permet au serveur de s'y adapter, loadtest vous permet de définir un taux ou des requêtes par seconde avec l'option –rps. Exemple :
loadtest -c 10 --rps 200 http://mysite.com/
Cette commande envoie exactement 200 demandes par seconde avec une concurrence de 10, afin que vous puissiez voir comment votre serveur fait face à des rps soutenus. Même si ab signalait un taux de 200 rps, vous serez surpris de voir comment un taux constant de demandes par seconde affecte les performances : ce ne sont plus les demandes qui s'ajustent au serveur, mais le serveur qui doit s'ajuster aux demandes ! Les taux de rps sont généralement abaissés de façon spectaculaire, au moins 20~25% (dans notre exemple, de 200 à 150 rps), mais la figure résultante est beaucoup plus robuste. loadtest est également assez extensible. En utilisant l'API fournie, il est très facile d'intégrer loadtest à votre paquet, et d'exécuter des tests de charge programmatiques. loadtest rend très facile l'exécution de tests de charge dans le cadre de tests de systèmes, avant de démarrer une nouvelle version de votre logiciel. Les résultats incluent les temps de réponse moyens et les pourcentages, de sorte que vous pouvez interrompre le déploiement, par exemple si 99 % des demandes ne se terminent pas en 10 ms ou moins.
Utilisation à ne pas faire
loadtest saturation assez rapidement un seul processeur. N'utilisez pas loadtest si le processus Node.js est au-dessus de 100% d'utilisation dans le top , ce qui arrive approximativement lorsque votre charge est supérieure à 1000~4000 rps. (Vous pouvez mesurer les limites pratiques de loadtest sur vos machines de test spécifiques en l'exécutant contre un processus simple Apache ou nginx et en voyant quand il atteint 100% de CPU). Il existe de meilleurs outils pour ce cas d'utilisation :
- Apache ab a de grandes performances, il Mais is also par Une exécution Limité de CPU de Seule. Sa limite pratique se situe quelque part autour de ~40 krps.
- weighttp est également compatible avec ab et est censé être très rapide (l'auteur ne l'a pas personnellement utilisé).
- wrk est multithread et adapté à une utilisation lorsque plusieurs CPU sont nécessaires ou disponibles. Il may l' installation Une cependant à nécessiter partir des sources, l' interface fils et pas Ne est ab compatible.
Utilisation régulière
Les paramètres suivants sont compatibles avec Apache ab.
-n requests
Nombre de demandes à envoyer. Remarque : le nombre total de requêtes soumises peut être plus grand que le paramètre s'il y a un paramètre de concurrence ; loadtest rapportera seulement le premier n .
-concurrency
loadtest créera un certain nombre de clients ; ce paramètre en détermine le nombre. Les requêtes provenant de ces clients arriveront simultanément au serveur. Remarque : les demandes ne sont pas transmises en parallèle (à partir de différents processus), mais de manière concurrente (une deuxième demande peut être adressée avant que la première ait reçu une réponse).
-t timelimit
Nombre maximal de secondes à attendre jusqu'à ce que les demandes ne sortent plus. Remarque : ceci est différent d'Apache ab , qui arrête de recevoir les demandes après les secondes données.
-k ou --keepalive
Ouvrez des connexions en utilisant le mode "keep-alive" : utilisez l'en-tête "Connection : Keep-alive' au lieu de 'Connection : Close'. Remarque : use agentkeepalive , qui est plus performant que l'agent node. js par défaut.
-C cookie-name=value
Envoyer un cookie avec la requête. Le cookie nom=valeur est alors envoyé au serveur. Ce paramètre peut être autant de fois que nécessaire.
-H header:value
Envoyez un en-tête personnalisé avec la requête. La ligne header:value est alors envoyée au serveur. Ce paramètre peut être autant de fois que nécessaire. Exemple :
$ loadtest -H user-agent:tester/0.4 ...
Remarque : s'il n'est pas présent, loadtest ajoutera quelques en-têtes par lui-même : l'en-tête "host" analysé à partir de l'URL, un agent utilisateur personnalisé "loadtest/" plus la version ( loadtest/1.1.0 ), et un en-tête accept pour "*/*". Remarque : lorsque le même en-tête est envoyé plusieurs fois, seule la dernière valeur sera prise en compte. Si vous voulez envoyer plusieurs valeurs avec un en-tête, séparez-les par des points-virgules :
$ loadtest -H accept:text/plain;text-html ...
Remarque : si vous devez ajouter un en-tête avec des espaces, veillez à entourer l'en-tête et la valeur de guillemets :
$ loadtest -H "Authorization : Basic xxx=="
-T content-type
Définit le type de contenu MIME pour les données POST. Par défaut : text/plain .
-P POST-body
Envoyez la chaîne de caractères comme corps du POST. Par exemple : -P '{"key" : "a9acf03f"}'
-A PATCH-body
Envoyez la chaîne de caractères comme corps du PATCH. Par exemple : -A '{"key" : "a9acf03f"}'
-method
Envoyer la méthode au lien. Accepteur : [GET, POST, PUT, DELETE, PATCH, get, post, put, delete, patch], La valeur par défaut est GET Ex : -m POST
--data POST some variables
Envoyez des données. Il ne supporte pas la méthode GET. Par exemple --data '{"username" : "test", "password" : "test"}' -T 'application/x-www-form-urlencoded' -m POST Il fallait -m et -T 'application/x-www-form-urlencoded' .
-p POST-file
Envoyer les données stockées dans le fichier donné dans le corps du POST. N'oubliez pas de définir -T sur le bon type de contenu. Si le POST-file a l'extension .js , il sera require d. Il Doit Être un module de noeud valide et il Doït exporter Une Seule fonction, Qui est invoquée Avec un identifiant de Requête Généré automatiquement verser provide le corps de each Requête. Ceci est utile si vous voulez générer dynamiquement le corps de requête et le faire varier pour chaque requête. Exemple :
module. exportations = fonction(requêteId) {// cet objet sera sérialisé en JSON et envoyé dans le corps de la requêterevenir{valeur clé',Id de la demande : Id de la demande} ;} ;
-u PUT-file
Envoyer les données contenues dans le fichier donné en tant que requête PUT. N'oubliez pas de définir -T sur le type de contenu correct. Si PUT-file a .js d'extension, il sera require d. Il Doit Être un module de noeud valide et il Doït exporter Une Seule fonction, Qui est invoquée Avec un identifiant de Requête Généré automatiquement verser provide le corps de each Requête. Ceci est utile si vous voulez générer dynamiquement le corps de requête et le faire varier pour chaque requête. Pour un exemple de fonction, voir ci-dessus pour -p .
-a PATCH-file
Envoyez les données stockées dans le fichier donné sous la forme d'une requête PATCH. N'oubliez pas de définir -T sur le type de contenu correct. Si le PATCH-file a l'extension .js , il sera require d. Il Doit Être un module de noeud valide et il Doït exporter Une Seule fonction, Qui est invoquée Avec un identifiant de Requête Généré automatiquement verser provide le corps de each Requête. Ceci est utile si vous voulez générer dynamiquement le corps de requête et le faire varier pour chaque requête. Pour un exemple de fonction, voir ci-dessus pour -p .
-r
Récupérer les erreurs. Toujours actif : le test de charge ne s'arrête pas sur les erreurs. Après la fin des tests, s'il y avait des erreurs, un rapport avec tous les codes d'erreur sera affiché.
-s
La méthode TLS/SSL à utiliser. (par exemple TLSv1_method) Exemple :
$ loadtest -n 1000 -s TLSv1_method https://www.example.com
-V
Afficher le numéro de version et quitter.
Utilisation avancée
Les paramètres suivants ne sont pas compatibles avec Apache ab.
--rps requestsPerSecond
Contrôle le nombre de demandes par seconde qui sont soumises. Peut être fractionnaire, par exemple --rps 0.5 envoie une demande toutes les deux secondes. Remarque : La concurence n'affecte pas le nombre final de requêtes par seconde, puisque rps sera partagé par tous les clients. Par exemple :
loadtest ; -c 10 --rps 10
enverra un total de 10 rps à l'URL donnée, depuis 10 clients différents (chaque client enverra 1 requête par seconde). Attention : si la concurrence est trop faible, il est possible qu'il n'y ait pas assez de clients pour envoyer toutes les rps, ajustez-la avec -c si nécessaire. Remarque : –rps n'est pas supporté pour les websockets.
--timeout milliseconds
Délai d'attente pour chaque requête générée en millisecondes. Le définir sur 0 désactive le délai d'attente (par défaut).
-R requestGeneratorModule.js
Utiliser une fonction de générateur de demandes personnalisées à partir d'un fichier externe. Un exemple de module générateur de demandes pourrait ressembler à ceci :
module . exportations = fonction ( paramètres , options , client , rappel ) {generateMessageAsync ( fonction ( message ) {si (message){option . headers [ 'Content-Length' ] = message . longueur ;option . headers [ 'Content-Type' ] = 'application/x-www-form-urlencoded' ;}request = client (options, rappel);si (message){demande . écrire (message);}demande de retour ;}}
Voir sample/request-generator.js pour un exemple de code incluant un corps (ou sample/request-generator.ts pour ES6/TypeScript).
--agent (déprécié)
. Ouvre les connexions en utilisant le mode keep-alive. Remarque : au lieu d'utiliser l'agent par défaut, cette option est maintenant un alias pour -k .
--quiet
Ne pas afficher de messages.
--debug
Afficher les messages de débogage.
--insecure
Autoriser les certificats invalides et auto-signés sur https.
--cert path/to/cert.pem
Définit le certificat à utiliser par le client http. Doit être utilisé avec --key .
--key path/to/key.pem
Définit la clé à utiliser par le client http. Doit être utilisé avec --cert .
Serveur
loadtest regroupe un serveur de test. Pour l'exécuter :
$ testserver-loadtest [--delay ms] [error 5xx] [percent yy] [port]
Cette commande affichera le nombre de demandes reçues par seconde, la latence de réponse aux demandes et les en-têtes des demandes sélectionnées. Le serveur renvoyer un texte de cour 'OK' pour chaque requête, de sorte que les mesures de latence ne doivent pas prendre en compte le traitement des requêtes. Si aucun port n'est indiqué, le port par défaut 7357 sera utilisé. Le délai programmé indique au serveur d'attente le nombre de millisecondes indiqué avant de répondre à chaque demande, afin de simuler un serveur occupé. Vous pouvez également simuler des erreurs sur un pourcentage donné de demandes.
Exemple complet
Voyons maintenant comment mesurer les performances du serveur de test. Tout d'abord, nous installons loadtest de manière globale :
$ sudo npm install -g loadtest
Maintenant nous démarrons le serveur de test :
$ testserver-loadtest Listening on port 7357
Dans une autre fenêtre de console, nous exécutons un test de charge contre lui pendant 20 secondes avec une concurrence de 10 (seuls les résultats pertinents sont affichés) :
$ loadtest http://localhost:7357/ -t 20 -c 10 ... Requests: 9589, requests per second: 1915, mean latency: 10 ms Requests: 16375, requests per second: 1359, mean latency: 10 ms Requests: 16375, requests per second: 0, mean latency: 0 ms ... Completed requests: 16376 Requests per second: 368 Total time: 44.503181166000005 s Percentage of the requests served within a certain time 50% 4 ms 90% 5 ms 95% 6 ms 99% 14 ms 100% 35997 ms (longest request)
Les résultats étaient assez erratiques, avec certaines requêtes prenant jusqu'à 36 secondes ; cela suggère que Node.js rencontré certaines requêtes en fichier d'attente pendant longtemps, et y répond de manière irrégulière. Maintenant, nous allons essayer un taux fixe de 1000 rps :
$ loadtest http://localhost:7357/ -t 20 -c 10 --rps 1000 ... Requests: 4551, requests per second: 910, mean latency: 0 ms Requests: 9546, requests per second: 1000, mean latency: 0 ms Requests: 14549, requests per second: 1000, mean latency: 20 ms ... Percentage of the requests served within a certain time 50% 1 ms 90% 2 ms 95% 8 ms 99% 133 ms 100% 1246 ms (longest request)
Encore une fois, les résultats sont erratiques. En fait si on laisse le test tourner pendant 50 secondes on commence à voir des erreurs :
$ loadtest http://localhost:7357/ -t 50 -c 10 --rps 1000 ... Requests: 29212, requests per second: 496, mean latency: 14500 ms Errors: 426, accumulated errors: 428, 1.5% of total requests
Abaissons le taux à 500 rps :
$ loadtest http://localhost:7357/ -t 20 -c 10 --rps 500 ... Requests: 0, requests per second: 0, mean latency: 0 ms Requests: 2258, requests per second: 452, mean latency: 0 ms Requests: 4757, requests per second: 500, mean latency: 0 ms Requests: 7258, requests per second: 500, mean latency: 0 ms Requests: 9757, requests per second: 500, mean latency: 0 ms ... Requests per second: 500 Completed requests: 9758 Total errors: 0 Total time: 20.002735398000002 s Requests per second: 488 Total time: 20.002735398000002 s Percentage of the requests served within a certain time 50% 1 ms 90% 1 ms 95% 1 ms 99% 14 ms 100% 148 ms (longest request)
Beaucoup mieux : on observe un taux soutenu de 500 rps la plupart du temps, 488 rps en moyenne, et 99% des demandes répondues dans les 14 ms. Nous savons maintenant que notre serveur peut accepter 500 rps sans problème. Pas mal pour un serveur Node.js naïf à un seul processus… Nous pouvons encore affiner nos résultats pour trouver à quel point de 500 à 1000 rps notre serveur tombe en panne. Mais recherchons plutôt comment améliorer les résultats. Un candidat évident est d'ajouter keep-alive aux requêtes afin de ne pas avoir à créer une nouvelle connexion pour chaque requête. Les résultats (avec le même serveur de test) sont impressionnants :
$ loadtest http://localhost:7357/ -t 20 -c 10 -k ... Requests per second: 4099 Percentage of the requests served within a certain time 50% 2 ms 90% 3 ms 95% 3 ms 99% 10 ms 100% 25 ms (longest request)
Maintenant vous parlez ! Le taux de régularité passe également à 2 krps :
$ loadtest http://localhost:7357/ -t 20 -c 10 --keepalive --rps 2000 ... Requests per second: 1950 Percentage of the requests served within a certain time 50% 1 ms 90% 2 ms 95% 2 ms 99% 7 ms 100% 20 ms (longest request)
Mal du tout : 2 krps avec un seul cœur, Pas soutenu. Cependant, si vous essayez de le pousser au-delà, à 3 krps, il échouera lamentablement.
API
loadtest ne se limite pas à s'exécuter en ligne de commande ; il peut être contrôlé à l'aide d'une API, ce qui vous permet de tester en charge votre application dans vos propres tests.
Invoquer le test de charge
Pour exécuter un test de charge, il suffit d'appeler la fonction exportée loadTest() avec un ensemble d'options et un callback optionnel :
const loadtest = require('loadtest');options constantes = {URL : 'http://localhost:8000',maxRequêtes : 1000,} ;loadtest.loadTest(options, fonction(erreur, résultat){si (erreur){return console.error('Vous avez une erreur : %s', erreur);}console.log('Tests exécutés avec succès');});
La function(error, result) sera invoquée lorsque le nombre maximum de requêtes est atteint, ou lorsque le nombre maximum de secondes s'est écoulé. Attention : s'il n'y a ni maxRequests ni maxSeconds , les tests s'exécuteront indéfiniment et n'appelleront pas le rappel.
Options
Toutes les options sauf url sont, comme leur nom l'indique, facultatives.
url
L'URL à invoquer. Obligatoire.
concurrency
Combien de clients à démarrer en parallèle.
maxRequests
Un nombre maximum de requêtes ; lorsqu'il est atteint, le test se termine. Remarque : le nombre réel de requêtes demandées peut être plus grand s'il y a un niveau de concurrence ; le test de charge rapportera seulement le nombre maximum de requêtes.
maxSeconds
Nombre maximum de secondes pour exécuter les tests. Remarque : après le nombre de secondes indiqué, loadtest cessera d'envoyer des demandes, mais pourra continuer à des tests par la suite.
timeout
Délai d'attente pour chaque demande générée en millisecondes. La valeur 0 désactive le délai d'attente (par défaut).
cookies
Un tableau de cookies à envoyer. Chaque cookie doit être une chaîne de caractères de la forme name=value.
headers
Un tableau d'en-têtes. Chaque en-tête doit être une entrée dans la carte avec la valeur donnée sous la forme de chaîne. Si vous voulez avoir plusieurs valeurs pour un en-tête, écrivez une seule valeur séparée par des points-virgules, comme ceci :
{ accept : "text/plain;text/html" }
Remarque : lors de l'utilisation de l'API, l'en-tête "host" n'est pas déduit de l'URL mais doit être dit explicitement.
méthode
La méthode à utiliser : POST, PUT. Par défaut : GET.
body
Le contenu à envoyer dans le corps du message, pour les requêtes POST ou PUT. Peut être une chaîne de caractères ou un objet (qui sera converti en JSON).
contentType
Le type MIME à utiliser pour le corps du message. Le type de contenu par défaut est text/plain .
requestsPerSecond
Combien de requêtes chaque client enverra par seconde.
requestGenerator
Fonction de générateur de demande personnalisée. Un exemple de fonction de générateur de requête pourrait ressembler à ceci :
fonction ( paramètres , options , client , rappel ) {generateMessageAsync ( fonction ( message ) ) {request = client ( options , rappel ) ; si ( message ){option . headers [ ' Content-Length ' ] = message . longueur ;option . headers [ ' Content-Type ' ] = ' application/x-www-form-urlencoded ' ;demande . écrire ( message ) ;} demande . fin ( ) ;}}
agentKeepAlive
Utilisez un agent avec « Connexion : Keep-alive ». Remarque : use agentkeepalive , qui fonctionne mieux que l'agent node.js par défaut.
silencieux
N'affiche aucun message.
indexParam
La chaîne donnée sera donnée dans l'URL par un index unique. Ex. : si l'URL est http://test.com/value et indexParam = value , alors l'URL sera :
- http://test.com/1
- http://test.com/2
- …
- body sera également remplacé body : {userid : id_value} sera body : {userid : id_1}
indexParamCallback
Une fonction qui serait utilisée pour remplacer la valeur identifiée via indexParam via un générateur de valeur personnalisée. Ex. : si l'URL est http://test.com/value et indexParam = value et
indexParamCallback : fonction customCallBack ( ) {retour Maths . étage ( Math . aléatoire ( ) * 10 ) ; // retourne un entier aléatoire de 0 à 9}
alors l'URL pourrait être :
- http://test.com/1 (Entier généré aléatoirement 1)
- http://test.com/5 (Entier 5 généré aléatoirement)
- http://test.com/6 (Entier 6 généré aléatoirement)
- http://test.com/8 (Entier généré aléatoirement 8)
- …
- body sera également remplacé body : {userid : id_value} sera body : {userid : id_ & lt; valeur de rappel & gt; }
non sécurisé
Autorisez les certificats non valides et auto-signés sur https.
secureProtocol
La méthode TLS/SSL à utiliser. (par exemple, TLSv1_method) Exemple :
const loadtest = require ( ' loadtest ' ) ; options constantes = {URL : ' https://www.example.com ' ,maxRequêtes : 100 ,SecureProtocol : ' TLSv1_method '} ; test de charge . loadTest ( options , fonction ( erreur ) {si ( erreur ) {console de retour . error ( ' Vous avez une erreur : %s ' , erreur ) ;}console . log ( ' Tests exécutés avec succès ' ) ;} ) ;
statusCallback
Exécuter cette fonction après la fin de chaque opération de requête. Fournit un accès immédiat aux résultats du test pendant que le lot de test est toujours en cours d'exécution. Cela peut être utilisé pour une journalisation personnalisée plus détaillée ou pour développer votre propre feuille de calcul ou une analyse statistique des résultats. Les résultats et l'erreur transmise au rappel sont dans le même format que les résultats transmis au rappel final. De plus, les trois Suivantes Propriétés à l'Sont ajoutées objet result :
- requestElapsed : temps en millisecondes nécessaire pour terminer cette requête individuelle.
- requestIndex : index basé sur 0 de cette requête particulière dans la séquence de toutes les requêtes à effectuer.
- instanceIndex : l'index d'instance loadtest(...) . Ceci est utile si vous appelez loadtest() plus d'une fois.
Vous devrez vérifier si l' error est renseigné afin de déterminer quel objet vérifier pour ces propriétés. Exemple:
const loadtest = require ( ' loadtest ' ) ; fonction statusCallback ( erreur , résultat , latence ) {console . log ( ' Latence actuelle %j, résultat %j, erreur %j ' , latence , résultat , erreur ) ;console . log ( ' —- ' ) ;console . log ( ' Request elapsed milliseconds : ' , result . requestElapsed ) ;console . log ( ' Index de requête : ' , result . requestIndex ) ;console . log ( ' Request loadtest() index d'instance : ' , result . instanceIndex ) ;} options constantes = {URL : ' http://localhost:8000 ' ,maxRequêtes : 1000 ,statusCallback : statusCallback} ; test de charge . loadTest ( options , fonction ( erreur ) {si ( erreur ) {console de retour . error ( ' Vous avez une erreur : %s ' , erreur ) ;}console . log ( ' Tests exécutés avec succès ' ) ;} ) ;
Avertissement : Le format de statusCallback a changé à partir de la version 2.0.0. Auparavant, il s'agissait de statusCallback(latency, result, error) , il a été modifié pour se conformer à la norme Node.js habituelle.
contentInspector
Une fonction qui se déroulerait après chaque requête avant que son statut ne soit ajouté aux statistiques finales. L'est peut être utilisé lorsque vous souhaitez marquer un résultat avec un code d'état 200 http comme un échec ou une erreur. L'objet result transmis à cette fonction de rappel aux mêmes champs que l'objet result transmis à statusCallback . customError peut être ajouté pour marquer ce résultat comme un échec ou une erreur. customErrorCode sera fourni dans les statistiques finales, en plus du code d'état http. Exemple :
fonction contentInspector ( résultat ) {if ( résultat . statusCode == 200 ) {corps const = JSON . parse ( résultat . corps )// comment examiner le corps dépend du contenu que le service renvoieif ( body . status . err_code !== 0 ) {résultat . customError = corps . statut . err_code + " " + corps . statut . messagerésultat . customErrorCode = corps . statut . code_erreur}}} ,
Résultats
Les résultats de latence transmis à votre rappel à la fin du test de charge contiennent un ensemble complet de données, notamment : la latence moyenne, le nombre d'erreurs et les centiles. Un exemple de costume :
{totalDemandes : 1000 ,centiles : {' 50 ' : 7 ,' 90 ' : 10 ,' 95 ' : 11 ,' 99 ' : 15} ,rps : 2824 ,totalTimeSecondes : 0 . 354108 ,signifieLatencyMs : 7 . 72 ,maxLatencyMs : 20 ,totalErreurs : 3 ,codes d'erreur : {' 0 ' : 1 ,' 500 ' : 2}}
Le deuxième paramètre contient des informations sur la requête en cours :{hôte : ' localhost ' ,chemin : ' / ' ,méthode : ' GET ' ,code d'état : 200 ,corps : ' salut ' ,en-têtes : [ … ]}
Démarrer le serveur de test
Pour démarrer le serveur de test, utilisez la fonction exportée startServer() avec un ensemble d'options et un rappel facultatif :
const testserver = require ( ' testserver ' ) ;serveur const = serveur de test . startServer ( { port : 8000 } ) ;
Cette fonction renvoie un serveur HTTP qui peut être close() lorsqu'il n'est plus utile. Les options suivantes sont disponibles.
port
Port facultatif à utiliser pour le serveur. Remarque : le port par défaut est 7357, car le port 80 nécessite des privilèges spéciaux.
delay
Attendez le nombre de millisecondes indiqué pour répondre à chaque requête.
error
Renvoie un code d'erreur HTTP.
percent
Renvoie un code d'erreur HTTP uniquement pour le % de requêtes données. Si aucun code d'erreur n'a été spécifié, la valeur par défaut est de 500.
Fichier de configuration
Il est possible de mettre des options de configuration dans un fichier nommé .loadtestrc dans votre répertoire de travail ou dans un fichier dont le nom est spécifié dans l'entrée loadtest de votre package. json . Les options du fichier ne seront utilisées que si elles ne sont pas définies dans la ligne de commande. La structure attendue du fichier est la suivante :
{" delay " : " Retarder la réponse pour les millisecondes données " ," error " : " Renvoie un code d'erreur HTTP " ," percent " : " Renvoie une erreur (par défaut 500) uniquement pour certains % de requêtes " ," maxRequests " : " Nombre de requêtes à effectuer " ," concurrence " : " Nombre de requêtes à faire " ," maxSeconds " : " Temps maximum en secondes pour attendre les réponses " ," timeout " : " Timeout pour chaque requête en millisecondes " ," méthode " : " méthode pour url " ," contentType " : " Type MIME pour le corps " ," body " : " Données à envoyer " ," file " : " Envoyer le contenu du fichier " ," cookies " : {" clé " : " valeur "} ," en- têtes " : {" clé " : " valeur "} ," secureProtocol " : " Méthode de protocole sécurisé TLS/SSL à utiliser " ," non sécurisé " : " Autoriser les certificats auto-signés sur https " ," cert " : " Le certificat client à utiliser " ," key " : " La clé client à utiliser " ," requestGenerator " : " Module JS avec une fonction de génération de requête personnalisée " ," recover " : " Ne pas quitter en cas d'erreur de réception de socket (par défaut) " ," agentKeepAlive " : " Utiliser un agent http keep-alive " ," proxy " : " Utiliser un proxy pour les requêtes " ," requestPerSecond " : " Spécifiez les requêtes par seconde pour chaque client " ," indexParam " : " Remplace la valeur de l'argument donné par un index dans l'URL "}
Pour plus d'informations sur le nom du fichier de configuration réel, lisez le manuel d'utilisation confinode . Dans la liste des types de fichiers pris en charge , veuillez noter que seuls les chargeurs synchrones peuvent être utilisés avec loadtest .
Exemple complet
Le fichier lib/integration.js montre un exemple complet, qui est également un test d'intégration complet : il démarre le serveur, envoie 1 000 requêtes, attend le rappel et ferme le serveur.
Source de la traduction : https://www.npmjs.com/package/loadtest