Main: Load Testing

Updated

Main: Load Testing

Overview

Use this page to understand how load testing works on the LoadGen platform before you build your first test. The Load Testing overview is the informational front door for the load and performance testing area, sitting in the Main section of the navigation menu alongside the other module overviews. It draws the moving parts as one diagram, sequences the work as a lifecycle, and links into the pages where each piece is configured.

Load testing answers the question "will it cope?". LoadGen drives real client software through real protocols, so a virtual user connects the way a real user does, over Azure Virtual Desktop, Citrix, RDP, or the web, rather than replaying raw network traffic. The business value is knowing your capacity limit before your users find it: how many concurrent sessions the environment sustains, where response times start to degrade, and which component gives way first.

This page changes nothing and requires no configuration to open. The capability cards are navigation into the load testing pages, and those pages keep their own licence and role gates.

Main: Load Testing, full page

Key concepts

  • Workload - A LoadGen script file (.lgs) describing what one simulated user does, for example opening an application, signing in, and working through transactions. Workloads are authored in LoadGen Studio and uploaded to the appliance. (related: managed on Configuration: Workloads)
  • Scenario - The load pattern: the phases that control when users start, how many are active, and when they idle or stop. A scenario shapes the ramp; the workload defines the behaviour. (related: Configuration: Testing: Scenarios)
  • Load profile - The object that ties everything together: connection technology, target user and agent counts, the test users to use, and optionally a System Under Test profile and a scenario. A test is always launched from a load profile. (related: Testing: Load Profiles)
  • Agent - The machine that generates the load. Full Agents provide complete load generation, Core Agents cover basic load testing, and VDI Agents execute profiles directly on Azure Virtual Desktop and Omnissa Horizon machines. (related: the Configuration LoadGen Agents section)
  • System Under Test (SUT) profile - The group of machines from which Windows Performance Counters are collected while the test runs, so you can correlate client-side response times with server-side CPU, memory, disk, and network. (related: Configuration: Systems Under Test: Profiles)

When to use it

  • When you are about to build your first load test and want the shape of the workflow before opening individual pages.
  • When you know you need a load test but are not sure which objects have to exist first, and in what order.
  • When you need to explain to a colleague or a stakeholder how LoadGen generates load and what it measures.
  • When you are sizing an environment and want to see where agents, test users, and licensed capacity fit into the picture.
  • When a test failed to start and you want to re-check the chain of prerequisites from one place.
  • When you want a launch point into Load Profiles, Run Test, Test Runs, or the analysis pages.

Before you begin

  • No prerequisites for opening this page. It is informational and ungated.
  • Running an actual test requires the load testing licence module. Testing: Run Test shows your licensed concurrent-user capacity as a badge in the page header, and starting a test without the entitlement returns a licence error with a link to licence management. Check your entitlement on Infrastructure: Licensing.
  • Recurring tests additionally require the LG053 Test Scheduling module. Without it, Testing: Schedules blocks the create flow and says so.
  • Editing load profiles requires the LoadProfilesEditor or GlobalAdmin role. Without it, the New Profile button is not shown.

Steps

Step 1

Open Load Testing in the Main section of the left navigation menu.

Expected result: The overview page opens immediately, with the architecture hero at the top. It renders on any appliance, including one with no agents, workloads, or profiles configured yet.

Step 2

Read the architecture hero.

The diagram separates the platform, the agents that generate load, and the environment being tested, and labels the network paths between them with port chips. A VDI Agent runs the same agent service as a Full Agent, so both use the same port.

Quantities drawn inside the diagram are illustrative and are prefixed e.g.; they do not read your configuration.

Main: Load Testing, architecture hero

Main: Load Testing, lifecycle strip

Step 3

Follow the lifecycle strip.

The strip lays load testing out as six ordered steps. The underlying chain, as documented across the Testing and Configuration pages, is:

  1. Register agents. Full, Core, or VDI agents must be online before a profile has real execution capacity.
  2. Upload a workload. Author the .lgs script in LoadGen Studio, then upload or publish it to the appliance on Configuration: Workloads.
  3. Define test users and a scenario. The user pool lives on Configuration: Testing: Users; the ramp phases live on Configuration: Testing: Scenarios.
  4. Build a load profile. Combine technology, users, agents, scenario, and optionally a SUT profile on Testing: Load Profiles.
  5. Run the test. Launch on Testing: Run Test immediately, at a set time, or after a delay, and watch it live on Testing: Active Test.
  6. Analyse the result. Review the run on Testing: Test Runs and drill into Analyse: Analysis.

The page's lifecycle strip, From plan to verdict, in six steps, reads: 1 Design (workload + profile), 2 Validate (automatic ramp-up analysis), 3 Schedule (or start right away), 4 Run (agents drive sessions), 5 Watch live (Active Test view), 6 Analyse (results + comparison). The numbered list above expands those labels (verified).

Step 4

Use the capability cards to enter the module.

Each card names one thing load testing does and links to the page where you do it. Selecting a card is read-only navigation; no test is started and no object is created from this page.

Main: Load Testing, capability cards

Step 5

Read the pulse chips, if present.

Where the platform holds a reliable count, such as the number of configured load profiles, the page surfaces it as a small live chip. Treat these as orientation only; the module pages are the authority for anything you intend to act on.

Next steps

Verify the result

The page is working correctly when the architecture hero renders as a diagram, the lifecycle strip shows its steps, and the capability cards navigate into the Testing pages. Nothing is saved here, so there is no state to confirm. If a capability card opens a page showing an activation card instead of the feature, that is the target page's licence gate rather than a fault on this page.

Troubleshooting

  • Symptom: A capability card opens a page showing an activation card with Activate License and Learn More. Fix: Load testing is not licensed on this appliance. Check Infrastructure: Licensing. This overview page is ungated by design and describes the module regardless.
  • Symptom: The lifecycle mentions Configuration pages you cannot see in the navigation menu. Fix: Configuration sections are hidden in Basic mode; switch the sidebar footer toggle to Expert.
  • Symptom: You reach Testing: Run Test but the Load Profile dropdown is empty and Start Test stays disabled. Fix: Only profiles with at least one user group assigned are runnable. Open Testing: Load Profiles and assign users to the profile.
  • Symptom: Testing: Schedules refuses to create a schedule and mentions LG053. Fix: The Test Scheduling module is not licensed. Verify on Infrastructure: Licensing; the manual Run Test path is unaffected.
  • Symptom: A quantity in the diagram does not match your environment. Fix: Numbers prefixed e.g. inside the diagram are illustrative examples, not readings of your configuration.
Was this article helpful?
0 out of 0 found this helpful