Comment faire des tests de charge?

, ,
1

Bonjour tout le monde :slight_smile:

Je n’ai pas trouvé ce sujet dans le forum ^^’

Ma question est de savoir comment vous faite vos tests de charges ?

Par exemple, je travaille pour une entreprise qui déploie du BBB (Big Blue Button).

On doit déployer du BBB chez un client mais à distance :3
Cela nous arrive de déployer dans un nos providers.

Mais dans le contrat avec le client il souhaite du BBB pour X utilisateurs avec Y caméras actives.

Mais il y a une chose qui m’intrigue. C’est comment faire un test de charge ?

Bien sûr, on a (l’entreprise) l’expérience dans le produit BBB. Mais quand même !

Comment on fait un test de charge ? Est-ce que c’est possible d’automatiser ? Oui ? Non ? Comment on fait ? Est-ce compatible dans le principe du CI/CD ? Quel rapport dans le cycle DevOps ? Comment ça se passe chez vous ? :slight_smile:

Merci beaucoup par avance :slight_smile:

Cordialement,

Zak,

2

Hello,

je suis pas expert de tests de charges, mais t’as @DamyR qui a tweeté y a pas longtemps sur Artillery: https://blog.wescale.fr/2019/08/01/tests-de-charge-avec-artillery-io/

J’ai aussi d’anciens collègues qui propose Octoperf (https://octoperf.com/), regarde chez eux, tu peux tester gratuitement.

En règle générale c’est orienté tests web en multipliant les sessions HTTP, après pour aller plus loin je laisse d’autres en parler !

A+

1 « J'aime »
3

Hey,

Pour BBB, je connais pas assez, les tests de charges un peu plus. En général quand tu tests des services comme ça tu vas essayer d’attaquer directement l’API en reproduisant au mieux la charge.

En général, je fais comme ça (c’est pas ma plus grosse expertise les tests de charge) :

  • Je créer si ce n’est pas le cas des environements ISO prod (déployable à la demande), si possible avec un monitoring similaire;
  • Je détermine des “parcours” standards d’utilisateurs, avec des répartitions (exemple : 15% de parcours connecté, 35% de parcours non connecté etc…)
  • A partir de ces parcours, j’en déduit des séries d’appels API (avec les auths nécessires)
  • Je regarde si l’application subbit différents types de pics de trafics, s’il est nécessaire de prévoir des tests avec différents contextes.
  • J’écris ensuite les parcours et je les implémente dans l’outil.
  • Ensuite je m’amuse à tout lancer :stuck_out_tongue:

C’est tout à fait possible d’automatiser c’est ce que je fais :slight_smile: Je l’ai fait il y a deux semaines stack tech pour automatiser ça :

Tu peux le mettre dans la CD, mais en général sur des tâches manuel vu que ça reste “lourd”. Dans le cycle DevOps, je le met entre test et release, car à mon sens c’est souvent le test le plus globale qui va toucher aussi bien le dev que l’infra. J’ai tendance à le faire à chaque release majeure (aussi bien sur le dev que l’infra).

Comme le disais @remi, j’aime bien Artillery.io, car je trouve le logiciel bien pensé, les notions de base sont claires et surtout les sénarios de test sont ultra lisible, et intègre pas mal de choses par défauts.

Après tu as d’autres technologies Locust.io par exemple que @cchaudier aime bien. Encore une fois c’est aussi beaucoup une question de goût.

2 « J'aime »
4

Salut.

Perso j’utilise locust.io qui permet d’écrire les tests en python, mais l’outil de DamyR à l’air très sympa, je le note, merci ;p

2 « J'aime »
5

Merci beaucoup @remi !!! :slight_smile:
Voilà un outil où je pourrais me renseigner ! :slight_smile:

6

Merci beaucoup @DamyR ! :slight_smile:

D’accord, il faut avoir accès aux APIs du service en question pour tester la charge si j’ai bien compris.

C’est quoi un environnement ISO ? :sweat_smile:

Intéressant ton parcours de test ! :smiley:

Pour ton automatisation tu utilise Terraform, Packer (je ne connais pas) et/ou Scaleway pour créer ton environnement ? Ansible pour déployer ton App ?

Tu veux dire que les tests sont lourds à lancer automatiquement ?

Normalement dans un cycle DevOps c’est dans l’environnement Test & Release, normal, non ?

J’ai regardé un peu les outils et Artillery.io est vraiment pas mal ! Il est pas mal dans mon cas car je suis le seul Dev et j’ai 2 collègues SysAdmin donc pas forcément dev… Même si j’ai un collègue qui dev quand même un peu en PHP je ne sais pas si en ajoutant Python qui embarque la notion d’objet avec Locust.io ça puisse le faire…

Dans les 2 cas, on peut héberger ces solutions dans notre infra et ça c’est cool ! :slight_smile:

Merci beaucoup pour l’aide :blush:

7

J’ai aussi noté l’outil https://locust.io/ ! :wink:

Je ferais un Benchmarking un jour peut-être :wink:

1 « J'aime »
8

Au final pour vous, c’est long et fastidieux de mettre en place des tests de charges ?

Si oui, pourquoi ?

Même question pour l’automatisation ?

9

Salut,

J’ai fait un peu de Neoload, c’est un produit propriétaire (:expressionless:). Bon dans le cas d’utilisation qui était de faire des tests de charge sur une appli en GWT c’était pas forcement le plus adapté.
Mais le logiciel est pas si mal. Un des plus c’est une offre “cloud” qui permet de facilement générer du trafic depuis plusieurs endroits de la planète et voir l’experience utilisateur en fonction d’où il se trouve.

Sinon je reste sur le classique Jmeter, c’est libre et ça marche plutôt bien et tu trouves plein de tutos etc… Tu peux faire beaucoup de choses par exemple couplé avec Selenium. C’est vieux et pas hype mais ça fait bien le taf.
Le plus pénible c’est de faire les parcours. Ca peut s’enregistrer mais c’est souvent moins bien que de les coder. Ca permet quand même parfois de se faire un modèle.
Jmeter permet aussi de tester les DB via JDBC, voir si tu derives d’un jeu de requetes à un autres.
Un autre truc souvent difficile, c’est l’authentification qui peut se révéler pénible et arriver à bien randomiser les tests. Note: il y a des helpers dans l’outil pour gerer ces parties.

1 « J'aime »
10

De mon côté les derniers tests de charge sur lesquel j’ai travaillé ont été fait avec JMeter, le standard là où je travaille, lancé avec Taurus (https://gettaurus.org/), ce qui m’a permis de les insérer plus facilement dans une chaîne CI/CD (GitLab en l’occurence).

Ce qui est cool avec JMeter c’est que tu le peux le coupler avec InfluxDB pour faire des dashboards Grafana et visualiser plus facilement les conséquences sur le CPU, la RAM, etc en fonction de ton nombre d’utilisateurs en cours.

L’outil Taurus est par ailleurs compatible avec plein d’autre outils, dont l’offre SASS JMeter de BlazeMeter.

1 « J'aime »
11

D’accord, il faut avoir accès aux APIs du service en question pour tester la charge si j’ai bien compris.

En général c’est le plus simple et efficace.

C’est quoi un environnement ISO ?

Dans le cadre là, même capacité technique que la production (machines, autoscaling groups, Lb etc…).

Pour ton automatisation tu utilise Terraform, Packer (je ne connais pas) et/ou Scaleway pour créer ton environnement ? Ansible pour déployer ton App ?

Sur le dernier projet j’avais cette stack, Terraform pour provisionner les ressources d’infrastructure de mon environement de test (machines, réseau, load balancer etc…). Packer à créer des images de machine sur mesures, pour éviter de tout réinstaller à chaque fois et Ansible pour déployer ce qu’il reste et bien sur l’application.

Tu veux dire que les tests sont lourds à lancer automatiquement ?

Dans mon cas j’en fait toujours des infrastructures éphemeres, pour réduire les coûts, éviter de pêter la production (aussi) et surtout pouvoir contrôler le nombre d’utilisateur (oui en prod il y a déjà des utilisateurs :stuck_out_tongue: ). Du coup, provisionner une infrastructure, tout y installer, faire les tests, les exporter et ensuite tout détruire c’est un peu trop lourd à mon sens pour le lancer automatiquement.

Après encore une fois, c’est très lié au contexte et à la manière dont j’ai implémenté les tests. Techniquement rien ne t’emêche de la faire automatiquement.

Normalement dans un cycle DevOps c’est dans l’environnement Test & Release, normal, non ?

Pas compris ta question pour le coup :sweat_smile:

Le gros avantage pour moi d’Artillery.io c’est que la syntaxe est propre à lire, pas besoin de connaitre un langage ou autre. De mémoire, faut check la documentation tu peux même le paramétrer avec des variables d’environement si tu veux l’intégrer totalement à ta CI/CD.

1 « J'aime »
12

Re.

En regardant vite fait l’outil de DamyR, l’avantage de locust et qu’avec les taches écrites en python, je peux dans ces taches faire des process python (exemple: modifier les résultats de la première requete avec de continuer sur la deuxieme, etc…)

Après en principe pour faire de la vrai montée en charge, il faudrait déployer des pods locust.io sur différents cloud provider en les synchronisants pour qu’ils effectuent les tests depuis différents cloud provider/réseaux afin d’être au plus proche de la réalité je pense.
Mais perso étant très compliqué au boulot de faire ouvrir un compte chez un nouveau fournisseur, je lance plusieurs pods locust sur mon cluster de dev et lance les tests.

1 « J'aime »
13

En regardant vite fait l’outil de DamyR, l’avantage de locust et qu’avec les taches écrites en python, je peux dans ces taches faire des process python (exemple: modifier les résultats de la première requete avec de continuer sur la deuxieme, etc…)

J’ai pas trop compris ce que tu ne peut pas faire du coup avec Artillery.io ? Tu peux aussi récupérer des datas d’une requète pour les ré-utiliser :slight_smile:

14

Récupérer les data de la premiere requête, lancer par exemple un calcul sur ces data qui seront par la suite injectés dans la deuxième requêtes, c’est possible ?

15

Oui, tu peux :wink: L’outil est très flexible pour le coup. Sans compter les plugins qui sont utilisables.

2 « J'aime »
16

Hello,

C’est peut être une question séparée en elle même, mais comment vous faites pour gérer le coût de vos tests de charges ? Je n’en ai jamais vraiment fait, mais je me dit qu’un test de charge assez brut ferait vite augmenter la facture vu que beaucoup de services scale “à l’infini” et nous facture en fonction de l’utilisation (parfois réseau) ?

Deuxième question à propos des environnements serverless. Est-ce que c’est vraiment intéressant de tester la mise sous charge d’un service qui est vendu comme pouvant subir la charge ? Est-ce que des tests de charge plus “discrétisé” / “unitaire” (par lambda pour le FaaS) est possible ?

1 « J'aime »
17

Perso j’utilise JMETER couplé avec Terraform pour monter des machines chez OVH.
Grosso modo, je me suis fait une image toute prête chez OVH.
Je monte à la demande 1 serveur principal et X serveurs slaves le tout dans un vRack.
j’envoie mon test sur le serveur principal qui l’envoie sur les secondaires.
Une fois fini, ma facture est connue car chez OVH on ne paye pas à l’utilisation de la bande passante mais à la durée de vie des VM (qq heures pour un gros test)

1 « J'aime »
18

Salut.

De mon côté j’ai effectué les tests sur mon environnement de DEV qui est similaire (un peu moins de node) et qui lui ne peut pas scale.

ça me permet de voir avec 2 nodes (au lieu de 3 en prod) comment l’infra réagis.