Comment distribuer le stress dans les scénarios de test de charge ?

L’un des défis posés par les tests de charge est d’arriver à prévoir et à décider quelles activités utilisateur inclure et comment combiner différents scénarios d’utilisation. Notre article précédent « comment prévoir des scénarios de test de charge réalistes » donnait quelques conseils pour identifier les transactions utilisateur. Mais envisageons que vous en soyez déjà à l’étape suivante, se pose maintenant la question de savoir comment définir la proportion à attribuer aux différentes activités.
Partons donc d’un exemple pratique. Disons que vous testez un site de commerce en ligne. Votre scénario de charge simulera probablement les activités liées à l’intégralité du site : pages produits, recherche, page boutique, procédure de commande, panier et paiement. Mais savez-vous comment bien distribuer la charge entre ces différents domaines ? Quelle proportion du scénario doit être dédiée aux pages produits par rapport à la fonction recherche ?
Disons que vous dédiez 10 % du scénario à la recherche de produit, puisque cela représente le nombre moyen d’utilisateurs qui effectuent cette action sur le site. Mais, et si cette hypothèse était erronée et qu’il y avait plus de recherches effectuées sur le site, et que lorsque la proportion de charge des recherches passait à 15 % les problèmes commençaient à apparaître ? Même si une augmentation de 5 % semble presque négligeable, elle correspond à une augmentation de 50 % de la charge placée sur les recherches dans la base de données. Si la base de données dorsale est en fait un lien sensible, alors elle peut avoir un impact sur la stabilité de toute l’application. Mais elle doit être soumise à un stress suffisant pour mettre à jour ses faiblesses. Pour le dire clairement, si vous ne placez pas suffisamment de stress aux bons endroits, alors votre scénario de charge ne remplira pas ses objectifs.
Alors, que pouvez-vous faire ? Bien évidemment, vous pouvez toujours charger votre système avec plus d’utilisateurs/de stress que prévus par vos données « brutes ». Mais de même, vous devez aussi essayer de modifier et d’augmenter/diminuer les proportions entre les différentes transactions. Votre rôle en tant qu’ingénieur de performance est de tester même l’inattendu et d’identifier les emplacements ou scénarios où une augmentation du stress met votre système « en échec ».
Par David BUCH, Directeur innovation de Radview