Simulating VDI Users – Introduction to Login VSI Workloads
Most people describe Login VSI as a “load generator”, but I don’t feel this actually does it justice. The main differentiator between Login VSI and other load testing solutions is the fact that Login VSI generates load on a virtualized desktop environment by using virtual users to simulate the same behavior as your real users, instead of just static load. There’s much more to consider when simulating those pesky and unpredictable humans. This enables any IT department to test the real-life impact of changes on the maximum capacity of their VDI environment without having to use (and bother) their real users.
To help you better understand how this actually works, I figured that it would make sense to write a blog post about the most important part of a Login VSI test, the virtual users, and the instructions they use to do their thing… the workload.
What is a workload?
For the most part a Login VSI Workload is a set of actions that are executed by the virtual user. These workloads perform operations intended to:
- Determine a baseline performance level.
- Execute a standard set of functions that allow for an objective performance measurement of the hosted desktop or application in order to determine VSImax.
- Execute a custom set of functions that allow for the use of any Windows application to be used to measure performance and stress the system.
What are the components of a workload?
Login VSI workloads consist of a number of different functions.
The workloads included with Login VSI are each comprised of 5 segments. The first prepares the user environment and the other 4 run the applications and timers. Workloads can be created or modified to include fewer segments or more segments.
Sets up the virtual user’s environment to eliminate unexpected or unwanted actions that may occur and cause the session to become stuck. This includes but is not limited to operations like setting file type associations, disabling popups, and setting security to allow for VSI applications access to the VSIshare.
The Login VSI Timer function uses native Windows applications and operations to determine system saturation and provides Login VSI with information necessary to evaluate the user experience. These operations are intended to stress and measure the host system’s resources like CPU, Memory and Storage. Without the Login VSI Timer function, there would be no VSImax or VSIbaseline measurements to determine the quality of the user experience. Timers are kicked off at a regular frequency and typically there will be a timer execution every 3 – 4 minutes. More detailed information about Timers, VSImax and VSIbase can be found in this blog post.
4. Application Actions
The application actions within the workload will use a number of functions to mimic human behavior of using the applications. These functions include but are not limited to the following: Open file, save file, close file, copy file, delete file, Print to PDF, Scroll, Compose and send an email, Watch videos, Edit Excel cells, Type fixed and random text.
Humans are unpredictable and typically very random. Login VSI workloads do operations like typing random text as well as copying and opening random files to keep systems from caching repeated activities which could give a false sense of performance. Each workload is typically composed of multiple segments, each of which may use different applications in different orders. When testing with many users, the workloads will start with different segments in the workload and loop back around during the test. To simulate multiple, different types of users in the same test, it is possible to do what is called a ‘workload mashup’. For more information about workload mashup check out this blog post.
6. Idle Time
Unlike some benchmark software, humans don’t operate at a system’s CPU speed and they also take breaks. Wait times and idle times are also built into workloads to simulate a human’s natural click and typing speed as well as built-in bathroom and coffee breaks.
30 user sessions simulated by Login VSI
While the baseline is not necessarily a predetermined workload component, it is a phase in the test that is important in determining user experience and the calculation of VSImax. As the Login VSI workload starts up, measurements are taken on the system in an optimal state, prior to becoming saturated with a large volume of user activity. This baseline is used to calculate the best user experience as well as the threshold for VSImax—the point at which the system becomes so saturated it no longer provides a good end user experience.
What applications are used in default workloads?
Login VSI offers by default four flavors of workloads without any need for scripting:
- Task Worker: Microsoft Word, Microsoft Outlook, Internet Explorer, Adobe Reader, Microsoft Excel
- Office Worker: Microsoft Word, Microsoft Outlook, Internet Explorer, Adobe Reader, Microsoft PowerPoint, Microsoft Excel, Photo Viewer
- Knowledge: Microsoft Word, Microsoft Outlook, Internet Explorer, Adobe Reader, Microsoft PowerPoint, Microsoft Excel, Freemind / Java, Photo Viewer
- Power Worker: Microsoft Word, Microsoft Outlook, Internet Explorer, Adobe Reader, Microsoft PowerPoint, Microsoft Excel, Freemind / Java, Photo Viewer, Simulated application install.
NOTE: For many of the applications in power worker, larger files and higher resolution media will be used.
Login VSI offers by default four flavors of workloads
What makes the workloads different?
While many of the applications listed above are the same between workloads, each one, from Task Worker to Power Worker becomes increasingly aggressive while continuing to maintain the behavior of the type of user the workload is named after. One of the things that makes the workloads different in terms of their aggressiveness is how many of the applications are run concurrently, or within the workload segment (see above).
In our labs at Login VSI, we have run each of the default workloads against a specified hardware environment, virtual machine configuration and set of users. During this test we observed differences in the impact to the system and behavior of the workload. Below you will find a table that helps to identify the behaviors of the different workloads.
NOTE: These values will be different depending on the hardware used, virtual machine optimizations and user concurrency. The information provided below is only provided to help you understand how they behave relative to each other.
|Workload Name||Login VSI Version||Applications Opened||Estimated CPU Usage||Estimated IOPS per user||Typical VM Memory Profile||Typical VM vCPU Profile|
|Task Worker||4.1+||2-7||70%||6.0||1.0 GB||1vCPU|
|Office worker||4.1+||5-8||82%||8.1||1.5 GB||1vCPU|
|Power worker||4.1+||8-12||119%||10.8||2.0 GB||2vCPU+|
Other types of workloads
Login VSI workloads can be customized to add any line-of-business applications our customers wish to have the virtual users operate. My colleague Mark recently wrote a great blog with 5 best practices for workload customization. In addition, Login VSI also offers a storage workload designed to stress the storage subsystem as well as a graphics framework that is designed to stress the graphics resources like CPU and GPU.