In January we published a blog post on our first experiences with the HTML5 RD Web Client. Now, in this multi-part article series, we investigate the overall performance of this new client (out in public preview). Our testing focuses on the perceived end-user experience. For these tests we:
- Used REX Analytics workloads to generate automated work in the user session
- Recorded the user experience of the primary user using Camtasia software
- Used REX Analyzer to visually compare the recordings
To simulate a real-world scenario, we created our RDS environment in Azure (West EU) and we connected to the deployment from a location in Amsterdam which generates low latency, typical of users connecting to an azure deployment from their office. Appendix A details our RDS environment build out in Azure.
Part 1 – RD Web Client vs MSTSC Client
This article compares the performance of the RD Web Client against the traditional MSTSC client that is native to the Windows OS. We will look for any variation in the end user experience that we witness as due to using one client or the other. Specifically, we will look for variation in user interface response times and refresh rates as well as perceived graphics and media performance. We chose to run a full desktop session for these tests and we also enabled AVC encoding via Group Policy. Appendix A explains why we chose these options. We published the Session Collection and connected to the deployment via the respective web sites. The following is our match-ups and our analysis.
Test 1 – 1080p Video Performance
In this test we played hi-res video (1080p) stored on the RD Session Host server.
Results: Both clients had issues playing the hi-res video. In the beginning the MSTSC client seems to output more frames for a crisper, smoother, more detailed picture. But throughout both test runs we encounter some choppy performance and missed frames. Particularly towards the end of the match-up, we witness some serious mosaicking. If we had to choose a winner we would choose the MSTSC client, but not by much.
Test 2 – Google Maps Performance (DX9)
This test compares Google Earth DX9 performance.
Results: The experiences were very similar for both clients. Nothing particularly remarkable stood out by comparison. It did seem like the HTML 5 client might have performed just slightly better a few times – a few scenes became crisper faster. But on the whole, this was a tie.
Test 3 – Roller Coaster Performance (DX9)
This test runs a DX9 animation file depicting a roller coaster ride.
Results: The MSTSC client and the HTML 5 client performed similarly. We did not see any real difference in the amount of degradation or frame loss, the graphics were both smooth at the same points and choppy at the same points.
Test 4 – PowerPoint Presentation Performance (DX10)
In this test we use Microsoft PowerPoint Viewer to open and run a PowerPoint presentation that has animations.
Results: Both clients performed decently. MSTSC client wins this round, but again, not by much. We can tell a few times where MSTSC provides more frames resulting in a more detailed and smoother transition from one graphic animation to the next.
Detected Bandwidth Observation
It was interesting that in these back to back test runs (per match-up) we saw that the bandwidth detected by RD Analyzer in the HTML5 test runs was approximately double the bandwidth in the MSTSC test runs. More investigation here is needed.
RemoteApp Start Experience
We noticed that when you close a RemoteApp using the HTML 5 client the webpage window goes black for several seconds.
After several seconds the screen changes and you will see the RemoteApp icons again. The user experience with the MSTSC is different in that when you closed a RemoteApp you could immediately start another RemoteApp from the RD We Access website.
This is expected behavior. Since the RD Web Client uses Immersive RemoteApp, when the last window is closed, the session is still active. By default, the session will stay active (even when there are no windows open) for 20 seconds (configurable by admins) before dropping the session. In MSTSC, when you close an application window, you still see the regular RD Web Access website, so you can instantly choose a different RemoteApp – the session sticks around for 20 seconds in this scenario as well – you just don’t realize it because if you used the RD Web Access website, you end up back on that webpage and you can choose a new RemoteApp.
IN the RD Web Client you need to select the All Resources tab to launch a new RemoteApp without having to wait.
AVC vs Default Profile
We made sure that both clients used the AVC profile. We also did some comparisons with the clients using their default configuration to see what differences in performance there might be. This meant that out of the box, MSTSC does not use the AVC profile and the RD Web Client does. In this context, the HTML 5 client performed a bit better in our Google Earth test runs, and it performed as well as the MSTSC client in our PowerPoint test runs and used less bandwidth. Here are those match-ups:
Test 5 – Google Maps Performance – Default Deployment
Within this test we run Google Earth testing DX9 performance.
Results: The HTML 5 client experience wins. The HTML 5 client showed more graphic details especially while panning across the globe surface. The details of zoomed in locations also appeared to be more defined faster than in the MSTSC client experience.
Test 6 – PowerPoint Presentation (DX10) Performance – Default Deployment
In this test we use Microsoft PowerPoint Viewer to open and run a PowerPoint presentation.
Results: Both clients performed decently. We do see some dropped frames and some stuttering, but on the whole the performance was similar in both scenarios. It is interesting to point out that the MSTSC used more bandwidth and utilized the UDP protocol while the HTML 5 client does not use UDP and uses less bandwidth while providing a similar end user experience.
UDP vs TCP
In the “out of the box” tests, we noticed more than once that UDP output bandwidth in the MSTSC client test run was much more (twice+) than the TCP output bandwidth in the HTML5 client test run. (see the Roller Coaster test runs to witness it). It would seem that in this case TCP as a remoting protocol is more efficient than RDP 10 (UDP). For now, this is just an observation and requires more research. When we know more, you will.
We were expecting the MSTSC client to do better than the HTML 5 client due to it utilizing the UDP protocol (the HTML5 client cannot use this protocol). We also expected that when both clients utilized AVC that MSTSC would really shine. So, we were a bit surprised to observe that while MSTSC may have had a slight edge on some test runs and scenarios, the HTML 5 client really stood up well.
This is great news in that your client options have just grown – it’s possible that you can offer an out of the box HTML5 client, and you may not have to give up much in performance!
Coming Up Next!
In our next article we will compare these two clients again, but this time we will remove UDP protocol from the mix (as some companies do not like to enable it.) We expect that the HTML 5 client may shine here. Stay tuned to find out if this is true or not!
Have a great idea for a comparison that you would like to see between the native MSTSC client and the new RD Web Client? Let us know!
Appendix A – Our Infrastructure Setup
For this article series we will run all performance tests in the same highly available RDS environment hosted on Azure IaaS with the following components:
- 2 VMs running the RD Connection Broker (RDCB) and RD Licensing (RDL) roles
- 2 VMs running the RD Web Access (RDWA) and RD Gateway(RDGW) roles
- 2 VMs running RD Session Host (RDSH) role
- 1 External Azure Load Balancer, load balancing the RDGW and RDWA roles
- 1 Internal Azure Load Balancer, load balancing the RDCB role
- 1 Azure SQL Database used by the RDCB roles
More environment details are as follows:
- The RD Session Host servers are a D2_v2 VM, (Xeon E5 processor, 7GB RAM)
- We installed the RD Web Client (the HTML 5 client) on both existing RD Web Access Servers
- We used a Windows 10 client with the latest updates & patches
- We used Microsoft Edge as the web browser
Full Desktop Comparison Instead of RemoteApp
We decided to use the full desktop instead of RemoteApp so that we made a fair comparison. Here’s why:
“The windows client (MSTSC) can do full integrated RemoteApp with advanced graphics but the RD Web Client can only do immersive RemoteApp. Integrated RemoteApp with advanced graphics supports per surface remoting and each surface (RemoteApp window) has its own graphics context. This allows us to integrate better with the local shell and provide a seamless experience for users. But it is also more resource intensive. Immersive RemoteApp only has 1 graphics context for each monitor. For example, if a RemoteApp is occluded on the screen, we won’t have its graphics content. The resource cost of this kind of connection is similar to desktop.”
Jayashree Sadagopan – Software Engineer Lead, Microsoft
AVC Encoding Tweaks
We enabled AVC encoding via Group Policy to make sure both clients used the same AVC capabilities. By default, MSTSC uses the default profile (non-AVC enabled) whereas the RD Web Client uses the AVC profile (the RD Web Client uses a thin client flag to get AVC from the server regardless of Group Policy settings).
AVC encoding will outperform for graphics intensive scenarios in terms of encoding time and bit rate. Also, both clients use hardware accelerated decoding for the AVC profile but not for default profile.
We should also point out that AVC capabilities also have OS version requirements:
- RemoteApp in advanced graphics mode was supported since Server 2012 R2 – https://cloudblogs.microsoft.com/enterprisemobility/2013/11/25/remoteapp-improvements-in-windows-server-2012-r2/.
- AVC mode was supported since Server 2016
For more on Remote Desktop Protocol (RDP) 10 AVC/H.264 improvements in Windows 10 and Windows Server 2016 see this article.
Appendix B – Other REX Bench-marking Tests
Here are some other examples of projects where we have use the REX Analytics framework: