+33 9 83 01 45 18
webcontact@syloe.fr
Formations Syloé | Blog | Support Linux
Facebook
Twitter
LinkedIn
  • Expertise
    • Conseil
      • Audit
      • Devops
      • Test de charge
      • Expertise Linux
    • Hébergement
      • Hébergement SaaS
      • Serveur Dédié
      • Hébergement Cloud 100% libre
      • Hébergement Cloud : AWS, Azure, Google, OVH
      • Hébergement Cloud Atlassian
    • Infogérance
      • Maintenance de Serveurs
      • Monitoring et Supervision
      • Support Linux
      • Astreinte Linux
  • Nos solutions
    • E-commerçants
    • Éditeurs de logiciels
    • Grands comptes
    • Agences digitales
    • Start-ups
  • Vos besoins
    • Garantie de la performance des sites web
    • Rationalisation des coûts d’infrastructure
    • Pannes informatiques majeures
    • Démarrage ou croissance d’activité
  • Logiciels libres
    • Logiciels libres pour TPE – PME
    • Tester Zimbra
    • Tester Bluemind
  • Me faire rappeler

Test de montée en charge : exemple de rapport simplifié

Contexte du test de montée en charge

Un client nous soumet une problématique concernant la future augmentation en nombre d’utilisateurs de son site internet.
Afin de valider la tenue de charge pour un certain nombre d’utilisateurs, nous allons effectuer un test de montée en charge afin de vérifier que le serveur peut accepter une telle demande en fournissant des temps de réponses convenables aux requêtes web des visiteurs, et mesurer les réserves systèmes dont dispose le serveur à ce moment là. 
Enfin nous conseillons le client concernant d’éventuelles optimisations et modifications de l’architecture matérielle ou logicielles à envisager afin de pouvoir soutenir une charge supplémentaire.

Les étapes de préparation et premières constatations

Nous avons effectué, comme prévu, un pré-test de charge afin de valider les configurations et notre script de test. L’objectif était d’avoir une idée précise de la réaction de l’application afin de mieux calibrer notre test réel final. Le pré-test a consisté à connecter progressivement de 0 à 40 utilisateurs simultanés en 60 minutes.

Puis, nous avons lancé le test de charge le vendredi de 2H à 7H30 du matin ou l’on est monté de 0 à 180 utilisateurs simultanés.

Les scénarios de test de montée en charge

Temps de pause définis :

  • Page d’accueil : ~10sec
  • Pages « FAQ » et « spécifique » : ~15sec
  • Résultat d’une recherche : ~15sec
  • Page d’un élément donné : 30sec à 60sec
  • Remplissage du formulaire : ~20sec
  • Page dynamique émulation flash : ~10sec entre chaque images

Vous pouvez également consulter notre article sur la création de scénarios de test de montée en charge avec JMeter

Scénario 1
Scénario 2
Scénario 3
Scénario 4
Scénario 1
(10% des internautes)

  • Page d’accueil
  • Affichage d’un élément par un clique sur un point de la carte
  • Télécharger d’un pdf concernant l’élément
  • Affichage du formulaire
  • Remplissage du formulaire
  • Envoi du formulaire
Scénario 2
(70% des internautes)

  • Page d’accueil
  • Affichage de la page « FAQ »
  • Affichage de la page « spécifique »
  • Page d’accueil
  • Effectuer un recherche selon critères
  • Affichage du résultat de la recherche
  • Affichage des résultats détaillés.
  • Affichage du formulaire
  • Remplissage du formulaire
  • Envoi du formulaire
  • Retour au résultat de la recherche
  • Clique sur une nouvelle page « spécifique »
Scénario 3
10% des internautes)

  • Page d’accueil
  • Effectuer un recherche selon critère unique.
  • Affichage du résultat de la recherche
  • Affichage des résultats.
  • Affichage du formulaire
  • Remplissage du formulaire
  • Envoi du formulaire
  • Retour au résultat de la recherche
  • Clique sur une nouvelle page « spécifique »
  • Page d’accueil
  • Affichage de la page « FAQ »
  • Affichage d’une nouvelle page « spécifique »
Scénario 4
(10% des internautes)

  • Page d’accueil
  • Affichage de la page « FAQ »
  • Affichage de la page « spécifique »
  • Affichage recherche avec plus de critère
  • Effectuer un recherche nombreux critères.
  • Affichage du résultat de la recherche
  • Affichage des pages « spécifiques » de la recherche.

Critères supplémentaires pour les recherches, 3 groupes:

  • 20 critères
  • 5 critères sortant des résultats
  • 5 critères ne sortants pas de résultats

Le client veut pouvoir avoir une idée précise du temps de réponse des éléments externes d’un fournisseur de webservices.

Test de montée en charge du vendredi à 2H00

  • on monte à 180 utilisateurs simultanés sur une durée de 5 heures 30
  • on utilise :
    • 2 agents de notre datacenter
    • 1 agent adsl
    • 1 agent d’un datacenter distant
  • Simulation du cache : chargement des éléments de template (css, js, img) à 50%

Déroulement du test : Début à 2H00

  • Etape1: de 2H à 3H  de 0 à 60
  • Etape2: de 3H à 3H30 : stabilisation à 60 users
  • Etape3: de 3H30 à 5H30  de 60 à 120
  • Etape4: de 5H30 à 6H00 : stabilisation à 120 users
  • Etape5: de 6H00 à 7H  de 120 à 180
  • Etape6: de 7H00 à 7H30 : stabilisation à 180 users

Observations et Analyses pour le test de montée en charge du Vendredi

Objectif

Le choix de faire un test de charge sur une durée de 5H et de monter jusqu’à 180 utilisateurs avait pour objectif de faire tourner le serveur le maximum possible, mais en dessous du point de «bascule » provoquant l’emballement des services. Ce qui nous permet de récolter un ensemble de graphes pour voir les éventuelles fuites de mémoire/cpu/load et/ou limites des configurations systèmes. La très forte charge sera abordée dans le test suivant.

Trafic absorbé lors du test de charge et Pics:

35 Mbs atteint avec 180 utilisateurs simultanés

Remarque : quand on dit qu’on a 180 utilisateurs participant au test de charge, cela ne veut pas dire qu’ils sont en train de « cliquer » en même temps en direction de l’application, car un utilisateur lance des requêtes, attend la réponse, lit les pages affichées, regarde les images etc … ; toutes ces actions passives ne sollicitent pas à chaque seconde le serveur.

Constatations graphiques : Page d’accueil

test de montée en charge
Le graphe ci-dessus, représente le temps d’affichage de la page d’accueil durant le test de charge, à partir d’un serveur se situant dans le même datacenter, c’est à dire avec des temps de réponse ne reflétant pas la réalité de l’internet, les serveurs étant sur les mêmes switchs gigabit.

Le plus important est de voir la progression des temps de réponse durant le test. Au début, on se situe dans une moyenne autour de 1,4 secondes, qui va presque doubler à la fin , autour de 2,6 secondes.

Ci dessous un graphe représentant les temps d’affichage de la page d’accueil durant le test de charge, à partir d’un serveur se situant derrière une connexion ADSL:

On commence avec des valeurs autour de 3,2 secondes et on arrive à des valeurs autour de 4 secondes.

Pour comparer avec un navigateur internet, sans aucune charge, la page d’accueil s’affiche en 5,6 secondes, au début du test, alors que avec 180 utilisateurs actifs en cours d’exécution, on peut atteindre 12 secondes.

Test de montée en charge : l’analyse des graphes

Montée de 0 à 60 utilisateurs :

Le temps de chargement des pages html est légèrement décroissant. On remarque une stabilisation à 60 utilisateurs ainsi qu’un début de croissance.

Les images, css, js et autres fichiers statiques ont quant à elles un temps de chargement constant.

Montée de 60 à 120 utilisateurs :

Le temps de chargement des pages html poursuit sa croissance jusqu’à être remonté aux environs des temps initiaux, puis continue une légère croissance.

Les images, css, js et autres fichiers statiques restent constant.

Montée de 120 à 180 utilisateurs :

Le temps de chargement des pages html augmente légèrement de façon non proportionnelle à l’augmentation des utilisateurs.

Comme depuis le début, les images, css, js et autres fichiers statiques restent constant.

Graphes de monitoring des services :

Lors du test de charge, nous avons installé des capteurs sur les différentes applications systèmes afin de remonter un maximum d’informations quand à leur réaction face à la charge. Ci joint quelques graphes:

Processeur:

Test de montée en charge : cpu usage

Mémoire

Application, SQL et Serveur HTTP:

test de montée en charge

Les graphes ci dessus montrent, que pendant le test, le serveur disposait toujours de ressources en CPU et en mémoire vive pour répondre aux requêtes.

Vers la fin du test, la mémoire disponible était assez basse.

Tous les services au niveau du serveur ont une allure correspondant à la montée en charge. Les valeurs croissent de façon linéaire.

Corrélation entre tous les graphes

La décroissance du temps de chargement des pages html est due à la mise en cache au niveau php et mysql. Cela est du au fait que les scénarios ne sont pas totalement aléatoire (recherches préprogrammées).

Télécharger la version PDF de l'exemple de rapport simplifié de Test de charge - Expert Linux

Qui sommes-nous ?

Syloé est une ENL de plus de 14 ans d'expertise Linux : audit, conseils, hébergement, infogérance, cloud, devops, formations.

Depuis Mars 2019, Syloé a rejoint la société DRI, un hébergeur web qui partage les valeurs de Syloé autour de l’open source.

Syloé c'est aussi des contributions techniques autour des logiciels libres, des éditons de livres blancs et du sponsoring des associations du Libre.

CONTACTEZ-NOUS

Syloé

  • Glossaire
  • Actualités
  • Qui sommes-nous ?
  • Démarche qualité
  • Rejoindre l’équipe
  • Références clients
  • Sponsoring
  • Partenariats

Communauté du libre

  • Réseaux Libre-Entreprise
  • Nos valeurs
  • Labs
  • All4Dev
  • Planète Libre-Entreprise

Suivez-nous !

Follow @syloe_SARL

Actualité Syloé

Tweets by @syloe_SARL
CGVCPPSCPVM
© Syloé, 2004-2017, tous droits réservés. | Notice légale
Un expert Syloé vous rappelle

Merci de bien vouloir remplir le formulaire ci-dessous.