How To Choose Instance Types For High-Cost Savings

August 4, 2023

Traditional insight on how to provide the best user experience doesn’t always ring true.  We have seen many occasions how the wrong configuration can not only provide slow VDI performance but also wasted capital resources. 

When considering how to design a VDI environment, it’s important to leverage a scientific approach that is consistent and repeatable in order to determine the ideal configuration to provide the best and most cost-effective solution. 

This journey always starts in the same place, which is understanding what your current user experience is like and what is the cost of it. 

What Does Your User Experience Cost?

The first step to understanding the price tag of your user experience is to execute individual or small scalability or capacity planning scenarios against your current configuration.

Before you begin your iterative process, make sure that the target of your experimentation does not have external interference.  As much as possible, you will want to segment that target environment from the activities of other users. 

Ideally, you will have a dedicated host or virtual machine free from external influence.  Once you’ve done this, you can begin to collect a repeatable set of data.  You will also want to ensure that the target environment is as close to the configuration of your production environment as possible. Apply any policies, configurations, agents, etc. 

The standard of comparison or control in our scientific method is the activities that are being executed against the environments we will compare.

Start With One Virtual User

Initially, you’ll want to start with one user.  Although one user will not help you understand the capacity or scalability of the environment, it will allow you to see how the system performs and functions under little to no load. 

This is the best place to start because if things perform poorly individually, there is no reason to add additional users.  The virtual user will process interactions with applications like your users would, and at the end, you will see if any of the applications either failed to launch or if the interactions of those workflows did not perform the way you expected.

Extrapolation Gone Wrong: How to Avoid this Trap

Now, you have run your first couple of individual users through your target configuration and understand how the system performs under little or no load.  You may be tempted to think that you can now just do some simple multiplication depending upon how large the environment is to understand how many of these individual users or desktops you can support—Wrong, this would be a mistake. 

We’ve seen numerous examples of extrapolation going wrong. One such was a government customer where an issue in asynchronous routing did not manifest itself or become a bottleneck until a multitude of behaviors was introduced. 

No matter how sophisticated or advanced the technology is, one that will inevitably lead to an exponential failure is shared subsystems. 

Test the Scalability of Your Virtualized Desktop Environment

By now moving onto scalability testing, you can better understand or define the veritable “curve in the hockey stick” or point where user experience begins to decline exponentially.  In our experience, linear scalability is much sought but still elusive. 

You will now want to start to ramp up your environment with more users.  Typically, this is now an individual VM hosting many users or an individual host that is hosting many VMs. Sample size becomes important as data is more statistically accurate with a larger set. 

Start with one host or one VM and then build to two or three. Using the same workflow that we had previously leveraged for our individual user scenario, we can introduce a number of users to find the inflection point. 

Key Insights: Why is understanding login rates crucial for optimizing performance?

To ensure that this is as accurate as possible for your organization, you must understand the login rates that you see during production. If you are operating an environment like Citrix, this information is available to you through historical real user data within Director. 

Other ways you can obtain this is through Windows Event logs or asking stakeholders what an acceptable login rate is for a standard scenario.  It is worth noting that when you are in production, the user logins are generally round-robin between the members of the delivery group. 

For example – Say you have 100 users and 10 servers in your delivery group. If the connection attempts were evenly distributed between each server and the login rate was 10 seconds, each server would receive a login attempt every 100 seconds. 

Leverage this methodology to understand the per-server login rate and adjust your scenarios accordingly based on how large your target environment is. Execution of this iterative capacity and scalability scenario will help to understand the point at which you are unable to sustain the experience we had previously achieved with a single-user session. 

This is where things get interesting…

Once you have this set of baseline data both from an individual as well as from a scalability perspective, the real interesting part happens.  You can leverage the control, which is the set of interactions to iterate.  Take the iterative approach one change at a time.

For example, remove an agent, turn off a security setting, or change the NUMA configuration or ratio of cores / processors to the amount of memory provided per user or to the individual machine.  When you find a configuration or change that results in your ability to support more desktops per host or more users per VM, you are headed in the right direction.

Now, for those of us who are fiscally minded, this is where things get interesting.  For on-prem deployments, you may need to do a little poking, but the information you are looking for is the cost associated with the single host (many VMs) or single VM (many users).  For example – Say you have a Cisco UCS chassis, which is approximately $10,000.00.

This would leave 20 cores and 40 threads available for virtualization.  If you were provisioning this piece of hardware for 4vCPU machines, you could fit approximately 9 users with basic workloads (leaving room for overhead for management, vMotion, etc.). In this example, we will give each machine 8GB of RAM.  This would make your cost per user $1,111. This is overly simplistic for explanation purposes. 

When you find this number, you must consider things like networking equipment, power, cooling cost, software, etc.

Balance Capacity and Experience with Individual Configurations

You could modify the individual machine configuration to 2vCPU instead and potentially double your density number on a single piece of hardware, which would exponentially change the cost associated with supporting your environment because now you are running double the users on the same hardware.

Now, you will run an 18-user test against the same hardware with Login Enterprise. You can easily overlap these results and, based on the overall end-user experience, login times, or application performance, make a decision on whether you are providing an acceptable user experience. 

If you choose the 2vCPU configuration, your per-user cost is $555. This same methodology can be leveraged to understand if you are better off moving to a Windows Server-based operating system for efficiency or cost gains.  You can leverage this data to compare to the cost of running this workload on Azure, AWS or Google Public Cloud.

Learn how the Login Enterprise virtual users can help you optimize the cost and performance of your VDI environment like never before. Request a live demo of the Login Enterprise Platform today.