Performance testing RDS (Session-Based Desktop deployment) on Azure

If you’ve read my previous blog post you’ll know that Session-Based Desktop Deployment is now supported on Azure and can be licensed using SPLA. Details: Running VDI Session-Based Desktops on Azure now supported for SPLA

Now that this architecture is supported I thought it would be a good time to share some performance tests on Windows Azure I did earlier, to get an idea on how many concurrent sessions Azure is able to host on a single Remote Desktop Session Host (RDSH) server.

For this performance test I used the following Windows Azure VM’s (all Windows Server 2012).

A VDI Session-Based Scenario-Based Deployment has been enrolled, and the servers are running the roles as shown below. Although technically for this test, a role-based deployment of just the RD Session Host role would have been enough because the other RDS roles are not touched within this particular load test.

To perform the load testing and benchmarking I used Login VSI. Login VSI is an industry standard benchmarking tool for measuring the performance and scalability of Virtual Desktop Infrastructures. These tests were performed before the release of 4.0 For more info also see: http://www.loginvsi.com.

Login VSI is capable of generating different types of workloads and calculates what they call a VSIMax, which is basically the maximum capacity of the RD Session Host server expressed in the amount of sessions.

The following table shows the specifications of the different Windows Azure virtual machine sizes I used for the purpose of this test.

Azure VM Size	CPU	Memory
Extra Large	8 cores	14 Gb
A7	8 cores	56 Gb

I left out the VM’s with less available resources because I figured these two VM types would be most interesting since they can probably host the most number of sessions.

The following table shows the different VSI workloads (in number of sessions launched and type of workload) as well as the different Windows Azure virtual machine sizes I used for the purpose of this test. For more information on the workload types visit http://www.loginvsi.com./documentation/v3/performing-tests/workloads.

Number	Azure VM	Workload	# Sessions launched
1	Extra Large	Medium	30
2	Extra Large	Medium	40
3	Extra Large	Light	45
4	Extra Large	Light	50
5	A7	Medium	40
6	A7	Light	55

In all tests, user profiles have been pre-created for the test users and prior to each new test a reboot of the RD Session Host server has been performed to ensure everything is cleaned up properly. Also, all tests were performed several times to ensure more accuracy. Microsoft Performance monitor was also running during the tests to capture the performance counters on the RD Session Host server as shown below.

Performance counter	color
Processor - % Processor time _total	Green
Memory – Available Mbytes	Blue
Terminal Services – Active Sessions	Red
Logical Disk – Disk Reads / Sec	Purple
Logical Disk – Disk Writes / Sec	Yellow

Test number 1

Azure VM	Workload	# Sessions launched
Extra Large	Medium	30

In this scenario the VSIMax is not reached.

Test number 2

Azure VM	Workload	# Sessions launched
Extra Large	Medium	40

The Extra Large Azure VM reaches its VSIMax limit at 36 concurrent sessions.

Test number 3

Azure VM	Workload	# Sessions launched
Extra Large	Light	45

In this scenario the VSIMax is not reached.

Test number 4

Azure VM	Workload	# Sessions launched
Extra Large	Light	50

The Extra Large Azure VM reaches its VSIMax limit at 46 concurrent sessions.

Test number 5

Azure VM	Workload	# Sessions launched
A7	Medium	40

The A7 Azure VM reaches its VSIMax limit at 36 concurrent sessions.

Test number 6

Azure VM	Workload	# Sessions launched
A7	Light	55

The A7 Azure VM reaches its VSIMax limit at 49 concurrent sessions.

Summary

As a summary, here are the results of the highest VSIMax value I got calculated per Azure VM type.

Azure VM	Workload	VSIMax
Extra Large	Light	46
Extra Large	Medium	36
A7	Light	49
A7	Medium	36

So according to the test results, these are the VSI workloads a RD Session Host (running Server 2012) is able to handle on Windows Azure. Note that these results are of course based on a Full Desktop being published. Publishing just Remote Apps obviously consume fewer resources. Also, in these tests I’ve used Office 2013 and, as you might have heard, Office 2013 causes additional resources to be used compared to previous versions of office. And I’ve used a plain Windows Server 2012 image for the RD Session Host role without any optimizations. Also note that the number of concurrent sessions (VSIMax) is a simulation, the actual performance will always vary depending on your specific applications and users. But since LoginVSi is an industry standard these workloads can be compared to other environments.

It’s interesting to see that when workloads run towards the VSIMax, available CPU is the biggest part of the bottleneck. Because CPU is the biggest part of the bottleneck, the difference in VSIMax on an Extra Large VM and A7 Azure VM (both 8 Cores) are practically the same. Since Light workloads consume less CPU and there is a difference in available memory between the Extra Large Azure and A7 Azure VM, there is a (little) difference in the VSIMax there. Therefore, environments with Light workloads could take advantage of the biggest Azure VM, the A7.

For more information on pricing and detailed specifications on Azure VM’s see:
http://www.windowsazure.com/en-us/pricing/details/virtual-machines/