Remote Desktop User Experience (Terminal Server) – solving slow performance issues.
Some companies and users experience performance problems in a Remote Desktop Environment (Terminal Server).
One application which impact Remote Desktop Server’s processing appears to be Internet Explorer as websites are more graphical and cpu intensive than ever, at any given time it’s able to use up to 12% per Tab per user. Internet pages such as THEAGE.COM.AU, NEWS.COM.AU or HERALDSUN.COM.AU are exceptionally heavy & use approximately 5% per Tab, regardless if the user is actually viewing the tab at the time. We have a large number of customers that are aware of this limitation & reserve personal browsing to either their local Internet Browser, or Mobile Devices.
The solution for the problems can be to either add additional processing power, reduce the processing power required or remove the Virtual Scheduling component from the Session Host. The methods we recommend for doing this is to split the users amongst additional session hosts or place the entire Session Host onto a new Physical Session Host.
It is possible adding additional Virtual Processors/Cores to the Session Host may help, however we have our reservations about recommending this approach due to Virtual Scheduling limitations.
Reported Problems Examples
- General slowness compared to full desktop experience (especially when users previously worked on a fast desktop running applications locally)
- Clicking between Emails within Outlook result in delays in seconds before the email is displayed.
- Websites within Internet Explorer are slower to display & navigate than the staff would (Response when opening Internet Explorer is one such example.)
- User Connections for Remote Desktop Services loose connection & can take a few moments before being able to Sometimes does not appear to affect multiple users at the same time.
- Network File Shares appear empty & may take several moments to show the
- Typing in various applications will display the text slowly, can take several seconds before it displays everything.
- Poor graphics
Companies use various types of computers, from Win 7, 8 & 2010 to Thin clients running Win 7 & 8 imbedded, propriatary or Linux based. Some companies are still using old XP machines.
We do find that the newer the desktop the better experience but this is hard to qualify. We advise customers buy one new machines and get the users to compare new to old.
High latency does cause issues with terminal server – eg 3g & wireless or slow ADSL 1 connections.
We highly recommend running cables to the desktop , Ethernet based internet.
We also highly recommending QOS on both LAN switching and WAN.
Virtualization limits that amount of users connecting to one Terminal server operating system to about 20-25 users.
Physical servers can have up to 70 users if configured correctly.
Although virtualization potentially allow you to support 100s of users onto one host by creating multiple Virtual terminal servers.
Old hosts for Remote Desktop Services.
Based on our experience with Remote Desktop Servers, high CPU utilisation is closely associated with poor user experience & matches the performance problems reported by staff. – We have found CPU overhead especially important when older CPU architecture is involved, the newer generations generally handle tasks more effectively & efficiently than older generations.
Our findings can point to old session hosts being the the cause of some problems. When the CPU hits 100% for a prolonged period of time, other programs take a number & sit in the background waiting to be scheduled… when these scheduling problems occur, new requests will not be processed until the queue is reset or empty.
Internet Browsers, whether it is a web based applications, or simply Internet browsing, when you have many users utilising the same Processors, this will always cause congestion, restricting the RD Session Hosts to just business browsing is the approach some organisations take, & use local browsers or mobile devices for personal browsing.
We understand this can be less than ideal, at times we’ve found alternate browsers such as Google Chrome do not have quiet as heavy processing footprint, however security does need to be considered & locking down Browser Add-on’s via Group Policy is recommended.
Windows Server 2008 was one of the last to have tools to limit the amount of processor a single user or application can utilise; we’ve applied this in the past to help remove unstable programs that thrash the Processor from affecting other users. This isn’t really an option I’m recommending as it generally has the side effect of slowing down individual users experience, in the later generations of Windows Server, they’ve removed these tools & worked on optimising the Application scheduling.
User education is also beneficial, recommending to users to ensure they close down browser tabs when they’re not using them can help to free up resources.
New Session Hosts.
Our companies experience with Remote Desktop Services on Virtualised hardware has found that once the Session Host reaches about 25 users the performance does not scale, regardless of how much resources you throw at the Virtual Machine. To overcome this limitation, we generally restructure our customer’s session hosts to approximately 25 users per guest. Majority of our Session Hosts have between 2 & 4 Virtual Processors / Cores assigned to them, with a varying amount of RAM. We’ve found when you reach the 4 Virtual Processor level the performance scaling drops considerably as you add more Cores, granted majority of our clients do utilise VMWare ESXi rather than Microsoft Hyper- V.
Depending on the number of users, operating with 1 Session Hosts per 25 users should provide ample performance. We do have concerns about the CPU utilisation for Internet Explorer as Multimedia rich websites continue to have a very high impact, however splitting across multiple Session Hosts will allow you to use more of the Physical Processing power effectively & should offset this considerably. With a second session host with 7 Virtual Processors/Cores assigned to each session host, this will increase Processing power.
Add more processing power.
It may be worthwhile adding all Physical Processors / Cores except two across to the Virtual Session Host. We have come across occasions where adding too many processors to a session host causes the Session Host to slow down considerably… VERY considerably… it is rare, but it does happen. If there were additional Virtual Guests on this server, I would not recommend doing this due to Virtual Scheduling limitations.
Adding Virtual Cores isn’t the only method of adding processing power, upgrading the Physical Processors to the latest generation & more powerful models can have a substantial impact on performance. Using the latest generation Hardware can have a major impact on user experience, potentially even more so than IO intensive Database servers on occasions. There are occasions where we’ve found the difference of 30% processing power per Virtual Processor/Core can have a substantial difference to the users experience.
Add SSD Storage
SSD storage for Remote Desktop Servers can assist with application responsiveness, however this depends on where the majority of the Data is stored (eg on another host or same host). It’s really only the opening
& closing of applications that benefit from local SSD storage and temp file access if profile stored locally.
When splitting up users amongst multiple session hosts, at times there are applications that are difficult to maintain due to aging software, poor quality upgrade paths, or simply due to OS impacting design. For these packages sometimes we find to publish these applications via Remote Desktop Services or Citrix an effective approach, this allows us to utilise a single Session Host to centralise the Applications & limit the amount of machines required to update when required. Ideally we only deploy Microsoft Office to the Remote Desktop Session hosts & applications that integrate directly with Microsoft Office whenever possible.
Physical Remote Desktop Server
Another approach to minimize bottlenecks for Remote Desktop Servers is to remove the virtualisation layer entirely. Physical Windows Servers perform well above what a Virtualised Server does in just about every way. We’ve successfully deployed multiple hundreds of users to single Physical Servers without any of the inherit problems faced by their Virtualised brethren. The main reason both us & our customers avoid this method is due to the added complexity with recovery, maintenance & deployment of these machines.
This solution is generally recommended when you cannot run multiple terminal servers due to limitations of 3rd party database applications (especially old type databases MYOB, Foxpro , Access & filemaker)
We have found that R2 2008 is better than 2008 R1, R2 2012 better than R1 2012.
We find users who are used to a Full Desktop Experience complain regularly when moving to a Remote Desktop environment, many of these problems can be minimised by over provisioning IOPS & CPU processing power, however generally speaking the cost doesn’t always outweigh the benefit.
For the absolute best Remote Desktop Experience, a physical Windows Server with SSD storage, plenty of RAM & multiple latest series high spec’d Processors cannot be beaten, however maintaining, securing & deploying physical servers, steer majority of both our customers & us away from recommending these as a solution. I mention this as some of the problems reported such as Application Responsiveness I don’t believe can be resolved completely whilst virtualisation is involved (although there are plenty of happy customers using Virtualisation).
Deploying a new Session Host & balancing the users across multiple servers will greatly improve the responsiveness of their user experience, & based on what I’ve seen, should virtually eliminate the drop outs users experience from time to time.
for more information email : firstname.lastname@example.org