Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have Windows server 2008 R2 (SP1) installed on my VMware Host to work as RDS server. Sometimes my remote users can see the lagging/delay on RDS server. Can anyone tell me from their experience what are the best practices to find the bottleneck for this server?

share|improve this question
What have you done to try to track down the latency? Are the clients on a local network? Network equipment composition? Do they all lag at the same time? Server resources; processor(s), RAM, disk? Performance monitor? Client versions, extension, RemoteFX? – Chris S Nov 19 '11 at 3:25
If you are running a TS, as a VM, then how many virtual CPUs did you assign? You may be better off with multiple VMs with a smaller number of CPUs. – Zoredache Nov 19 '11 at 5:43
Thank you for the suggestions. I have not done anything to track down the latency. Will try to figure out step by step... – Hemal Nov 21 '11 at 16:09
up vote 12 down vote accepted

As Chris S mentioned, there are several things that can contribute to poor remote desktop performance. From my experience, these are the main causes, in order of likelihood.

The #1 cause of poor performance with remote desktop is lack of bandwidth. Depending on exactly what is being done, a session can use anywhere from a a few Kbps to a few Mbps of bandwidth. My own tests have shown that scrolling through a PDF will use up to 3 Mbps. As available bandwidth decreases, so does perceived performance.

You first need to determine the bandwidth needs of your application. This requires testing in a controlled LAN environment, then measuring the bandwidth use as you perform normal tasks. I personally had success with NetLimiter on my personal workstation. You can also approach the problem from another angle, and use NetLimiter to force your connection speed down to whatever your WAN connection is rated at. This should give a good indication of what your remote users are seeing.

Once you know how much bandwidth your application wants, you need to determine whether it is the limiting factor. First, measure the available bandwidth between the client and the server. An excellent tool for this is iperf. I'll assume that you have sufficient bandwidth available during a controlled test.

Next, you will want to set up some kind of bandwidth monitoring to see whether user-reported problems correlate with spikes in traffic or other undesirables. My preference is to dump traffic from a switch or router into ntop, as it provides useful realtime and historic reports on bandwidth usage.

If you're encountering bandwidth problems, one easy change is to change the "Experience" settings on the remote desktop connection. Disable visual styles and animations, and many desktop operations will seem magically faster.

Another common issue with remote desktop connections is latency. There needs to be a reasonably quick round-trip time between the client and server, or people will be able to perceive a delay. As a rule of thumb, most people start to notice problems between 50 and 100 ms ping times.

Luckily, this is usually easy to diagnose. You can set up monitoring tools like SmokePing or PRTG Network Monitor to provide reports on the latency between your monitoring server and any other arbitrary host. You can even just use the built-in ping -t command for short sessions. Normally you want to locate the monitoring server on the same LAN as your remote desktop server, then set up monitoring against both the server and your clients. Try to correlate problem reports with incidents of high ping time.

If you're having problems with high ping times, use traceroute to find out where the delay is being introduced. If you determine that the problem resides within your own network, consider introducing QoS filtering to prioritize realtime traffic like Remote Desktop.

Also, be wary of anybody who is connecting over a wireless medium, whether that is 802.11 (WiFi), or worse, a satellite connection. Wireless connections are prone to environmental interference that can cause extreme latency problems under various conditions, and for varying periods of time. And using remote desktop through a satellite always sucks.

Local CPU or memory And finally, it's possible that your server is simply overburdened. Monitor the CPU and memory usage, especially during peak hours, to ensure that the server is capable of meeting requests in a timely fashion.

One of the tools mentioned above (PRTG) can be set up to monitor CPU and memory usage of a server over time, and can produce graphs that make it easy to correlate problem problem reports with specific faults.

Bonus tip: If your users are having trouble typing, especially with regard to modifier keys not applying properly, try changing your keyboard settings on the Remote Desktop connection shortcut so that Apply Windows key combinations is set to On the local computer.

share|improve this answer
Nice answer. I manage a farm of 20 TS servers and the 2 most common causes of performance problems that we see are the 2 you listed first in your answer: bandwidth and latency. These 2 factors have the greatest impact on performance (or perceived performance) in my opinion. My own testing showed that a user running several Office applications, IE, and opening PDF files consumed an average of 100Kbps over an 8 hour period. That's what our planning number is in terms of bandwidth allocation per user and that's what we recommend our customers have in order to have "well performing" sessions. – joeqwerty Nov 19 '11 at 4:34
Hi Nic, Thank you very much for the nice detailed answer. I will go through it and will try to figure it out.. Thanks a bunch for the answer. Thanks to Joeqwerty also for comments.. – Hemal Nov 21 '11 at 16:12
I manage a small farm and I agree. We also use PRTG to look at see if historic data matches reported issues. Our number two issues are bandwitch (local/ISP issues) and CPU (bad programs on low core count servers). The best way to quickly see if it bandwidth is to ask the users if text input seems to lag. – Gomibushi Jun 4 '12 at 7:26
You mentioned a lot of great tools, but how much of a sessions bandwidth requirements can be gathered through WMI? or even better performance counters? I'm new to TS, but been tasked to surface various stats on a session. Thks in advance for your time. – codputer Jul 18 at 21:13

Check out the RDS Best Practises Analyzer.

share|improve this answer
Thank you Mitch.. – Hemal Nov 21 '11 at 16:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.