In the previous post, I had a look at Guacamole, an open source client-less remote desktop gateway. It’s a cool piece of software and I have already used it with 12 people connecting to the same number of workstations in the cloud. In this setup, the central Guacamole server that I equipped with 8 vCPUs hardly required any CPU resources at all. However, most of the time, not much was changing on the remote desktops, so my scenario was not very demanding. So while that’s good to know, I wanted to know the limits of my 8 vCPU setup, so I stress tested my setup. A fun experience!
As noted above, Guacamole requires almost no CPU resources while nothing changes on the graphical desktop. When scrolling heavily through documents, however, remote desktop forwarding gets quite demanding on the CPUs of the central server. Based on a single session and lots of scrolling, I established that 4 virtual CPUs in a VM in the cloud should probably do the job for a workshop with 20 people and significant continuous and simultaneous screen changes. To be on the save side, I scaled up the virtual machine on which I hosted Guacamole to 8 vCPUs.
Stress testing means to have lots of clients. I thus pressed all computers I had at home into service, ran 3 browser tabs with individual sessions on each and asked several friends to join the virtual party. In total, I had 26 simultaneous sessions running to 10 virtual desktops. Without much activity on the screen, CPU load on the central server is negligible. However, when running a ‘sudo tcpdump‘ in a shell window on each VM to get a lot of scrolling activity on each desktop, all 8 CPUs of the central server ran at 85% load. I would have liked to go higher but I ran out of equipment and people to help me to push things further.
Load from the nginx reverse proxy was around 15% on only one CPU. I found that a bit surprising, because I thought that TLS encryption on the front end would require more processing resources. Traffic on the Ethernet interface of the Guacamole server was at around 130 Mbit/s during heavy simultaneous scrolling on all virtual screens. That’s quite a bit but nowhere near the capacity of the Gbit/s Ethernet link.
I then ran this ‘heavy scrolling’ setup for 3 hours to see if the solution is stable, and occasionally interacted with some of the virtual servers to see how reactive the system still is under high load. To my delight, things worked perfectly for the complete duration of the test, and reaction time when interacting with a virtual desktop under almost full load of the system was only slightly delayed. Very impressive!
In a real live scenario, not all 26 users would scroll at the same time and all the time, so I am confident that this really was a ‘super worst case’ scenario. In a ‘real world scenario’, the centralized Guacamole server probably requires significantly fewer compute resources and could thus serve a significantly higher number than ‘just’ 26 users with 8 vCPUs.