5 Best Practices for VDI Workload Customization with Login VSI
Applications, applications, applications… The most important part of the user’s desktop are the actual apps and therefore also the most important part of the Login VSI workload. In this blog I will share five important best practices when adding applications to your VDI performance tests with Login VSI.
1. Start with out-of-the-box workloads
A lot of customers ask us “What if I only want to test with my own applications?” No problem, you can do this but to make your life easier Login VSI is shipped with many out-of-the-box applications such as Microsoft Word, Outlook, Excel, Internet Explorer, PowerPoint, Adobe Reader, Java applications etcetera. Basically, generic office user workloads in different flavors. We offer these standard workloads for two reasons.
- To make sure that you can start testing right away.
- That you can perform a high-quality test that you can compare to the rest of the world.
It sounds nice to only add your own applications but it will take you some time, and that’s why we always recommend to first start with the default workloads. This way you can make sure that everything works before adding you own applications.
From experience the amount of things that you can already uncover with Login VSI’s default applications will already help you to improve your virtualized desktop environment. That’s awesome because then you don’t even have to invest in any workload customization right away.
Login VSI’s out-of-the-box workloads use the most common applications
2. Do not add every application
Some of our customers have virtualized desktop environments with thousands of applications. I frequently hear the question “If I have a thousand applications, do I need to add them all?” My simple answer would be: No, you should add a lot less. It’s important to look at the apps that are most frequently used by the majority of your end users such as Epic, Cerner or SAP. 80% to 90% of your users will use those applications.
When selecting applications, I always like to stick to a common application, and I always add a virtualized application, typically App-V or ThinApp, to be sure that the virtual infrastructure is also working and can handle the load. And when you ask the IT guy, there is always this one application that his gut feeling says not to trust. I’d usually also add that one too. There is not really a scientific reason for adding that specific application other than just making sure it doesn’t explode in your face.
So the trick is to add custom applications one by one and of course you can have ten or twenty if you really want to do this. Nothing is preventing you from building a complicated workload with a high diversity of applications and actions, and it can be extremely worthwhile, but make sure to do this step by step. Don’t try to add them all at once because this will make your life much more complicated.
3. Choose simple workload actions
Select the most important applications, but when you start adding actions, be realistic there as well. First, configure the workload to start the application, logon, and do some basic interaction and move on to the next application. You don’t have to add a thousand steps immediately to test these applications. From practice we’ve learned that more steps in the application will not impact the test results so much in comparison to a couple of steps, and it does save you a lot of time.
4. Do not add “modify, update or create new records” workload actions
With Login VSI, you are usually performing tests at scale. One strategy for customized complicated applications to keep in mind is to choose workload actions that do not modify, update or create new records in your database. Make sure that your Login VSI workloads stay in some sort of “viewing” mode where you only do queries or browse through data and generate a report that is just copied locally in the home drive. These are activities that don’t change the database but they do hit the application, also the backend, and they are really easy to replicate at scale.
When you are running in production mode with Login PI, then you can choose to have far more complicated workloads scenarios where you do business workflow modelling and simulate real users that also add records. But this is only suitable for a couple of users and not for thousands of users like simulated by Login VSI. It’s important to make that distinction to keep your life simple as a testing engineer, especially at scale.
5. Test your new workload by running a small number of sessions
Now that you have created a new workload it is recommended to run the test with 1 – 5 sessions in order to make sure it runs as expected. Running with just a few sessions allows the test to happen quickly and cleanly so you can get your feedback about how well the workload ran.
I hope that you enjoyed reading this blog. In case you have any questions about workload customization, do not hesitate to reach out to me via @MarkPlettenberg.
Ps. this blog might be interesting to you as well: A hidden gem for Login VSI workload customization: Problem Steps Recorder in Windows