When we last looked at XenDesktop 5 scalability, we really focused on the user experience in that users should not be required to wait longer than 2.5 seconds before the system responded to an authentication or launch request. We said that if the controller got very busy due to logon storms, we could add additional controllers to help lower the overall load and get us back to that 2.5 second goal. But guess what? The 2.5 second goal might require that we look at other aspects of the XenDesktop 5 architecture beyond the controllers. We already looked at the maximum size of a XenDesktop controller, so th next thing to look at is how big can a XenDesktop 5 site become?
We can keep adding controllers, but won’t we eventually hit a site limit? If the controllers “talk” to the SQL Database for pretty much every transaction, we want to make sure that the database server is designed appropriately to support the storms. We could easily run into an instance where the controllers are functioning well below thresholds, but the user experience is still poor. We need to take a look to see if we allocated enough resources to make sure that the SQL database is not bogged down.
The SQL Database is the heart of a XenDesktop 5 site. Here’s the good news… Databases are built for transactional type processes, and that is what XenDesktop 5 is using the SQL Database for. We should be able to see some crazy scalability numbers and with testing being conducted, we are.
For example, I’ve seen one test that simulated 20,000 logon connections in 13 minutes (25 new requests per second). An 8 core, 16GB RAM dedicated SQL Server consumed 32% CPU utilization. This is a fairly sizable logon storm. Even if you extrapolated this out, you should be able to get an insane size of a single XenDesktop site. I haven’t seen anything in production at this size yet on XenDesktop 5, but things are looking very promising.
As you would expect, once you are running, you need to monitor the database server (especially if you are sharing this database with other database or services). At a high level, focus on the standard items:
If you need to drill down more, due to performance issues, this is when you need to be looking closer at the SQL Server metrics:
- Buffer manager
- Memory manager