Test de charge Baeldung avec Gatling

Exemple de test de charge avec Gatling

1. Vue d'ensemble

Dans lesprevious tutorial, nous avons vu comment utiliser Gatling pour tester le chargement d'une application Web personnalisée.

Dans cet article, nous utiliserons l'outil de stress Gatling pour mesurer les performances de l'environnement de mise en scène de ce site Web.

2. Le scénario de test

Commençons par définir notre scénario d'utilisation principal, qui se rapproche d'un utilisateur typique qui pourrait naviguer sur le site:

Aller à la page d'accueil
Ouvrir un article depuis la page d'accueil
Allez à Guides / REST
Aller à la catégorie REST
Aller à l'archive complète
Ouvrir un article de l'archive

3. Enregistrer le scénario

Maintenant, nous allons enregistrer notre scénario à l'aide de l'enregistreur Gatling - comme suit:

$GATLING_HOME/bin/recorder.sh

Et pour les utilisateurs Windows:

%GATLING_HOME%\bin\recorder.bat

Remarque:GATLING_HOME est votre répertoire d'installation Gatling.

Il existe destwo modes for Gatling Recorder: proxy HTTP et convertisseur HAR.

Nous avons discuté du mode proxy HTTP en détail dans lesprevious tutorial - jetons maintenant un œil à l'option HAR Converter.

3.1. Convertisseur HAR

HAR est l'abréviation de HTTP Archive - qui est un format essentiellementrecords the full information about a browsing session.

Nous pouvons obtenir les fichiers HAR à partir du navigateur puis utiliser Gatling Recorder pour le convertir en une simulation.

Nous allons créer notre fichier HAR à l'aide des outils de développement Chrome:

Menu → Plus d'outils → Outils de développement
Aller à l'ongletNetwork
Assurez-vous quePreserve log est coché
Une fois que vous avez fini de naviguer sur le site Web, cliquez avec le bouton droit sur les demandes que vous souhaitez exporter.
Ensuite, sélectionnez Copier tout en tant que HAR.
Collez-les dans un fichier, puis importez-le à partir de l'enregistreur Gatling.

Lorsque vous avez terminé d’ajuster l’enregistreur Gatling selon vos préférences, cliquez sur Démarrer.

Notez que le dossier de sortie est par défautGATLING_HOME/user-files-simulations

4. La simulation

Le fichier de simulation généré est écrit de manière similaire en scala. C'est généralement correct, mais pas très lisible, nous allons donc faire quelques ajustements pour nettoyer. Voici notre simulation finale:

class RestSimulation extends Simulation {

    val httpProtocol = http.baseURL("http://staging.example.com")

    val scn = scenario("RestSimulation")
      .exec(http("home").get("/"))
      .pause(23)
      .exec(http("article_1").get("/spring-rest-api-metrics"))
      .pause(39)
      .exec(http("rest_series").get("/rest-with-spring-series"))
      .pause(60)
      .exec(http("rest_category").get("/category/rest/"))
      .pause(26)
      .exec(http("archive").get("/full_archive"))
      .pause(70)
      .exec(http("article_2").get("/spring-data-rest-intro"))

    setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)
}

Une note importante ici est que le fichier de simulation complet est beaucoup plus volumineux; ici,we didn’t include static resources pour plus de simplicité.

5. Exécutez le test de charge

Maintenant, nous pouvons exécuter notre simulation - comme suit:

$GATLING_HOME/bin/gatling.sh

Et pour les utilisateurs Windows:

%GATLING_HOME%\bin\gatling.bat

L'outil Gatling analyseraGATLING_HOME/user-files-simulations et listera toutes les simulations trouvées pour que nous puissions les choisir.

Après avoir exécuté la simulation, voici à quoi ressemblent les résultats:

Pour un utilisateur:

> request count                                304 (OK=304    KO=0)
> min response time                             75 (OK=75     KO=-)
> max response time                          13745 (OK=13745  KO=-)
> mean response time                          1102 (OK=1102   KO=-)
> std deviation                               1728 (OK=1728   KO=-)
> response time 50th percentile                660 (OK=660    KO=-)
> response time 75th percentile               1006 (OK=1006   KO=-)
> mean requests/sec                           0.53 (OK=0.53   KO=-)
---- Response Time Distribution ------------------------------------
> t < 800 ms                                           183 ( 60%)
> 800 ms < t < 1200 ms                                  54 ( 18%)
> t > 1200 ms                                           67 ( 22%)
> failed                                                 0 (  0%)

Pour 5 utilisateurs simultanés:

> request count                               1520 (OK=1520   KO=0)
> min response time                             70 (OK=70     KO=-)
> max response time                          30289 (OK=30289  KO=-)
> mean response time                          1248 (OK=1248   KO=-)
> std deviation                               2079 (OK=2079   KO=-)
> response time 50th percentile                504 (OK=504    KO=-)
> response time 75th percentile               1440 (OK=1440   KO=-)
> mean requests/sec                          2.411 (OK=2.411  KO=-)
---- Response Time Distribution ------------------------------------
> t < 800 ms                                           943 ( 62%)
> 800 ms < t < 1200 ms                                 138 (  9%)
> t > 1200 ms                                          439 ( 29%)
> failed                                                 0 (  0%)

Pour 10 utilisateurs simultanés:

> request count                               3058 (OK=3018   KO=40)
> min response time                              0 (OK=69     KO=0)
> max response time                          44916 (OK=44916  KO=30094)
> mean response time                          2193 (OK=2063   KO=11996)
> std deviation                               4185 (OK=3953   KO=7888)
> response time 50th percentile                506 (OK=494    KO=13670)
> response time 75th percentile               2035 (OK=1976   KO=15835)
> mean requests/sec                          3.208 (OK=3.166  KO=0.042)
---- Response Time Distribution ----------------------------------------
> t < 800 ms                                          1752 ( 57%)
> 800 ms < t < 1200 ms                                 220 (  7%)
> t > 1200 ms                                         1046 ( 34%)
> failed                                                40 (  1%)

Notez que certaines des requêtes ont échoué lors du test de 10 utilisateurs simultanés, simplement parce que l'environnement de test n'est pas capable de gérer ce type de charge.

6. Conclusion

Dans cet article rapide, nous avons exploré l'option HAR d'enregistrement de scénarios de test dans Gatling ainsi qu'un simple test initial de example.com.

TOC