LR: Puis-je rendre le pseudo-aléa dans LoadRunner déterministe?

Question

Il y a deux sources aléatoires dans les scénarios LoadRunner:

• rand() fonction
• deltas temps penser au hasard (paramètres d'exécution)
• composants de temps de stimulation aléatoire (paramètres d'exécution)
• aléatoire paramètres (dans le cadre du test VUGen)

J'utilise ces fonctionnalités, et je pourrais vivre avec leur pseudo-tolérance. Je ne peux pas, cependant, vivre avec le fait que tous les scénarios contenant au moins une de ces fonctionnalités se comportent de façon pseudo-aléatoire ET indéterministe, ie pour un état de départ donné (graine aléatoire), je veux que deux passages génèrent EXACTEMENT la même charge, incluant (rythme et temps de réflexion). Je veux donc que deux passages soient basés exactement sur les mêmes séquences aléatoires. Cela signifie que je veux semer tous les générateurs aléatoires moi-même, dans le cadre de l'initialisation de chaque exécution. Je peux utiliser srand() pour définir une valeur initiale pour rand(). La définition d'une valeur de départ spécifique (codée en dur) lors de l'initialisation aboutit toujours à la même séquence fournie par rand() - pour tous les utilisateurs virtuels. Si je graine avec le numéro d'identification de VUser, j'obtiendrais même différentes séquences rand() pour chaque vuser, alors qu'elles sont toujours les mêmes d'exécution à exécuter pour chaque utilisateur. Qu'en est-il des autres sources pseudo-aléatoires dans LR, celles au-delà de rand()?

Ai-je la chance de tout semer pour obtenir un comportement de scénario déterministe?

Je pense que cela aiderait grandement. Sans un mécanisme comme celui-là, il faut prévoir des scénarios de test très longs et/ou à très fort trafic afin de «faire la moyenne» du caractère aléatoire dans les statistiques de résultats (êtes-vous d'accord avec ça?) Que je faire toute la journée.

Answer 1

Déjà couvert. Je travaille avec LoadRunner depuis 4.51 et je ne me souviens pas d'une version sans la possibilité de définir une graine aléatoire. Généralement, cela se trouve dans les paramètres d'exécution du scénario définis dans le contrôleur. Vous devriez être en mesure de trouver de la documentation à ce sujet pour votre version de LoadRunner en ouvrant la version Acrobat du Guide de l'utilisateur du contrôleur et en recherchant le terme «seed».

Answer 2

La réponse courte à votre question est: NO.

Random implies just what it says => "Random". 

Si vous utilisez le « CONÇU dans » caractéristiques aléatoires des paramètres que vous êtes à peu près vissable vous avez aucun contrôle sur la façon dont les graines aléatoires internes sont initialisés, et cela ne peut prédire en aucune manière la valeur suivante .

Si ce que vous voulez finalement obtenir est d'extrapoler les résultats et de prédire le comportement du serveur sous charge, vous êtes dans une voie très difficile.

résultats Extrapolation

Your run with 100 vusers and achieve an avg. of 50-60 hits/sec with 
response times under 3 sec. 

Logically 1000 vusers (10x load) would give you 500-600 hits/sec ... 

But what about the response times? How do you extrapolate them? How do you know 
when the web-server(s) chokes and achieves it's knee-point? 

Rappelez-vous que les coups/sec est directement proportionnelle aux temps de réponse ...si la prédiction de coups/sec (ou pages/sec) devient très difficile et imprécis

Les choses que vous ne pouvez pas contrôler

Même si vous obtenir un « exacte » copie d'un autre terme que vous avez toujours à traiter avec les temps de réponse et les retards de réseau, cela est toujours différent, indépendamment des circonstances (et aussi totalement hors de votre contrôle).

Une autre façon de définir la charge

-test de charge « réaliste » en soi pas une science exacte, et pas de test de charge peut jamais simuler le monde réel complètement, mais nous pouvons approcher. La façon dont nous le faisons ici est que nous essayons de simuler les utilisateurs individuels aussi près que possible. De cette façon, nous pouvons définir les attentes de charge en fonction des types d'utilisateurs, ce que les gens d'affaires ont généralement la moindre idée.

Nous divisons également les "utilisateurs" en types, tels que les utilisateurs de puissance, normal ou novice - la différence pour ces derniers est la vitesse à laquelle ils fonctionnent (et la façon dont ils utilisent les interfaces utilisateur). En faisant cela, nous pouvons "charger" l'application cible avec une certaine "charge d'utilisateur attendue" au lieu de valeurs de pages/sec ou de coups/s ou d'autres compteurs techniques. Nous exécutons également des courses plus longues pour voir comment le service se comporte dans le temps, donc un test de 72h ou plus n'est pas inhabituel pour la phase de test d'Endurance. Cela indique également s'il y a des fuites de mémoire sur les serveurs et comment les processus d'arrière-plan affectent les performances du serveur pendant la «nuit»

Answer 3

La répartition du générateur de nombres aléatoires est impérative pour un système comme un programme de chargement. Exemple parfait - J'ai un changement de code que je veux tester. Je graine le générateur de nombres aléatoires, puis je cours avec et sans le code modifié. La séquence des fonctions exécutées sera aléatoire, mais les deux tests utiliseront la même séquence. Cela me permet de voir l'impact exact de mon changement de code. Sans la possibilité de voir le générateur de nombres aléatoires, je devrais faire de très longs tests sous une charge très élevée pour essayer de faire la moyenne du hasard.

Sans la graine, le 2ème test choisirait un chemin complètement différent. Et sur une autre itération, encore un autre chemin complètement différent. Je veux des séquences RANDOM, mais des séquences RANDOM REPEATABLES. C'est pourquoi toutes les langues modernes vous permettent de graver un générateur de nombres aléatoires. Le client Load Runner a juste besoin d'ajouter un seul champ de texte qui vous permet d'entrer la "valeur de départ" pour son générateur de nombres aléatoires.