Les tests de performances hardware ne se comptent plus : tous les produits qui sortent sont testés, re-testés, encore et encore.

Pourtant, plus de 95% des éditeurs (de sites ou d’applications en ligne) ne pensent pas à faire des tests de performance, ou ne savent pas comment faire.

Or, il arrive que certains sites ne répondent plus lors de grosses affluences : ce phénomène s’appelle « Slashdot Effect« .

Slashdot effect : désigne le fait qu’un site internet soit submergé de requêtes provenant d’utilisateurs de Slashdot (ou Digg/Techcrunch) au moment de la publication d’une nouvelle le référençant, le rendant ainsi momentanément indisponible par déni de service (Wikipedia).

Vous vous souvenez de l’indisponibilité de Pownce ? Voilà un bon exemple d’un buzz qui a parfaitement fonctionné, mais d’une infrastructure qui ne tenait pas la route.

Un cauchemar, non ?
Vous lancez une application susceptible d’intéresser des milliers d’utilisateurs, vous buzzez autour, mais celle-ci est indisponible.

Vous avez dit benchmark ?

La majorité des éditeurs que je rencontre me soutiennent que « leur application est stable, et qu’elle ne consomme rien« .

Admettons, mais savez-vous comment celle-ci va réagir avec plusieurs centaines (voire milliers) d’utilisateurs simultanés ?

Les tests de performance (ou benchmarks) sont prévus pour définir des contraintes maximales, et isoler les points faibles d’une application/infrastructure : toutes les données vous permettrons la définition d’un Capacity Planning.

Note : les tests peuvent également servir à optimiser votre application, en rejouant le même scénario après modifications de certains paramètres.

Il y a cinq secteurs majeurs sur lesquels il est possible d’optimiser une application :

  • la bande passante,
  • l’infrastructure réseau,
  • l’architecture applicative,
  • la configuration et le modèle de la base de données,
  • le développement.

Le principe d’un benchmark est relativement simple : un logiciel permet l’enregistrement d’un scénario à partir de votre navigateur. Une fois l’enregistrement fini, on utilise des injecteurs de charge qui vont simuler les actions des utilisateurs. Enfin, des sondes vont permettre de relever les données à traiter (CPU, Ram, requêtes, etc.) sur les serveurs (voir image ci-dessous).

Evolution de la RAM d'un serveur durant un test de charges

Exemple d’un graphique d’évolution de la mémoire d’un serveur

Les benchmarks que je réalise sont définis en sept étapes :

  1. Analyse du besoin : vous planifiez une évolution de la plate-forme, ou vous voulez connaître les impacts d’une montée en charge rapide ?
  2. Définition du plan de tests : présentation du projet, données techniques, schémas techniques, jeux de tests, etc.
  3. Définition des scénarios : je conseille toujours de faire trois jeux de scénarios (simple, médium, complexe), pour simuler des comportements utilisateurs différents.
  4. Enregistrement des scénarios.
  5. Adaptation : pour chaque scénario, il faut configurer le comportement des utilisateurs virtuels.
  6. Déroulement du test : injection de la charge pour chaque scénario.
  7. Analyse et interprétation des résultats.

Comme vous pouvez le constater, il ne s’agit pas simplement d’installer un logiciel et de faire « Next, Next, Next ». :)

Types de benchmark

Plusieurs types de tests sont possibles :

  • Test de capacité : vous désirez connaître les limites de votre application en fonction d’un nombre d’utilisateurs,
  • Test de performance : pour mesurer les performances et voir l’influence d’un nombre important d’utilisateurs sur les temps de réponses,
  • Test de stress : ce type de test permet de vérifier la tenue en charge de l’application sur une utilisation non linéaire (pics de charge aléatoires),
  • etc.

D’autres « variantes » existent, le type est choisi en fonction de vos besoins et de vos objectifs pour votre campagne.

Les tests de performances sont très souvent négligés par les entreprises, car jugés inutiles : pourtant, une application non testée est pour moi une application « non hébergeable ». Sans benchmark, comment est-il possible de dimensionner un serveur autrement qu’au jugé ?

Et, comme j’ai l’habitude de le dire : « rajouter des serveurs n’est pas la solution ! »

Si quelqu’un désire plus de détails, ou des conseils, vous pouvez m’écrire ou me laisser un commentaire.