VDI Profiles used in Sizer
Sizer relies on Login VSI profiles and tests. Here are descriptions about the profiles and applications run
Task Worker Workload
- The Task Worker workload runs fewer applications than the other workloads (mainly Excel and Internet Explorer with some minimal Word activity, Outlook, Adobe, copy and zip actions) and starts/stops the applications less frequently. This results in lower CPU, memory and disk IO usage.
Below is the profile definition for a Task Worker:
Knowledge Worker Workload
- The Knowledge Worker workload is designed for virtual machines with 2vCPUs. This workload contains the following applications and activities:
- Outlook, browse messages.
- Internet Explorer, browse different webpages and a YouTube style video (480p movie trailer) is opened three times in every loop.
- Word, one instance to measure response time, one instance to review and edit a document.
- Doro PDF Printer & Acrobat Reader, the Word document is printed and exported to PDF.
- Excel, a very large randomized sheet is opened.
- PowerPoint, a presentation is reviewed and edited.
- FreeMind, a Java based Mind Mapping application.
- Various copy and zip actions.
Below is the profile definition for a Knowledge Worker:
Power Worker Workload
- The Power Worker workload is the most intensive of the standard workloads. The following activities are performed with this workload:
- Begins by opening four instances of Internet Explorer which remain open throughout the workload.
- Begins by opening two instances of Adobe Reader which remain open throughout the workload.
- There are more PDF printer actions in the workload as compared to the other workloads.
- Instead of 480p videos a 720p and a 1080p video are watched.
- The idle time is reduced to two minutes.
- Various copy and zip actions.
Below is the profile definition for a Power Worker:
Developer Worker Type
Sizer does offer Developer profile which is assumes 1 core per user (2 VCPU, VCPU;pCore = 2). Use that for super heavy user demands.
Below is the profile definition for a Developer:
What is strength and weaknesses of Profiles
Strengths
- LoginVSI is the defacto Industry standard VDI performance testing suite. That offers ability to have common terms like “knowledge worker” .
- Test suite was run on Nutanix-based cluster and number of users were found with reasonable performance. From there we could build out the profile definitions in Sizer and this is based on lab results.
- Things were setup optimally. Hyperthreading is turned on and the cluster is set up using best practices.
- It does a good job of not only having mix of applications but having different workload activity as add more users. For example, how frequently applications are opened and so it does simulate having multiple users in real environment.
- Essentially the “best game in town” to getting consistent sizing
Weaknesses
- In the end VDI is a shared environment and sizing will depend on the activities of the users. So if three companies have 1000 task workers, each company could have different sizing requirements as what the users do and when will vary.
What are other fctors Sizer considers for VDI sizing:
Common VDI sizing parameters: (Across all VDI Brokers)
Windows desktop OS and Office version:
Depending on the OS and Office version type, there are performance implications and cores are adjusted accordingly.
The below table has the adjustment factors for cores depending on the Windows OS:
| Version | Factor |
| No adjustment | 1 |
| Windows 11 – 22H2 | 1.3915 |
| Windows 11 – 21H2 | 1.334 |
| Windows 10 – 22H2 | 1.1845 |
| Windows 10 – 21H2 | 1.219 |
| Windows 10 – 20H2 | 1.219 |
| Windows 10 – 2004 | 1.15 |
| Windows 10 – 1903/1909 | 1.135 |
| Windows 10 – 1803/1809 | 1.1 |
| Windows 10 – 1709 | 1.05 |
The factors above include performance hits from Spectre and Meltdown updates.
Similarly, the below table has the adjustment factors for cores depending on the Windows Office version:
| Office 2010 | 0.75 |
| Office 2013 | 1 |
| Office 2016/2019 | 1 |
Display Protocol:
Depending on the VDI broker, there are the following Display Protocols:
VMware Horizon View:
- Blast(default)
- PCoIP
Citrix Virtual Desktop:
- ICA(default)
Frame:
- Frame Remote Protocl(FRP)
There are adjustment to cores depending on the selected protol for the respective VDI brokers as follows:
| ICA | 1 |
| PCoIP | 1.15 |
| Blast | 1.38 |
| Frame | 1.45 |
Sizing equations for Cores/RAM/Storage:
Cores:
| Cores | users * VCPUs per user * (1 / (Vcpu per CPU) *125% if V2V/P2V * 85% if 2400 MhZ DIMM |
| Note this change | If provisioning type is V2V/P2V then need to increase cores by 25%, due to change this provisioning. Now default is Thinwire video protocol and that causes 25% hit. If H264 then no hit. We will assume the default of Thinwire is used as Sizer user probably does not know. |
RAM:
| RAM | (users * RAM in GiB / user * 1/1024 TiB/GiB) +
(64MB * users * conversion from MB to TiB) |
| Note this change | a. First part finds RAM for user data
b. Second part calculates reqt per VM which is user |
| Note: Hypervisor RAM will be added to CVM RAM as one Hypervisor per node |
SSD:
| For VDI workload, the rule to calculate SSD is as follows:
SSD = hotTierDataPerNode * estNodes + goldImageCapacity * estNodes + numUsers * requiredSSD, where hotTierDataPerNode = 0.3 GB converted to GiB , estimatedNummerOfNodes = ( max (1, cores/20) ) where cores is calculated cores, goldImageCapacity as per selected profile numUsers as received from UI, requiredSSD – 2.5GiB for task worker, 5GiB for Power user/Developer user, 3.3GiB for Knowledge worker/Epic Hyperspace/ Hyperspace + Nuance Dragon, |
|
| (0.3 GB* 0.931323 GiB/GB * est nodes + goldimage in GiB *est nodes + users * reqdSSD in GiB) * 1/1024 TiB/GiB | |
| reqdSSD = 2.5 GiB for task worker, 5 GiB for Power user/developer, 3.3 GiB for knowledge |
HDD:
| For VDI workload, the rule to calculate HDD is as follows:
if VDI > SSD, HDD = VDI – SSD else HDD = 0 where VDI = numUsers * actPerUserCap numUsers as received from UI, actPerUserCap : if provisionType is V2V/P2V or Full Clone, actPerUserCap = goldImageCapacity + userDataCap where goldImageCapacity and userDataCap are received from UI : if provisionType is not V2V/P2V or Full Clone, actPerUserCap = userDataCap |
|
VDI Sizing – July 2018 sprint
- Dell completed extensive VDI testing using LoginVSI profiles and test suite on a Nutanix cluster using their skylake models. So we now have the most extensive lab testing results to update Sizer profiles. Given that we updated Sizer VDI workload sizing. The key reasons:
- This was run on skylake models and so includes any enhancements in that architecture
- Latest AOS version was used
- Best practices were used in setting up the cluster by VDI experts. For example hyperthreading is turned ON
- Latest login VSI suite was used
- Here is summary of the results:
- Big change is Task workers. In old days of Windows 7 and Office 2010 we were seeing 10 task workers per core as common ratio. However, both Windows 10 and Office 2016 are very expensive resource-wise. In the lab tests we only get about 6 users per core. We are seeing a big bump in core counts for task workers as a result. For example 18% increase in cores for Xenapp Task workers and 28% for Horizon task workers. A customer’s actual usage will vary.
- Windows 7 is estimated to be needing 60% of cores vs Windows 10.
- Office 2010 is estimated to be needing 75% of cores vs Office 2016.
- Knowledge workers for either View or Xen Desktop brokers did not change much
- Power users on View did not change much
- Power users for Xen Desktop did increase by 21% as the profile changed from 5 users per core to just 4 users per core.
VDI Sizing – November 2018 sprint
We made adjustments for Intel Spectre patches in various versions of Windows.
- Applied spectre adjustment for VDI and Xenapp – Windows 7 – 20% hit, Windows 10 version 1709 – 7% hit, Windows 10 version 1803 – 11% hit
