Citrix: XenDesktop Planning Guide – XenDesktop Scalability

Citrix just released the XenDesktop Planning Guide – XenDesktop Scalability and these are the results (also from the PDF):

Desktop Controller SQL Database
Type Physical server Physical server
Operating System Windows 2008 R2 Windows 2008 R2
Product Version XenDesktop 5 SQL Server 2008 SP1
# of CPU Dual, quad core 1.86Ghz Dual, quad core 1.86Ghz
Memory 16 GB RAM 16 GB RAM
Disk Single SAS drive (10,000 RPM) Fibre Channel
Vol 1: SQL temp DB
Vol 2: SQL install and DB
Number of servers 2 servers 3 servers (Principal, Mirror, Witness)
Configuration Information Power management disabled Synchronous database mirroring with automatic failover
Desktop Load 20,000 simulated desktops 20,000 simulated desktops
Boot Storm 40-50% CPU utilization during the virtual desktop registration process 15-25% CPU utilization across the SQL principal database
(20,000 desktops in 10 minutes) 5-10% for SQL mirror
The SQL witness was essentially idle.

 

 

XenDesktop Controller SQL Database
Type Virtual Physical server
Operating System Windows 2008 R2 Windows 2008 R2
Product Version XenDesktop 5.0 SQL Server 2008 SP1
# of CPU 2 vCPU Dual, quad core 1.86Ghz
Hypervisor host: Dual, Quad core 2.26Ghz
Memory 4GB RAM 16GB RAM
Disk 30GB image on NFS share 34GB Local Hard disk
400GB FC disk (Database)
Number of servers 2 servers 3 servers (Principal, Mirror, Witness)
Configuration Information Power management disabled Synchronous database mirroring with automatic failover
Desktop Load 2,500 desktops 2,500 desktops
Boot Storm 10% CPU utilization during the virtual desktop registration process No data available
(2,500 desktops in 4 hours)
Logon Storm 12-15% CPU utilization during user connection process No data available
2,500 connections in 30 minutes)
User Perception Launch and logon operations averaged 2.5 seconds for all 2,500 users

The key when planning the XenDesktop site configuration is to follow these recommendations:

1. N+1: Always make sure there is extra capacity in the event that a single controller fails. If two controllers are required to support the user/desktop load, three should be implemented.

2. Estimate: Based on the boot storm, logon storm and hardware selected, create a rough estimate based on the above examples. The following can be used as a rough estimate when CPU resources are dedicated to the controller:

a. Desktop registrations per minute per dedicated core: 125-180 desktops

Assumes the desktops are delivered via Provisioning Services and that the controller’s CPUs are not shared with other virtual servers.

b. Logons per minute per dedicated core: 100-120 users

Over-committing a controller or SQL database will make the initial user launches slower than if the resources are under-committed. Additional resources can be added easily to overcome estimation discrepancies.

Sharing vCPUs will have an impact on overall scalability as those cores are not 100% dedicated to controller activities. Care must be taken when virtualizing controllers with other virtual servers.

3. Monitor: The most important thing is to do is to monitor the resources. The following are recommended metrics to observer the Controller scalability as well as the user experience:

XenDesktop Controller
CPU Process Utilization
Citrix XML Service Enumerate Resources (Avg Transaction Time)Validate User Credentials (Avg Transaction Time)

Launch Get Address (Avg Transaction Time)

Launch Get Logon Ticket (Avg Transaction Time)

Note: Disk and network utilization were negligible during the tests for the XenDesktop Controllers.

As we can see the Desktop Controller is very scalable and provides good leverage to design and build large farm without performance degradation. Keep in mind that these are tests in a controlled environment and should just be used as guide lines, so testing should be done at site and depending on the customer configuration and requirements.

The following two tabs change content below.

Kees Baggerman

Kees Baggerman is a Staff Solutions Architect for End User Computing at Nutanix. Kees has driven numerous Microsoft and Citrix, and RES infrastructures functional/technical designs, migrations, implementations engagements over the years.

Leave a Reply