Comment effectuer des tests de performances et de charge sur une application web ?

Que ce soit pour un nouveau développement ou une refonte significative, il est important de valider que le nouvel applicatif va répondre dans de bonnes conditions et sera capable de tenir le volume de trafic attendu.  Bien souvent, il faut pouvoir réaliser ces tests rapidement, entre la fin des développements qui ne sont jamais en avance et la date de mise en ligne que l’on ne veut pas repousser.

Comment réaliser ces tests ? Avec quels outils ? Comment construire sa campagne de test ? Quels indicateurs analyser  pendant les tests ? Comment interpréter les résultats ? Nous vous proposons de partager notre expérience.

Préambule sur le déroulement des tests

Avant de démarrer il faut comprendre comment vont se dérouler les tests.

Dans la majorité des cas, on va réaliser une série de tests successifs en faisant monter à chaque fois l’intensité du trafic. Cela va permettre de tester la capacité du site à tenir un niveau de trafic en mesurant à chaque fois les temps de réponse et les indicateurs techniques de l’infrastructure. On va ainsi aller chercher la limite du site. Il faut donc bien calibrer les scénarios du test pour qu’ils soient représentatifs de la navigation d’une journée ou d’un mois.

Exceptionnellement, on peut aussi faire des tests de résistance beaucoup longs, qui vont chercher à vérifier la tenue dans la durée, mais ce n’est pas le cas que nous allons développer ici.

Calibrer ses objectifs, le volume et type de trafic

La situation sera différente selon qu’il s’agit d’une application existante ou non. Avec une application existante, on va pouvoir travailler avec les logs de connexion,  soit directement pour ré-injecter le trafic passé, soit pour les analyser et simuler un trafic très proche de la réalité. Pour une nouvelle application , il faut s’appuyer sur les hypothèses  de trafic du service marketing en les challengeant avec  une analyse de la concurrence.

 

Voici les valeurs à définir :

  • trafic global mensuel en nombre de visites,
  • trafic par jour ? quel est le profil par jour sur un mois, quel trafic le week-end par rapport à la semaine ?
  • courbe de trafic par heure sur une journée, quelle est la montée en charge le matin ? jusqu’à quelle heure la navigation est-elle significative ? Y a t-il un ou plusieurs pics d’audience ?
  • quel % de « survoleurs » ? le « survoleur » étant l’internaute qui arrive sur une page mais ne reste pas,
  • quel nombre de pages/visites en moyenne, avec et hors survoleurs ?
  • liste des pages les plus consultées ?
  • durée moyenne d’une session, intervalle de temps entre 2 pages ?

Hypothèses de trafic webSI vous avez un historique de navigation, votre outil préféré d’analyse de trafic  (Piwik, Google Analytics) doit vous permettre de construire ce jeu de donnée rapidement. Vous pourrez ainsi de définir les « paliers » de tests: pour un objectif de trafic mensuel en visites et pages vues, on va définir un test correspondant sur 1h. Le tableau ci-contre illustre une telle simulation:

Notre test porterait ici sur la simulation d’environ 22.000 visites sur une heure avec 115.000 pages vues. On démarrerait les tests probablement à 5.000 pour monter progressivement par paliers de 2500.

Les outils de tests :  Siege et/ou Gatling ?

Chez alfa-safety, nous utilisons principalement 2 outils libres:  Siege et Gatling; chacun présente ses points forts et faiblesses, et nécessite un apprentissage.

Rapport d’un test de charge web avec le logiciel Siege

Siège est un outil d’injection d’URLs en masse avec un nombre d’utilisateurs simultanés.  Nous l’utilisons dans les conditions suivantes :

  • Injection d’URL de manière aléatoire par rapport à une liste d’URLs sélectionnées pour le test, nous recommandons une 50aine d’URLs ou pages web.
  • Injection simple linéraire d’utilisateurs simultanés dont chacun requête une URL. les injections avec montée en charge (« ramp ») s’avèrent en réalité délicates à piloter.

Siege est un bon outil de montée en charge car il permet de simuler des trafics élevés. En revanche, le reporting de Siege est très rudimentaire et il est important de savoir calibrer l’injection (nous publierons prochainement un article détaillé sur l’utilisation de Siege et Gatling). ci-contre un exemple de rapport Siege.

Gatling est un injecteur de scénarios de navigation, il permet :

  • D’enregistrer un scénario de navigation, en cadençant l’enchainement des consultations de pages,
  • De programmer les tests, en répétant un scénario ou en combinant plusieurs scénarios,
  • De simuler un volume de trafic constant, ou avec une montée en charge, par exemple montée de 1 à 10 utilisateurs en 10s. Chez alfa-safety, nous privilégions le trafic constant, car la montée en charge est délicate à régler et vient polluer le travail.

Gatling est un bon outil de simulation de scénarios, son reporting est beaucoup plus complet que celui de Siege, en revanche son comportement est moins prévisible et 1 injecteur plafonne assez vite à partir de 60/75 users simultanés, il faut alors multiplier les  injecteurs.

Dans la plupart de nos tests, nous combinons les deux outils Siege et Gatling afin de croiser les résultats.

Quels indicateurs techniques analyser ?

Dans tous les cas, le logiciel de test est installé dans notre data center de manière à ce qu’il accède directement aux serveurs sans passer par internet, et donc sans que les résultats ne soient pas affectés par des ralentissements liés aux flux sur internet.

Très important, avec Siege comme avec Gatling, il faut étalonner le nombre moyen de transactions par page requêtée pour pouvoir interpréter les résultats. En effet, le nombre de transactions n’est pas le nombre de pages requêtées, mais bien la somme des requêtes générées. Pour cela, il suffit d’injecter un nombre connu et fixe de pages, et une fois test achevé, en déduire le ratio total des transactions/page. Ce travail est bien à faire pour chaque campagne de test car ce ratio va dépendre du site, de l’échantillon de pages sélectionnées et du logiciel utilisé.

Les indicateurs clés des logiciels de test sont :

  • le nombre de transactions, qui permettra de valider le nombre de pages intérrogées sur la durée du test,
  • le temps de réponse, chez Siege c’est une simple valeur moyenne, alors que chez Gatling on a différents percentiles ce qui permet une analyse plus fine,
  • le nombre de users simultanés, (« concurrency » chez Siege)
  • Les données de transfert pendant le test (« transaction rate », « throughtput » en MB/sec,..), ici Siege est supérieur à Gatling.

En parallèle, il faut monitorer avec votre outil de supervision les indicateurs de bande passante, de consommation de ressources des serveurs, cela permet d’analyser les éventuels points de contention:

  • Bande passante consommée,
  • CPU load, RAM usage %, des serveurs,
  • Activité de la base de données, req/sec,
  • Comportement du cache Varnish si vous en avez un (% de hit/miss).

Naviguer sur le site pendant le test, permet aussi de mesurer le comportement de votre applicatif en charge.

Combien de temps cela prend ?

Il ne faut pas sous-estimer le temps que prennent ces tests.

  • Le travail de préparation de l’échantillon des pages et des scénarios doit être réalisé avec soin, les pages doivent être testées pour vérifier qu’elles ne génèrent pas d’erreur. La plan de test doit être établi, dans la pratique vous serez surement amenés à l’ajuster en fonction des résultats,
  • Nous conseillons de faire des tests unitaire de 10 à 30mn, voire 1 heure.  Moins de 10mn est trop court pour une mesure sérieuse. Après chaque test, il faut récupérer les résultats et les analyser. Il est souvent nécessaire de rejouer ou d’ajuster les paliers de test en fonction des résultats. Rapidement une dizaine de tests prendra la journée.
  • Compiler les résultats pour analyser l’ensemble et en tirer les conclusions est la dernière phase qu’il ne faut pas négliger.

Au global, une campagne de test prendra minimum 3 jours, et bien souvent une semaine, un peu plus la première fois, un peu moins si vous la rejouez à l’identique.  En fait, 2 campagnes de tests ne sont jamais identiques, on aura toujours effectué quelques modifications entre les 2, et les objectifs seront affinés. Il faut se donner le temps de bien croiser les résultats, ajuster le plan de test, pour aboutir à quelque chose de bien cohérent. D’expérience, chaque campagne de test est différente et nécessite des ajustements, l’expérience du testeur est un facteur important dans la construction du plan de test et pour l’analyse des résultats.

Bref le test de performance et de charge d’une application web est un métier en soi. Chaque application est différente et le contexte et les objectifs vont varier dans le temps. Si vous ne pratiquez pas cette exercice régulièrement, nous ne pouvons que vous conseiller de le confier à une société expérimentée, qui ira plus vite pour un résultat plus complet.

Pour plus d’information sur le thème de la performance des sites web et des temps de réponse , voir notre page spécialisée sur le site alfa-safety.fr

Laisser un commentaire

*

Be sure to include your first and last name.

If you don't have one, no problem! Just leave this blank.