Currently I am at a customer that uses RES Workspace Manager on Windows Server 2008R2 XenApp servers.
Because lots of users logon to your XenApp servers, one can consume all the resources on the server. Thankfully Microsoft and Citrix both have their own technologies to prevent users from eating up all the resources. Both Microsoft and Citrix say that if using XenApp 6.x you should use either Dynamic Fair Share Scheduling (Microsoft technology) or Citrix CPU utilization (Citrix Technology).
Most customers I work at that use RES Workspace manager have disabled Citrix CPU optimisation, but still use RES Workspace Manager CPU optimisation on top of Dynamic Fair Share Scheduling.
The goal of this set of articles is to answer the following questions:
- Do we need RES Workspace Manager CPU optimisation on top of Dynamic Fair Share Scheduling?
- Which technique should we use? (RES or MS?)
- Do we even need resource sharing in this modern age?
To answer the above questions I will be using LoginVSI 126.96.36.1994. The tests are run at the customer, which has the following specs:
- HP Proliant DL308p Gen8
- dual Xeon E5-2640
- 65 gb Memory
- DAS for the VM disks
The software configuration:
- Vmware vSphere 5.1.0 (2000251)
Virtual Machines running:
- 3x XenApp 6.5 worker
- 8 vCPU
- 16 GB memory
- XenApp 6.5
- RES Workspace Manager 2014 SR1
- RES Automation Manger 2014 agent
- Office 2010
- AppV 4.6 SP1
- Adobe Reader X
VSI workload: Officeworker
- On NetApp filer
Before I will go into the technical stuff, first let me start off to explain a little about what the different kinds of technologies do.
RES WM CPU Optimization
This particular technology doesn't really optimize the CPU, in that way it is a little misleading. What it does, is if a process in a user session goes above a set threshold for a set period of time it sets the process priority in windows on low priority. Windows will give the process less CPU cycles then other processes on the server. This has a side effect on the user side, a user may experience "hung" applications, or inresponsive applications. On the server side the results are that you can handle more users on your server, because one user can't claim all the CPU cycles to themselves.
Dynamic Fair Share Scheduling
Fair Share CPU Scheduling is a new feature included with Remote Desktop Services in Windows Server 2008 R2. Fair Share CPU Scheduling dynamically distributes processor time across sessions based on the number of active sessions and load on those sessions by using the kernel-level scheduling mechanism included with Windows Server 2008 R2. On an RD Session Host server, one user will not affect the performance of another user's session, even if the RD Session Host server is under a high load.(Source: Microsoft)
Citrix CPU Utilization Managment
The CPU utilization management feature can be used to improve the ability of a farm to manage resources and normalize CPU peaks when the farm’s performance becomes limited by CPU-intensive operations. When you enable CPU utilization management, the server manages the share of the CPU allocated to each user. By default, this is an equal share. This prevents one user from impacting the productivity of other users and allows more users to connect to a server. This feature allows you to control the share.
- CPU reservation is a percentage of your server’s CPU resource that is available to a user. If all of a reserved allocation is not being used, other users or processes can use the available resource, as needed. Up to 20% of the work capability of a single CPU on a server is always set aside for the local system account and is not available to users.
- CPU shares are percentages of the CPU time. By default, CPU utilization management allocates four shares for each user. If two users are logged on to a server and the local system account does not need any of the resources on the system, each user receives 50% of the CPU time. If there are four users, each user receives 25% of the CPU time.
So far the background about the differnt kinds of technologies, the reasons why I am going to blog this series.
Stay tuned for the next post, which I hope to be able to do soon, but first I need to repair my RAID set :)
Please feel free to discuss, call me mad, give feedback or what so ever.
Ok so a little update. The second post in this series is taking up some time, because we are remoddeling our house and I cannot access my lab server at the moment.
I have purchased a samsung 1 tb SSD to host my VM's because I was seeing a performance degradation due to IO misbehaviour, probably due to SATA/RAID issues. Have updated the post above to reflect the new test setup.
Little update again. Remoddeling is taking a little longer. I have performed the tests on an isolated server at the customer. Updated the article with all information.