LoadRunner Analysis: Reading Graphs and Reports Correctly

LoadRunner Analysis opens the result data from a Controller scenario run and generates a large library of possible graphs — knowing which ones actually answer the question you care about (rather than just generating an impressively long report) is the real skill.

Transaction Response Time graphs

The Average Transaction Response Time graph, plotted over the test’s duration, is usually the first one people open — but as covered elsewhere on this site regarding percentiles, the average can hide tail-latency problems. Analysis also offers Transaction Response Time (Percentile) and Transaction Response Time (Distribution) graphs specifically to address this — use these alongside the average, not instead of looking at the average at all (the average still has some value for tracking trend, just not for understanding worst-case experience).

Vusers graphs

Running Vusers confirms your scenario actually achieved the concurrency you configured — a useful sanity check that ramp-up behaved as expected and that Vusers didn’t fail early en masse (which would show as a count that never reaches your target or drops unexpectedly mid-run). Vuser status breaks down running/ready/failed counts over time.

Throughput and Hits per Second

Analogous to JMeter’s throughput graphs — confirms the actual achieved request rate, and whether it held steady, ramped as expected, or degraded mid-test (often a sign you found a real capacity ceiling, same interpretation as in JMeter’s dashboard).

Merging graphs for correlation

Analysis supports merging multiple graphs onto one timeline (e.g. overlay Transaction Response Time with Running Vusers, or with a server-side resource counter if monitoring was configured during the run) — this is where real diagnostic insight tends to come from: seeing that response time degradation started exactly when Vuser count crossed a certain threshold, or exactly when a server-side CPU counter spiked, ties symptom to cause far better than viewing either graph in isolation.

Filtering by transaction and time range

Analysis lets you filter graphs to specific transactions (rather than all of them at once, which can be visually overwhelming) and to a specific time range — useful for excluding ramp-up/ramp-down periods from steady-state analysis, the same principle covered for JMeter’s percentile analysis.

Auto-correlation and the Cross Result feature

For comparing multiple separate scenario runs (e.g. baseline vs. after-a-fix), Analysis’s Cross Result feature lets you open and compare graphs from two different result sets side by side — more structured than manually comparing two separately generated reports, and the right tool specifically for before/after regression validation.

Exporting for reporting

Analysis can export graphs and summary data (HTML report, raw data export) for sharing with stakeholders who don’t have Analysis installed themselves — worth setting a consistent template for what a “results report” includes across your team, rather than ad hoc exports that vary run to run.

Takeaway: Analysis’s real value is in merging and correlating graphs, not any single graph viewed alone — the question “why did response time degrade” is usually answered by overlaying it against Vuser count or a server-side resource metric, not by staring at the response time graph by itself.