Question

Suppose I have a VUGen C test which writes results to some data log file, i.e. it lists processed IDs or something like that in a file that is created (or appended) upon init, written to in the main action, and closed upon shutdown.

Then I wonder if there is a LR functionality that allows me to find a consolidated directory structure on the controller containing all vusers copies of that file?

As far as I can see, all vuser instances use one common copy of the test directory structure, located somewhere in temp. So a) I need to include the VUser ID into the name of my custom log file, and b) I have to collect the result files manually from my load generator after a scenario execution, which is a clumsy process.

The only comfortable alternative would be to report all processed IDs (or whatever) into VTS (HP virtual table server, seems to be freeware) and pick them up from there, right? Then I have additional coding to do. Can it be that nobody ever missed such a functionality in VUgen/LR?

I hope this is not too offtopic since this question is not neccessarily code-related.

Answer 1

The way we do this, regardless of Performance Center or Standalone is to have a UNC path mappable by the scripts. We then create/write/read from files there.

This allows for running the scripts from multiple load-generators without having to copy any files anywhere after the test, and also gives us a general storage where we can load DLL s and other files needed by all the scripts.

Please note that creating/writing to the SAME file from two different vusers won t work, you should either create vuser_id specific names or use a database for storing the data. The DB option requires that you have a 3rd party DB library (DLL) at hand thou ..

Answer 2

Simple, use lr_output_message() to oputput your custom log message to the controller during the test. At the end of the test simply dump out the log elements you need from an export of the output window.

You will want to be wary of heavy logging during the test. You can quite easily turn your entire disk subsystem into a bottleneck for the test, this is double so if you are running users on an already busy host like the controller and not on a dedicated piece of hardware. Using lr_output_message() takes your log off of the virtual user host and moves it to the controller for logging.

Be sure to include a reference, or control generator, with only a single virtual user of each type staged upon it (hardware matched to the rest of your generators) to check against the disk subsystem becomming a bottleneck.

Also, if you want to recover the data at the end of the test and want to consider a decoupled host altogether you can look at K Sandell s suggestion of a UNC path to a common host/location, with the added complication of having to manage locks with other virtual users if going to a common file, or simply include another target in your test such as VTS, any of the many Java based messaeg queue solutions, or even MySQL with a light front end to simply push data into a table using a form.

友情链接