VDI · /// Load Testing
Load test your VDI estate the way your users actually use it.
Real sessions on Citrix, AVD, Horizon and RDS. Logon, profile load and application launch are measured by one engine, so p95 means the same thing on every stack you compare.
Citrix · AVD · Horizon · RDSReal sessions, not HTTP scripts50 to 25,000+ vUsersFrom €1,099 / week
Live cockpit mid-run. Sessions, logon phases and p95 as the run happens.
The Problem
Why VDI breaks in production and not in your pilot.
A pilot proves the scenario runs. Production asks a different question: what happens when the whole cohort logs on inside the same twenty minutes, on the hosts you actually bought.
Pilot pools don’t predict production.
Twenty users on a lab pool tells you the workload executes. It tells you little about 2,000 people logging on between 08:45 and 09:05. Session density often degrades non-linearly: the curve can hold steady and then turn sharply as CPU contention and logon storms compound. You find that knee on purpose, or production finds it for you.
A request test and a session test measure different things.
An HTTP check can confirm that StoreFront or the AVD feed answers, and that the front door is up. A user session then negotiates the protocol, authenticates, brokers to a host, loads a profile and launches applications. Most of the cost sits in those phases, and they sit beyond the request that was measured.
Numbers gathered two different ways are hard to argue with.
Citrix tooling reports Citrix numbers. Azure tooling reports Azure numbers. When the migration question lands on your desk, two metrics collected by two methods rarely settle it. Measuring both stacks with one engine at least removes the measurement itself as a variable.
Why LoadGen for VDI load testing
Real sessions. One engine. One definition of p95.
LoadGen drives genuine sessions from agents inside your estate and measures what the user experienced — not what a request returned.
Real sessions, not scripted requests
Full agents drive Citrix, RDS and FAT-client sessions; VDI agents drive AVD and Horizon. Each virtual user logs on, loads a profile and launches applications against the real session host.
One engine, one definition of p95
The same engine computes generic p95 on every stack, so the metric is defined and calculated the same way on each side of a comparison. What each platform does under that load is what you are trying to find out — the measurement should not also be a variable.
One scenario, reused across stacks
Author the workload (`.lgs`) once and reuse it across stacks. The platform connection is configured per stack in its own flow: Citrix 7-step, AVD 7-step with Azure-native ARM discovery, RDS 8-step RDP, and the generic wizard with Omnissa technology for Horizon.
How it works
From scenario to breakpoint.
Four steps from an empty workload to a measured concurrency limit you can defend in a capacity review.
- Author the scenario once — a workload (`.lgs`) describing what a real user does: log on, open the apps, do the work.
- Configure the platform in its own flow — Citrix 7-step (StoreFront, Gateway, PNAgent, Basic ICA or Enhanced HDX), AVD 7-step (subscription, resource group, host pool), RDS 8-step RDP with native RD Gateway, generic wizard with Omnissa technology for Horizon.
- Launch real sessions and watch the live cockpit — Full agents for Citrix, RDS and FAT client, VDI agents for AVD and Horizon, with sessions, success rate, logon phases and latency visible while the run is happening.
- Capture generic p95 and find the breakpoint — logon time, application launch, throughput and latency computed the same way on every platform, then overlay runs, change one variable and re-run.
Orchestration cockpit. vUsers ramping against a real session host.
Where the scenario engine runs
Four VDI stacks — and the web and FAT-client workloads beside them.
Citrix
Basic ICA and Enhanced HDX. StoreFront, Gateway and PNAgent connection surfaces. Dedicated 7-step wizard.
Learn moreAzure Virtual Desktop
Azure-native ARM discovery — subscription, resource group and host pool authored directly in the flow. Dedicated 7-step wizard.
Learn moreOmnissa Horizon
Published apps and desktops on one flow, through the generic wizard with Omnissa technology. Driven by VDI agents.
Learn moreMicrosoft RDS
Dedicated 8-step RDP wizard with native RD Gateway support, across multi-session farms.
Learn moreWeb
Playwright-based browser automation on the same platform, with SessionSight heatmaps, replay and journeys for the web tier in front of the desktop.
Learn moreFAT client
Workload-based `.lgs` scripts on Full Windows agents, for thick-client applications running inside the session.
Learn morePeak and breakpoint
Find the knee on purpose.
The same scenario at growing scale shows where the pool stops holding. Warm-up, steady, spike and cool-down phases model the peak deliberately, so the first time you see it is not a Monday morning.
- Ramp to expected peak plus headroom, then keep going until p95 stops being acceptable.
- Per-step latency and error hotspots visible during the run, not reconstructed afterwards.
- Bind generic Windows performance counters to the run via SUT Monitoring, so host pressure and user experience share one timeline.
- Re-run after a change — image, SKU, policy, application version — and overlay the two runs to see what actually moved.
Spike simulation. Measured peak against modelled peak.
Measurement models
What a session test measures that a request test does not.
This compares two measurement models, not two products. A request-level test is the right model for a web application, and LoadGen runs those too, with Playwright. A VDI session test measures the phases that only exist once a session has been established.
| What happens | Request-level test | LoadGen VDI session test |
|---|---|---|
| Entry point answers (StoreFront, Gateway, AVD feed) | Measured | Measured |
| Authentication completes and a session is issued | Endpoint or form response | Completed logon, timed |
| Brokering to a session host | Outside the request | Timed per session |
| Profile load | Outside the request | Timed per session |
| Application launch inside the session | Outside the request | Timed per application |
| Effect of concurrency on the session host | Request throughput and response time | Session density and generic p95, with SUT counters |
Proof
Numbers from the platform.
1.45M+
Tests run
across the customer base
250M+
Monitoring sessions
across the customer base
50 → 25,000+
vUsers · license tiers
starts at 50, scales up to 25,000+
From €1,099
Per week · transparent
starts at 50 vUsers
Where VDI load testing lands
Three decisions this evidence is built for.
Sizing input for capacity planning
Measured session density per host feeds the sizing decision directly: session-host SKU, host-pool count, storage and licence tiers. Measurement, not a spreadsheet estimate.
See use caseCitrix and AVD on the same scenario
Run the same workload on the current estate and the target estate, with p95 computed the same way on both, and take the cutover decision on measurement rather than on whoever argues best.
See use caseAfter go-live: continuous synthetic monitoring
Load testing proves the estate holds before the wave ships. Synthetic monitoring keeps watching the same journeys once real users are on it.
See use caseSee it run against your own estate.
We configure a scenario for your platform on a call, fire real sessions from agents in your environment, and walk you through the live cockpit while the run is happening. Every engagement starts with a tailored demo and a Proof of Concept in your own infrastructure.
FAQ
VDI load testing questions.
What is VDI load testing?
VDI load testing measures how a virtual desktop environment behaves under realistic concurrent user load. Instead of sending HTTP requests, it launches real sessions that log on, load a profile and open applications, then measures logon time, application launch time and responsiveness as concurrency rises. The goal is to find the point where session density stops being acceptable — before production finds it for you.
How is VDI load testing different from web load testing?
They measure different things. A request-level test measures request and response times, which is the right model for a web application. A VDI session test measures the session itself: protocol negotiation, authentication through StoreFront or Gateway, brokering to a host, profile load and application launch. Those phases exist only after a session is established, and they are usually where VDI degrades.
How many virtual users do I need?
Enough to reach realistic peak concurrency for the estate you are validating, not your total named users. A common approach is to test at expected peak plus headroom. LoadGen licenses from 50 vUsers and scales past 25,000.
Can LoadGen load test Citrix?
Yes. Citrix has a dedicated 7-step wizard covering StoreFront, Gateway and PNAgent connections, with both Basic ICA and Enhanced HDX. Citrix sessions are driven by Full agents.
Can LoadGen load test Azure Virtual Desktop?
Yes. AVD has a dedicated 7-step wizard with Azure-native ARM discovery — subscription, resource group and host pool are authored directly in the wizard. AVD sessions are driven by VDI agents.
Can LoadGen load test Omnissa Horizon?
Yes. Horizon runs through the generic wizard with Omnissa technology, covering published apps and desktops in one flow, driven by VDI agents. There is no separate Horizon wizard and no native vCenter integration.
Can I compare Citrix and AVD directly?
This is the main reason to use one tool for both. The same workload is reused on each stack, with the platform connection configured per stack in its own wizard, and generic p95 is computed the same way on both sides. That makes the comparison a comparison of the platforms rather than of two measurement methods.
What is p95?
The 95th percentile: the value below which 95% of measurements fall. For a logon-time p95 of 12 seconds, 95% of logons completed within 12 seconds and 5% took longer. It is used instead of an average because averages hide the slow tail, and the slow tail is what generates tickets.
How does session density work?
Session density is how many concurrent sessions a host can carry while still meeting your performance targets. It depends on host CPU and memory, the workload profile, the platform and your own acceptance thresholds. It is measured rather than calculated, which is why a spreadsheet estimate and a measured result routinely disagree. See /vdi-capacity-planning for the sizing side of this.
Do I need agents in my environment?
Yes. LoadGen deploys as an appliance (Ubuntu with Docker recommended, or bring your own Windows) plus agents. Core agents handle web, API and background monitoring; Full agents handle Desktop, RDS, FAT client and Citrix; VDI agents handle AVD and Horizon.
How quickly can I start?
The documented onboarding flow runs about 215 minutes to a first completed test: 30 minutes setup, 60 minutes configuration wizards, 15 minutes workload creation, 20 minutes agent deployment, and 90 minutes testing and analysis.
What does VDI load testing cost?
Load & Performance Testing starts at €1,099 per week at the 50-vUser tier, and is licensed by vUser tier from 50 to 25,000+ with terms from one week to five years. Larger tiers are priced accordingly — the €1,099 entry point does not cover every tier.
Does LoadGen offer a free trial?
No. LoadGen does not offer a free trial. Every subscription begins with a tailored demo and a Proof of Concept run inside your own infrastructure, so you evaluate on your estate and your data rather than on a sandbox.
