Setting up a VDI environment requires testing and verifying multiple components to verify the operation of our equipment before rolling out our implementation into a production environment. An important aspect of this testing phase deals with identifying the amount of virtual guest operating systems that each host is capable of handling. This is an important endeavor that must be taken in order to not overload our hosts and have our users suffer slow downs from performance degradation due to the saturation of our hosts.
An administrator trying to find out the amount of guests that a host can handle might mistakenly start creating multiple instances of vPCs and monitor the CPU as well as memory usage until it has reached the server capacity. This is not the best way of testing the capacity that a host can handle as there are many factors that are being overlooked. The issue with the above method is that our guests are sitting idle and are not simulating a workload that users in our enterprise might perform.
How can we go about automating a workload that users in our enterprise might perform on a daily basis? We want to come up with a baseline for this workload that would simulate the applications that our users in our enterprise will regularly use. This workload will have to be recreatable in order for us to have consistency in our testing when we decide to make changes to hardware, configuration, software, etc… and we want to test the effects that the changes will have.
LoginVSI is a desktop performance benchmarking tool that accomplishes this task for us. The LoginVSI benchmarking tool provides a set of preconfigured workloads that we can execute across multiple desktop configurations using a launcher station. We can use a workload that best matches the type of users in our enterprise that will be using vPCs. If we are deploying vPCs to replace public computer stations that are used for web access then we can simulate this type of usage using a light workload. Similarly, if we have vPCs replacing regular workers’ stations then we can simulate their usage with a medium workload. If we have unique user usage then we can also create a custom workload with the specific programs that are used in our enterprise.
A standardize user workload that we can execute across multiple vPCs gives us a recreatable testing environment for our benchmarking procedure. If we are interested in finding out the amount of guest that our host can handle when they are all executing a workload then we can do so with LoginVSI. LoginVSI will provide a VSIMax value that tells us the maximum amount of guest that a host can handle without users experiencing negative performance impacts due to saturating the host.
LoginVSi uses seven operations to measure the VSIMax. The measured operations by LoginVSI hit considerably different subsystems such as CPU (user and kernel), Memory, Disk, the OS in general, the application itself, print, GDI, etc… The response time of the operations are measures in milliseconds and when it reaches the threshold that is calculated by using the average of the first 15 guest then we have reached the VSIMax. Adding more clients than the value of the VSIMax will increate the response time to the point that our uses will experience slow downs and a negative experience.
For my testing procedure a host with the following specifications was used:
Manufacturer: Dell
Model: PowerEdge 2950
Processor Type: 2 x Intel Quad core Xeon X5460 @ 3.16GHz
Ram: Approximately 63GB
The guest was configured with the following configuration:
Operating System: W7 x64 SP1
Guest Memory: 2GB
Page File: 4GB Fixed
Processor: 1vCPU
Vmware View Optimizations
My results led me to conclude that this host was capable of handling 31 vPCs that used the above configuration when they were executing a medium workload. It makes sense that this number will be higher if a light workload is use and lower if a heavier workload is use instead.
Note: Keep the following in mind when reading the charts:
• Vertical axis: Response Time in milliseconds
• Horizontal axis: Total Active Sessions
• Red line: Maximum Response (worst response time of an individual measurement within a single session)
• Orange line: Average Response Time for each level of active sessions
• Blue line: the VSImax average (Typically VSImax is reached when CPU Utilization is around 100%)
• Green line: Minimum Response (best response time of an individual measurement within a single session)
37 vPCs:
The average of the first 15 sessions gave us a threshold of 4005 and we reached this threshold when 31 vPCs were executing the medium workload. As we added more the response time got worse and users would experience a degradation in performance leading to negative experience.
40 vPCs:
Test Run Demo: