LoadRunner Architecture: How VuGen, Controller, and Analysis Fit Together

Understanding how LoadRunner’s components hand off to each other clarifies a lot of the otherwise-confusing terminology around “scripts,” “scenarios,” and “sessions” that trips up people new to the tool.

VuGen produces a script, not a scenario

A VuGen script (a .usr/Vuser script project, internally C-based with lr_* API calls) represents one virtual user’s behavior: a sequence of actions, with sections (vuser_init, Action, vuser_end) and any number of custom actions in between. A script alone doesn’t define load — it defines what one user does.

Controller turns scripts into a scenario

A Controller scenario assembles one or more scripts, assigns virtual user counts to each, defines scheduling (ramp-up, steady state, ramp-down), and specifies which physical or virtual machines (“load generators”) will actually run those virtual users. This separation — script defines behavior, scenario defines load — is conceptually similar to JMeter’s Test Plan/Thread Group split, just organized as separate tools rather than one GUI.

Load Generators: where virtual users actually run

Load Generators are the machines that execute virtual user instances during a scenario run — analogous to JMeter’s remote engines in distributed mode. Controller coordinates one or more Load Generators, distributing the configured virtual user load across them and collecting results back centrally.

Analysis works from result files, after the run

Once a scenario run completes, Controller produces result data that Analysis opens to generate graphs (transaction response time, throughput, Vuser status over time) and correlate it with any infrastructure monitors configured during the run (CPU, memory, custom counters via SiteScope or similar integrations). Analysis is a separate, after-the-fact step — unlike JMeter where you can watch a live dashboard during the run itself (though Controller does provide live monitoring graphs during execution too).

The protocol decision happens in VuGen, early

When creating a new VuGen script, you choose a protocol (Web/HTTP, Citrix, SAP, etc.) up front — this is one of the most consequential early decisions in a LoadRunner project, since it determines what VuGen actually records and what API calls are available in the generated script. Getting this wrong (e.g. recording at the wrong protocol layer for a thick-client app) often means starting over. The next article in this series covers protocol selection in more detail.

A typical end-to-end flow

1. Identify the protocol and record a script in VuGen.
2. Correlate and parameterize the recorded script (covered later in this series).
3. Validate the script runs correctly standalone (VuGen’s own “Replay” feature) before scaling up.
4. Build a Controller scenario: assign Vuser counts, load generators, and scheduling.
5. Run the scenario, monitoring live graphs in Controller.
6. Open results in Analysis for detailed post-run review and reporting.

Takeaway: LoadRunner’s three-tool split maps to three distinct questions — what does one user do (VuGen), how much load and from where (Controller), and what happened (Analysis) — keeping those questions separate in your head makes the tool’s terminology much less confusing.