I’m sure we’ve all heard it! “Citrix is slow”. Truth of the matter is, if you setup your Citrix environment correctly in the first place you should not have any performance issues related to Citrix. Having said that, you can be at the mercy of slowness related to the infrastructure used for hosting your Citrix environment. In order to reduce the possibility of the slowness being caused by your Citrix setup, there are a few recommended settings that in my experience can improve performance:
VDA Adapter Properties
On your session hosts\VDAs ensure your adapter advanced settings are configured as follows (those in bold):
IPv4 Checksum Offload = Disabled
IPv4 TSO Offload = Disabled
Large Send Offload V2 (IPv4) = Disabled
Large Send Offload V2 (IPv6) = Disabled
Offload IP Options = Disabled
Offload tagged traffic = Disabled
Receive Side Scaling = Disabled
TCP Checksum Offload (IPv4) = Disabled
TCP Checksum Offload (IPv6) = Disabled
UDP Checksum Offload (IPv4) = Disabled
UDP Checksum Offload (IPv6) = Disabled
I was recently asked why the above settings should be set. I don’t believe Citrix have a documented reason but the short of it is, to improve performance 🙂 Without getting into each setting, the little bit longer of it is that these settings handle how the traffic for Citrix sessions are handled on the hosts.
For example, directing traffic handling to use the hosts CPU rather than using the network stack resources. Ensuring TCP and UDP traffic is not processed by the network controller. Also, setting to handle a TCP connection’s processing on a single core rather than spread across multiple cores.
UPDATE: I received this recommendation from Trentent Tye:
Something to reconsider is enabling RSShttps://t.co/Y1DKWCQTwQ
PVS is traffic heavy. Without RSS it could be artificially limited.
— Trentent Tye (@TrententTye) August 13, 2017
Network Provider Order
Also on the host\VDA, ensure the Citrix Client Network is first in the Provider Order.
You can access this by going to Network Connection in Control panel, hitting Alt on your keyboard and going to Advanced–>Advanced Settings. Changing these settings requires a reboot.
Similarly, if possible also ensure Citrix Single Sign-on is first in the Provider Order on the clients. Many vendors will recommend their product be top of the order, so this may not be possible. Setting this on end user devices will likely need to be set centrally, this can be done via the registry e.g. HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order. Again, a reboot will be required. This can also be set via Group Policy.
Citrix Recommended Hotfixes
Citrix provide a list of recommended Citrix and Microsoft hotfixes which can be crucially important. Many Microsoft RDS related hotfixes can have a significant impact on the performance of your VDA. Check out the list of hotfixes for Server 2012 R2 HERE.
Beware the Web Proxy
In an environment I worked in recently, we discovered several launch issues which were being caused by heavy NetBIOS traffic on the client devices. We detected this using a simple Wireshark trace on clients exhibiting the issue and filtering the output to show nbns. In some cases NetBIOS packets accounted for up to a third of all packets on the client! The slowness was not just experienced on launch either; if you reset the Citrix Receiver the desktop shortcuts would come back very, very slowly and one at a time rather than all at once. Disabling NetBIOS on the client appeared to resolve the issue BUT this was not a fix. It appeared that the traffic was related to WPAD. Setting up a WPAD server did resolve the issue but was not required, this issue is best handled by your network team. They should know how to best handle this for your network.
Firewall and AV
This one is a little less black and white. There are of course recommended policies, such as for printing performance but policies are a very org specific thing. Carl Stalhood has a great article about policies HERE. A somewhat obvious pointer is to ensure your AD is not a mess! Both from an infrastructure perspective (how many domain controllers in your environment, where are they located, are they working well? How about replication?) and what is the health of your accounts\groups and group policy objects?
If, say for example you have a tonne of group policies which need to be filtered through on each login, of course this will result in a slow launch for users. Not just in Citrix but if they go to use any desktop for the first time, they will experience slow logins that’s just how it works!
Profiles and Resource Management
Manage your profiles!! Do not rely on roaming profiles, if a user stores several GB of data in their profile it roams with them. Each time they launch a Citrix session that brings them to a new machine it will result in that data being brought across the wire for that user. Not only resulting in a slow login for that particular user but also possibly causing slowness for other users too. For more on this, check out this article: https://support.citrix.com/article/CTX120285, I also recommend checking out Hal Lange’s great video series:
The above is just one video but this tool can help with managing user data and also even optimize application performance with neat process priority management! This can ensure your critical applications keep humming along even if the resources on a server are being taxed.
For the love of god, do not use Active Setup with your applications! If you are using an appvirt product such as App-V, follow industry best practices to ensure optimal performance. Check out .NET optimization? What is your app packaging standard? Do you use App Paths? Check it out!
A popular new addition is the Connection Quality Indicator which can give a quick view into connection performance. You can read more about this HERE. If you are receiving complaints of slowness or even dropped connections, this is a great place to start when troubleshooting.
As recommended by Trentent Tye, if using VMware Tools, you should be on 10.1.7+ for a fix for a known RSS bug.
Know Your Load
When setting up your Citrix environment you should have based your number of delivery controllers, session hosts etc. based on the capacity required to effectively support your user base. Part of that process should have been configuring your paging file on the session hosts by launching all applications and getting a good baseline. This is all fine and well. You can prepare as best you can but there are many usage variables which will be out of your control and impossible to predict. You cannot know how your users will use the applications at all times.
For example, I once worked in an environment in which we published Word to a subset of users. This was for working with an application that interacted with Word and was required for supplying documents to a Government agency. They also needed access to Word standalone for working on the documents outside of the parent app. It was critical and required. What was unknown was that one of the users who had been published word decided one day that she wanted to run a mail merge for tens of thousands of addresses. It brought one of our hosts to it’s knees.
Another example may be finance users only doing their intensive work at the end of a quarter or fiscal year. Or even employees possibly accessing a resource published in XenApp when it’s time to file their taxes.
Another example, a place I worked used an application that was all encompassing. Everybody used it and they all used different features. The application was published across hundreds of hosts. Some of the users used a feature to look at real time video being presented via an attached device. This could impact performance for others who happened to have a session on the same host and if multiple users on the same host just happened to be running this type of video, forget about it!
Obviously vGPU can help for the latter but I’m trying to highlight the unpredictable nature of usage. Some of this usage information can be gathered with a solid request form when a department requests an application to be published. A good monitoring solution such as ExtraHop Discover, Splunk w/ UberAgent, Goliath Performance Monitor etc. can help you get ahead of these exceptional cases and can provide invaluable data for troubleshooting pretty much any and all potential performance issues you may encounter.
Vendors such as ControlUp, LoginVSI and Goliath also have “logon simulator” or “application simulator” products which allows you to run a test load in your environment to see potential performance issues related to load before it ever occurs in production.
To read about general IT problem solving, check out the article HERE.
Note: This blog post will continue to grow as performance is a hot topic and is also something which is always in flux. Also, I likely forgot some 🙂