LR fichiers journaux personnalisé: Comment puis-je les obtenir à partir des machines de générateur?

Question

Supposons que j'ai un test VUGen C qui écrit des résultats à un certain fichier journal de données, à savoir qu'il énumère ID traités ou quelque chose comme ça dans un fichier qui est créé (ou en annexe) sur init, écrit dans l'action principale, et fermé lors de l'arrêt.

Alors je me demande s'il y a une fonctionnalité LR qui me permet de trouver une structure de répertoire consolidé sur le contrôleur contenant des copies de tous les Vusers de ce fichier?

Pour autant que je peux voir, toutes les instances de Vuser utiliser une copie commune de la structure de répertoire de test, quelque part situé à température. Donc, a) je dois inclure la Vuser ID dans le nom de mon fichier journal personnalisé, et b) je dois collecter les fichiers de résultat manuellement à partir de mon générateur de charge après une exécution de scénario, ce qui est un processus maladroit.

La seule alternative confortable serait de faire rapport tous les ID traités (ou autre) en VTS (serveur de table virtuelle HP, semble être freeware) et les ramasser à partir de là, non? Ensuite, je dois faire le codage supplémentaire. Peut-il que personne n'a jamais manqué une telle fonctionnalité dans VUGen / LR?

J'espère que ce ne soit pas trop offtopic car cette question est neccessarily liée code.

Answer 1

La façon dont nous le faisons, quel que soit Performance Center ou autonome est d'avoir un chemin UNC mappable par les scripts. Nous créons ensuite / écriture / lecture de fichiers.

Cela permet d'exécuter les scripts de plusieurs charge générateurs sans avoir à copier tous les fichiers partout après le test, et aussi nous donne un stockage général où l'on peut charger DLL et d'autres fichiers nécessaires à tous les scripts.

S'il vous plaît noter que la création / écriture au même fichier à partir de deux travaux Vusers ne différents, vous devez créer soit des noms de spécifiques vuser_id ou utiliser une base de données pour stocker les données. L'option DB exige que vous avez une bibliothèque 3ème partie de DB (DLL) à portée de main tu ..

Answer 2

Simple, utilisez lr_output_message() à oputput votre message de journal personnalisé au contrôleur lors de l'essai. A la fin de l'essai tout simplement vider les éléments du journal dont vous avez besoin d'une exportation de la fenêtre de sortie.

Vous voulez méfiez-vous de l'exploitation forestière lourde lors de l'essai. Vous pouvez transformer facilement votre sous-système de disque entier dans un goulot d'étranglement pour le test, soit le double, donc si vous êtes utilisateurs en cours d'exécution sur un hôte déjà occupé comme le contrôleur et non sur un morceau de matériel dédié. L'utilisation lr_output_message() prend votre journal hors de l'hôte d'utilisateur virtuel et le déplace vers le contrôleur pour l'enregistrement.

Assurez-vous d'inclure une référence, ou générateur de commande, avec un seul utilisateur virtuel de chaque type mis en scène sur elle (matériel adapté au reste de vos générateurs) pour vérifier contre le sous-système de disque becomming un goulot d'étranglement.

En outre, si vous voulez récupérer les données à la fin du test et envisager un hôte découplé tout à fait, vous pouvez regarder la suggestion de K Sandell d'un chemin UNC vers un hôte / emplacement commun, avec la complication supplémentaire d'avoir pour gérer les serrures avec d'autres utilisateurs virtuels si vous allez dans un fichier commun, ou simplement inclure une autre cible dans votre test, comme VTS, l'un des nombreux Java solutions messaeg file d'attente, ou MySQL, même avec une extrémité avant la lumière simplement pousser des données dans un une table en utilisant un formulaire.