0

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.

markalex
  • 8,623
  • 2
  • 7
  • 32
TheBlastOne
  • 4,291
  • 3
  • 38
  • 72

2 Answers2

1

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.

James Pulley
  • 21
  • 1
  • Thanks -- however, that is quite exactly what I do (and know) today. I was wondering if there is a mechanism that LoadRunner uses to collate its event files to the controller (sure there is!), and if there is a cheap way to scrounge that off from LR for my own result data files. (I currently use VTS Virtual Table Server to consolidate results from my load generators.) – TheBlastOne Apr 04 '11 at 12:50
0

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 ..

K.Sandell
  • 1,369
  • 10
  • 19
  • I would not love that since I would in effect write to the network in my VUgen script. This might have side effects to the transaction times measured. I would have to pause all open transactions before the network write, and resume them afterwards. But, since writing to a file might well be handled asynchroneously (or not?), I fear I would still unprecise transaction times. – TheBlastOne Mar 14 '11 at 12:02
  • In our organization with over 50 performance testers I've never (ever) seen anyone have a mission critical transaction open during any "script specific" work, but sure enough the times may vary a little (thou I suspect the differences would be less then 0.1% in the end). – K.Sandell Mar 17 '11 at 18:26
  • I see, but doesn't that directly depend on the operation you perform in your LR transactions, and the time spent for that operation? For example, consider measuring how much time is spent in preparing and sending data to subsystems on a PC controlling a sorting machine which only offers a 250 ms time window between scanning (OCRing) an address and activating the right sorter. Here, a log file write might take longer if it is going over the network. It might be a 0.1% difference for longer transactions, but could be 30% for very short ones. – TheBlastOne Mar 17 '11 at 21:28
  • Meanwhile, the first usable answer deserves an "accept", although this won't be the solution I'll be happy with. If time allows, I will dig out the LR mechanism for transferring event files and use it myself, maybe I can add the info I discover underway into this answer. – TheBlastOne Apr 18 '11 at 06:40
  • If you ever find out exactly how it works, please post about it! I'd loove to hear how it works .. :) – K.Sandell Apr 21 '11 at 13:39