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.

RPA Robot in action with CitraTest RPA

Posted on by

Intelligent Data Entry
RPA is perfect for tasks, processes and workflows that have repeatable, predictable interactions with other IT applications.

Watch a CitraTest APM Robot in Action – Workflow Automation

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.