introduction
La version v0.27.0 nous a apporté un nouveau moteur d'exécution et de nombreux nouveaux exécuteurs pour répondre à vos besoins spécifiques. Il comprend également une nouvelle API de script avec de nombreuses options différentes pour le réglage et la simulation de la charge du système sous test (SUT). C'est le résultat d'un an et demi de travail sur la tristement célèbre pull request # 1007 .
Pour générer des requêtes à un rythme constant, nous pouvons utiliser
constant-arrival-rateinterprète. Ce runner exécute le test avec des itérations à une fréquence fixe pendant la durée spécifiée. Cela permet à k6 de modifier dynamiquement le nombre d'utilisateurs virtuels actifs (VU) pendant l'exécution du test afin d'atteindre le nombre d'itérations spécifié par unité de temps. Dans cet article, je vais vous expliquer comment utiliser ce scénario pour générer des requêtes à un rythme constant.
Principes de base des options de configuration de script
Jetons un coup d'œil aux paramètres clés utilisés dans k6 pour décrire une configuration de test dans un script qui utilise un
constant-arrival-rateexécuteur:
- executor ():
— k6. VU - — , , . rate()timeUnit( ):
k6ratetimeUnit.
:
rate: 1,timeUnit: '1s'« »rate: 1,timeUnit: '1m'« »rate: 90,timeUnit: '1m'« 90 », 1,5 /, 667 ,rate: 50,timeUnit: '1s'« 50 », 50 (requests per second — RPS), , .. 20
- duration ():
,gracefulStop. preAllocatedVUs:
.maxVUs:
, .
Ensemble, ces paramètres forment un script qui fait partie des options de configuration de test. L'extrait de code ci-dessous est un exemple de
constant-arrival-ratescript.
Dans cette configuration, nous avons un
constant_request_ratescript, qui est un identifiant unique utilisé comme étiquette pour le script. Ce scénario utilise un constant-arrival-rateexécuteur et s'exécute en 1 minute. Chaque seconde ( timeUnit), 1 itération ( rate) sera effectuée . Le pool d'utilisateurs virtuels pré-provisionnés contient 20 instances et peut aller jusqu'à 100, en fonction du nombre de demandes et d'itérations.
Sachez que l'initialisation des utilisateurs virtuels pendant un test peut être gourmande en ressources processeur et donc biaiser les résultats des tests. En général, il est préférable d'en
preAllocatedVUavoir suffisamment pour exécuter le test de charge. Par conséquent, n'oubliez pas d'allouer plus d'utilisateurs virtuels en fonction du nombre de requêtes de votre test et de la vitesse à laquelle vous souhaitez exécuter le test.
export let options = {
scenarios: {
constant_request_rate: {
executor: 'constant-arrival-rate',
rate: 1,
timeUnit: '1s',
duration: '1m',
preAllocatedVUs: 20,
maxVUs: 100,
}
}
};Un exemple de génération de requêtes à fréquence constante avec constant-arrival-rate
Dans le didacticiel précédent, nous avons montré comment calculer le taux de demande constant. Examinons-y à nouveau, en gardant à l'esprit le fonctionnement des scripts:
supposons que vous vous attendiez à ce que votre système testé traite 1000 requêtes par seconde à un point final. La préallocation de 100 utilisateurs virtuels (maximum 200) permet à chaque utilisateur virtuel d'envoyer environ 5 à 10 demandes (sur la base de 100 à 200 utilisateurs virtuels). Si chaque demande prend plus d'une seconde à se terminer, vous finissez par faire moins de demandes que prévu (plus
dropped_iterations), ce qui est le signe de problèmes de performances ou d'attentes irréalistes pour votre système testé. Si tel est le cas, vous devez résoudre les problèmes de performances et redémarrer le test ou modérer vos attentes en ajustant timeUnit.
Dans ce scénario, chaque utilisateur virtuel pré-alloué fera 10 demandes (
ratedivisées parpreAllocatedVU). Si aucune demande n'est reçue dans la seconde, par exemple, il a fallu plus d'une seconde pour obtenir une réponse, ou si votre système testé a mis plus d'une seconde pour terminer la tâche, k6 augmentera le nombre d'utilisateurs virtuels pour compenser les demandes manquées. Le test suivant génère 1 000 demandes par seconde et s'exécute pendant 30 secondes, soit environ 30 000 demandes, comme vous pouvez le voir dans la sortie ci-dessous: http_reqset iterations. De plus, k6 n'a utilisé que 148 utilisateurs virtuels sur 200.
import http from 'k6/http';
export let options = {
scenarios: {
constant_request_rate: {
executor: 'constant-arrival-rate',
rate: 1000,
timeUnit: '1s', // 1000 , ..1000
duration: '30s',
preAllocatedVUs: 100, //
maxVUs: 200, // preAllocatedVU , ,
}
}
};
export default function () {
http.get('http://test.k6.io/contacts.php');
}Le résultat de l'exécution de ce script sera le suivant:
$ k6 run test.js
/\ |‾‾| /‾‾/ /‾/
/\ / \ | |_/ / / /
/ \/ \ | | / ‾‾\
/ \ | |‾\ \ | (_) |
/ __________ \ |__| \__\ \___/ .io
execution: local
script: test.js
output: -
scenarios: (100.00%) 1 executors, 200 max VUs, 1m0s max duration (incl. graceful stop):
* constant_request_rate: 1000.00 iterations/s for 30s (maxVUs: 100-200, gracefulStop: 30s)
running (0m30.2s), 000/148 VUs, 29111 complete and 0 interrupted iterations
constant_request_rate ✓ [======================================] 148/148 VUs 30s 1000 iters/s
data_received..............: 21 MB 686 kB/s
data_sent..................: 2.6 MB 85 kB/s
*dropped_iterations.........: 889 29.454563/s
http_req_blocked...........: avg=597.53µs min=1.64µs med=7.28µs max=152.48ms p(90)=9.42µs p(95)=10.78µs
http_req_connecting........: avg=561.67µs min=0s med=0s max=148.39ms p(90)=0s p(95)=0s
http_req_duration..........: avg=107.69ms min=98.75ms med=106.82ms max=156.54ms p(90)=111.73ms p(95)=116.78ms
http_req_receiving.........: avg=155.12µs min=21.1µs med=105.52µs max=34.21ms p(90)=147.69µs p(95)=190.29µs
http_req_sending...........: avg=46.98µs min=9.81µs med=41.19µs max=5.85ms p(90)=53.33µs p(95)=67.3µs
http_req_tls_handshaking...: avg=0s min=0s med=0s max=0s p(90)=0s p(95)=0s
http_req_waiting...........: avg=107.49ms min=98.62ms med=106.62ms max=156.39ms p(90)=111.52ms p(95)=116.51ms
*http_reqs..................: 29111 964.512705/s
iteration_duration.........: avg=108.54ms min=99.1ms med=107.08ms max=268.68ms p(90)=112.09ms p(95)=118.96ms
*iterations.................: 29111 964.512705/s
vus........................: 148 min=108 max=148
vus_max....................: 148 min=108 max=148Lors de l'écriture d'un script de test, tenez compte des points suivants:
- k6 (), . , ,
maxRedirects: 0. http ,maxRedirects. - . , , , ,
sleep(). - , , .
preAllocatedVU/maxVU, , , ,preAllocatedVU,maxVU.
WARN[0005] Insufficient VUs, reached 100 active VUs and cannot initialize more executor=constant-arrival-rate scenario=constant_request_rate
- ,
drop_iterations,iterationshttp_reqs.dropped_iterations, , . , ,preAllocatedVU. , , , . - , , . :
WARN[0008] Request Failed - N'oubliez pas que l'API de script ne prend pas en charge l'utilisation globale de la durée, du vus et des étapes, bien qu'ils puissent toujours être utilisés. Cela signifie également que vous ne pouvez pas les utiliser avec des scripts.
Conclusion
Avant la version v0.27.0 , k6 ne disposait pas d'un support suffisant pour générer des requêtes à un rythme constant. Par conséquent, nous avons implémenté une solution de contournement en JavaScript , en calculant le temps nécessaire pour traiter les requêtes pour chaque itération du script. Avec la v0.27.0, ce n'est plus nécessaire.
Dans cet article, j'ai expliqué comment k6 peut atteindre un taux de requêtes cohérent avec la nouvelle API de script en utilisant
constant-arrival-rateinterprète. Cet exécuteur simplifie le code et fournit les moyens d'atteindre un nombre fixe de requêtes par seconde. Cela contraste avec une version précédente du même article, dans laquelle j'ai décrit une autre méthode pour obtenir sensiblement les mêmes résultats en calculant le nombre d'utilisateurs virtuels, les itérations et la durée à l'aide d'une formule et d'un code JavaScript standard. Heureusement, cette nouvelle approche fonctionne comme prévu et nous n'avons plus besoin d'utiliser de hacks.
J'espère que vous avez apprécié la lecture de cet article. J'aimerais beaucoup entendre vos commentaires.
