1. What version of LoadRunner (LR) or PerformanceCenter (PC) are you using? PC 9.52
2. What is the protocol you are recording. Full url w/concurrent
4. If URL mode: Concurrent groups
5. Which PerformanceCenter feature or service packs are you using? 9.52
6. VuGen Recording - are you using Old or New Recording Engine?
7. -Click to view license info.
8. Is your support/maintenance contract current and active? Yes, overly active. [img]/images/graemlins/wink.gif[/img]
9. What platform(s) (PCs) and Operating Systems (Windows-XP, etc.) are being used for load generators and controllers? Include version and service packs (SP1 or 2, etc.)
10. If you have filed a service request with HP/Mercury, what have they told you at this point with respect to your issue? Filed and closed. HP could not reproduce. Suggested use SysInternals to detect which dlls were attached. Our policy is such that a lengthy desktop testing and legal process blocks using SysInternals.
In versions up through PC 8.1, transaction data related to usage of the lr_start/end_transaction_instance(), always showed up in the default report.html and also in the LRA file. Since we moved to 9.5x, the trans data no longer shows, yet user data points still show. Has anyone else bumped into this? If so, how did you overcome this? I like to use the lr_user_data_point_instance_ex() function to allow correlation of document sizes with trans times. This issue forced me to a work-around as follows. Wrap the lr_start/end_transaction_instance() within a lr_start/end_transaction() of the same name. While this does not force the lr_start/end_transaction_instance() function to output, it does make it easy to correlate data from the user data point data to the trans response time.
There have been reports of odd _transaction() behavior when the generators are mismatched to the core controllers. You may want to verify that the Load Generator software was upgraded at the same time as the rest of the performance center environment.