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

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

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:

Mémoire

Application, SQL et Serveur HTTP:

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).