Test de charge à l'aide de Visual Studio 2008: problèmes d'analyse des résultats

Question

J'utilise Visual Studio Team System 2008 Team Suite pour le test de charge de mon application Web (il utilise la technologie ASP.MVC). Motif de charge: Constante (cela signifie que je dispose d'une quantité constante d'utilisateurs virtuels tout le temps). Je spécifie coniguratiton de 1000 utilisateurs pour analyser la perfomance de mon application Web dans des conditions vraiment stress. J'exécute le même test de charge plusieurs fois tout en faisant quelques changements dans mon application. Mais quand j'analyse les résultats des tests de charge, j'arrive à une étrange dépendance: lorsque le temps moyen de réponse des pages augmente, la valeur des requêtes par seconde augmente aussi et vice versa: lorsque le temps moyen de réponse des pages est inférieur, moins.Cette situation ne se reproduit pas lorsque le nombre d'utilisateurs est faible (5-50 utilisateurs).

Comment pouvez-vous expliquer de tels résultats?

Answer 1

Il existe peut-être un malentendu sur le terme Demandes/Sec ici. Demandes/Sec selon ce que je comprends est juste une représentation de la façon dont un nombre de demandes que le test pousse dans l'application (pas le nombre de demandes complétées par seconde).

Si vous regardez de cette façon. Cela pourrait avoir du sens.

Les demandes élevées/sec entraîneront une augmentation de la moyenne Temps de réponse (en raison d'un goulot d'étranglement quelque part, c'est-à-dire lié au processeur, lié à la mémoire ou lié à l'E/S).

Alors que vos requêtes/sec augmentent et que vous avez des tonnes d'objets en mémoire, la mémoire est sous pression, déclenchant ainsi la récupération de place qui ralentira votre temps de réponse. Ou alors que vos demandes/sec augmentent et que votre processeur est martelé, vous devrez peut-être attendre le temps CPU, ce qui augmentera votre temps de réponse. Ou alors que votre demande/sec augmente, votre SQL n'est pas réglé correctement, et le blocage et l'interblocage se produisent, ce qui augmente votre temps de réponse.

Ce ne sont que des exemples de pourquoi vous pourriez voir cette corrélation. Vous devrez peut-être en rechercher plus en termes de CPU, d'utilisation de mémoire et d'E/S (réseau, disque, SQL, etc.)

Answer 2

Quelques détails supplémentaires sur le problème: nous testons notre moteur de rendu [NDjango] [1] par rapport à l'aspx ASP.NET standard. L'application web que nous utilisons pour charger le test est très basique - elle se compose de 2 pages statiques - pas de base de données, pas de traitement lourd, juste le rendu. Ce que nous voyons est qu'en termes de temps de réponse moyen aspx comme prévu est considérablement plus rapide, mais à ma grande surprise le nombre de demandes par seconde ainsi que le nombre total de demandes pour la durée du test est beaucoup plus faible. Laissons de côté ce que nous testons par rapport à quoi, je suis d'accord avec Jimmy, qu'un taux de requêtes plus élevé peut obstruer le serveur de plusieurs façons. Mais je crois comprendre que cela ferait augmenter le temps de réponse - n'est-ce pas? Si les chiffres que nous recevons reflètent vraiment ce qui se passe sur le serveur, je ne vois pas comment cette règle peut être brisée. Donc, pour l'instant, la seule explication que j'ai est que les chiffres sont faussés - quelque chose ne va pas dans la façon dont nous configurons l'outil.

[1]: http://www.ndjango.org Ndjango

Answer 3

Ceci est un résultat normal que le nombre d'utilisateurs augmente, vous chargerez le serveur avec un plus grand nombre de requêtes par seconde. Tout serveur prendra plus de temps pour traiter plus de demandes par seconde, ce qui signifie que le temps de réponse moyen de la page augmente.

Les demandes par seconde sont une mesure de la charge appliquée à l'application et le temps moyen de réponse de la page est une mesure de la performance des applications où le nombre élevé = réponse lente.

Il vaudra mieux utiliser un nombre d'utilisateurs échelonné ou une période d'échauffement où la charge est appliquée progressivement au serveur.

De plus, avec 1000 utilisateurs virtuels sur une seule machine de test, la CPU de la machine de test sera complètement atteinte. Ce sera probablement la chose qui fausse les résultats de vos tests. En jouant avec le nombre d'utilisateurs virtuels, vous trouverez qu'il y aura un point où les demandes par seconde sont maximales. L'ajout ou le retrait d'utilisateurs virtuels entraînera moins de demandes par seconde à partir de l'application.