What exactly do "graph_*.dat" files contain in LR raw results

Question

I'm attempting to decode the contents of the "graph_*.dat" files under the sum_data/ folder in a raw results file, obtained from Performance Center.

I've figured out the 1st (Transaction name), 2nd (Unix timestamp) and 3rd (response time) columns but there are 4 more that do not really make sense to me. Could someone please explain them?

I'm especially interested in the graph_5.dat file (transaction response times). I've also come to the conclusion that not all graph_*.dat files contain meaningful data in these columns.

Here's a short snip from the graph_5.dat file:

40 xxxxxx7723 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7724 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7725 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7726 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7727 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7728 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7729 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7730 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7731 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7732 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7733 1.317764 0.600000 0.936688 1.896918 1.145876
40 xxxxxx7734 1.317764 0.600000 0.936688 1.896918 1.145876
40 xxxxxx7735 1.317764 0.600000 0.936688 1.896918 1.145876
40 xxxxxx7736 1.317764 0.600000 0.936688 1.896918 1.145876
40 xxxxxx7737 1.317764 0.600000 0.936688 1.896918 1.145876
40 xxxxxx7738 1.168778 0.400000 1.108304 1.229253 0.547880
40 xxxxxx7739 1.168778 0.400000 1.108304 1.229253 0.547880
40 xxxxxx7740 1.168778 0.400000 1.108304 1.229253 0.547880
40 xxxxxx7741 1.168778 0.400000 1.108304 1.229253 0.547880
40 xxxxxx7742 1.168778 0.400000 1.108304 1.229253 0.547880

Answer 1

First, I cannot recommend interpreting or otherwise depending on Loadrunner's internal data formats. I've done that with WinRunner, and it totally was not a long- or mid-term solution since they (HP/Ex-Mercury) seem to change formats as they see fit, even for small rather updates/SRs/minor releases.

Second -- one of the figures could be the "wasted" time, i.e. the sum of all think times that were part of the transaction.

Try fiddling with lr_set_transaction and related functions so you can predict what the file should contain if you pass certain values to those functions.

Third -- but this is just a guess: I'm 99% (well -- 70%...) sure the other times contain the values that LR collects so it can do a web request breakdown. (When you integrate LR scripts into Business Availability Center, you can have a breakdown graph for all web requests of any transaction. I'm not sure if LR itself does use those values in the reports, or what have we. However, You can validate my guess by using an empty transaction -- the breakdown time components should be 0 (or equal to the total response time?), as should the think time component).

Hths...

Answer 2

I've been able to deduct the following about the columns:

ID TimeStamp  RespTim  TPS      A        B        C 
== ========== ======== ======== ======== ======== =========
40 xxxxxx7723 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7724 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7725 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7726 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7727 5.458429 0.800000 2.406426 8.481170 27.879561

40 xxxxxx7728 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7729 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7730 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7731 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7732 2.551755 0.400000 2.462352 2.641159 2.607780

ID          Transaction ID from sum_data.ini file
TimeStamp   UNIX Timestamp (UTC 0)
RespTime    Avg. Response for this period
TPS         Transactions per Seconds
A,B and C   These are unknown still

Note that the 5 first lines are IDENTICAL except for the TimeStamp. This I believe is due to the way LR collects data in 5 sec brusts.

The TPS (0.8) value indicates that during those 5 seconds there were actually 4 transactions made. Their avg. response time was 5.458429 seconds.

To verify the TPS column I discovered that if you sum all the TPS values for a specific transaction you will end up with the PASSED count as seen in the Summary page !

I've determined that A is always smaller than B and C, but B might be bigger than C, thou usually C is much bigger than B. I just don't see a pattern for them yet ...