Remote Desktop Performance – Key Metrics to Watch

So, you’ve implemented a brand new Remote Desktop Services (RDS) or Citrix XenDesktop farm, and now you want to start monitoring different metrics to both a.) ensure a good user experience as well as b.) determine which users and/or clients are the most costly in terms of resources used. Here are the key remote desktop performance categories you need to keep an eye on, and why they’re so important:

Remote Desktop CPU Usage

While RDS Dynamic Fair Share Scheduling (and the built in Citrix XenApp equivalents) help evenly distribute CPU load amongst “plain vanilla,” “task worker” user sessions, this technology is not a panacea. For some MSPs and on-premise Remote Desktop Services shops, some users will require a much larger share of CPU (implemented via the Windows System Resource Manager) in order to run their beefier software. In other situations, Dynamic Fair Share Scheduling may let you inadvertently stuff too many users on an existing virtual machine, because DFSS will dutily throttle available CPU down to the point where common tasks may take *forever* to complete. Therefore, it is still very important to look at remote desktop CPU consumption patterns by user, even down to the process level running in the user sessions.

Remote Desktop Memory Usage

Unlike DFSS above, there is no way to throttle available remote desktop memory per user session, which makes it even more critical to monitor remote desktop memory consumption both by user session aggregate and on a per process basis. By analyzing memory use by user and by process, you can better optimize the farm, and/or silo certain users and/or applications on specific servers that are better provisioned for their memory needs.

Remote Desktop Bandwidth Usage

We’ve written at length about Remote Desktop Bandwidth consumption here and here, but many admins continue to be surprised at how much bandwidth RDP or ICA can use, depending on how it has been configured. Remote Desktop Protocol Version 8 and higher can double, triple, or even quadruple bandwidth use in certain use cases when UDP is enabled alongside TCP for transport. Moreover, if you permit transfer of files and screenshots via cut and paste, bandwidth can be consumed in a hurry. Since this has a significant impact on the user experience for others if RDP usage saturates the external Internet link, it’s important to see which users consume the most bandwidth, and what they are doing when they consume it.

Remote Desktop Connection Quality

If you’ve moved your RDS farm to Windows Server 2012 or later, you can now get a much greater handle on individual user session latency and “potentially available bandwidth” via new RemoteFX performance counters. This quickly lets you determine if user connection problems are on their end, or if many of your users are experiencing high latency due to a load or networking problem on your end. Unfortunately, these performance counters are not very easy to correlate with individual users, but fortunately, our Remote Desktop Commander Suite can do this automatically for you.

Leverage an Affordable Remote Desktop Performance Monitoring Solution

We’ve touched on four big remote desktop performance monitoring areas above. While Citrix provides some monitoring capabilities in its expensive, upper licensing tiers (via EdgeSight / Director), smaller shops running regular Microsoft Remote Desktop Services are not provided with built in monitoring tools, short of what an admin can script together with PowerShell. While you can look at upper tier monitoring solutions, the per concurrent user price of these tools are rather steep, especially as they are sold through the channel.

For only $9 per server per month, let our Remote Desktop Commander Suite offering monitor each of those areas for you. Please review our sample reports, demonstration videos, and feature listing now. Then, consider starting your subscription with us. With a 30-day money back guarantee and free initial support, you have absolutely nothing to lose.

Leave a Reply

Your email address will not be published. Required fields are marked *