Testing is knowing: Test your VDI environment to prevent unwanted surprises
The other day I was talking to a customer who was having some issues that he couldn’t solve himself. Because I’ve come across similar issues in the past, I wanted to share this one with you all. The customer was trying to test the performance difference between their XenApp environment and their XenDesktop environment. They had already concluded testing on their XenApp environment using 3 workloads, namely the Task Worker workload, the Knowledge Worker workload and the Power Worker workload. Once the customer switched over to testing the XenDesktop environment they ran into issues.
They saw that the Power Worker workload wasn’t generating as much load as they would expect. The Power Worker workload was generating significantly less load than the Task Worker workload. Which is weird because the Task Worker workload is approximately 20% lighter than the Knowledge Worker workload. The Knowledge Worker itself is about 20% lighter than the Power Worker workload. It is very weird to see the Power Worker workload generate less load than the Task Worker workload.
Please note that resource utilization shown is relative to the Knowledge Worker workload. The load generated by the Knowledge Worker workload is taken as the reference point and all other data points are relative to that.
Also, note that resource utilization shown in this diagram is what we see in our labs and are meant as an indication. There are many factors that influence the resource utilization as shown in this article.
The initial portion of the escalation focused on validating that the Power Worker workload was running as intended. A good chunk of the load in the Power Worker workload is generated from watching 720p videos. If the videos aren’t playing because they aren’t available or if there is a reason why playback isn’t working. However, the videos were playing fine.
Troubleshooting the VDI infrastructure
During troubleshooting we took a look at their XenApp results. Remarkably the results in the XenApp environment were like expected. Which was weird because the same VSI infrastructure was used for both tests. The only thing that changed was the environment that was being tested. That means that there wasn’t a configuration issue, missing files or bug with the VSI infrastructure. These would be the typical areas that we’d investigate for issues like these. Initially, we were expecting issues to arise in one of these areas. So, we decided to take a closer look at the Task Worker. Perhaps the Task Worker was generating too much load.
Office Worker saves the day
Going into the Task Worker workload we didn’t really know what we were looking for. So, we decided to simply watch the workload run with task manager running. Running task manager allowed us to watch the CPU utilization. During the test, we noticed that Excel was generating a high amount of CPU utilization when the virtual/scripted user was browsing through the Excel sheet. CPU usage never peaked to 100% but it was consistently around 40-50%. Since the Task Worker workload spends roughly 40% of its time on Excel that results in a massively higher resource utilization than expected from the Task Worker workload. A similar action in for example Adobe Reader only resulted in about 2-3% CPU utilization.
The customer’s XenApp environment didn’t show this behavior. So, the customer decided to run the Office Worker workload instead. As they didn’t want to invest any time in finding out why the XenDesktop environment was generating that much overhead using Excel.
The importance of testing your VDI environment
This is a good example of why testing any change in your VDI environment is important. The customer had a good idea of what the scaling was supposed to be but wasn’t expecting the Excel issue. This example also shows why it is important to test with an actual workload instead of more synthetic testing. The reason being that this issue would have never been revealed if the customer only ran synthetic testing.
Want to know more? We have several posts about testing your VDI environment: