LoadRunner is common in large systems requiring performance checks across protocols, load-generator management, and correlation with infrastructure metrics. Understanding scenarios and experiments is more useful than memorizing button locations. Even an advanced platform cannot automatically validate a recorded scenario.
LoadRunner includes different products, editions, and interface generations. Confirm capabilities, components, protocols, and usage terms for the installed version. The example below is a VuGen Web HTTP/HTML C script; it cannot be transferred unchanged to DevWeb or assumed universal across the family.
The workflow components
Create and debug a virtual user, define the load profile, execute a run, and analyze results. A classic workflow uses VuGen, run control, generators, and analysis. Exact components depend on the solution.
Investigate these levels separately. A script may pass in VuGen yet lack data on a remote generator. It may generate the right load while report transaction boundaries are wrong. Checking each level prevents confident conclusions from incomplete measurement.
Protocol and user meaning
APIs generally need an appropriate HTTP script. Protocol-level requests do not measure browser rendering or interface JavaScript. Time to usable screen requires another method or separate client observation.
Describe business operations before recording: login, search, request creation, and status reading. Define transaction start and end. One transaction around a whole session obscures slow steps; many meaningless transactions create noise.
A minimal VuGen fragment
In an existing Web HTTP/HTML project, the following Action reads a catalog from your own test environment. The endpoint must return status 200 and contain items. Replace the example domain with the agreed environment and configure timeout in runtime settings before execution.
int Action(void)
{
lr_start_transaction("catalog");
web_reg_find("Text=items", LAST);
web_url("catalog_request",
"URL=https://qa.example.test/api/catalog",
"Resource=0",
"RecContentType=application/json",
LAST);
if (web_get_int_property(HTTP_INFO_RETURN_CODE) != 200) {
lr_end_transaction("catalog", LR_FAIL);
} else {
lr_end_transaction("catalog", LR_AUTO);
}
return 0;
}This is a VuGen fragment using its headers and runtime, rather than a standalone C program. First run one iteration with one user. Intentionally change expected text and verify that the selected error-handling settings mark both request and transaction as failed.
Why registration precedes the request
web_reg_find registers a check for the next applicable operation. Its immediate return value does not indicate whether future response text was found; the check executes when the response arrives. Understand correlation-function registration timing in the same way.
Searching for items is only a teaching check, not full JSON Schema validation. Real scenarios need assertions on meaningful fields and values. Fast responses with empty or incorrect business data must not count as successful purchases or requests.
Correlation and parameters
Extract sessions, CSRF tokens, and object IDs from current responses. For JSON, use an appropriate extraction function registered before the relevant request. Verify the extracted value exists and use it in the next action.
Parameterize users and input data separately. One account shared across hundreds of Vusers can create artificial session or record contention. Understand parameter allocation and capacity, especially across generators. The dataset must support the full planned run.
Think time, pacing, and profiles
Think time models pauses between human actions; pacing controls repeated iteration starts. Their accidental interaction can change actual intensity substantially. With rising server delays, a fixed busy-user population generally starts fewer new operations.
Vuser count therefore differs from requests per second. Match the model to the question: concurrent operators or independently arriving requests? Verify achieved transactions and requests per interval. One universal profile cannot answer every performance question.
Preparing generators
Check versions, dependencies, environment access, certificates, and test files. A remote generator may have different routing or TLS configuration from the author's machine. A small validation run is more useful than a long test dominated by infrastructure errors.
Observe generator CPU, memory, networking, and available connections. Add generators only when a corresponding limit is identified. A data-setup or script problem will merely be replicated across more nodes.
A practical experiment
For a test catalog, agree on ramp-up, steady state, and stop phases. Prepare a known record discoverable independently of cache state. Record build, dataset size, resources, and latency criteria before running; the project determines numeric thresholds.
During steady state, expect correct responses and agreed thresholds at actual achieved load. Observe database pools, CPU, memory, and queues. Classify rising errors first: business assertions, timeouts, infrastructure, or overload. One red aggregate line cannot explain the cause.
Common mistakes and conclusions
Common mistakes include trusting recordings without correlation, timing login instead of the operation, treating Vusers as intensity, and mixing documentation editions. Conclusions about the whole product from one endpoint or comparisons using different datasets are equally risky.
Retain scripts, runtime settings, profiles, component versions, achieved flow, and resource observations. Explain which requirement was met and under what conditions. LoadRunner's value is a controlled experiment with evidence suitable for retesting.