Glass-level CitraTest VU load testing for Citrix, RDS, and cloud VDI in 2026 - login storm vs density, HDX/RDP pixels, WaitForImage timers.
Direct answer: Control-plane green (Director, ICA RTT, Workspace 200) is not proof that concurrent users can finish the job on screen. CitraTest VU® load-tests Citrix, Microsoft RDS, AVD, and cloud multi-user sessions from the glass: real client connections, real mouse and keyboard, WaitForImage sync, StartTimer/StopTimer for on-screen readiness. No agents on session hosts for the glass path. The control plane is not the farm.
Director is green. ICA RTT looks fine. The Workspace URL returns 200. And the clinician - or the claims clerk, or the trader - is still staring at a spinning published app.
That gap is not a monitoring failure so much as a category error. Control-plane health tells you whether brokers, gateways, and session hosts are alive. Load testing for end-user computing has to answer a harder question: did the business screen appear on the glass, under concurrent load, in time?
Citrix Virtual Apps and Desktops, Citrix DaaS, Microsoft RDS, AVD, and cloud multi-user sessions still deliver pixels, not HTML pages. HDX and RDP paint a desktop. If your load tool never drives that desktop with a real client, real keyboard, and real mouse - and never times what appears on screen - you are stress-testing the control plane while hoping the farm behaves.
Illustrative / method diagram - not Tevron customer results. Control-plane indices can remain "healthy" while glass-level response climbs with concurrency.
What glass-level VU load testing means
CitraTest VU is Tevron's virtual-user load product for this class of problem. Per the CitraTest User Guide (Chapter 11) and Quick Start VU overview, the architecture is deliberate:
- A dedicated VU load server (Windows Server with Remote Desktop Services) hosts many localhost RDP "CitraTest VU Sessions."
- Each session runs a CitraTest script that opens its own client connection to the environment under test - Citrix, RDS, or cloud - just as a group of real users would.
- Scripts drive the desktop with real mouse clicks and keyboard input, sync and verify with bitmap images, and optionally use OCR for dynamic text.
- Separate measurement machines record response timers under load; results land in a results database and VU Results Console. Existing CitraTest APM hosts can serve as measurement machines when that is how you operate.
Nothing invasive is required on the session hosts for the glass path itself: the load is client-side. You size and validate from what the concurrent user sees.
Illustrative architecture based on User Guide Ch 11 / Quick Start VU overview - not a performance result chart.
That is the operational definition of glass-level load testing: time the on-screen moment of truth (login complete, chart drawn, order line ready, Epic workspace usable), not merely the protocol handshake that started the session. Use WaitForImage to confirm readiness; place StartTimer after the initiating action and StopTimer after the image confirms completion.
Related: What is CitraTest VU?, How to load test Citrix, Logon storm vs density.
2026 method split: login storm vs density/sustain
EUC teams that collapse every scenario into "ramp to N users and hope" mix two different failure modes. Tevron's 2026 Citrix / RDS / cloud method guidance separates them on purpose:
| Phase | What you stress | What you learn |
|---|
| Login storm | Steep concurrent logons (broker, profile, session spin-up) | Can the farm absorb the rush? |
| Density / sustain | Hold concurrency; exercise multi-step business work on the glass | Sessions-per-host, glass latency, SKU and autoscale truth |
Autoscale can hide a bad sessions-per-host number if you only ever storm and never sustain with density held and autoscale off (or controlled). A second run that isolates scale-out lag is often the difference between "we passed" and "Monday morning still hurts."
Illustrative method diagram - not customer results. Apply the same split to Citrix, Microsoft RDS, and cloud VDI / DaaS catalogs.
Use the same glass scripts for both phases. Change ramp, concurrency, and think time - not the definition of success. Success remains: the image or OCR-verified UI state appeared within the timer threshold under the load you claim to support.
Why Workspace / RD Web URL tests miss the farm
A StoreFront, Gateway, Workspace, or RD Web Access check is necessary. It is not sufficient.
- URL / control-plane tests cover HTTPS health, auth redirects, and whether the launch icon is reachable.
- HDX / RDP glass paths cover the session host, the published app, and whether the business step completed on screen under concurrency.
Illustrative method diagram - not customer results. The control plane is not the farm.
When organizations "load test Citrix" by hammering Workspace URLs - or by replaying protocol traces that never wait for the chart to paint - they optimize the path users take to the session, then discover production pain inside it. Glass-level VU testing closes that gap without inventing a parallel synthetic protocol universe: each VU opens a real client connection and works the real GUI.
VU OCR Engine callout (do not treat OCR as wait/sync)
Quick Start and Rel Notes [878a1] document a dedicated CitraTestVUOCREngine.exe on the load server: a shared OCR service for all VU sessions, with an image cache so repeated regions are not re-OCRed blindly.
Operational rules that matter for script authors:
- OCR under VU is not a wait or sync. VU OCR calls have no timeout for that purpose. Confirm readiness with image functions first (
WaitForImage, ClickOnImage, and friends), then OCR.
- No full-screen OCR and no OCR-based Advanced Areas on the VU OCR path. Image-based Advanced / Relative / Fixed areas remain appropriate.
- Prefer bitmaps when the UI cue is static; reserve OCR for dynamic text that cannot be a static baseline image.
Ignore those rules and you get flaky load scripts that look like "OCR problems" when they are really sync problems.
Sizing note: RAM for the VU load server
Current User Guide Chapter 1 and Quick Start align on:
8 GB baseline + 8 GB additional RAM per 200 VU sessions, quad CPU minimum, 200 GB disk minimum, RDS configured per Chapter 11.
Release Notes front-matter and an older Chapter 11 checklist still mention 4 GB + 1 GB per 20 VUs. Treat the 8 GB + 8 GB / 200 formula as the versioned requirements summary for planning, and resolve any remaining conflict with Tevron before freezing hardware SKUs.
Also operational: do not minimize VU RDP windows during a run - RDP can blank the display, and scripts need a visible desktop to see.
How VU pairs with APM (brief)
Load testing and production watch are the same path at different times:
- CitraTest VU - size the farm in the lab (or a controlled window): login storm, then density/sustain, same glass scripts, timers under concurrency.
- CitraTest APM - schedule the same class of glass transaction in production so regressions show up before the help desk queue does.
Chapter 11 explicitly allows APM machines to act as VU measurement machines and the APM results path to participate in VU results. One license story on the Tevron VU page covers Citrix, RDS, AVD, and Windows 365 client paths - because HDX and RDP are still pixels either way.
Closing: test the glass, then watch the glass
A green Director dashboard is evidence that something is up. It is not evidence that your concurrent users can finish the job. In 2026, separate login storm from density/sustain, refuse to confuse a Workspace 200 with a painted chart, size the VU load server with the current 8 GB + 8 GB / 200 guidance, and keep OCR in its lane (cache yes; wait/sync no).
Then keep the same glass definition of success in production monitoring. That is how lab confidence survives Monday morning.
FAQ
Why is the control plane not the farm in Citrix and RDS load testing?
Workspace, Gateway, StoreFront, and RD Web URL checks cover HTTPS health and launch reachability. HDX and RDP still deliver pixels on a session host. Glass-level VU testing drives the real client GUI and times what appears on screen under concurrency.
What does CitraTest VU glass-level load testing measure?
Each VU session opens a real client connection, drives mouse and keyboard, syncs with WaitForImage (and related image functions), and captures StartTimer/StopTimer for on-screen moments of truth such as login complete, chart drawn, or order line ready.
What is the difference between login storm and density/sustain?
Login storm stresses steep concurrent logons (broker, profile, session spin-up). Density/sustain holds concurrency and exercises multi-step business work on the glass to validate sessions-per-host, glass latency, SKU, and autoscale truth.
Can OCR be used as a wait or sync under CitraTest VU?
No. VU OCR calls have no timeout for wait/sync. Confirm readiness with image functions first (WaitForImage, ClickOnImage), then OCR. Prefer bitmaps for static UI cues; reserve OCR for dynamic text.
Do you need agents on session hosts for CitraTest VU?
No. For the glass path, load is client-side from VU sessions on a dedicated load server. Nothing invasive is required on the session hosts themselves.
Contact Tevron
Tevron LLC
402 Amherst Street, Nashua, NH 03060
Phone: 866.788.3650
Email: sales@tevron.com
Web: www.tevron.com
Product: CitraTest VU - Citrix, RDS & cloud load testing
Charts labeled illustrative are method diagrams, not customer benchmarks. Citrix, Director, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, Azure Virtual Desktop, Epic, and related marks are trademarks of their respective owners. Tevron is not affiliated with Citrix, Microsoft, or Epic. Names are used for identification only. CitraTest VU® and CitraTest APM® are Tevron products.