Reducing a LoadRunner finding with concurrency evidence

Reducing a LoadRunner finding with concurrency evidence comes down to one move: replacing the total Vuser allocation the audit has assumed with the real peak that the test runs actually drove. LoadRunner is licensed by simultaneous virtual users, and the run data already records how many ran at once, so the finding falls to whatever the peak concurrency genuinely was.

A LoadRunner finding inflates when an audit counts the Vuser capacity that was provisioned, licensed, or configured rather than the number that ever ran together. Performance testing is bursty by nature: a team might own a large protocol bundle but only ever drive a fraction of it in any single run, and the simultaneous figure across the audited period is what the entitlement is sized against. Because the EULA places compliance on the licensee, the run data that proves the real peak has to come from the buyer, and presenting it cleanly is what converts an assumed allocation into a defended number.

Why concurrency evidence reduces a LoadRunner finding

The Vuser metric meters simultaneity, not allocation. A team that provisioned a large Vuser pool but only ran a few hundred at peak owes against the peak, not the pool, and the gap between the two is exactly what concurrency evidence removes. An audit that counts configured capacity, total scenarios, or the sum of every Vuser ever defined charges for load that never existed at one moment, the central error explained in how Vuser counting inflates a LoadRunner finding. Concurrency evidence is the antidote because it shows the single highest simultaneous figure the system ever reached.

The reason the evidence is decisive is that LoadRunner records it. Every controller run logs how many Vusers were active, so the peak concurrency is not an estimate but a measured fact already sitting in the run results. The defense is therefore less an argument than a presentation: pull the run logs, find the high water mark, and put it in front of the audit in place of the allocation. Whether the audit can even count a momentary peak the way it has is a separate question, addressed in can OpenText count peak Vusers against your license.

How to build the concurrency reduction

Pull the controller run data

The peak simultaneous Vuser figure lives in the controller run results across the audited period. Gathering those results and identifying the high water mark is the raw material of the reduction, and it parallels the scoping discipline in how to scope LoadRunner Vuser bursts.

Establish the metric the license uses

The reduction only works if the entitlement is genuinely metered by concurrent Vusers, so confirming what a Vuser is and how it is licensed comes first, the ground covered in what is a Vuser and how is it licensed.

Set aside provisioned capacity

Once the peak is established, the provisioned pool and the configured scenarios drop out of the analysis, the same separation of capacity from real use that governs LoadRunner environment counts and license exposure.

How we reduce a LoadRunner finding under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. We take over the single controlled channel and ensure the controller run results are preserved, because the peak concurrency figure that drives the reduction lives in that data.

Reconstruct. We build the effective license position by establishing the Vuser metric and measuring the peak simultaneous figure from the run logs, before any vendor measurement fixes a higher allocation in place.

Rebut. We challenge every line that counts provisioned capacity or summed scenarios, replacing the allocation with the measured peak concurrency. The finding falls by the difference between the two.

Resolve. We settle on the peak based count and, where it serves you, convert forward into an OpenPass agreement that records the concurrent Vuser metric and how it is measured, so the next review starts from real concurrency rather than provisioned capacity.

An anonymised outcome

The reason the concurrency reduction is worth pursuing is the remedy behind the finding. On noncompliance the licensee is deemed to have acquired licenses at then current list price, owes back maintenance and support, owes first year maintenance on the new licenses, and reimburses the cost OpenText incurs performing the audit, so collapsing an assumed allocation to the real peak can lift a large block of charge at once. Our anonymised case files show reductions of this scale across the estate, including a banking ArcSight finding reduced from $6.0M to $1.8M, a 70 percent reduction built on splitting a momentary burst from sustained activity. A LoadRunner finding yields to the same logic, because the run data already separates the peak from the provisioned pool.

Let the run logs set the number

The durable lesson is that a LoadRunner finding is reduced with measured data, not argument: the controller results already hold the peak concurrency that the entitlement is sized against, and the reduction is simply to put that figure in front of the audit in place of the allocation. A buyer who pulls the run logs and presents the high water mark holds the finding to the load that genuinely ran at once. To build the position, read how Vuser counting inflates a LoadRunner finding and how to scope LoadRunner Vuser bursts, alongside can OpenText count peak Vusers against your license. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If a LoadRunner finding counts provisioned capacity against your license, open a case.