English 
Vietnamese In this blog series I’m going to take a look at some of the scalability considerations for XenApp 6.5, including:
- Estimating XenApp 6.5 Hosted Shared Desktop scalability
- What’s the optimal XenApp 6.5 VM specification?
- XenApp 6.5 Hosted Shared Desktop sizing example
So first, let’s look at how you can estimate XenApp 6.5 Shared Desktop scalability.
In an ideal world, every project would include time for scalability testing so that the right number of optimally specified servers can be ordered. However, there are various reasons why this doesn’t always take place, including time and budgetary constraints. And often architects are asked to provide their best guess on the resources required to support a VDI environment.
I’ve been in this situation myself and I know just how stressful it can be. If you over specify you’re going to cost your company money. If you under specify you’ll reduce the number of users that can be supported – or even worse, you’ll impact performance.
To help improve hardware estimates, I’ve been looking at XenApp 6.5 scalability guidance by reviewing testing results from a variety of sources including customers, vendors and internal test teams. I documented the test results in a spreadsheet so that I could look for patterns between user density, workload and server specification.
The first thing I noticed is that the processor subsystem is always the primary bottleneck for XenApp 6.5. This isn’t that surprising as XenApp 6.5 is 64-bit only, so as long as you don’t mess up the RAM allocation you’re not going to run out of memory.
I also saw a lot of variation between the tests due to the number of processors, physical cores, processor speed, user workload, use of antivirus, management tools and whether the XenApp servers were hosting applications or published desktops. However, once I adjusted the results based on these factors, I could see a pattern emerge between the number of physical cores available and user workload:
Interestingly, the test results showed that the move from dual to quad processor servers is not linear and this has been accounted for by a 15% drop in user density per core – don’t get caught out by this!
The next step was to use this formula to estimate user density for some of the more common processor specifications out there:
So why are these estimates lower than normal? The reason is that I’ve made allowances for factors that aren’t always included during the scalability testing process – such as running antivirus, management software and monitoring tools. All of which have a significant impact on scalability.
One thing to keep in mind is that these estimates are based on the following conditions:
- The speed of the processors has a direct impact on the number of users that can be supported per processor. The estimates provided are based on a processor speed of 2.7 GHz.
- Hyperthreading has been enabled on the virtualization host.
- The light, normal and heavy workloads are not mixed within a virtual XenApp server or physical virtualization host.
- Flash redirection is enabled.
- It is assumed that all workloads include antivirus and standard monitoring/management tools.
- The recommended XenApp optimizations have been applied. For more information, please refer to the Citrix Knowledgebase Article CTX131577 – XenApp 6.x Optimization Guide.
- There are multiple definitions on what constitutes a light, normal, and heavy user. I’ve followed previous guidelines from Citrix:
- Light: One or two applications no browser-based activity.
- Normal: Multiple applications with browser-based activity.
- Heavy: Few applications but heavy system resource requirements. Data processing, compiling, or graphics manipulation are common applications.
Source: Citrix's Blog
***
Thank you for reading and look forward to your comments. Visit our website to find out more about Citrix Virtualisation Solutions.
Subscribe to our blogs to get great content delivered straight to your inbox!
