On Mon, Nov 2, 2020 at 1:21 AM Bernd Hofner <[email protected]> wrote:
> Hello, > > we plan to use Guacamole to run a Virtual Desktop Infrastructure VDI) for > a legacy Flash application. > The remote desktops host a customized Linux that allows the users to run a > restricted version of Firefox with the Flash plugin. > This allows us to run the legacy Flash application in a controled > environment until migration to a non-Flash application can be finished. > > Now I would like to run a performance test to check how many users can run > concurrently on our VDI - and maybe also monitor VDI performance > automatically durng "normal" operation. > > My idea is to remotely control the Flash application via > JMeter/Webdriver.io and measure response times for "telling" user > interactions, like: > - how long dies it take from "login to Guacamole", via logon to the remote > desktop, startup of the browser and finally startup of the Flash app. > Furhermore, simulating interactions within the Flash app should be timed. > > Up till now, I managed to automate the Guacamole login and monitoring of > the startup progress by taking screenshots and analysing their content in a > webdriver script. > But I did NOT succeed in controlling the remote desktop through the > Guacamole browser. > It's clear that I only see a bitmap of the remote desktop in a <canvas> > element. > I tried to control the remote desktop by sending "click" events at > specifix x/y coordinates to the canvas element and also to some of it's > surrounding elements (e.g. <div id="content">). > Unfortunatly, there is no reaction whatsoever. > > Can you help me to identify the HTML element on the Guacamole web page > that is responsible for intercepting UI interactions (especially mouse > click events)? > > Or do you have another idea how to do performance monitoring/load testing > in our setting? > > When we did our own load tests at my day job (resulting in the "1 core and 2 GB per 25 concurrent users" rule of thumb), this was accomplished by: - Scripting a series of interactions with the web application using Sikuli, using a dedicated virtual machine for each simulated user to avoid client-side load from affecting the test. The virtual machines were set up to automatically run a script which started a web browser within a VNC server and then interacted with it continuously via Sikuli. - Having actual human beings interact with remote desktops through the same Guacamole server while this was happening. - Gradually increasing the number of simulated users until the humans reported that performance felt slower. We found that the threshold after which users reported subjective performance degradation was consistently after the load exceeded 25 concurrent users per core, regardless of how many servers were involved or how those cores were spread out. To perform your own tests, I think you will need to do something similar and use real people to determine how things feel subjectively and when that feeling changes. The events you describe make sense intuitively, but they don't actually exist in a way that could be timed. It's easy for a person to click a button and assess whether things are slower than normal *based on their own experience with that button*. For a machine, there's no way to know that the change in the screen contents following a click is due to that click, or that the delay in that change is due to performance change in the remote desktop gateway vs. the remote desktop server vs. the application within the remote desktop. Michael Jumper CEO, Lead Developer Glyptodon Inc <https://enterprise.glyptodon.com/>.
