How to Measure Sage Response Time (From the Glass)

Posted on by
How to Measure Sage Response Time (From the Glass)
Tevron editorial illustration: The API returned 200. The invoice screen is still spinning.
Editorial illustration for this article. Not a data chart.

The API returned 200. The invoice screen is still spinning. CDN cache is warm. Browser RUM says the document loaded. Finance and ops staff are still waiting for the ledger to paint and payroll to confirm. That is the Sage response-time problem: SaaS or protocol health is not the wait the business feels.

Direct answer: Measure Sage – accounting, ERP, and payroll products including Sage Intacct, Sage X3, and Sage 50cloud / 200-class desktop and cloud accounting – response time from what finance and ops staff see on screen – on the glass – not only from browser RUM, CDN or API latency, synthetic HTTP checks, or “the page returned 200.” Time the interval from a click or key until the expected Sage UI is visible: login-to-home, ledger / GL ready, AP / AR invoice or payment step, report / dashboard / payroll run ready. That interval is click-to-ready – the number a controller, help desk, and IT vendor can share.

Sage is business management software for accounting, people, payroll, and payments (product context: Sage). Browser Intacct / cloud suites and thick-client or remoted desktop apps still paint a GUI. Sister glass methods: Remedly, Epic, Oracle Health / Cerner, plus Citrix, RDS, and cloud VDI. Method framing: on-the-glass APM. This article times Sage itself.

Why a green SaaS tile is not “Sage is ready”

Cloud and hybrid finance suites sit behind HTTPS, CDNs, identity providers, browsers, and often Citrix, Microsoft RDS, or AVD. Uptime pages, URL checks, API latency, and Real User Monitoring (RUM) tell you the service is reachable and the document finished. They are not a stopwatch for “the company home painted,” “the journal entry opened,” or “payroll confirmed.”

A tab can show a spinner, a skeleton ledger, a half-hydrated AP form, or a toast that never confirms – and still count as a successful page load. Client-side rendering and heavy report grids sit after the network already said OK. An HTTP generator that hammers login times the front door, not the workflow.

A 200 from the API is useful. It is not the same as “the invoice screen appeared.”

If Sage is opened inside Citrix, Microsoft RDS, AVD, or other cloud VDI, the split doubles: protocol green still is not Sage UI ready. ICA/HDX or RDP can stream a spinning browser or thick client while the ledger is still hydrating. Host CPU and broker tiles do not close a “Sage is slow” ticket. Use the Citrix, RDS, and cloud VDI posts above for remoting.

Schematic: green CDN, API 200, RUM, and protocol tiles do not equal Sage UI-ready states for home, GL, AP/AR, and payroll on the glass.
Schematic from this article: network/HTTP/SaaS health versus glass time. Not a customer dashboard and not a measured finance org.

Top row is what network, CDN, API, RUM, and remoting health see. Bottom strip is what finance and ops staff wait on. Only the glass strip is Sage response time as a person experiences it.

Which Sage steps to time

Write the steps before you pick a tool. Four intervals cover most finance UX arguments on browser Intacct / cloud and thick-client or remoted desktop sessions:

  1. Sign-in to usable home / company – from credentials submitted (or SSO return) until usable Sage navigation is ready – company context, menus, no full-screen spinner. Not “the IdP redirected” or “the document loaded.”
  2. GL / ledger / journal entry ready – from opening the general ledger or starting a journal entry until the form and controls are usable. Not “the route changed.”
  3. AP / AR invoice or payment step – from open invoice, vendor bill, customer invoice, or payment action until that step’s ready state on glass. Pin the ready image for your product (Intacct, X3, 50cloud / 200-class).
  4. Report / dashboard / payroll run – from the click that starts a financial report, dashboard refresh, or payroll run step until results or confirmation paint.

Pin the browser or thick-client build (or published-app / Workspace image if remoted), display scale, company branding, and ready baselines. A timer on a moving theme is a story, not a measurement. When Sage runs inside Citrix or other VDI, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session Sage work on hosts that already have users.

Time it like a script, not a feeling

On a modern cloud finance UI there is often no reliable DOM event that means “done” – and inside a remoted browser or thick client none you can trust from outside the glass. The practical signal is the bitmap:

  • StartTimer when the user action happens – submit, click, or key.
  • WaitForImage until a baseline of the ready state is visible: home chrome, ledger, invoice step, report or payroll confirmation.
  • StopTimer when that image matches.

The recorded interval is click-to-ready for that step. Image recognition – and OCR when the ready state is text – is how you know the glass painted, without an agent inside Sage. That is the core of on-the-glass APM.

Four-step finance waterfall: StartTimer, WaitForImage, and StopTimer for Sage sign-in, GL, AP/AR, and payroll or report click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for sign-in, GL, AP/AR, and report / payroll steps. Change the start action and the ready image. Keep the timer. Sister posts use the identical glass method for EHR and remoted desktops.

Stopwatch versus synthetic

A person with a stopwatch can time one Sage invoice open on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at month-end close, hold concurrent sessions while timing payroll, or attach a screenshot of the failed state. Means hide the damage until finance is already saying “Sage is slow.”

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real browser or remoted Workspace / Remote Desktop client, on a schedule or under load, with the same home, ledger, invoice, and payroll-ready baselines – continuous on-the-glass monitoring, or a Sage load/change test when it ramps virtual users.

If you only have a stopwatch, use it to write the acceptance line – then automate it. Example go-live language (schematic only – not a customer dataset or Sage SLA): sign-in to usable home at p95 inside budget; GL ready at p95; open AP invoice and payroll step inside budget at p95; fewer than 1 percent of runs hang or miss the ready image.

Continuous watch versus load test

On-the-glass is an idea, not a product SKU. Two jobs share the path:

  • CitraTest VU load-tests capacity and change. Freeze the image, walk sign-in → GL → AP/AR → report / payroll, ramp concurrent staff-like users, stop at the written budget. When remoted, run storm and sustain separately. See CitraTest VU load testing.
  • CitraTest APM watches production. The same Sage steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.

The lab answers how many good concurrent Sage workflows fit before click-to-ready breaks. The watch answers whether today’s ledger and invoice steps are still inside the line. Do not use a load-test generator as your only production monitor. No agents inside Sage’s cloud or desktop binaries – each virtual user is another staff browser or remoted session driving the UI like a person.

What this is not

  • It is not a replacement for CDN, API, uptime, or browser RUM graphs. Keep those for the network and document path.
  • It is not an HTTP soak of the login URL or a health endpoint. Keep that for the front door.
  • It is not “we have full-stack APM, so Sage is covered.” Ledger and invoice GUIs are pixels staff wait on, not only traces.
  • It is not a claim about Sage proprietary internals, unpublished SLAs, or customer contracts – only delivered UI readiness on the glass.
  • It is not a promise that last month’s number survives a UI redesign, new company theme, browser or thick-client update, or a move into Citrix / RDS / AVD. Re-time the glass when the image changes.

Take the interval staff already wait

Sage response time is click-to-ready on the glass – home, ledger, AP/AR, and report / payroll ready – not a green CDN or protocol tile. Time sign-in, GL, invoice / payment, and payroll steps that generate tickets. When remoted, separate logon storm from density. Use a stopwatch only to write the line; use a synthetic to keep it: CitraTest VU under load or change, CitraTest APM on a continuous watch.

When you need that path without agents in the Sage tenant or desktop install – real browser or remoted client, image and OCR, StartTimer to StopTimer for Sage – schedule a demo. Product pages: on-the-glass APM, CitraTest VU, and CitraTest APM.

Sage, Sage Intacct, Sage X3, Sage 50cloud, and related marks are trademarks of The Sage Group plc or its affiliates. Tevron is not affiliated with Sage. Product names are used for identification only.

How to Measure Remedly Response Time (From the Glass)

Posted on by
How to Measure Remedly Response Time (From the Glass)
Tevron editorial illustration: The page can return 200. Remedly is still waiting.
Editorial illustration for this article. Not a data chart.

CDN cache is warm. The API returned 200. Browser RUM says the document loaded. Front-desk staff are still waiting for the schedule to paint and the encounter note to save. That is the Remedly response-time problem: SaaS health is not the wait the practice feels.

Direct answer: Measure Remedly – cloud EHR, practice management, and RCM for medical practices – response time from what staff see on screen – on the glass – not only from browser RUM, CDN or API latency, synthetic HTTP checks, or “the page returned 200.” Time the interval from a click or key until the expected Remedly UI is visible: schedule ready, chart or encounter open, note saved, claims or payment step complete. That interval is click-to-ready – the number a practice manager, help desk, and IT vendor can share.

Remedly is a cloud-based, customizable EHR plus RCM and practice-management suite (product context: Remedly) – notably for plastic surgery, med spa, and mental health – with practice management, patient portal, analytics, marketing, AI assistant, e-prescribing, eLabs, eFax, and payments, on PC, phone, or laptop. It still paints a GUI. Sister glass methods: Epic and Oracle Health / Cerner (same timer pattern), plus Citrix, RDS, and cloud VDI. EHR framing: Epic / EHR on the glass. This article times Remedly itself.

Why a green SaaS tile is not “Remedly is ready”

Cloud EHRs sit behind HTTPS, CDNs, identity providers, and browsers. Uptime pages, URL checks, API latency, and Real User Monitoring (RUM) tell you the service is reachable and the document finished. They are not a stopwatch for “the schedule painted,” “the encounter opened,” or “the note saved.”

A tab can show a spinner, a skeleton layout, a half-hydrated calendar, or a toast that never confirms – and still count as a successful page load. Client-side rendering and heavy encounter forms sit after the network already said OK. An HTTP generator that hammers login times the front door, not the workflow.

A 200 from the CDN is useful. It is not the same as “the schedule appeared.”

If Remedly is opened inside Citrix, Microsoft RDS, AVD, or other cloud VDI, the split doubles: protocol green still is not Remedly UI ready. ICA/HDX or RDP can stream a spinning browser while the EHR is still hydrating. Host CPU and broker tiles do not close a “Remedly is slow” ticket. Use the Citrix, RDS, and cloud VDI posts above for remoting.

Two-column schematic: network, HTTP, CDN, and SaaS health timers versus on-the-glass Remedly UI-ready click-to-ready for the same staff workflow.
Schematic from this article: network/HTTP/SaaS health versus glass time. Not a customer dashboard and not a measured practice.

Left column is what network, CDN, API, and SaaS health see. Right column is what front desk, clinical, and billing staff wait on. Only the right column is Remedly response time as a person experiences it.

Which Remedly steps to time

Write the steps before you pick a tool. Four intervals cover most practice UX arguments on browser and remoted-browser sessions:

  1. Sign-in to usable home – from credentials submitted (or SSO return) until usable Remedly navigation is ready – menus, no full-screen spinner. Not “the IdP redirected” or “the document loaded.”
  2. Schedule / practice-management ready – from opening the calendar or front-desk view until appointments and controls are usable. Not “the route changed.”
  3. Chart / encounter / note – from open patient, open encounter, or save note until ready: chart visible, form interactive, save confirmed. Customizable notes and consents make the ready image practice-specific – pin it.
  4. RCM / claims / payments / portal staff steps – from the click that starts billing, claims, payment, eFax, eLabs, e-prescribe, or a staff-side portal task until that step’s ready state.

Pin the browser build (or published-browser / Workspace image if remoted), display scale, tenant branding, and ready baselines. A timer on a moving theme is a story, not a measurement. When Remedly runs inside Citrix or other VDI, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session Remedly work on hosts that already have users.

Time it like a script, not a feeling

On a modern SaaS EHR there is often no reliable DOM event that means “done” – and inside a remoted browser none you can trust from outside the glass. The practical signal is the bitmap:

  • StartTimer when the user action happens – submit, click, or key.
  • WaitForImage until a baseline of the ready state is visible: home chrome, schedule, encounter, save confirmation.
  • StopTimer when that image matches.

The recorded interval is click-to-ready for that step. Image recognition – and OCR when the ready state is text – is how you know the glass painted, without an agent inside Remedly. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for Remedly sign-in, schedule ready, and encounter or RCM click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for sign-in, schedule, encounter/note, and RCM steps. Change the start action and the ready image. Keep the timer. The Epic sister post uses the identical glass method for hospital EHR plus ambulatory SaaS.

Stopwatch versus synthetic

A person with a stopwatch can time one Remedly schedule open on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at Monday check-in rush, hold concurrent sessions while timing save-note, or attach a screenshot of the failed state. Means hide the damage until the front desk is already saying “Remedly is slow.”

A synthetic does the same StartTimer -> WaitForImage -> StopTimer path as a real browser (or remoted Workspace / Remote Desktop browser), on a schedule or under load, with the same schedule, encounter, and claims-ready baselines – continuous on-the-glass monitoring, or a Remedly load/change test when it ramps virtual users.

If you only have a stopwatch, use it to write the acceptance line – then automate it. Example go-live language (schematic only – not a customer dataset or Remedly SLA): sign-in to usable home at p95 inside budget; schedule ready at p95; open encounter and save note inside budget at p95; fewer than 1 percent of runs hang or miss the ready image.

Continuous watch versus load test

On-the-glass is an idea, not a product SKU. Two jobs share the path:

  • CitraTest VU load-tests capacity and change. Freeze the image, walk sign-in -> schedule -> encounter -> RCM, ramp concurrent staff-like users, stop at the written budget. When remoted, run storm and sustain separately. See CitraTest VU load testing.
  • CitraTest APM watches production. The same Remedly steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.

The lab answers how many good concurrent Remedly workflows fit before click-to-ready breaks. The watch answers whether today’s schedule and note-save are still inside the line. Do not use a load-test generator as your only production monitor. No agents inside Remedly’s cloud – each virtual user is another staff browser (or remoted session) driving the UI like a person.

What this is not

  • It is not a replacement for CDN, API, uptime, or browser RUM graphs. Keep those for the network and document path.
  • It is not an HTTP soak of the login URL or a health endpoint. Keep that for the front door.
  • It is not “we have full-stack APM, so Remedly is covered.” Schedule and encounter GUIs are pixels staff wait on, not only traces.
  • It is not a claim about Remedly proprietary internals, unpublished SLAs, or customer contracts – only delivered UI readiness on the glass.
  • It is not a promise that last month’s number survives a UI redesign, new encounter template, browser update, or a move into Citrix / RDS / AVD. Re-time the glass when the image changes.

Take the interval staff already wait

Remedly response time is click-to-ready on the glass – schedule, chart, note, and RCM ready – not a green CDN or protocol tile. Time sign-in, schedule, encounter/note, and billing steps that generate tickets. When remoted, separate logon storm from density. Use a stopwatch only to write the line; use a synthetic to keep it: CitraTest VU under load or change, CitraTest APM on a continuous watch.

When you need that path without agents in the SaaS tenant – real browser or remoted client, image and OCR, StartTimer to StopTimer for Remedly – schedule a demo. Product pages: on-the-glass APM, CitraTest VU, and CitraTest APM.

How to Measure Oracle Health (Cerner) Response Time (From the Glass)

Posted on by
How to Measure Oracle Health (Cerner) Response Time (From the Glass)
Tevron editorial illustration: Director can look fine. PowerChart is still waiting.
Editorial illustration for this article. Not a data chart.

Director says ICA RTT is fine. StoreFront returned 200. The VDA is green. The nurse is still waiting for the chart. That is the Oracle Health (Cerner) response-time problem: remoting health is not the wait the clinician feels.

Direct answer: Measure Oracle Health / Cerner – for example PowerChart or other Millennium clinical GUI – response time from what the clinician sees on screen – on the glass – not only from Citrix HDX/ICA counters, RDP latency, Workspace or portal HTTP, or host CPU. Time the interval from a click or key until the expected EHR screen state is visible. That interval is click-to-ready – the number a CAB, help desk, and clinical informatics can share.

Oracle Health (the former Cerner business) is the EHR and application layer – product context: Oracle Health. Citrix, Microsoft RDS, AVD, and other VDI stacks deliver the pixels. Hospitals often run Epic and Oracle Health side by side; the glass method is the same. Sibling page: Epic / EHR on the glass. Sister posts: Epic, Citrix, RDS, and cloud VDI. Load-test method: How to load test Citrix and How to load test Citrix Virtual Apps and Desktops. This article times Oracle Health / Cerner itself.

Why a green Director tile is not “the chart appeared”

HDX, ICA, RDP, and cloud remoting move pixels out and keyboard and mouse in. Director, Monitor, broker health, and host CPU tell you the session is up and the channel is healthy. They are not a stopwatch for “PowerChart painted” or “the chart is ready.”

A session can stream a logon animation, a spinning cursor, or a half-drawn Millennium window and still look connected. Profile attach, GPO, FSLogix (or equivalent), and the EHR client sit after remoting is already up. StoreFront, Workspace, and hospital portals are websites – an HTTP generator times the store, not the chart.

A green Director tile is useful. It is not the same as “the chart appeared.”

Host CPU can sit at 40 percent while login-to-shell stretches and PowerChart paints late. Protocol RTT can look fine while open-chart stalls. Green remoting tiles do not close a “Cerner is slow” ticket.

Two-column schematic: broker, protocol, and host timers versus on-the-glass Oracle Health / Cerner chart-ready click-to-ready for the same session.
Schematic from this article: broker/protocol/host versus glass time. Not a customer dashboard and not a measured farm.

Left column is what broker, protocol, and host timers see. Right column is what the clinician waits on – Oracle Health / Cerner response time as a person experiences it.

Which Oracle Health / Cerner steps to time

Write the steps before you pick a tool. Three intervals cover most clinical UX arguments on published apps and remoted desktops:

  1. Logon-to-shell – from credentials submitted (or Workspace / StoreFront / Gateway / portal launch) until a usable desktop or published-app window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
  2. Oracle Health / published-app launch – from the icon or Start-menu click until first usable paint of PowerChart or the Millennium clinical GUI you publish. Not “the process started on the VDA or Session Host.”
  3. In-session transactions – from the click or key that starts the work until ready: open chart or record, search, save, switch activity. This is the wait behind “Cerner is slow” tickets after clinicians are already in session.

Pin the image, VDA or Session Host SKU, Workspace or Remote Desktop client, StoreFront / Gateway / portal build, and the published Oracle Health / Cerner resource. A timer on a moving image is a story, not a measurement.

For capacity work, run a logon storm separately from density. Storm stresses login-to-shell; density stresses in-session chart and search on hosts that already have clinicians. Blending them hides which interval broke.

Time it like a script, not a feeling

On remoted Oracle Health / Cerner there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on published EHR GUIs:

  • StartTimer when the user action happens – submit, Workspace launch, click, or key.
  • WaitForImage until a baseline of the ready state is visible: the shell, the PowerChart / Millennium window, the chart.
  • StopTimer when that image matches.

The recorded interval is click-to-ready for that step. Image recognition – and OCR when the ready state is text – is how you know the glass painted, without an agent on the VDA. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for Oracle Health / Cerner logon-to-shell, PowerChart / Millennium launch, and chart-ready click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for login, EHR launch, and in-session chart work. Change the start action and the ready image. Keep the timer. The Epic sister post uses the identical glass method for Hyperspace / Hyperdrive when the same team supports both EHRs.

Stopwatch versus synthetic

A person with a stopwatch can time one PowerChart logon on a quiet morning. That is a demo, not a measurement program. A one-off cannot give a tail, run at shift change every weekday, hold concurrent sessions while timing open-chart, or attach a screenshot of the failed state. Means hide the damage until the desk is taking “Cerner is slow” calls.

A synthetic does the same StartTimer -> WaitForImage -> StopTimer path as a real Workspace or Remote Desktop client, on a schedule or under load, with the same PowerChart / Millennium and chart-ready baselines. That is on-the-glass monitoring when it runs continuously, and an Oracle Health-on-Citrix (or RDS / AVD) load test when it ramps users.

If you only have a stopwatch, use it to write the acceptance line – then automate it. Example capacity-plan language (schematic only – not a customer dataset or Oracle/Cerner SLA): logon-to-shell 45 seconds at p95 and 60 at p99; EHR published-app open 8 seconds at p95; open-chart inside the written budget at p95; fewer than 1 percent of runs fail, disconnect, or hang.

Continuous watch versus load test

On-the-glass is an idea, not a product SKU. Two jobs share the path:

  • CitraTest VU load-tests capacity. Freeze the image, walk the real StoreFront / Workspace / Gateway path into published PowerChart or Millennium, run storm and sustain as separate shapes, stop at the written budget. See CitraTest VU load testing.
  • CitraTest APM watches production. The same login -> EHR -> open-chart steps, every N minutes, with alerts and screenshots when glass time slips. See CitraTest APM.

The lab answers how many good Oracle Health / Cerner sessions fit on this SKU. The watch answers whether today’s logon-to-shell and open-chart are still inside the SLA. Do not use a load-test generator as your only production monitor, or treat a single synthetic as a density number. No agents on VDAs, Session Hosts, or brokers – each virtual user or monitor is another Workspace or Remote Desktop session launching the EHR like a clinician.

What this is not

  • It is not a replacement for Director, Monitor, HDX Insights, RD Connection Broker health, or AVD host metrics. Keep those for the remoting path.
  • It is not an HTTP soak of StoreFront, Workspace, Gateway, or the hospital portal. Keep that for the front door.
  • It is not “we have full-stack APM, so Oracle Health is covered.” Published PowerChart and Millennium GUIs are pixels, not traces.
  • It is not a claim about Oracle Health or Cerner proprietary metrics, internal tooling, or customer SLAs – only delivered session UX on Citrix, RDS, AVD, and peers, on the glass.
  • It is not a promise that last quarter’s number survives a new VDA image, FSLogix policy, Millennium / PowerChart build, or a move to DaaS / AVD. Re-time the glass when the image changes.

Take the interval clinicians already wait

Oracle Health / Cerner response time is click-to-ready on the glass – PowerChart or Millennium chart ready, not a green protocol tile. Time logon-to-shell, EHR published-app launch, and the in-session steps that generate tickets. Separate logon storm from density. Use a stopwatch only to write the line; use a synthetic to keep it: CitraTest VU under load, CitraTest APM every shift.

When you need that path without agents on the farm – real client, image and OCR, StartTimer to StopTimer for Oracle Health / Cerner – schedule a demo. Product pages: Epic / EHR on the glass, on-the-glass APM, CitraTest VU, and CitraTest APM.

How to Measure Epic Response Time (From the Glass)

Posted on by
How to Measure Epic Response Time (From the Glass)
Tevron editorial illustration: HDX can look fine. The chart is still waiting.
Editorial illustration for this article. Not a data chart.

Director says ICA RTT is fine. StoreFront returned 200. The VDA is green. The nurse is still waiting for the chart. That is the Epic response-time problem in one sentence: remoting health is not the wait the clinician feels.

Direct answer: Measure Epic — Hyperspace or Hyperdrive — response time from what the clinician sees on the screen — on the glass — not only from Citrix HDX/ICA counters, RDP latency, StoreFront or Workspace HTTP, or host CPU. Time the interval from a click or key until the expected Epic screen state is visible. That interval is click-to-ready. It is the number a CAB, a help desk, and clinical informatics can share.

Epic is the EHR and application layer. Citrix, Microsoft RDS, AVD, and other VDI stacks deliver the pixels. Product context: Epic / EHR on the glass. Sister posts on the same glass clock: Citrix, RDS, and cloud VDI response time. Load-test method: How to load test Citrix and How to load test Citrix Virtual Apps and Desktops. This article is narrower: how to time Epic itself.

Why a green Director tile is not “the chart appeared”

HDX, ICA, RDP, and cloud remoting protocols move pixels out and keyboard and mouse in. Director, Monitor, broker health, and host CPU are good at telling you the session is up and the channel is healthy. They are not a stopwatch for “Hyperspace painted” or “the chart is ready.”

A session can stream a logon animation, a spinning cursor, or a half-drawn Epic window and still look connected. Profile attach, GPO, FSLogix (or equivalent), and the EHR client itself sit after remoting is already up. StoreFront and Workspace are websites. Hammering them with an HTTP generator times the store, not the chart.

A green Director tile is useful. It is not the same as “the chart appeared.”

Host CPU can sit at 40 percent while login-to-shell stretches and Hyperdrive paints late. Protocol RTT can look fine while open-chart stalls. Green remoting tiles do not close an “Epic is slow” ticket.

Two-column schematic: broker, protocol, and host timers versus on-the-glass Epic chart-ready click-to-ready for the same session.
Schematic from this article: broker/protocol/host versus glass time. Not a customer dashboard and not a measured farm.

Left column is what broker, protocol, and host timers see. Right column is what the clinician waits on. Only the right column is Epic response time as a person experiences it.

Which Epic steps to time

Write the steps before you pick a tool. Three intervals cover most Epic UX arguments on published apps and remoted desktops:

  1. Logon-to-shell — from credentials submitted (or the Workspace / StoreFront / Gateway / portal launch) until a usable desktop or published-app window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
  2. Epic / published-app launch — from the icon or Start-menu click until first usable paint of Hyperspace or Hyperdrive. Not “the process started on the VDA or Session Host.”
  3. In-session transactions — from the click or key that starts the work until the ready state: open chart, search, save, switch activity. This is the wait that generates “Epic is slow” tickets after everyone is already in session.

Pin the image, VDA or Session Host SKU, Workspace or Remote Desktop client, StoreFront / Gateway / portal build, and the published Epic resource. A timer on a moving image is a story, not a measurement.

For capacity work, run a logon storm separately from density. Storm stresses login-to-shell. Density stresses in-session chart and search work on hosts that already have clinicians. Blending them hides which interval broke.

Time it like a script, not a feeling

On remoted Epic there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on published EHR GUIs:

  • StartTimer when the user action happens — submit, Workspace launch, click, or key.
  • WaitForImage until a baseline of the ready state is visible: the shell, the Hyperspace or Hyperdrive window, the chart.
  • StopTimer when that image matches.

The recorded interval is click-to-ready for that step. Image recognition — and OCR when the ready state is text — is how you know the glass painted. You do not install an agent on the VDA to learn that. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for Epic logon-to-shell, Hyperspace/Hyperdrive launch, and chart-ready click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for login, Epic launch, and in-session chart work. Change the start action and the ready image. Keep the timer.

Stopwatch versus synthetic

A person with a stopwatch can time one Epic logon on a quiet morning. That is a demo, not a measurement program.

A one-off cannot give you a tail, run at shift change every weekday, hold concurrent published-app sessions while timing open-chart, or attach a screenshot of the failed state. Means hide the damage until the service desk is already taking “Epic is slow” calls.

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real Workspace or Remote Desktop client, on a schedule or under load, with the same Hyperspace, Hyperdrive, and chart-ready baselines. That is on-the-glass monitoring when it runs continuously, and an Epic-on-Citrix (or RDS / AVD) load test when it ramps concurrent users.

If you only have a stopwatch, use it to write the acceptance line — then automate the line. Example language teams already put on capacity plans (schematic only, not a customer dataset): logon-to-shell 45 seconds at p95 and 60 seconds at p99; Epic published-app open 8 seconds at p95; open-chart inside the written budget at p95; fewer than 1 percent of runs fail, disconnect, or hang.

Continuous watch versus load test

On-the-glass is an idea, not a product SKU. Two jobs share the path for Epic:

  • CitraTest VU load-tests capacity. Freeze the image, walk the real StoreFront / Workspace / Gateway path into published Epic, run storm and sustain as separate shapes, stop at the written budget. That is the concurrent-clinician number a CAB can defend. See CitraTest VU load testing.
  • CitraTest APM watches production. The same login → Epic → open-chart steps, every N minutes, with alerts and screenshots when glass time slips. That is the morning watch after go-live or an image change. See CitraTest APM.

The lab answers “how many good Epic sessions fit on this SKU.” The watch answers “is today’s logon-to-shell and open-chart still inside the SLA.” Do not use a load-test generator as your only production monitor, and do not treat a single synthetic as a density number.

No agents on the VDAs, Session Hosts, or brokers are required for that path. Each virtual user or monitor is another Workspace or Remote Desktop session launching Epic like a clinician. If the generator desktop is pegged, you are measuring the lab, not the farm.

What this is not

  • It is not a replacement for Director, Monitor, HDX Insights, RD Connection Broker health, or AVD host metrics. Keep those for the remoting path.
  • It is not an HTTP soak of StoreFront, Workspace, or Gateway. Keep that for the front door.
  • It is not “we have full-stack APM, so Epic is covered.” Published Hyperspace and Hyperdrive GUIs are pixels, not traces.
  • It is not a claim about Epic’s internal tooling or proprietary metrics — only the delivered session UX on Citrix, RDS, AVD, and peers, on the glass.
  • It is not a promise that last quarter’s number survives a new VDA image, FSLogix policy, Hyperdrive build, or a move to DaaS / AVD. Re-time the glass when the image changes.

Take the interval clinicians already wait

Epic response time, as a clinician experiences it, is click-to-ready on the glass — Hyperspace or Hyperdrive chart ready, not a green protocol tile. Time logon-to-shell, Epic published-app launch, and the in-session steps that generate tickets. Separate logon storm from density. Use a stopwatch only to write the line. Use a synthetic to keep the line: CitraTest VU under load, CitraTest APM every shift.

When you need that path without agents on the farm — real Workspace or Remote Desktop client, image and OCR, StartTimer to StopTimer for Epic — schedule a demo. Product pages: Epic / EHR on the glass, CitraTest VU, and CitraTest APM.

How to Measure Cloud VDI Response Time (From the Glass)

Posted on by
How to Measure Cloud VDI Response Time (From the Glass)
Tevron editorial illustration: The broker can look fine. The glass is still waiting.
Editorial illustration for this article. Not a data chart.

Cloud ops says the Workspace URL returned 200. The DaaS or AVD broker assigned a session. Protocol RTT looks fine. The nurse is still waiting for the chart. That is the cloud VDI response-time problem in one sentence: control-plane health is not the wait the user feels.

Direct answer: Measure Citrix DaaS, Azure Virtual Desktop (AVD), Windows 365, and other cloud-hosted virtual apps and desktops from what the user sees on the screen — on the glass — not only from Workspace URL HTTP, broker health, or protocol RTT. Time the interval from a click or key until the expected screen state is visible. That interval is click-to-ready — the number a CAB and a help desk can share.

The sibling method for walking a real cloud path under load is in How to load test cloud virtual apps and desktops. Tooling context: best cloud load testing tools. Sister posts on the same glass clock: Citrix response time and RDS response time. This article is narrower: how to time the wait when the broker is in the cloud and the pixels live in a resource location.

Why the control plane can look fine while users wait

In cloud VDI the front door and the pixels are not the same machine. Workspace (or the AVD / Windows 365 portal) is a website and a control plane. The broker assigns a session to a resource location — a host pool, a delivery group, a Cloud PC. Portal HTTP, broker assignment, and protocol RTT tell you the channel is up. They are not a stopwatch for “the published app painted.”

A session can stream a logon animation, a spinning cursor, or a half-drawn shell and still look connected. Profile attach, GPO, FSLogix (or equivalent), and the line-of-business app itself sit after remoting is already up. Hammering the Workspace URL with an HTTP generator times the store, not the session host.

Broker green is useful. It is not the same as “the shell appeared.”

Autoscale makes the split easier to miss. When hosts come and go, average density can look comfortable while some users sit on a hot host or wait through a cold start. Autoscale can hide density problems; it does not remove them. Green control-plane tiles do not close a “cloud desktop is slow” ticket.

Two-column schematic: cloud control-plane, broker, and network timers versus on-the-glass click-to-ready for the same cloud VDI session.
Schematic from this article: control plane versus glass time. Not a customer dashboard and not a measured farm.

Left column is what control-plane, broker, and network timers see. Right column is what the user waits on. Only the right column is cloud VDI response time as a person experiences it.

Which steps to time

Write the steps before you pick a tool. Three intervals cover most cloud VDI UX arguments — Citrix DaaS, AVD, Windows 365, or another hosted desktop:

  1. Logon-to-shell — from credentials submitted (or the Workspace / portal / Gateway launch) until a usable desktop or published-app window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
  2. Published app / RemoteApp launch — from the icon or Start-menu click until first paint of the business app: Epic, SAP, Outlook, the line-of-business client. Not “the process started on the session host.”
  3. In-session transactions — from the click or key that starts the work until the ready state: search, open the record, save, print, switch published apps. This is the wait that generates “the cloud desktop is slow” tickets after everyone is already in session.

Pin the image, resource-location SKU, client (Workspace app, Remote Desktop client, or Windows 365), portal or Gateway build, and the published resource. A timer on a moving image is a story, not a measurement.

For capacity work, run a logon storm separately from density. Storm stresses login-to-shell — including cold starts when autoscale brings hosts online. Density stresses in-session transactions on hosts that already have users. Blending them hides which interval broke.

Time it like a script, not a feeling

On remoted cloud desktops there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on published apps — and it applies whether the pixels come from DaaS, AVD, or Windows 365:

  • StartTimer when the user action happens — submit, Workspace launch, click, or key.
  • WaitForImage until a baseline of the ready state is visible: the shell, the published or RemoteApp window, the chart.
  • StopTimer when that image matches.

The recorded interval is click-to-ready for that step. Image recognition — and OCR when the ready state is text — is how you know the glass painted. You do not install an agent on the session host or Cloud PC to learn that. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for cloud VDI logon-to-shell, published/RemoteApp launch, and in-session click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for login, published/RemoteApp launch, and in-session work. Change the start action and the ready image. Keep the timer.

Stopwatch versus synthetic

A person with a stopwatch can time one Workspace logon on a quiet morning. That is a demo, not a measurement program. A one-off cannot give you a tail, run at 8:00 every weekday, hold concurrent sessions while autoscale adds hosts, or attach a screenshot of the failed state.

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real Workspace or Remote Desktop client, on a schedule or under load, with the same baseline images. That is on-the-glass monitoring when it runs continuously, and a cloud VDI load test when it ramps concurrent users.

If you only have a stopwatch, use it to write the acceptance line — then automate it. Example language (schematic only, not a customer dataset): logon-to-shell 45 seconds at p95 and 60 at p99; published-app open 8 seconds at p95; fewer than 1 percent of runs fail or hang. Re-check after an autoscale or image change.

Continuous watch versus load test

On-the-glass is an idea, not a product SKU. Two jobs share the path:

  • CitraTest VU load-tests capacity. Freeze the image, walk the real Workspace / portal / Gateway path into the resource location, run storm and sustain as separate shapes, stop at the written budget. That is the concurrent-user number a CAB can defend — including how autoscale behaves under a logon storm. See CitraTest VU load testing.
  • CitraTest APM watches production. The same login → published app → in-session steps, every N minutes, with alerts and screenshots when glass time slips. That is the morning watch after go-live to cloud. See CitraTest APM.

The lab answers “how many good sessions fit on this host-pool SKU.” The watch answers “is today’s logon-to-shell still inside the SLA.” Do not use a load-test generator as your only production monitor, and do not treat a single synthetic as a density number. No agents on session hosts or cloud brokers are required — each monitor is another Workspace or Remote Desktop session.

What this is not

  • It is not a replacement for Workspace health, DaaS / AVD / Windows 365 host metrics, or protocol Insights. Keep those for the control plane and remoting path.
  • It is not an HTTP soak of the Workspace URL or cloud portal. Keep that for the front door.
  • It is not “we have full-stack APM, so cloud VDI is covered.” Remoted GUIs are pixels, not traces.
  • It is not a promise that last quarter’s on-prem number survives a move to DaaS, AVD, or Windows 365 — or that last month’s number survives a new golden image or autoscale policy. Re-time the glass when the image or resource location changes.

Take the interval users already wait

Cloud VDI response time — Citrix DaaS, AVD, Windows 365, and peers — as a user experiences it, is click-to-ready on the glass. Separate the control plane from session pixels. Time logon-to-shell, published/RemoteApp launch, and the in-session steps that generate tickets. Use a stopwatch only to write the line. Use a synthetic to keep the line: CitraTest VU under load, CitraTest APM every shift.

When you need that path without agents on the resource location — real Workspace or Remote Desktop client, image and OCR, StartTimer to StopTimer — schedule a demo. Product pages: CitraTest VU and CitraTest APM.

How to Measure RDS Response Time (From the Glass)

Posted on by
How to Measure RDS Response Time (From the Glass)
Tevron editorial illustration: RDP can look fine. The glass is still waiting.
Editorial illustration for this article. Not a data chart.

Ops says RDP latency is fine. The session is connected. RD Connection Broker handed out a Session Host. The clerk is still waiting for the desktop to finish painting. That is the Microsoft RDS response-time problem in one sentence: protocol health is not the wait the user feels.

Direct answer: Measure RDS response time from what the user sees on the screen — on the glass — not only from RDP round-trip, network latency, host CPU, or broker health. Time the interval from a click or key until the expected screen state is visible. That interval is click-to-ready. It is the number a CAB and a help desk can share.

This post is about Microsoft Remote Desktop Services (RDS) — Session Hosts, RemoteApp, RD Gateway / RD Web — not Amazon Relational Database Service. The sibling method for walking a real RDS path under load is in How to load test Microsoft RDS. Tooling context lives on best RDS load testing tools. This article is narrower: how to time the wait itself.

Why RDP can look fine while users wait

RDP is a remoting protocol. It moves pixels out and keyboard and mouse in. Performance Monitor counters, RD Connection Broker health, and “session connected” status are good at telling you the channel is up. They are not a stopwatch for “the published app painted.”

A session can stream a logon animation, a spinning cursor, or a half-drawn shell and still look connected. Profile attach, GPO, FSLogix (or equivalent), and the line-of-business app itself sit after RDP is already up. RD Web is a website. Hammering it with an HTTP generator times the portal, not the Session Host farm.

RDP round-trip is useful. It is not the same as “the shell appeared.”

The same glass-versus-protocol split shows up on Citrix farms — see the sister post How to measure Citrix response time. Host CPU can sit at 40 percent while login-to-shell stretches and the RemoteApp paints late. Green session tiles do not close that ticket.

Two-column schematic: RDP and session protocol timers versus on-the-glass click-to-ready for the same Microsoft RDS session.
Schematic from this article: protocol timers versus glass time. Not a customer dashboard and not a measured farm.

Left column is what protocol and host timers see. Right column is what the user waits on. Only the right column is RDS response time as a person experiences it.

Which steps to time

Write the steps before you pick a tool. Three intervals cover most RDS UX arguments:

  1. Logon-to-shell — from credentials submitted (or the RD Web / Gateway launch) until a usable desktop or RemoteApp window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
  2. RemoteApp / published app launch — from the icon or Start-menu click until first paint of the business app: Epic, SAP, Outlook, the line-of-business client. Not “the process started on the Session Host.”
  3. In-session transactions — from the click or key that starts the work until the ready state: search, open the record, save, print, switch RemoteApps. This is the wait that generates “the desktop is slow” tickets after everyone is already in session.

Pin the image, Session Host SKU, client (mstsc / Remote Desktop app), RD Web or Gateway build, and the published collection. A timer on a moving image is a story, not a measurement.

For capacity work, run a logon storm separately from density. Storm stresses login-to-shell. Density stresses in-session transactions on hosts that already have users. Blending them hides which interval broke.

Time it like a script, not a feeling

On RDP there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on remoted apps — including Citrix HDX farms — and it applies unchanged to Microsoft RDS:

  • StartTimer when the user action happens — submit, click, or key.
  • WaitForImage until a baseline of the ready state is visible: the shell, the RemoteApp window, the chart.
  • StopTimer when that image matches.

The recorded interval is click-to-ready for that step. Image recognition — and OCR when the ready state is text — is how you know the glass painted. You do not install an agent on the Session Host to learn that. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for RDS logon-to-shell, RemoteApp launch, and in-session click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for login, RemoteApp launch, and in-session work. Change the start action and the ready image. Keep the timer.

Stopwatch versus synthetic

A person with a stopwatch can time one logon on a quiet morning. That is a demo, not a measurement program.

A one-off cannot give you a tail. It cannot run at 8:00 every weekday. It cannot hold two hundred sessions and still time open-record. It cannot attach a screenshot of the failed state. Means hide the damage until the service desk is already taking calls.

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real Remote Desktop client, on a schedule or under load, with the same baseline images. That is on-the-glass monitoring when it runs continuously, and an RDS load test when it ramps concurrent users.

If you only have a stopwatch, use it to write the acceptance line — then automate the line. Example language teams already put on capacity plans (schematic only, not a customer dataset): logon-to-shell 45 seconds at p95 and 60 seconds at p99; RemoteApp open 8 seconds at p95; fewer than 1 percent of runs fail, disconnect, or hang.

Continuous watch versus load test

On-the-glass is an idea, not a product SKU. Two jobs share the path:

  • CitraTest VU load-tests capacity. Freeze the image, walk the real RD Web / Gateway / mstsc path, run storm and sustain as separate shapes, stop at the written budget. That is the concurrent-user number a CAB can defend. See CitraTest VU load testing.
  • CitraTest APM watches production. The same login → RemoteApp → in-session steps, every N minutes, with alerts and screenshots when glass time slips. That is the morning watch after go-live. See CitraTest APM.

The lab answers “how many good sessions fit on this Session Host SKU.” The watch answers “is today’s logon-to-shell and open-record still inside the SLA.” Do not use a load-test generator as your only production monitor, and do not treat a single synthetic as a density number.

No agents on the Session Hosts or brokers are required for that path. Each virtual user or monitor is another Remote Desktop session. If the generator desktop is pegged, you are measuring the lab, not the farm.

What this is not

  • It is not a replacement for Performance Monitor, RD Connection Broker health, or Azure Virtual Desktop / Windows 365 host metrics. Keep those for the remoting and host path.
  • It is not an HTTP soak of RD Web or Gateway. Keep that for the front door.
  • It is not “we have full-stack APM, so RDS is covered.” Remoted GUIs are pixels, not traces.
  • It is not a promise that last quarter’s number survives a new Session Host image, profile policy, or a move to AVD. Re-time the glass when the image changes.

Take the interval users already wait

Microsoft RDS response time, as a user experiences it, is click-to-ready on the glass. Time logon-to-shell, RemoteApp launch, and the in-session steps that generate tickets. Use a stopwatch only to write the line. Use a synthetic to keep the line: CitraTest VU under load, CitraTest APM every shift.

When you need that path without agents on the farm — real Remote Desktop client, image and OCR, StartTimer to StopTimer — schedule a demo. Product pages: CitraTest VU and CitraTest APM.

How to Measure Citrix Response Time (From the Glass)

Posted on by
How to Measure Citrix Response Time (From the Glass)
Tevron editorial illustration: HDX can look fine. The glass is still waiting.
Editorial illustration for this article. Not a data chart.

Director says ICA RTT is fine. StoreFront returned 200. The session is connected. The nurse is still waiting for the chart. That is the Citrix response-time problem in one sentence: protocol health is not the wait the user feels.

Direct answer: Measure Citrix response time from what the user sees on the screen — on the glass — not only from ICA/HDX protocol counters or StoreFront HTTP. Time the interval from a click or key until the expected screen state is visible. That interval is click-to-ready. It is the number a CAB and a help desk can share.

The full method for walking StoreFront or Gateway, driving HDX, and stopping at a written experience budget is in How to load test Citrix. This post is narrower: how to time the wait itself.

Why HDX can look fine while users wait

HDX — the current name for the ICA protocol family — is a remoting protocol. It moves pixels out and keyboard and mouse in. Director, Monitor, and HDX Insights are good at telling you the session is up and the channel is healthy. They are not a stopwatch for “the published app painted.”

A session can stream a logon animation, a spinning cursor, or a half-drawn shell and still look connected. Profile attach (FSLogix or equivalent), GPO, and the line-of-business app itself sit after HDX is already up. StoreFront is a website. Hammering it with an HTTP generator times the store, not the farm.

ICA RTT is useful. It is not the same as “the chart appeared.”

The same split, in product language, is Citrix HDX vs real user experience. Host CPU can sit at 40 percent while login-to-shell stretches and Hyperspace paints late. Green protocol tiles do not close that ticket.

Two-column schematic: ICA and HDX protocol timers versus on-the-glass click-to-ready for the same Citrix session.
Schematic from this article: protocol timers versus glass time. Not a customer dashboard and not a measured farm.

Left column is what protocol timers see. Right column is what the user waits on. Only the right column is Citrix response time as a person experiences it.

Which steps to time

Write the steps before you pick a tool. Three intervals cover most Citrix UX arguments:

  1. Logon-to-shell — from credentials submitted (or the Workspace / Gateway launch) until a usable desktop or published-app window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
  2. Published app launch — from the icon or Start-menu click until first paint of the business app: Epic, SAP, Outlook, the line-of-business client. Not “the process started on the VDA.”
  3. In-session transactions — from the click or key that starts the work until the ready state: search, open the record, save, print, switch published apps. This is the wait that generates “Epic is slow” tickets after everyone is already in session.

Pin the image, VDA, Workspace app, StoreFront or Gateway build, and the published resource. A timer on a moving image is a story, not a measurement.

For capacity work, run a logon storm separately from density. Storm stresses login-to-shell. Density stresses in-session transactions on hosts that already have users. Blending them hides which interval broke.

Time it like a script, not a feeling

On HDX there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on published apps:

  • StartTimer when the user action happens — submit, click, or key.
  • WaitForImage until a baseline of the ready state is visible: the shell, the app window, the chart.
  • StopTimer when that image matches.

The recorded interval is click-to-ready for that step. Image recognition — and OCR when the ready state is text — is how you know the glass painted. You do not install an agent on the VDA to learn that. That is the core of on-the-glass APM.

Three-row schematic of StartTimer, WaitForImage, and StopTimer for Citrix logon-to-shell, published app launch, and in-session click-to-ready.
Schematic of the measurement pattern in this article. Not a CitraTest screenshot and not a customer dataset.

That pipeline is the same for login, app launch, and in-session work. Change the start action and the ready image. Keep the timer.

Stopwatch versus synthetic

A person with a stopwatch can time one logon on a quiet morning. That is a demo, not a measurement program.

A one-off cannot give you a tail. It cannot run at 8:00 every weekday. It cannot hold two hundred sessions and still time open-chart. It cannot attach a screenshot of the failed state. Means hide the damage until the service desk is already taking calls.

A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real Workspace app client, on a schedule or under load, with the same baseline images. That is on-the-glass monitoring when it runs continuously, and a Citrix load test when it ramps concurrent users.

If you only have a stopwatch, use it to write the acceptance line — then automate the line. Example language teams already put on capacity plans (schematic only, not a customer dataset): logon-to-shell 45 seconds at p95 and 60 seconds at p99; published-app open 8 seconds at p95; fewer than 1 percent of runs fail, disconnect, or hang.

Continuous watch versus load test

On-the-glass is an idea, not a product SKU. Two jobs share the path:

  • CitraTest VU load-tests capacity. Freeze the image, walk the real StoreFront or Gateway path, run storm and sustain as separate shapes, stop at the written budget. That is the concurrent-user number a CAB can defend. See CitraTest VU load testing.
  • CitraTest APM watches production. The same login → app → in-session steps, every N minutes, with alerts and screenshots when glass time slips. That is the morning watch after go-live. See CitraTest APM.

The lab answers “how many good sessions fit on this SKU.” The watch answers “is today’s logon-to-shell and open-chart still inside the SLA.” Do not use a load-test generator as your only production monitor, and do not treat a single synthetic as a density number.

No agents on the VDAs or brokers are required for that path. Each virtual user or monitor is another Workspace app session. If the generator desktop is pegged, you are measuring the lab, not the farm.

What this is not

  • It is not a replacement for Director, Monitor, or HDX Insights. Keep those for the remoting path.
  • It is not an HTTP soak of StoreFront or Gateway. Keep that for the front door.
  • It is not “we have full-stack APM, so Citrix is covered.” Published HDX GUIs are pixels, not traces.
  • It is not a promise that last quarter’s number survives a new VDA, FSLogix policy, or a move to Citrix DaaS. Re-time the glass when the image changes.

Take the interval users already wait

Citrix response time, as a user experiences it, is click-to-ready on the glass. Time logon-to-shell, published-app launch, and the in-session steps that generate tickets. Use a stopwatch only to write the line. Use a synthetic to keep the line: CitraTest VU under load, CitraTest APM every shift.

When you need that path without agents on the farm — real Workspace client, image and OCR, StartTimer to StopTimer — schedule a demo. Product pages: CitraTest VU and CitraTest APM.

How to Load Test Cloud-Hosted Virtual Apps and Desktops

Posted on by
Tevron editorial illustration: The control plane is not the farm. Autoscale hides density problems.
Editorial illustration for this article. Not a data chart.

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.

Two-column schematic: Citrix Cloud or AVD control plane versus the resource location with session hosts and Cloud Connector.
Schematic of the split in this article: control plane versus resource location. Not a cloud architecture from a customer tenant.

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.

Two-test schematic: density with autoscale off on a fixed host count versus scale-out lag with autoscale on.
Two tests from this article: density with autoscale off, scale-out with autoscale on. Schematic only — not a measured catalog and not a customer dataset.

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).
Four example acceptance-line cards from the article: 45s p95 and 60s p99 logon, 8s p95 app open, under 1 percent fail, per-host CPU memory and profile IOPS in production bands.
Example acceptance line from this article. Schematic only — not a customer dataset and not a measured catalog.

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.

Two-column schematic comparing a login storm (steep ramp, logon path) with a sustain (steady state, session hosts).
Two test shapes from this article: a login storm versus a sustain. Schematic only — not a load-generator screenshot and not a customer dataset.

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

Numbered schematic of the article’s seven CAB steps: freeze the image, script the day, baseline, storm and sustain, tails, stop at the line, re-test.
Schematic of the CAB method in this article, in Citrix wording. Rebuild the connection script per stack — the same seven steps still fit AVD and DaaS catalogs. Not a customer dataset.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

How to Load Test Citrix Virtual Apps and Desktops

Posted on by
Tevron editorial illustration: HDX is not HTTP. Load-test the session, not the portal.
Editorial illustration for this article. Not a data chart.

Capacity conversations about Citrix still die in the same place: a vendor density spreadsheet on one side, last quarter’s peak from Director on the other, and no one who can say what the user actually saw on the glass. Finance and the CAB want a concurrent-user number they can defend. That number does not come from HTTP replay, and it does not come from a single login-storm screenshot.

This is a method for Citrix and VDI admins and QA who have to produce that number in 2026 — for Citrix DaaS, for Citrix Virtual Apps and Desktops, and for shops that also run Azure Virtual Desktop (AVD) or Windows RDS and need the same kind of answer. Citrix Virtual Apps and Desktops is the current name for the on-premises and hybrid platform many teams still remember as XenApp and XenDesktop.

HDX is not HTTP

Most load-testing practice grew up on websites. You record HTTP, correlate cookies, replay thousands of threads, and graph page time. That model does not describe a Citrix session.

If you only hammer StoreFront with a web generator, you have load-tested the store, not the farm.

StoreFront is a web application. Citrix Gateway is a web and SSL-VPN front door. The session that follows is HDX — the current name for the ICA protocol family. The published app or desktop does not send DOM or window handles to the endpoint. It sends pixels. The client sends keyboard and mouse.

A synthetic ICA stream that never paints a real Workspace app window can miss the events users wait on: the logon animation, the shell, the first paint of Epic or SAP, the modal after a click. Those events exist on the bitmap. Treat HDX as a remoting protocol with a human on the other end, not as another API to replay.

What a defensible concurrent-user number actually is

A defensible number is not the highest session count you can boot before the broker returns errors. It is the highest concurrency at which a defined set of user transactions still meets a defined experience budget, with a defined failure rate, on the image and hardware you intend to ship. 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.
  • Session-host CPU, memory, and profile IOPS stay inside the same alert bands you already use in production.
Four example acceptance-line cards from the article: 45s p95 and 60s p99 logon, 8s p95 app open, under 1 percent fail, host CPU memory and profile IOPS in production bands.
Example acceptance line from this article. Schematic only — not a customer dataset and not a measured farm.

When the run crosses that line, that concurrency is the number. Averages, “it still launched,” and a green Director dashboard are not. ICA RTT is useful. It is not the same as “the chart appeared.”

Test the path users actually take

Users do not appear already inside an HDX session. They hit StoreFront (internal) or Gateway (external and most hybrid designs), then authentication — Active Directory, MFA, SAML, FAS, or a mix — then store enumeration, resource launch, HDX to the VDA, profile and GPO processing (FSLogix or equivalent), and only then the business application.

Schematic Citrix path: StoreFront or Gateway, Auth and MFA, enumerate, HDX, profile and GPO, then the published app. Caption notes skipping Gateway is the lab trap.
Schematic of the connection path in this article. Skipping Gateway because “it is just a proxy” is the lab trap. Not a network capture and not a customer dataset.

Skip Gateway in the lab because “it is just a proxy” and you will be surprised on go-live morning. Skip MFA because the tool cannot type an OTP and you have tested a path nobody uses. If production is Gateway plus SAML plus a published desktop, that is the script.

Pin VDA version, Citrix Workspace app version, StoreFront and Gateway builds, GPO, profile solution, and the published resource. A load test of a moving image is a story, not a measurement. AVD and RDS have their own brokers and gateways; a Citrix result does not transfer. Reuse the transactions and budgets, and rebuild the connection script for each stack if you are comparing platforms.

Measure from the user’s screen

On HDX 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 Citrix client with keyboard and mouse, compares the live screen to baseline images, and does not install agents on the VDAs or brokers. Protocol replay and in-guest workload agents scale on cheaper generators, but they are not a substitute for “did the chart actually appear.”

Correlate the two views. When p95 “open chart” jumps from 6 seconds to 14 seconds at 280 users, you want host CPU, logon duration, and profile IOPS on the same timeline. The screen tells you it broke. The infrastructure tells you which layer.

In-guest agents that burn CPU and disk are a legitimate way to study raw host density. They are not how a nurse uses an EHR, and they can perturb the thing you are measuring. A client-side, image-and-OCR approach leaves the farm alone: each virtual user is a real Workspace app session from a generator desktop. You pay in generator hardware — those VMs must not become the bottleneck — and you gain fidelity. If generator CPU is pegged, you are measuring the lab, not the farm.

A seven-step method you can take to a CAB

Numbered schematic of the article’s seven CAB steps: freeze the image, script the day, baseline, storm and sustain, tails, stop at the line, re-test.
Schematic of the CAB method in this article, in Citrix wording. Rebuild the connection script per stack — the same seven steps still fit RDS and cloud catalogs. Not a customer dataset.
  1. Freeze the image and the client. Record the catalog, machine profile, VDA, Workspace app, StoreFront, Gateway, and Windows image hash. If you change any of those mid-test, start over. Capacity is always “on this build.”
  2. Script the business day, not only a login. Logon is mandatory. It is not the workload. Script the five to ten transactions that represent a real hour for the actual population: launch, search, open, save, print, switch published apps, idle. Put think time in. Do not test a knowledge-worker desktop if 80% of sessions are task workers on one published app.
  3. Take a single-user baseline, then a handful. One session, then five, on the same script. If one user already takes 40 seconds to a usable desktop, you do not have a capacity problem. You have an image, profile, or GPO problem. Fix that before you add concurrency.
  4. Ramp, then sustain — and run a login storm as its own test. A login storm — two hundred users authenticating in two minutes — is a real event: shift start, a DR test, Monday at 8:00. It is not the same as two hundred users already in session doing work. Run both shapes. Storm: steep ramp; measure logon time, broker and StoreFront or Gateway CPU, and the profile store. That is how you find the morning outage. Steady state: slower ramp to target, 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 the logon infrastructure and under-size the session hosts. If you only sustain, you will miss 8 a.m.
  5. Watch the tail and the failures. Means hide the damage. Report p95 and p99 for every transaction, plus fail, retry, and disconnect counts. One stuck GPO or one saturated CIFS share will not move the average until the service desk is already taking calls.
  6. Stop at the acceptance line. Add concurrency in steps — 25 or 50 users is typical — until a transaction budget or a reliability budget is breached. The last step that still passed is the number you take to the business. Write down hardware, image, client version, script name, and the exact pass/fail table. Launch without a usable desktop is not capacity. It is a queue.
  7. Re-test when density-changing things change. New VDA, new Workspace app, Windows feature update, FSLogix policy, an extra published app, a move from on-prem Virtual Apps and Desktops to Citrix DaaS, a Gateway or MFA change. Capacity is not a one-time project.
Two-column schematic comparing a login storm (steep ramp, logon path) with a sustain (steady state, session hosts).
Two test shapes from this article: a login storm versus a sustain. Schematic only — not a load-generator screenshot and not a customer dataset.

FAQ

Can we web-test StoreFront and call it a Citrix load test?

You can load-test StoreFront that way. You cannot size VDAs, HDX, profiles, or the published application that way. StoreFront and Gateway belong in the path. They are not the path.

How is Citrix DaaS different from on-prem Virtual Apps and Desktops for this?

The user path is the same idea: Workspace or Gateway, HDX, VDA, app. Cloud connectors and the shared control plane are extra moving parts. Include them. Do not assume a density number from the old resource location still holds after you move the catalog.

What about AVD and RDS in the same environment?

Reuse the transactions and the budgets. Rebuild the connection for each protocol. A Citrix concurrency figure is not an RDS or AVD figure.

When is protocol-level ICA replay enough?

For a quick broker or Gateway soak, sometimes. For a number you will print on a capacity plan and live with at 8 a.m., measure the screen.

Take the number you can stand behind

A Citrix load test that a CAB will accept has four traits: it walks the real StoreFront or Gateway path, it drives HDX from a real client, 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 Citrix servers — Tevron’s CitraTest VU is built for the job. See CitraTest VU load testing.

How to Load Test Microsoft RDS (Remote Desktop Services)

Posted on by
Tevron editorial illustration: RDP is not HTTP. Size the session hosts, not RD Web.
Editorial illustration for this article. Not a data chart.

This post is about load testing Microsoft Remote Desktop Services on Windows Server — concurrent RDP sessions on Remote Desktop Session Hosts — not Amazon RDS, the Relational Database Service. Search engines treat “RDS load testing” as a database topic. If you are here to soak a SQL instance, stop. If you need a concurrent-user number for Windows Server RDS that a CAB will accept, keep reading.

This is a 2026 method for VDI and RDS admins and QA. The stack is Windows Server Remote Desktop Services, Remote Desktop Session Host (RDSH) collections, RD Gateway, RD Web Access, and the real Remote Desktop client. Azure Virtual Desktop (AVD) is a cousin: same RDP family, different control plane. An AVD density figure is not an on-prem RDS figure.

RDP is not HTTP

Most load-testing practice grew up on websites. You record HTTP, replay thousands of threads, and graph page time. That model does not describe a Remote Desktop session.

Hammer RD Web Access with a web generator and you have load-tested the portal, not the session hosts.

RD Web Access is a web application. RD Gateway is an HTTPS front door that wraps RDP. The session that follows is Remote Desktop Protocol. The published desktop or RemoteApp does not send DOM or window handles to the endpoint. It sends pixels. The client sends keyboard and mouse.

A synthetic RDP stream that never paints a real Remote Desktop client window misses the events users wait on: the logon animation, the shell, the first paint of Epic or a line-of-business RemoteApp, the modal after a click. Those events exist on the bitmap. Treat RDP as a remoting protocol with a human on the other end, not as another API to replay.

What a defensible concurrent-user number actually is

A defensible number is not the highest session count you can boot before the Connection Broker returns errors. It is the highest concurrency at which a defined set of user transactions still meets a defined experience budget, with a defined failure rate, on the image and hardware you intend to ship. Write the acceptance line before the first ramp:

  • Logon to a usable desktop: 45 seconds at p95, 60 seconds at p99.
  • Launch the RemoteApp or in-session line-of-business app, search, open the record: 8 seconds at p95.
  • Fewer than 1% of sessions fail, disconnect, or hang during the sustain.
  • Session-host CPU, memory, and profile IOPS stay inside the same alert bands you already use in production.
Four example acceptance-line cards from the article: 45s p95 and 60s p99 logon, 8s p95 app open, under 1 percent fail, host CPU memory and profile IOPS in production bands.
Example acceptance line from this article. Schematic only — not a customer dataset and not a measured RDSH collection.

When the run crosses that line, that concurrency is the number. Averages, “it still launched,” and a green RDSH CPU chart are not. RDP round-trip time is useful. It is not the same as “the chart appeared.”

Test the path users actually take

Users do not appear already inside an RDP session. They hit RD Web Access (internal) or RD Gateway (external and most hybrid designs), then authentication — Active Directory, MFA, smart card, or a mix — then collection enumeration, resource launch, RDP to the Remote Desktop Session Host, profile and GPO processing (FSLogix or a roaming profile), and only then the business application.

Schematic RDS path: RD Web or RD Gateway, Auth and MFA, collection, RDP, profile and GPO, then RemoteApp or desktop. Caption notes skipping Gateway is the lab trap.
Schematic of the connection path in this article. Skipping RD Gateway because “it is just a proxy” is the lab trap. Not a network capture and not a customer dataset.

Skip RD Gateway in the lab because “it is just a proxy” and you will be surprised on go-live morning. Skip MFA because the tool cannot type an OTP and you have tested a path nobody uses. If production is Gateway plus MFA plus a published desktop collection, that is the script.

Pin Windows Server version, RDSH image, RDP client version, Connection Broker and Gateway builds, GPO, profile solution, and the published resource. A load test of a moving image is a story, not a measurement. AVD and Citrix have their own brokers and gateways; an RDS result does not transfer. Reuse the transactions and budgets; rebuild the connection script if you are comparing platforms.

Measure from the user’s screen

On 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 Remote Desktop client with keyboard and mouse, compares the live screen to baseline images, and does not install agents on the session hosts, the Connection Broker, or RD Gateway. Protocol replay and in-guest workload agents scale on cheaper generators, but they are not a substitute for “did the chart actually appear.”

Correlate the two views. When p95 “open chart” jumps from 6 seconds to 14 seconds at 180 users, you want RDSH CPU, logon duration, and profile IOPS on the same timeline. The screen tells you it broke. The infrastructure tells you which layer. If generator CPU is pegged, you are measuring the lab, not the session hosts.

FSLogix and profiles deserve their own watch. A session host that looks fine at 80 users can fall over at 81 if the profile store cannot keep up with concurrent logons. Measure container attach time, profile IOPS, and the delay from credentials accepted to a usable shell. That interval is often the real login-storm bottleneck, not RDSH CPU.

A seven-step method you can take to a CAB

Numbered schematic of the article’s seven CAB steps: freeze the image, script the day, baseline, storm and sustain, tails, stop at the line, re-test.
Schematic of the CAB method in this article. Citrix wording; rebuild the connection script for RDS — the same seven steps still fit. Not a customer dataset.
  1. Freeze the image and the client. Record the collection, machine profile, Windows Server build, RDP client, RD Web Access, RD Gateway, Connection Broker, and image hash. If you change any of those mid-test, start over. Capacity is always “on this build.”
  2. Script the business day, not only a login. Logon is mandatory. It is not the workload. Script the five to ten transactions that represent a real hour: launch, search, open, save, print, switch RemoteApps, idle. Put think time in. Do not test a knowledge-worker desktop if most sessions are task workers on one RemoteApp.
  3. Take a single-user baseline, then a handful. One session, then five, on the same script. If one user already takes 40 seconds to a usable desktop, you do not have a capacity problem. You have an image, profile, or GPO problem. Fix that before you add concurrency.
  4. Ramp, then sustain — and run a login storm as its own test. A login storm — two hundred users authenticating in two minutes — is a real event: shift start, a DR test, Monday at 8:00. It is not the same as two hundred users already in session doing work. Run both shapes. Storm: steep ramp; measure logon time, Connection Broker and RD Gateway CPU, and the profile store. Steady state: slower ramp to target, 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 the logon path and under-size the session hosts. If you only sustain, you will miss 8 a.m.
  5. Watch the tail and the failures. Means hide the damage. Report p95 and p99 for every transaction, plus fail, retry, and disconnect counts. One stuck GPO or one saturated CIFS share will not move the average until the service desk is already taking calls.
  6. Stop at the acceptance line. Add concurrency in steps — 25 or 50 users is typical — until a transaction budget or a reliability budget is breached. The last step that still passed is the number you take to the business. Write down hardware, image, client version, script name, and the exact pass/fail table.
  7. Re-test when density-changing things change. New Windows Server feature update, new RDP client, FSLogix policy, an extra RemoteApp, different RDSH hardware, an RD Gateway or MFA change, a move from on-prem RDS to Azure Virtual Desktop. Capacity is not a one-time project.
Two-column schematic comparing a login storm (steep ramp, logon path) with a sustain (steady state, session hosts).
Two test shapes from this article: a login storm versus a sustain. Schematic only — not a load-generator screenshot and not a customer dataset.

FAQ

Can we web-test RD Web Access and call it an RDS load test?

You can load-test the portal that way. You cannot size session hosts, RDP, profiles, or the published application that way. RD Web Access and RD Gateway belong in the path. They are not the path.

How is Azure Virtual Desktop different from Windows Server RDS for this?

AVD is a cousin, not the same stack. Users still get an RDP session, but the broker, gateway, and host pool live in Azure. Do not assume an on-prem RDSH density number still holds after you move the workload. Rebuild the connection script; reuse the transactions and the budgets.

What about Citrix in the same environment?

Reuse the transactions and the budgets. Rebuild the connection for each protocol. An RDS concurrency figure is not a Citrix or AVD figure.

When is protocol-level RDP replay enough?

For a quick Connection Broker or RD Gateway soak, sometimes. For a number you will print on a capacity plan and live with at 8 a.m., measure the screen.

Take the number you can stand behind

A Microsoft RDS load test that a CAB will accept has four traits: it walks the real RD Web Access or RD Gateway path, it drives RDP from a real client, 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 Remote Desktop client, image and OCR, no agents on the session hosts — Tevron’s CitraTest VU is built for the job. See CitraTest VU load testing and Tevron’s notes on RDP load testing.

The Impact of Application Speed on User Retention

Posted on by
The Impact of Application Speed on User Retention
Abstract Tevron illustration: users feel milliseconds, businesses feel percentages.
Editorial illustration for this article. Not a data chart.

Measuring application performance is important because modern software is the product, the storefront, the factory floor, and often the brand. Users do not experience your architecture, your sprint velocity, or your cloud bill. They experience latency, errors, jank, and whether the thing they came to do actually completed. If you do not measure that experience in production, you are flying by anecdote, support tickets, and luck.

Performance is a product feature, not a leftover…

For decades, teams shipped features first and “tuned later.” That model collapsed for three reasons.

  1. User tolerance collapsed. On the web and on mobile, people abandon pages that take more than a few seconds. A site that loads in about one second converts several times better than one that takes ten. Bounce rates climb steeply as load time moves from two seconds to three, then five. Users do not file a bug; they leave and often do not come back.
  2. Software became the transaction itself. Checkout, login, search, booking, trading, claims, payroll, and internal tools are not “supported by” an application. They are the application. A slow query or a 500 on a payment path is not a technical inconvenience. It is lost revenue, abandoned carts, failed trades, or employees who cannot work.
  3. Systems got too distributed to understand by inspection. Monoliths on a few servers could be reasoned about with logs and a profiler. Microservices, queues, caches, CDNs, third-party APIs, mobile clients, and multi-region clouds cannot. A request that looks “fine” in your service can still be slow because of a downstream dependency, a cold start, a lock, a chatty N+1 query, or a network hop you do not own. Measurement is how you reconstruct the path the user actually took.

If you only measure after users complain, you are measuring the residue of failure, not the system.

Users feel milliseconds; businesses feel percentages

The most cited commercial evidence is still Amazon’s mid-2000s internal experiments: adding about 100 milliseconds of latency was associated with roughly a 1% drop in sales.

The public record on that exact coefficient is thin (it comes from an engineer’s talks and posts, not a peer-reviewed paper), so treat “1% per 100ms” as a famous directional finding, not a universal law. What has been replicated, again and again, is the shape of the relationship.

Walmart reported that a one-second improvement in page load increased conversions by about 2%, with roughly 1% incremental revenue per 100ms of improvement. Google’s search experiments showed that adding a few hundred milliseconds reduced queries and revenue per user, and some of the lost behavior persisted after the delay was removed.

Akamai/SOASTA retail data associated a 100ms delay with conversion drops on the order of 7% in some slices, and a one-second delay with much larger drops. A Deloitte/Google study of brand sites associated a 0.1-second mobile improvement with high-single-digit conversion lifts in retail and travel (those figures are observational, not a clean A/B, so they should be read as “speed and conversion move together,” not “this exact lift is guaranteed”). More recent platform-level work, including Shopify’s 2026 analysis of Core Web Vitals across live stores, still finds that slower Largest Contentful Paint is associated with substantially lower conversion.

Four separately labeled published findings on latency and business impact from Amazon, Walmart, Akamai/SOASTA, and Deloitte/Google.
Published findings named in this article. Different studies, methods, and metrics — not one dataset. Shopify is omitted because this post does not cite a numeric figure for it.

The mechanism is not mysterious

  • Attention is scarce. Extra wait time is extra time to notice a competitor, a notification, or a reason to abandon.
  • Trust is fragile. Slow feels broken. Broken feels untrustworthy, especially for money, health, or identity.
  • Mobile multiplies the penalty. Unreliable networks, weaker CPUs, and impatient thumbs make the same backend look worse.
  • The tail matters more than the average. Users remember the 95th and 99th percentile, not your mean. A system that is “200ms on average” and “4 seconds for 2% of requests” is a system that regularly fails the people who matter most.

This is why performance work is not vanity. It is conversion, retention, and word of mouth wearing a stopwatch.

Schematic showing a typical 200 millisecond average and a far tail at 4 seconds for 2 percent of requests.
Example from this article (“200ms on average” and “4 seconds for 2% of requests”). Schematic only — not a customer dataset.

Downtime and slowness have a price tag you can itemize

Outages are the loud version of the same problem. Industry figures vary by sector and methodology, but they are consistently ugly: organizations quote downtime in thousands of dollars per minute; some financial and insurance environments have reported multi-million-dollar hourly costs for high-impact incidents. Detection and repair still often take tens of minutes. During that window you lose transactions, burn support capacity, trigger contractual penalties, and generate the kind of screenshots that live on social media forever.

Slowness is the quiet version

It does not page you at 2 a.m. It just taxes every session: fewer pages viewed, fewer items added, more retries, more “is it working?” tickets, more people who silently switch vendors.

Measurement changes the economics of both:

  • You detect degradation before it becomes an incident.
  • You shrink mean time to detect and mean time to recover because you can see which service, query, region, or release caused the change.
  • You can put a dollar figure on a regression (“this checkout p95 went from 800ms to 1.6s after Friday’s deploy”) instead of arguing from feelings.

Observability investments are often justified on exactly this: fewer customer-facing outages, much faster recovery, and reported ROIs that look large because the alternative is paying for fire drills forever.

You cannot manage what you cannot see in production

Lab benchmarks lie in predictable ways. Synthetic tests use warm caches, happy-path data, desktop networks, and one user.

Production has:

  • cold caches and thundering herds
  • pathological inputs and bot traffic
  • mobile networks and last-mile ISPs
  • third-party tags, fonts, ads, and APIs
  • data distributions your fixtures never had
  • garbage collection, lock contention, and noisy neighbors
  • deployments that only fail for 3% of users in one region
Two-column comparison of lab conditions versus production: warm caches, happy path, and desktop against cold caches, mobile, third parties, and 3 percent regional failures.
A comparison of conditions, not a measured chart. Lab and production examples are taken from this article.

Measuring application performance is how you close that gap

Useful measurement is not “CPU is 40%.” It is a stack of complementary views:

  • User-centric timing: time to first byte, Largest Contentful Paint, Interaction to Next Paint, time-to-interactive, Apdex, successful task completion.
  • Request traces: the critical path across services, with spans for DB, cache, queue, and HTTP.
  • Error and availability rates: not just 5xx, but failed business outcomes (checkout started but not completed).
  • Saturation: queues growing, thread pools exhausted, connection pools starved, disk and memory pressure.
  • Work done per dollar: cost per request, cost per search, cost per successful order.
Five-item stack of complementary measurements: user-centric timing, request traces, error and availability, saturation, and work done per dollar.
The five complementary views listed in this article. Not a live dashboard.

Without those, optimization is superstition. Teams rewrite the wrong layer, add hardware to hide a query, or declare victory because the homepage is fast while search and checkout are dying.

Cost control is a performance problem

In the cloud, performance and spend are the same knob turned in opposite directions.

Over-provision to hide inefficiency and your bill grows every month. Under-provision and latency and errors explode. Idle capacity, chatty microservices, unbounded retries, unindexed queries, oversized instances “just in case,” and functions that run longer than they should all show up first as performance symptoms, then as invoices.

Measurement lets you answer the only questions FinOps actually cares about

  • Which endpoints consume the most compute per successful user action?
  • Did the new ranking model double CPU per query?
  • Are we paying for headroom we never use, or starving the path that makes money?
  • Can this internal tool tolerate 200 extra milliseconds overnight so we can right-size it?

Teams that only optimize for “as fast as possible” overspend. Teams that only optimize for “as cheap as possible” ship a product people hate. Measurement is the only way to pick a point on that curve on purpose.

Engineering culture changes when performance is visible

Unmeasured systems produce heroics. A senior engineer who “just knows” the database becomes the bottleneck. Releases feel dangerous. Postmortems become blame sessions because nobody can reconstruct the timeline.

Measured systems produce feedback loops:

  • A regression is caught in canary or in the first hour, not after a weekend of lost sales.
  • SLOs and error budgets make reliability a product tradeoff instead of a slogan.
  • Developers can see whether their change helped users, not just whether tests passed.
  • Capacity planning becomes a forecast instead of a panic buy before Black Friday.
  • Vendor and SLA arguments become evidence: what users actually experienced, not what the status page claimed.

This is also why performance measurement belongs in the same conversation as developer productivity. Time spent guessing is time not spent building. Faster diagnosis is a direct reduction in toil.

The hidden risks of not measuring

If you skip measurement, the failures are not evenly distributed. They concentrate where they hurt most.

You optimize the wrong thing. Homepage Lighthouse scores look great while the authenticated app, search, or payment confirmation is slow. Executives see a green dashboard. Customers see a brick.

You discover problems through customers. By then the damage is already in reviews, churn, and support queues. In many organizations a large share of issues are still first reported by users rather than by monitors. That is a process failure, not a badge of closeness to the customer.

You cannot prove value. Platform, SRE, and performance teams that do not measure outcomes struggle to justify investment. “We made it better” is not a budget. “p95 checkout dropped 40% and conversion rose X” is.

Complexity outruns intuition. Each new service, feature flag, CDN rule, and SaaS dependency multiplies failure modes. The system becomes un-debuggable without traces and real-user monitoring. Outages then last as long as the meeting required to decide whose dashboard is telling the truth.

You miss the tail and the journey. Averages hide the users on bad networks, the region with a sick replica, the cohort on an old app version. Business impact lives in journeys (browse, then search, then cart, then pay), not in isolated service health. If you only watch boxes, you will declare the system healthy while the journey is broken.

CitraTest APM is the application monitoring solution. Learn more about CitraTest APM.

RDS / RDP load testing and end-to-end monitoring for all applications that are accessible from Windows

Posted on by

Think you may be off the hook from load testing because you use Remote Desktop Service (RDS) / Remote Desktop Protocol (RDP) from Microsoft (which provides a user with a graphical interface to connect to another computer over a network connection)? Think again. Your users have the same level of expectations regardless of your behind the scenes architecture, and how your applications are deployed and consumed. And there are quite a large number of RDP users out there. In fact, out of 11 million devices with open online 3389/TCP ports, roughly 4.1 million of the 3389/TCP ports are specifically speaking the RDP protocol (Source: Rapid 7, recent security scan results)

In a nutshell, a Remote Desktop Services (RDS) platform runs applications or user desktops on the server rather than on user workstations. No underlying objects or controls are delivered to the client. Instead, the RDS server sends screen images of the user desktop to the end-user workstation, and keystrokes and mouse clicks are returned to the server. This adds a new layer of complexity and challenge– since you stream your applications, many test automation tools would not work because they use object recognition methodologies. Instead you need a test automation solution that uses image recognition and visually examines the desktop, responds to changes and uses the keyboard and mouse just like a real user does. And this is exactly what CitraTest does. Use Tevron solutions for complete end-to-end testing and monitoring as outlined below

1) Build your test scripts and automate manual, functional, smoke and performance testing: Easily automate all user actions (clicking on, comparing, verifying, awaiting display images…) with minimal effort. CitraTest utilizes an advanced proprietary image recognition system to replicate the actions of an actual user and visually analyze every aspect of the desktop. Just like a user, CitraTest does not need to ‘see’ an image in the same location each time. CitraTest looks at the entire desktop and when an image needs to be clicked, it will move the mouse to the desired image and issue the appropriate mouse action, just like a user would do. CitraTest also automates keystrokes in the same way that an actual user types. The simplicity of using these 3 elements (desktop visualization, keyboard and mouse) gives CitraTest the power and flexibility to operate with any application so you can easily automate all your testing activities.

2) Test your application under load. Use CitraTest scripts and CitraTest VU to ensure readiness for peak traffic and real-world conditions for all Citrix, Remote Desktop Services & Microsoft Terminal Services environments. You can test, measure and validate application response time, at the client UI, under various controllable load levels with non-intrusive load testing. “Load generating machines” are used to generate user load against the server environment under test, while “measuring machines” actively measure response times at the client UI and gather server performance metrics on the back-end. Each CitraTest VU script executes in its own “desktop” and opens its own client connection to the server-under-test, just as a group of real users would. CitraTest VU automatically compares what it “sees” on the screen to baseline response images (created during test script development), and measures and reports response times at the client GUI to immediately identify underperforming components. Validate complex multi-step scenarios end-to-end (e.g. find item, add to shopping cart, enter credit card information and complete payment) and easily customize load levels and virtual user ramp-up times as defined in your test plans.

3) Monitor response time from a user perspective. Reuse the same CitraTest scripts and proactively monitor any application with CitraTest APM . CitraTest APM periodically executes end-to-end transactions, taking response time measurements along the way. By automating the driving of any application just like a real user, CitraTest APM can validate whether all critical aspects of an application are available and working within limits. If they are not, CitraTest APM generates a real time alert to help you find and resolve problems before your users are impacted. Screenshots are also taken when problems are identified to help you analyze root cause. Any end to end transaction can be simulated and measured in absolute values, percentages or statistical deviations to help you identify problems early on.

Are you ready to boost quality and customer satisfaction? Start testing and monitoring ALL your applications today, without any code changes or production impact! All you need is access from Windows to any target application.

See how other enterprises and global leaders rely on Tevron to ensure their application SLAs are met.

Good luck!

What is Intelligent Automation?

Posted on by

Intelligent Automation
What’s the difference between Robotic Process Automation (RPA) and Intelligent Process Automation (IPA)? In a nutshell, RPA uses technology to configure computer software to process transactions, manipulate data, trigger responses and communicate with other applications, programs and systems. Ultimately, RPA is perfect for tasks, processes and workflows that have repeatable, predictable interactions with other IT applications. The concept of RPA started back during the early 2000s, when IT teams started to experiment with basic automation, using software commands that followed scripted processes to perform tasks within a single IT applications. RPA technology then moved this to the next level by scripting tasks across multiple applications.

What is Intelligent Automation?
The subsequent, natural progression between robotic and intelligent automation has introduced machine learning and artificial intelligence into the mix. Unlike RPA, which is designed to automate routine, repetitive tasks, intelligent automation has the capacity to automate non-routine tasks. Intelligent automation can even tackle processes that require judgment, creativity, persuasion and problem-solving – all skills that previously required human intervention. This means that when you combine it with RPA technology, you can harness the power of automation to streamline both routine and highly complex processes and workflows, reimaging how things might work and creating an intelligent, self-driving organization.

Major Catalyst for Growth
According to a recent report by Forbes, intelligent automation is a major catalyst for growth. It’s important to say that intelligent automation is not about replacing humans. By delegating routine admin tasks to automation, workplaces become environments where innovative thinking is encouraged by everyone, rather than be the preserve of leaders. In 2017 McKinsey article notes a financial institution that automated 60-70 percent of its tasks and therefore increased process efficiency by 30 percent. In retail, goods can be ordered and processed for delivery and stock levels can be adjusted without an employee having to do anything. Another process greatly improved by automation is employee onboarding for the Human Resources department. McKinsey’s research found that, in a manual world, it can take up to four weeks to successfully onboard a new employee before you start seeing results. In an automated one, the cost of onboarding is reduced by 80 percent. For our own part, an IT customer, tasked with moving 60,000 records manually with a team of six was scheduled to work on the project over many weeks. Using CitraTest® RPA, the work was completed in just four days.

CitraTest RPA delivers Intelligent Automation

Tevron® is a global leader in automation. Our customer portfolio includes industry giants such as Xerox, Fujitsu Services, Siemens, T-Systems, Ameriprise,  Brabant Water, and John Deere. Work with experienced automation experts who have a successful track record of success.

We believe that automation will become central to business strategy and operations, driving new standards of customer experience such as deeper personalization, higher quality, faster delivery and greater convenience. What are you waiting for? Let us support you on your intelligent automation journey.

Calling All Financial and Accounting Professionals… Robotic Process Automation Can Save You Thousands of Hours of Avoidable Work Annually

Posted on by

Managing Month-End

Month-end and quarter-end are dreaded words in every Finance Department, usually involving long working hours to get the books reconciled.  You and your team are checking transactions and journal entries, balancing accounts, reviewing expense reports, depreciating fixed assets, reconciling inventory discrepancies, settling work in progress material, posting billing documents, and of course, still managing payroll.

Ultimately, you are responsible for capturing key data that will be used to make decisions and drive the business. However, tight deadlines and pressurized working conditions can often result in errors. Did you know that any repetitive, routine financial and accounting processes can be customized and automated cost efficiently with minimal involvement from the IT team?

Migrating Data

Let’s look at another scenario. Perhaps as Financial Controller, you are considering migrating data from one platform to another but the process of moving the records is a mammoth task. Of course, one option is to hire a team of consultants to read and parse the data, check for duplicates, and transfer the data into the new database.

Another solution might be to transfer the data manually with assigned teams reading one screen while simultaneously entering data into the other system. The problem is that both options are time consuming and expensive with a high risk of error. There are also data privacy laws to comply with plus the issue of software compatibility and the likely need to invest in middleware.

Making the Complex, Easy

Meet the perfect solution – Tevron’s CitraTest RPA. Use software bots to customize and automate repeatable financial and accountancy tasks like accounts reconciliation, journal entries, and preparing financial statements with minimal human intervention. Transfer data from one system to the next efficiently and accurately in a fraction of the time and at a fraction of the cost. Our advanced, high performing solution enters data just like a real user would but importantly without the risk of errors.

Expert Study

A recent Gartner study showed that automation can save Finance Departments thousands of hours with estimates indicating that 77% of controllers will be operating RPA by 2020. According to the researchers there are three main roadblocks to automating financial reporting work. Financial controllers are slow about removing human input; they don’t see sufficient or fast enough return on investment from the technology, and finally they are worried about the delays associated with standardizing processes.

According to research, maintaining unnecessary human interaction in what’s supposed to be a fully automated process limits benefits of automation while still introducing the risk of human error and the need for rework. And as for ROI, according to the study, the average amount of avoidable rework in accounting departments can take up to 30% of a full-time employee’s time. If fully implemented, however, RPA saves upward of 25,000 hours per year and around $878,000.

Many financial professionals believe that the process must be standardized before it is implemented. However, the research shows that by implementing RPA on processes that can be automated from day one, accounting teams can immediately free up time and capacity with minimum disruption. This ultimately accelerates adoption plus all the associated benefits of automation.

 

Benefits of RPA

Data Integrity

However great your team is, human error is inevitable.  It’s a dynamic environment. Changing suppliers, different policies, fluctuating currencies can make it challenging. The good news is that when your data forms are automated, you have the reassurance of knowing your data is 100 percent accurate.

 

Better Efficiencies

You understand only too well the importance of cost reduction. Digitize your processes now to improve productivity, increase efficiencies, lower costs and ensure compliance. It’s a win-win. Taking manual, boring work away frees the team up to provide value-add, focusing on strategic activities that will add to the bottom line, and deliver a more rewarding career path.

 

360-Degree Visibility

Keeping accurate and up-to-date records is vital to the success of any business. With CitraTest RPA, you can ensure consistency, visibility and control over financial operations.

Power In Your Hands

How does it work? You know your financial and accounting processes better than anyone.  You’re the expert. We’ve created wizard tools to allow you to write your own customized scripts. With CitraTest RPA, you get a library of functions and utilities that you can customize in line with your business needs.

About Tevron

Tevron® is a global leader in automation. Our solutions are successfully deployed across multiple vertical industries. Our customer portfolio includes industry giants such as John Deere. the Mayo Foundation, T-Systems, Fujitsu Services, Con Edison, USPTO, British Airways, Ameriprise Financial and Alcon Labs. Contact us now for a free demo!

CitraTest RPA

We design powerful tools for your hands

www.tevron.com

For more information or to schedule a demo, please visit

https://tevron.com/robotic-process-automation-citratest-rpa.aspx.

Intelligent Automation – CitraTest RPA

Posted on by

Intelligent Automation
What’s the difference between Robotic Process Automation (RPA) and Intelligent Process Automation (IPA)? In a nutshell, RPA uses technology to configure computer software to process transactions, manipulate data, trigger responses and communicate with other applications, programs and systems. Ultimately, RPA is perfect for tasks, processes and workflows that have repeatable, predictable interactions with other IT applications. The concept of RPA started back during the early 2000s, when IT teams started to experiment with basic automation, using software commands that followed scripted processes to perform tasks within a single IT applications. RPA technology then moved this to the next level by scripting tasks across multiple applications.

What is Intelligent Automation?
The subsequent, natural progression between robotic and intelligent automation has introduced machine learning and artificial intelligence into the mix. Unlike RPA, which is designed to automate routine, repetitive tasks, intelligent automation has the capacity to automate non-routine tasks. Intelligent automation can even tackle processes that require judgment, creativity, persuasion and problem-solving – all skills that previously required human intervention. This means that when you combine it with RPA technology, you can harness the power of automation to streamline both routine and highly complex processes and workflows, reimaging how things might work and creating an intelligent, self-driving organization.

Major Catalyst for Growth
According to a recent report by Forbes, intelligent automation is a major catalyst for growth. It’s important to say that intelligent automation is not about replacing humans. By delegating routine admin tasks to automation, workplaces become environments where innovative thinking is encouraged by everyone, rather than be the preserve of leaders. In 2017 McKinsey article notes a financial institution that automated 60-70 percent of its tasks and therefore increased process efficiency by 30 percent. In retail, goods can be ordered and processed for delivery and stock levels can be adjusted without an employee having to do anything. Another process greatly improved by automation is employee onboarding for the Human Resources department. McKinsey’s research found that, in a manual world, it can take up to four weeks to successfully onboard a new employee before you start seeing results. In an automated one, the cost of onboarding is reduced by 80 percent. For our own part, an IT customer, tasked with moving 60,000 records manually with a team of six was scheduled to work on the project over many weeks. Using CitraTest® RPA, the work was completed in just four days.

CitraTest RPA delivers Intelligent Automation

Tevron® is a global leader in automation. Our customer portfolio includes industry giants such as Xerox, Fujitsu Services, Siemens, T-Systems, Ameriprise,  Brabant Water, and John Deere. Work with experienced automation experts who have a successful track record of success.

We believe that automation will become central to business strategy and operations, driving new standards of customer experience such as deeper personalization, higher quality, faster delivery and greater convenience. What are you waiting for? Let us support you on your intelligent automation journey.

What Is On-the-Glass APM?

Posted on by
What Is On-the-Glass APM?
Tevron editorial illustration: Green hosts are not a usable desktop. On-the-glass APM for EUC.
Editorial illustration for this article. Not a data chart.

Director is green. Azure workbooks are green. The session hosts are at 40% CPU. The help desk still has a queue of “Epic is slow” and “my desktop took forever.” That gap is not a mystery of bad users. It is a measurement gap. Most of what you watch in a Citrix, Microsoft RDS, or cloud VDI estate never times what appeared on the user’s screen.

On-the-glass APM is the name for closing that gap: application performance monitoring that measures response time and availability from the real user GUI — login-to-shell, published-app launch, and the in-session steps people actually wait on — using the same visual path a person takes. This post is the plain definition for EUC and VDI teams in 2026, and how it fits next to protocol counters, host metrics, and full-stack observability. The short answer page lives on tevron.com as What is on-the-glass APM?.

What “the glass” means

In EUC, the glass is the endpoint screen. HDX and RDP deliver a bitmap. The published desktop or RemoteApp does not hand the client a DOM event that means “the chart appeared.” The user knows the step finished when the pixels say so. On-the-glass monitoring takes that same signal seriously: image recognition and OCR against a baseline of what “done” looks like, then time from the click or key until that state is visible.

A connected session is not a usable desktop. A usable desktop is not a painted chart.

That is why a Workspace URL returning 200, an RDP connection that “succeeded,” or a green ICA RTT tile can all coexist with a nurse waiting fourteen seconds for Hyperspace. The control plane answered. The glass did not.

Four views of the same session

Four-column schematic comparing host, protocol, full-stack APM, and on-the-glass monitoring views.
Schematic from this article: four monitoring views. Not a customer dashboard.

You already run several of these. Keep them. Do not confuse them.

  • Host / infra — CPU, memory, disk, profile IOPS. Essential. Green hosts are still not proof the published app painted.
  • Protocol — ICA / HDX, RDP round-trip, Gateway health. Useful for the remoting path. Can miss a slow thick client that is already “in session.”
  • Full-stack APM / observability — traces, logs, code, infra for the services you own. Strong for web and microservices. Often weak on the published GUI path that HDX and RDP remoting hide behind pixels.
  • On-the-glass APM — synthetic transactions that drive the real Workspace, AVD, or Remote Desktop client and time screen-ready states. That is the user SLA for Citrix and RDS.

Protocol metrics answer “is the remoting path healthy.” On-the-glass answers “did the business transaction complete on the screen.” The HDX vs real user experience note on tevron.com is the same split in product language.

How on-the-glass APM typically works

The pattern is synthetic, not agent-on-VDA:

  1. A robot logs on like a real user — Citrix Workspace, RDP, or a cloud client, including the Gateway or portal hop you actually use.
  2. It drives keyboard and mouse through a business transaction: open Epic Hyperdrive or Hyperspace, search a patient, open a chart; or launch SAP, search, open the record.
  3. Image recognition (or equivalent visual checks) waits until the expected screen state appears and records the time for each step.
  4. Results feed SLAs, alerts, trends, and screenshots on failure — around the clock, not only during a load test.

Nothing needs to be installed on the session hosts, VDAs, or RDSH for that path to work. The synthetic is another client. That matters in locked-down healthcare and finance images where agent politics can stall a project for months.

When the glass view pays for itself

Use on-the-glass APM when the business owns a published experience and the tickets already say so:

  • Morning logon storms — shift start, failback, Autoscale powering a cold pool. Host CPU can look fine while FSLogix attach or GPO stretches login-to-shell. Pair this with the logon storm vs density split: storm numbers and density numbers are different jobs.
  • EHR and thick clients — Epic, Cerner, and similar apps on Citrix, AVD, or RDS. A Workspace or AVD URL test is not an EHR test. See Epic and EHR on the glass.
  • After go-live and image changes — new VDA, new Workspace app, Windows feature update, FSLogix policy, extra published app. Capacity tests size the change. Continuous glass watch catches the regression at 8 a.m. on Tuesday.
  • Whenever Director is green and users are not — that is the classic symptom. Do not argue about feelings. Time the glass.

Lab density is not the morning watch

Two-column schematic: CitraTest VU capacity testing versus CitraTest APM continuous on-the-glass watch.
Schematic from this article: same glass path, different jobs. Not a measured run.

On-the-glass is an idea, not a single product SKU. In the lab, you use it to produce a concurrent-user number a CAB can defend: freeze the image, walk the real path, ramp and sustain, run the login storm separately, stop at a written experience budget. That is the 2026 method in How to Load Test Citrix Virtual Apps and Desktops, Microsoft RDS, and cloud-hosted virtual apps and desktops.

In production, you reuse the same glass path continuously. The lab answered “how many good sessions fit on this SKU.” The morning watch answers “is today’s logon-to-shell and open-chart still inside the SLA.” Tevron’s product names map cleanly: CitraTest VU for capacity from the glass, CitraTest APM for the continuous watch. Same visual approach. Different cadence.

What this is not

  • It is not a replacement for Citrix Director, Monitor, or Azure Virtual Desktop workbooks. Keep those for broker and host health.
  • It is not an HTTP soak of the Workspace or RD Web URL. Keep that for the front door.
  • It is not “we have Dynatrace / New Relic / Datadog, so we are covered.” Those platforms are excellent for services they instrument. Published HDX and RDP GUIs are a different problem.
  • It is not a promise that last quarter’s on-prem number travels with a cloud catalog. Re-test density when the SKU, image, Connector, or autoscale schedule changes; keep watching the glass either way.

Write the SLA the glass can keep

A useful on-the-glass SLA is boring and specific. Example language teams already use on capacity plans — schematic only, not a customer dataset:

  • 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 synthetic runs fail, disconnect, or hang in the watch window.

Put those numbers next to host and protocol charts on the same timeline. When p95 “open chart” jumps, you want session-host CPU, profile IOPS, and Gateway or Cloud Connector health in the same hour — not a war room guessing which layer broke.

Take the signal users already send

On-the-glass APM is not a new philosophy of monitoring. It is admitting that for Citrix, RDS, AVD, and Windows 365, the user’s truth lives on the bitmap. Measure that truth with synthetics that look like real clients. Keep Director and observability for the layers they own. Size density in the lab; watch the glass every shift.

When you need that path without agents on the session hosts — real Workspace or Remote Desktop client, image and OCR, screenshots on failure — Tevron’s CitraTest APM is built for the continuous watch, and CitraTest VU for the same glass under load. Start from the on-the-glass APM answer or schedule a demo.

The Benefits of Cloud Multi-User Application Performance Testing Based on the Real User Experience

Posted on by
The Benefits of Cloud Multi-User Application Performance Testing Based on the Real User Experience
Tevron editorial illustration: The broker is not the session. Multi-user still has to paint the glass.
Editorial illustration for this article. Not a data chart.

Cloud multi-user is still a session. Citrix DaaS, cloud-hosted Citrix Virtual Apps and Desktops, and Azure Virtual Desktop multi-session catalogs deliver HDX or RDP pixels to a human. The control plane can be green, Autoscale can be adding hosts, and the Workspace URL can return 200 while the chart is still not on the glass. That is the gap real-user-experience testing closes.

This is not another how-to for walking Gateway. It is the case for measuring cloud concurrency from the user’s screen — and the benefits you only get when you do. The 2026 method for the lab itself is in How to Load Test Cloud-Hosted Virtual Apps and Desktops.

What “cloud multi-user” actually is

Multi-user in this article means several people sharing a session host: a Citrix VDA or an AVD multi-session host pool. Windows 365 is one Cloud PC per person. Reuse the path and the budgets there; do not treat it as a density problem. The cloud control plane — Citrix Cloud, Azure Virtual Desktop — brokers the session. The work still happens on a host in a resource location. Finance still asks how many concurrent users that SKU can carry without the day falling apart.

A green control plane is not a usable desktop.

The benefit of measuring on the glass

HTTP tests of the Workspace URL, the AVD web client, or the portal prove the front door. They do not prove logon, shell, FSLogix, GPO, or the published application. HDX and RDP send a bitmap. There is no DOM event that means “the record opened.” 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 — and time the click until that image is visible.

Two-column schematic: control-plane health versus what the user waits on on the glass.
Schematic from this article: broker health versus glass time. Not a customer dashboard and not a measured catalog.

GUI-level tools exist for this. CitraTest VU 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 session hosts. CitraTest APM uses the same glass path in production so the number you sized in the lab is the number you watch at 8 a.m.

Six benefits you only get from real user experience

1. You size the host, not the broker

Control-plane dashboards answer “did the broker hand out a session.” Density answers “how many good sessions fit on one D4s_v5” — or whichever SKU you actually run. A test that only hammers Workspace or the AVD ARM APIs will tell you the subscription can issue tokens. It will not tell you when p95 “open the chart” crosses the line at 28 users per host. That per-host number is what sets max sessions, buffer capacity, and the monthly compute bill.

2. Autoscale cannot hide a bad density number

Citrix Autoscale and AVD scaling plans add hosts when concurrency rises. Useful in production. A trap in a capacity test. If the pool grows as you ramp, you can “pass” hundreds of users while each host is miserable at 25. You learned that the region can provision VMs. You did not learn sessions-per-host. Measure density with autoscale off (or a fixed host count) until the experience budget breaks. Measure scale-out lag in a second run. Keep both. Skip density and you overpay for compute or discover the limit when the region will not give you another VM at 8 a.m.

3. The morning logon storm and the working day are both visible

Two hundred people authenticating in two minutes is a real cloud event: shift start, failback, Autoscale powering a cold pool. Two hundred people already in session doing work is a different shape. Screen-level timing separates them. Storm the logon path and you see Cloud Connector, profile store, and cold-boot delay. Sustain the business day and you see memory growth, CPU ready time, and session reliability. If you only storm, you under-size the hosts. If you only sustain, you miss 8 a.m. The APM logon-storm versus density note on tevron.com is the same split in production language.

4. The line-of-business app still has to appear

Epic Hyperdrive, Cerner, SAP, the thick client on the VDA — none of those are the Workspace URL. A session that “connected” is not a chart that painted. Measuring from the glass is how you catch the hop HTTP never sees: published app launch, search, open record, first usable screen. That is the transaction users complain about, and it is the transaction a CAB will actually fund a test to protect. See Epic and EHR on the glass.

5. The bill and the SLA share one number

Cloud VDI is billed by host hours and SKU. User experience is billed in complaints, overtime, and missed charts. Real-user-experience testing is how those two ledgers meet. Write the acceptance line before the first ramp — logon to a usable desktop, app open, fail rate, per-host CPU and profile IOPS — then stop at the last concurrency that still passed on that SKU. Example budgets belong in the method post. The benefit here is simpler: you are no longer arguing about a green tile while users wait fourteen seconds for a record.

6. Image, profile, GPO, and Connector problems show up before go-live

A single-user baseline on the glass tells you if one person already takes forty seconds to a usable desktop. That is an image, FSLogix, GPO, or Cloud Connector problem. Fix it before you add concurrency. A website test of the portal will not show it. A session-host CPU chart may not show it either until the storm. Screen timing plus host and Connector metrics on the same timeline tells you which layer broke.

What this is not

  • It is not a replacement for Monitor, Director, or Azure workbooks. Those remain the host and broker view. They are not “the chart appeared.”
  • It is not an HTTP soak of the Workspace URL. Keep that test for the front door. Do not take it to a CAB as a farm number.
  • It is not a Windows 365 density figure. One Cloud PC per user. Test the SKU and the logon path.
  • It is not a promise that last quarter’s on-prem number travels with the catalog. Re-test when the SKU, image, Connector, region, or autoscale schedule changes.

How to collect the number

Freeze the catalog and the SKU. Walk the path users take. Script the business day, not only a login. Take a one-user baseline. Measure density with autoscale off, scale-out with it on, and the login storm as its own run. Watch p95, p99, and failures. The seven-step CAB method is in the cloud load-testing guide, with the same shape for Citrix Virtual Apps and Desktops and Microsoft RDS.

Take the number the bill and the users can both survive

The benefit of cloud multi-user performance testing based on the real user experience is a number you can defend: sessions per host on a named SKU, with autoscale behavior written down separately, measured on the glass. That is the number finance can buy and the number the morning can live with.

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 lab and CitraTest APM for the same path in production. See CitraTest VU load testing and CitraTest APM.