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
With XenApp and previous versions of XenDesktop, the database was just the storage repository for static information. We really didn’t spend much time thinking about the impact of the database on production environments. The databases were small. They databases didn’t have a big impact on the underlying system. So what about XenDesktop 5’s SQL Database? Let me just say that the database is now the King.
What happens if you don’t plan your database appropriately? How about this:
- You run out of disk space
- You have a XenDesktop environment that fails
- You have poor enumerating and launching performance
I’m not trying to be an alarmist, but I want to make sure that everyone doing a XenDesktop 5 design spends enough time focusing on the importance of the SQL database instead of brushing it aside like we all did in previous versions.
Let me give you some stats to help you understand how the database might impact you. First, you must understand that the database contains all of the information about the XenDesktop site. It knows who is logged in, where, how long, resources in use, desktop states, etc. Anytime something changes within the site, the database is updated. Plus, in order to validate that the previous information is correct, there is a constant heartbeat within the environment. This helps provide a better fault tolerant infrastructure. But this comes at a price. Let’s run through a few examples:
- A XenDesktop site with 20,000 defined desktops will consume 250MB of space within the database.
This isn’t very large and shouldn’t bother us too much… right? True, the database is small, but what about the transaction log?
- Ten defined desktops in a site are idle for 24 hours will consume 14.5MB of space in the transaction log
Now that is interesting. Multiply this by 20,000 desktops and your transaction log for 24 hours (idle) is 29GB!!!! Hopefully that caught your attention. But all is not lost. You can use the “Simple Recovery Method” in your database configuration to keep the file small, but you do lose the ability to do SQL Mirroring. If you want to mirror, just do more frequent full backups of your database, which will also help to keep the transaction log small.
The point is you don’t want to be caught off guard with a SQL Server out of disk space. You can manage the transaction log, but you have to be smart about it.
If you want to know more, check out the Planning Guide: SQL Database in the XenDesktop Design Handbook. This is a great article you want to be aware of.
Daniel – Lead Architect