Monday, July 15, 2013

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).

image

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.

image

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

clip_image006[4]In this scenario the VSIMax is not reached.

Test number 2

Azure VM

Workload

# Sessions launched

Extra Large

Medium

40

clip_image008[4]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

clip_image010[4]In this scenario the VSIMax is not reached.

Test number 4

Azure VM

Workload

# Sessions launched

Extra Large

Light

50

clip_image012[4]The Extra Large Azure VM reaches its VSIMax limit at 46 concurrent sessions.

Test number 5

Azure VM

Workload

# Sessions launched

A7

Medium

40

clip_image014[4]The A7 Azure VM reaches its VSIMax limit at 36 concurrent sessions.

Test number 6

Azure VM

Workload

# Sessions launched

A7

Light

55

clip_image016[4] 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/

4 comments:

  1. Hi Freek,

    I notice you try to have an objective view on the matter, but i personally think these are very bad results. But as you say, this might be due to other circumstances like Office2013.

    So, to put this in perspective, could you do the same tests of physical hardware? Or if you don't have time or resources available, could you mail me to discuss letting us do the physical tests?

    Dennis

    ReplyDelete
  2. Hi Freek,
    Great article. Wondering if you are counting each RDP with apps as one session or are they counted as two like how quser breaks it down?

    ReplyDelete
  3. Mike,

    Yes, each user has a single session and is counted as such.

    ReplyDelete
  4. Hi Freek,

    I was told yesterday by a Microsoft support representative that it is quite normal for a RDWeb session to take 25 seconds to log someone on (as it does in my test setup). This is timed after a user has successfully logged into the RDWeb website and has clicked the published application (notepad in my test case). Is it really normal to take this long?

    Malcolm

    ReplyDelete