K6
Introduction à K6
K6 est un outil de test de charge open-source conçu pour être simple à utiliser, mais suffisamment puissant pour réaliser des tests de performance avancés. Construit en Go, K6 permet d’exécuter des tests de charge fiables avec un minimum de configuration et un maximum de flexibilité. Son approche en ligne de commande et sa compatibilité avec les pipelines d’intégration continue en font un choix attractif pour les équipes de développement et de DevOps qui cherchent à intégrer des tests de performance dans leurs processus.
Pourquoi choisir K6 ?
L’un des grands atouts de K6 est sa facilité d’utilisation couplée à une grande efficacité. Contrairement aux outils traditionnels de test de charge, souvent lourds à configurer, K6 permet d’écrire des scripts en JavaScript, ce qui le rend immédiatement accessible aux développeurs familiers avec ce langage. Cette approche simplifie aussi le partage des scripts entre les équipes, facilitant la collaboration. K6 offre une interface claire et concise, permettant aux testeurs et développeurs de comprendre facilement les résultats.
Fonctionnalités Clés de K6
- K6 utilise JavaScript pour ses scripts, avec une API accessible pour définir les charges de travail, les seuils et les métriques. Un développeur peut facilement créer un script de test qui simule des personnes et des actions réalistes.
- K6 s’intègre parfaitement dans les environnements CI/CD via son interface en ligne de commande. Cela permet de déclencher des tests de charge lors de chaque déploiement pour identifier des régressions de performance avant que le code n’atteigne la production.
- Étant conçu en Go, K6 est capable de simuler un grand nombre de personnes tout en maintenant une consommation de ressources faible.
- K6 propose des visualisations en temps réel et des métriques détaillées, tant pour les ressources du système que pour les statistiques réseau (latence, temps de réponse, débit, etc.). En plus des rapports locaux, il peut également être intégré à des services externes comme Grafana pour une visualisation plus poussée.
- Une fonctionnalité intéressante de K6 est la possibilité de définir des seuils sur les métriques. Par exemple, si le taux de succès d’une requête passe en dessous d’un certain pourcentage, K6 peut automatiquement déclencher une alerte et stopper le test. Cela permet de s’assurer que les performances respectent toujours les critères définis en amont.
Cas d’utilisation de K6 dans un contexte d’entreprise
K6 est utilisé par des entreprises de toutes tailles pour réaliser des tests de charge dans des environnements variés, allant des sites web aux microservices complexes. Voici quelques scénarios typiques d’utilisation :
- Validation des performances applicatives avant mise en production : K6 permet de simuler des charges importantes pour vérifier que les applications peuvent gérer le volume de personnes prévu.
- Tests de charge pour les APIs : Avec K6, les entreprises peuvent tester leurs APIs pour s’assurer que les réponses sont rapides et fiables, même sous une forte charge.
- Intégration avec des outils d’observabilité : Lorsqu’il est combiné avec des solutions comme Grafana, K6 fournit une vue complète sur les performances et les goulots d’étranglement.
Limites de K6
Malgré ses nombreux avantages, K6 présente également quelques limites. Par exemple, il est uniquement en ligne de commande, ce qui peut être un obstacle pour les équipes habituées aux interfaces graphiques. De plus, bien que K6 soit open-source, les fonctionnalités avancées (comme les tests sur le cloud) sont accessibles via la version payante, ce qui peut limiter l’utilisation pour certaines entreprises au budget restreint.
Installation de K6
Assurez-vous que K6 est installé sur votre machine. Vous pouvez l’installer en suivant les instructions sur k6.io.
Création d’un test de base
Voici un exemple de script en JavaScript pour K6 :
import http from ‘k6/http’;
import { check, sleep } from ‘k6’;
export let options = {
stages: [
{ duration: ’10s’, target: 1 },
{ duration: ‘5s’, target: 1 },
{ duration: ‘5s’, target: 0 },
],
};
export default function () {
let posts = http.get(‘https://jsonplaceholder.typicode.com/posts’);
check(posts, {
‘status is 200’: (r) => r.status === 200,
‘response time < 200ms’: (r) => r.timings.duration < 200,
});
let comments = http.get(‘https://jsonplaceholder.typicode.com/comments’);
check(comments, {
‘status is 200’: (r) => r.status === 200,
‘response time < 200ms’: (r) => r.timings.duration < 200,
});
let users = http.get(‘https://jsonplaceholder.typicode.com/users’);
check(users, {
‘status is 200’: (r) => r.status === 200,
‘response time < 200ms’: (r) => r.timings.duration < 200,
});
sleep(1);
}
Explication du Script
- Configuration des Stages : La section options définit trois étapes de montée en charge :
- Une montée en charge progressive pendant 1 minute pour atteindre 10 personnes.
- Une charge stable pendant 3 minutes avec 10 personnes.
- Une descente progressive à personne en 1 minute.
- Requêtes et Vérifications :
- Pour chaque endpoint (/posts, /comments, /users), une requête GET est envoyée, et des vérifications sont effectuées pour s’assurer que le code de réponse est 200 et que le temps de réponse est inférieur à 200 ms.
- Simuler une Pause : sleep(1); introduit une pause d’une seconde pour simuler un comportement humain réaliste entre les requêtes.
Lancer le test
Pour exécuter ce script, placez-le dans un fichier nommé mon_script.js et lancez-le avec la commande suivante dans votre terminal :
k6 run mon_script.js
Analyse des résultats
Statut HTTP :
Le test montre que la majorité des requêtes ont obtenu un code de statut 200 (✔️ status is 200), ce qui indique que les requêtes ont réussi.
Cependant, on voit également que la condition « temps de réponse inférieur à 200ms » n’est pas toujours respectée (X response time < 200ms), avec 53 échecs pour cette condition sur un total de 54 itérations. Cela suggère que le temps de réponse est parfois trop élevé.
Métriques générales :
Data reçue : 3.5 MB de données ont été reçues avec une moyenne de 171 kB/s.
Data envoyée : 12 kB ont été envoyés à un débit moyen de 573 B/s.
Ces valeurs montrent que le test a simulé un certain volume de trafic, ce qui est utile pour évaluer la bande passante consommée.
Détails sur les requêtes HTTP :
- http_req_duration : C’est la durée totale des requêtes, de la connexion initiale à la réponse finale. La moyenne est de 40.6ms, mais on observe une valeur maximale élevée de 207.04ms, avec les percentiles 90 (p(90)) et 95 (p(95)) proches de 48ms et 85ms respectivement.
- http_req_blocked : Il s’agit du temps pendant lequel la requête a été bloquée, avec une moyenne de 2.82ms. Cela peut inclure le temps d’attente pour établir une connexion. La valeur maximum est à 8.52ms, ce qui est assez raisonnable.
- http_req_connecting : Ce champ montre le temps pris pour établir la connexion TCP, ici 272.78µs en moyenne, ce qui est négligeable par rapport au reste.
Autres métriques HTTP :
- http_req_waiting : C’est le temps d’attente de la réponse du serveur après l’envoi de la requête. La moyenne est de 36.98ms, ce qui est globalement bon, mais le maximum (206.15ms) montre que certains appels ont pris plus de temps que d’autres.
- http_req_receiving : Temps pour recevoir la réponse, avec une moyenne de 3.35ms, maximum à 20.24ms. C’est rapide, indiquant que le téléchargement des réponses n’est pas un point de lenteur ici.
Iterations et Scénario :
- Iterations : 18 itérations ont été réalisées dans ce test, avec une durée moyenne par itération de 1.13s.
- vus (virtual users) : Le test a utilisé 1 utilisateur virtuel (VU), avec un maximum de 1 VU, ce qui indique que c’était un test léger.
Analyse des performances
- Temps de réponse : Bien que les temps moyens de requête soient relativement bas, la contrainte de moins de 200ms pour toutes les requêtes n’a pas été respectée, ce qui indique que, dans des conditions de charge plus élevées ou dans des cas spécifiques, l’application pourrait avoir des goulots d’étranglement.
- Stabilité : La stabilité du test semble bonne, avec très peu d’échecs (0%) et des valeurs de percentiles raisonnables, mais il faudrait probablement augmenter la charge (plus de VUs) pour voir comment l’application se comporte sous un stress plus intense.