Also published on the product site: autoscale-hides-sessions-per-host-citratest-vu.aspx
CitraTest VU density testing for Citrix Virtual Apps and Desktops and Citrix DaaS – prove sessions-per-host with Autoscale OFF first, then measure scale-out lag on the glass so scale-out cannot mask a bad host SKU.
Direct answer: Autoscale can hide a bad sessions-per-host number. If every density run lets Citrix Autoscale (on-prem or Citrix DaaS) keep adding session hosts, each machine may never reach the pack you claim to support – while Workspace, StoreFront, Gateway, and the broker stay green. CitraTest VU® load-tests from the glass: run density with Autoscale OFF (or pinned) first, size the host from WaitForImage / StartTimer/StopTimer moments of truth, then run a second test that measures scale-out lag. Do not let scale-out mask a bad sessions-per-host.
Teams that only ever "ramp until Autoscale catches up" often leave Monday morning with a false capacity story. New hosts absorb overflow; Director and the control plane look fine; nobody measured what a full session host feels like on screen when the catalog stops growing. That is not SKU truth. That is scale-out covering for density debt.
This post is the Autoscale-specific density method for CitraTest VU on Citrix Virtual Apps and Desktops and Citrix DaaS. It builds on The Control Plane Is Not the Farm and Logon storm vs density. It is not a how-to for splitting automated regression scripts (Control Plane ≠ Farm for automated testing), not APM continuous watch (Publish → Scenario → SLA), and not the general profile-then-scale sequencing article (Profile the User Journey, Then Scale the VUs). Same glass contract; this article is the order of operations when Autoscale is in the picture.
By Jay Labadini, Tevron
Why Autoscale can hide a bad sessions-per-host
Autoscale is useful operations. It is a poor substitute for density proof.
- Scale-out dilutes pack. When new session hosts keep joining under load, concurrency spreads across more machines. You never force the sessions-per-host number your SKU and image are supposed to carry.
- Broker green is not glass ready. Delivery Controllers / cloud brokers can place sessions and report healthy capacity while published-app first paint and in-session click-to-ready stretch on a packed host.
- Front door ≠ farm. Workspace, StoreFront, and Gateway are the control-plane front door. Session hosts are the farm. A green launch path does not prove density on the host.
- Storm-only runs miss sustain. A steep login storm may pass because Autoscale spun hosts in time – then mid-day density still hurts when everyone is already connected and working.
- Unnamed timers hide the host. If you only clock "session connected" or a single stopwatch, you cannot tell whether scale-out lag or packed-host glass latency broke first.
Size the host from the glass, not the broker. Prove what one (or a fixed set of) session host(s) can sustain under honest on-screen work – then decide what Autoscale is allowed to buy you.
Illustrative / method diagram – not Tevron customer results. Control-plane indices can remain "healthy" while glass-level response climbs when density is never isolated.
Control plane ≠ farm (reminder)
Keep the vocabulary tight for Citrix Virtual Apps and Desktops / Citrix DaaS:
| Layer | Examples | What a green check proves |
|---|---|---|
| Front door / control plane | Workspace, StoreFront, Gateway, broker / Delivery Controller | Auth, launch reachability, session placement – not packed-host glass latency |
| Farm / session hosts | VDAs / session hosts running published apps and desktops | Where HDX pixels, published-app work, and sessions-per-host density live |
URL and broker checks stay necessary. They are not density. For the deeper framing under load, see The Control Plane Is Not the Farm.
Illustrative method diagram – not customer results. The front door is not the farm.
Method: density with Autoscale OFF first
Before you celebrate scale-out, pin the farm (or turn Autoscale OFF / hold a fixed host count) and run a density / sustain phase with CitraTest VU:
- Encode the on-the-glass journey users cannot skip – Workspace / StoreFront / Gateway launch into the published app or desktop, then multi-step in-session work.
- Sync with WaitForImage on static bitmaps; place StartTimer immediately after each initiating action and StopTimer after WaitForImage confirms the screen state users care about.
- Hold concurrency at the sessions-per-host target you intend to claim – on that fixed host count – and exercise sustained work (not only logon).
- Read density from glass timers – published-app first paint, chart/grid ready, save/post confirmation – not from "ICA connected" or broker session count alone.
Prefer static bitmaps for sync cues that do not change (icons, window chrome, confirmation glyphs). Reserve OCR for dynamic text (IDs, order numbers, timestamps). OCR is not a wait/sync – confirm readiness with image functions first (WaitForImage, ClickOnImage), then OCR. Under VU, OCR calls have no timeout for wait/sync.
That first run answers: can this host SKU and image carry N concurrent users through real glass work? If it cannot, Autoscale will only spread the pain – or hide it until the catalog cannot grow fast enough.
Illustrative method diagram – not customer results. That pipeline is the measurement contract inside the density run Autoscale must not dilute.
Second run: measure scale-out lag
After density is honest on a fixed farm, turn Autoscale back on (or un-pin) and run a second test aimed at scale-out behavior – not at redefining sessions-per-host:
- What you change: allow capacity to grow under the same glass scripts and the same moments of truth.
- What you learn: how long until new hosts deliver usable glass (logon-to-shell / published-app ready) during the rush – scale-out lag – without pretending that lag is a substitute for density proof.
- What you do not do: treat a pass that only worked because hosts kept joining as proof of the old sessions-per-host number.
Login storm and density/sustain remain distinct ramp shapes on both runs. Storm stresses steep concurrent logons through the front door and broker. Density holds concurrency and works inside the session. Autoscale OFF belongs on the density proof; Autoscale ON belongs on the scale-out lag measurement. Mixing them into one "ramp forever" curve hides which story failed. See Logon storm vs density.
Illustrative method diagram – not customer results. Apply storm vs density on a pinned farm first; then measure Autoscale scale-out lag separately.
CitraTest VU on the glass (architecture, brief)
Per the CitraTest User Guide (Chapter 11) and Quick Start VU overview:
- A dedicated VU load server hosts many localhost RDP "CitraTest VU Sessions."
- Each session runs the profiled CitraTest script and opens its own client connection to the Citrix environment under test – Workspace / StoreFront / Gateway into session hosts – just as real users would.
- Scripts drive the remoted GUI with real mouse and keyboard, sync with bitmaps, and optionally use OCR for dynamic text after image sync.
- Separate measurement machines record response timers under load.
Nothing invasive is required on the session hosts for the glass path: the load is client-side. You change ramp, concurrency, think time, and whether Autoscale may grow the farm – not the definition of success. Success remains: the image-confirmed UI state appeared within the timer threshold under the load you claim to support.
Illustrative architecture based on User Guide Ch 11 / Quick Start VU overview – not a performance result chart.
Illustrative method diagram – not customer results. Encode the journey, prove density on a pinned farm, then measure scale-out lag.
Size the host from the glass, not the broker
Broker session counts, CPU averages, and Autoscale rules answer capacity placement. They do not answer whether the published app was ready on screen at the density you sell to operations. Pin the host count, hold concurrency, time WaitForImage moments of truth, and only then interpret Autoscale as a way to buy more of a host size you already trust – or as a lag you must budget for during storms.
Related method hubs: How to load test Citrix, Best Citrix Load Testing Tools, What is CitraTest VU?.
How this sits next to related posts (brief)
- The Control Plane Is Not the Farm – glass-level VU framing; this post expands the Autoscale / sessions-per-host method called out there.
- Logon storm vs density – why storm and sustain must stay separate; Autoscale does not collapse that split.
- Profile the User Journey, Then Scale the VUs – encode the journey before concurrency; Autoscale OFF density still needs an honest journey.
- Control Plane ≠ Farm (automated testing) – build separate login-storm vs sustained-path scripts; VU sizes them under load.
- CitraTest APM – keep the same glass definition of success as a production watch after lab density is proven.
Closing: prove density, then trust scale-out
Autoscale can hide a bad sessions-per-host number. Run density with Autoscale OFF (or pinned) first – WaitForImage sync, StartTimer/StopTimer on the glass, bitmaps for static cues, OCR only for dynamic text (OCR is not a wait). Size the host from what users see, not from the broker. Then run a second test that measures scale-out lag. Login storm and density/sustain stay distinct. Control plane ≠ farm: Workspace / StoreFront / Gateway are the front door; session hosts are the farm. Capacity stories that only worked because hosts kept joining are not SKU truth.
FAQ
How can Citrix Autoscale hide a bad sessions-per-host number?
When Autoscale keeps adding session hosts under load, each host may never reach the sessions-per-host density you claim to support. Broker and front-door metrics can stay green while glass latency on a packed host is never measured. Prove density with Autoscale OFF (or pinned) first; run a second test that isolates scale-out lag.
What is the CitraTest VU method for Citrix density vs scale-out?
First run: hold concurrency on a fixed host count with Autoscale OFF and exercise multi-step on-the-glass work with WaitForImage and StartTimer/StopTimer. That run sizes sessions-per-host from the glass. Second run: allow Autoscale and measure scale-out lag – how long until new capacity delivers usable glass – without letting scale-out mask a bad density number.
Is Workspace or StoreFront green enough to prove session-host density?
No. Workspace, StoreFront, and Gateway are the front door (control plane). Session hosts are the farm. Control-plane green is not farm proof. Size the host from the glass, not the broker.
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.
How does this post differ from The Control Plane Is Not the Farm and Logon Storm vs Density?
Those articles establish control plane vs farm and the login-storm vs density split. This article is the Autoscale-specific density method: prove sessions-per-host with Autoscale OFF first, then measure scale-out lag on a second run so scale-out cannot mask a bad sessions-per-host number.
When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.
Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.