Moving the broker to a cloud control plane does not turn a virtual desktop into a website. Citrix DaaS, cloud-hosted Citrix Virtual Apps and Desktops, Azure Virtual Desktop (AVD), and Windows 365 still deliver a session: HDX or RDP paints pixels, and the work happens on a session host in a resource location. Finance will still ask how many concurrent users that host SKU can carry. Autoscale is not the answer to that question.
This is a 2026 method for EUC and VDI admins sizing cloud session hosts and DaaS catalogs. A website test of the Workspace URL is not a farm test.
HDX and RDP still deliver pixels
A Workspace URL test is not a farm test.
The cloud did not change the protocol contract. Citrix Workspace, the AVD web client, and the Windows 365 portal are web applications. The session that follows is not. HDX — the current name for the ICA family — and RDP send a bitmap. There is no DOM and no REST payload that means “the chart appeared.”
If you only load-test the Workspace or RD Web URL, you have exercised the front door and the identity hop. You have not exercised the VDA, the session host, FSLogix, GPO, or the published application. The events users wait on — logon, shell, first paint of the app — exist on the glass. Treat HDX and RDP as remoting protocols with a human on the other end, not as another API to replay.
Control plane is not the resource location
In Citrix DaaS the control plane lives in Citrix Cloud. Session hosts live in a resource location: Azure, AWS, Google Cloud, or a remaining on-premises datacenter. Cloud Connectors (or Connector Appliances) are the bridge. They sit in the path for VDA registration, brokering, and many hybrid identity designs. They are not the farm.
AVD has the same split: Microsoft’s control plane versus your host pools and session hosts. Windows 365 Cloud PCs are one user per PC, but the path still includes the gateway, the Cloud PC SKU, profiles, and the app. A green control-plane dashboard means the broker answered. It does not mean forty task workers on a D4s_v5 multi-session host can open the line-of-business app in eight seconds.
Pin the path in the test record: client version, Cloud Connector count, region, host SKU, image hash, profile storage, Gateway or RDP Shortpath, and MFA. Skip the Connector because “it is just a proxy” and you will be surprised on go-live morning.
Autoscale and bursting hide density problems
Cloud catalogs are built to grow. Citrix Autoscale, AVD scaling plans, and similar bursting add session hosts when concurrency rises. That is useful in production. It is a trap in a capacity test. If the pool scales out as you ramp, you can “pass” 400 users while each host is actually miserable at 25. You learned that the subscription can provision VMs. You did not learn sessions-per-host on that SKU — the number that sets max sessions, buffer capacity, and the monthly compute bill.
Run density with autoscale off, or with a fixed host count, until the experience budget breaks on that SKU. Run a second test with autoscale on to measure scale-out lag and cold-boot time. Bursting can also hide a saturated profile share, a slow Cloud Connector, or a GPO that only hurts when twenty logons hit one host at once — until the region is out of quota at 8 a.m.
What a defensible cloud number actually is
A defensible number is not “the catalog launched N sessions before the cloud returned a quota error.” It is the highest concurrency at which defined user transactions still meet a defined experience budget, on a named host SKU and image, with autoscale behavior written down separately. Write the acceptance line before the first ramp:
- Logon to a usable desktop: 45 seconds at p95, 60 seconds at p99.
- Launch the published line-of-business app, search, open the record: 8 seconds at p95.
- Fewer than 1% of sessions fail, disconnect, or hang during the sustain.
- Per-host CPU, memory, and profile IOPS stay inside production alert bands — on that SKU, not averaged across a bursting pool.
- If autoscale is in scope: a new host is ready and taking sessions inside a written budget (for example, six minutes from power-on to first successful logon).
When the run crosses that line, that concurrency per host is the number. ICA RTT, RDP round-trip, and a green Monitor or Azure workbook are useful. They are not “the chart appeared.”
Measure from the user’s screen
On HDX and RDP there are no client-side objects to bind to. The practical way to know a step finished is to watch the screen: image recognition and OCR against a baseline of what “done” looks like. Time the interval from the click or key until that image or text is visible.
GUI-level tools exist for this. CitraTest VU, for example, drives the real Workspace, AVD, or Remote Desktop client with keyboard and mouse, compares the live screen to baseline images, and does not install agents on the VDAs or session hosts.
Correlate the two views. When p95 “open chart” jumps from 6 seconds to 14 seconds at 28 users per host, you want host CPU, Cloud Connector health, and profile IOPS on the same timeline. The screen tells you it broke. The control plane and the resource location tell you which layer. Put generators where they represent a real site. If generator CPU is pegged, you are measuring the lab, not the catalog.
Login storm versus sustain
A login storm — two hundred users authenticating in two minutes — is a real cloud event: shift start, failback, or Autoscale powering a cold pool. It is not the same as two hundred users already in session doing work. Run both shapes. Storm: steep ramp; measure logon time, Cloud Connector and Workspace or Gateway CPU, broker latency, the profile store, and time waiting for hosts to boot. Steady state: slower ramp to target on a fixed host count, then a sustain long enough for memory growth, CPU ready time, profile I/O, and session reliability to show up. Thirty minutes is a demo. Two hours is closer to a shift.
If you only storm, you will size logon infrastructure and under-size the session hosts. If you only sustain, you will miss 8 a.m. If you only storm with autoscale on, you will size the cloud’s ability to boot VMs and still not know density.
A seven-step method you can take to a CAB
- Freeze the catalog, the SKU, and the autoscale policy. Record host SKU, image hash, client, Cloud Connector count, Gateway or RDP path, profile solution, and whether Autoscale is on. Change any of those mid-test and start over.
- Walk the path users actually take. Workspace, Gateway, or the AVD / Windows 365 front door, then Entra ID or Active Directory plus MFA, then launch, remoting session, profile and GPO, then the app. A Citrix result does not transfer to AVD. Rebuild the connection for each stack.
- Script the business day, not only a login. Logon is mandatory. It is not the workload. Script five to ten real-hour transactions: launch, search, open, save, print, idle. Put think time in.
- Take a single-user baseline, then a handful on one host. If one user already takes 40 seconds to a usable desktop, you have an image, profile, GPO, or Connector problem. Fix that before you add concurrency.
- Measure density with autoscale off; measure scale-out with it on; run the login storm as its own test. Do not fold all three into one ramp. The last density step that still passed is sessions per host — the number you take to the business.
- Watch the tail, the failures, and the scale-out lag. Report p95 and p99, plus fail, retry, disconnect, and “waited for a host” counts. Means hide the damage.
- Re-test when the catalog, SKU, image, Connector, region, or autoscale schedule changes. Last quarter’s on-prem number does not travel with the catalog.
FAQ
Can we web-test the Workspace URL and call it a cloud VDI load test?
You can load-test Workspace, StoreFront, or the AVD web client that way. You cannot size session hosts, HDX or RDP, profiles, Cloud Connectors, or the published application that way. The URL belongs in the path. It is not the farm.
Does autoscale mean we can skip density testing?
No. Autoscale answers “can the pool grow.” Density answers “how many good sessions fit on one host.” You need both. Skip density and you will overpay for compute or discover the limit when the region will not give you another VM.
Do AVD, Windows 365, and Citrix DaaS share a concurrency figure?
No. Reuse the transactions and the budgets. Rebuild the connection for each stack. A Citrix DaaS figure is not an AVD host-pool figure, and Windows 365 is one Cloud PC per user — test the SKU and the logon path, not multi-session density.
Take the number the bill and the users can both survive
A cloud VDI load test that a CAB will accept has five traits: it walks the real Workspace, Gateway, or AVD path; it drives HDX or RDP from a real client; it measures density with autoscale off and scale-out with autoscale on; it ramps and then sustains, with a separate login-storm run; and it stops at a pre-written experience budget measured on the user’s screen.
When you need that GUI-level path — real client, image and OCR, no agents on the session hosts — Tevron’s CitraTest VU is built for the job. See CitraTest VU load testing.