Contexte du test de charge

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 votre application afin de mieux calibrer notre test réel final. Le test a consisté à connecter progressivement de 0 à 40 utilisateurs simultanées 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ées.

Les scénarios des tests de charges

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

Le client veut pouvoir avoir une idee precise du temps de reponse des elements externe d'un fournisseur de webservices.

Test du vendredi à 2H00

• on monte à 180 utilisateurs simultanées 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 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 graphe 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 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 reponse ne reflétant pas la réalité de l'internet, les serveurs etant 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.

L'analyse des graphes

Montée de 0 à 60 utilisateurs :

Le temps de chargement des pages html est legè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 quand à 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 croissants.

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

Montée de 120 à 180 utilisateurs :

Le temps de chargement des pages html continu une legère augementation non proportionnelle à l'augementation des utilisateurs.

Comme depuis le debut, 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'information 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).