In a previous blog post, I discussed how easy it is to deploy VMware App Volumes. Today, I want to talk about performance. Our customers and partners are reaping the benefits of App Volumes because it truly delivers on:
- Dynamic application delivery.
- Bringing persistence to nonpersistent desktops.
- Cost-optimized infrastructure.
- Seamless end-user experience.
- Simple deployment and management.
App Volumes enhances end-user mobility, delivering applications to users on demand and providing agility to the enterprise. If you are unfamiliar with VMware App Volumes, check out this App Volumes primer.
OK, What About Performance?
We know the questions on your mind. What are the some of the performance characteristics of applications when they are delivered by App Volumes? Do they really operate just like natively installed applications? Will my desktop be slower? Do I need to go out and purchase new storage to host my AppStacks?
These are all questions that I shared with my buddies Fred and Stephane. Fred Schimscheimer is the brilliant Staff Engineer in the VMware Office of the CTO. Stephane Asselin is an amazing architect on the VMware End-User-Computing Technical Enablement Team. The three of us worked together to build up a test environment and then conducted some testing where we could evaluate native versus App Volumes application performance.
What Did We Test?
Our lab was both modest and simple. We tested a very basic VMware Horizon implementation, with App Volumes, single vCenter, single App Volumes Manager, single View Connection Server and one linked-clone pool (with 1,000 desktops) at a time.
We used EMC VNX-5600 storage and spread our desktops over 47 LUNs. We used a separate LUN to host our App Volumes AppStack and Template directories. Our infrastructure and management servers ran on an isolated 3-host vSphere cluster, while our desktops ran on a 10-host cluster.
For the native application tests we did a basic application deployment:
- Microsoft Word 2013
- Excel 2013
- Outlook 2013
- PowerPoint 2013
- Adobe Reader 10
- Internet Explorer 9
For our App Volumes test we delivered the same six applications via a single AppStack that was provisioned to all 1,000 desktops.
How Did We Test?
When conducting View performance testing, it is important to simulate real-world usage as closely as possible. The Desktop Reference Architecture Workload Simulator (RAWC) can be used to simulate a user workload in a typical Microsoft Windows desktop environment. Desktop RAWC runs on each desktop virtual machine (VM) on one or more vSphere hosts. Each target desktop VM is equipped to run a RAWC workload that simulates typical user behavior, running an application-set commonly used across a broad array of desktop environments. For more information, visit our RAWC community forum.
We configured 4-hour test runs with random application-task execution, and randomly started the workload during the first hour of the test window. Three sets of each test type were executed (three with native applications, three with App Volumes).
We then used vRealize Operations for Horizon to gather host, desktop, and front-end storage performance metrics. These metrics were exported to Microsoft Excel to build graphs, charts, and a few basic infographics.
User Experience Findings
After measuring 3,000 user logins with native applications, and the same number of user logins on desktops with AppStack mounts, we observed a very modest difference in login performance. It is important to remember that with the App Volumes test, a VMDK mount operation was being executed on each desktop at time of user login. This resulted in a slight increase in login time for each user.
We observed a similar modest difference in application launch times. In some cases the difference in application launch times were not significant enough to be noted by the end user. Remember—the 1,000 desktop users were hitting the same centralized AppStack, and the application response times were still very comparable. Amazing when you consider that all of those VMs were hitting the same VMDK!
With App Volumes, users enjoyed virtually the same Windows login time, application launch time, and document access time as with natively installed applications.
Desktop Performance Results
We put vRealize Operations for Horizon through its paces. We utilized custom dashboards so that we could sample the desktop environment and gather some basic performance stats during our test runs.
Per-desktop CPU usage was comparable during both types of tests—native and with App Volumes. App Volumes required only slightly more CPU resources than native. It is important to note that on the vSphere host side we never pushed the host CPU demand level above 80 percent. This is in keeping with vSphere and Horizon with View best practices.
In per-desktop RAM utilization we saw more of a difference in memory utilization. We observed lower RAM usage with App Volumes than with native applications. This was a consistent observation during testing and is related to the unique way in which App Volumes handles application-related IO and interactions with the Windows OS buffer cache. Our next round of testing will study this effect in greater detail.
Desktops with AppStack-delivered applications are comparatively more read-and-write intensive. As you will see in the next section, most of this application-related IO is actually served by the App Volumes LUN. Thus, the per-desktop IO looks more demanding, but it is not exerting extra pressure or demand on the datastore where the desktops reside.
Datastore Performance Results
In evaluating the datastore IO patterns, it was clear that desktop LUNs (the datastores where the linked clones are placed) were under lower load with App Volumes applications. In the configuration where AppStacks were in use, much of the application IO (primarily reads) was served by the App Volumes LUN. Remember, though, we had 1,000 clones spread across 47 LUNs. That is about 21 desktops per LUN. During application testing, the average linked clone virtual desktop read-IOPS rate was a little less than 1.
With App Volumes, our desktop LUNs were under less pressure during the 4-hour test runs, and we saw that the App Volumes LUN experienced bigger read demand during the first hour of testing when all of the users were opening their six applications. We measured a datastore-read demand peak of about 10,000 IOPS. After the applications were loaded, the read pressure dropped off quite a bit.
To Summarize…
After studying a total of 20,000 desktops during this testing, here are our conclusions:
- Per-desktop resource planning (CPU, RAM) does not change much when you introduce App Volumes to a Horizon with View linked-clone environment.
- Your desktop LUNs will be under lower pressure when you deliver applications with AppStacks.
- Depending on your applications and users, you need to plan for some heavy read pressure on your App Volumes LUN. If you cannot deliver the IO with low latency, your application performance (and user experience) will degrade.
- If you add Writable Volumes to the mix, you will need to plan for some write demand on your App Volumes LUNs.
- Your results (and users and applications) might be different. It is important to pilot-test End-User Computing technologies in your environment.
What Is Next?
We are working on further testing where we will re-test the same basic scenario detailed here, and we will explore a few more things. We will
- Add more desktops per LUN
- Increase the number of AppStacks
- Experiment with a variety of AppStack densities (applications per AppStack)
- Further analyze the OS buffer-cache behavior
- Introduce low-latency flash storage
- Add more intense desktop workloads (more applications, more intensive operations)
- Introduce writable volumes
- Introduce full-clone desktops and measure performance
Thanks for your interest in our testing. We love your feedback and use it to influence some of the testing that we carry out in our labs. We will post an updated End-User Computing blog post soon to tell you how our testing is going. Also, we are planning a fun VMWorld 2015 session on this topic (details soon).
Would you like to play with App Volumes? Check out the App Volumes Hands-On Lab.
Epilogue – Some Details on Our Testing Environment
Versions and builds:
All software ran the latest generally available versions, with all patches installed.
All hardware ran updated firmware and micro-code.
Hosts:
Dell R720 hosts
(2 x 8 core Intel E5-2690, 256 GB of RAM)
EMC VNX-5600 with FAST, fC attached
Test desktops:
Windows 7 64-bit, 2 vCPU, 2 GB RAM
1 AppStack with Office 2013 Suite, IE9, Adobe Reader
By Tristan Todd, VMware End-User Computing Architect
With significant contributions from Fred Schimscheimer, Staff Engineer in the VMware Office of the CTO, and Stephane Asselin, Architect on the VMware End-User-Computing Technical Enablement Team
