Configuration d'un test de charge de base

Question

J'ai une question de test de charge très basique.

Je fais un test de charge en utilisant VSTS 2008 et j'ai un banc d'essai avec contrôleur + 10 agents. Ce test de chargement concerne une batterie de serveurs SharePoint. Mon but du test de charge est de connaître l'utilisation des ressources sur les niveaux web + app + db de ma batterie pour tout scénario de charge donné. Un exemple d'un scénario de charge est

profil d'utilisation: la collaboration moyenne (tel que défini par SCCP)

utilisateur charge: 500 (à l'aide modèle de charge étape = une étape de 50 toutes les 2 minutes et un temps de chauffe 2mins pour chaque étape)

temps de réflexion: 0

durée de charge: 8 heures

maintenant, la question est la suivante: est-il juste de penser que des mesures comme les demandes/s,% du temps processeur sur le Web frontal/App/DB, Test/sec, et etc deviennent plats ou en à un moment donné pendant l'essai de chargement. Comme je l'ai dit, le but n'est pas de créer un goulot d'étranglement mais seulement de mesurer l'utilisation des ressources par le profil de charge ci-dessus.

Je pose cette question parce que je vois quelque chose de différent. À un moment du test de charge, les demandes/s deviennent plus ou moins plates. Mais l'utilisation du processeur sur les serveurs Web/DB ne cesse d'augmenter. Après avoir un peu creusé les données, je vois que les "tests en cours" ont également augmenté régulièrement au fil du temps. Donc, si je lance le test de charge pendant plus de 8 heures, le pourcentage de processeur peut augmenter. De cette façon, je ne sais pas quoi considérer comme la charge excrétée par le profil de charge.

Que signifie vraiment ce compteur de "tests en cours"? En quoi est-ce différent des tests/s?

Une autre question est: comment puis-je savoir pourquoi le compteur "tests en cours" montre une augmentation des heures supplémentaires?

Merci pour votre temps

Answer 1

Avec plus d'informations que prévu, je suppose que cela a quelque chose à voir avec les demandes qui font la queue et la piscine de thread de travail.

Le pool de travail a un nombre limité de threads à utiliser pour répondre aux demandes. Une fois que cela est atteint (ce qui peut après un certain temps, parce que le front-end effectue les requêtes DB et les attend, très probablement pas de manière asynchrone), les requêtes sont mises en file d'attente (je pense que c'est l'augmentation du compteur).

Pourquoi plus de CPU s'utilise? Encore une fois, vous devez creuser dans les données du scénario, mais une hypothèse est que le changement de contexte et les échanges de mémoire et les allocations peuvent avoir quelque chose à voir avec cela. Prenez cela à la légère, car sans plus de données, rien ne peut être dit positivement.