On Tue, Oct 17, 2023 at 2:23 PM Julien Lejeune <[email protected]> wrote:
> Hi all! > > > > Luke and Mark, thank you for your helpful insights. > > > > I haven't solved the problem yet, but I give you a little feedback anyway. > > > > To be clear, if you connect directly via SSH without Guacamole, the cat > takes 4s. When using Guacamole with a defined SSH connection, it takes 1 > minute 37 seconds. > It's probably worth noting that we don't make any specific claims (that I can recall) about Guacamole being faster than a native SSH (or RDP) connection - or, at least, not without some better definitions of the characteristics of those connections. If I'm wrong about that, and we have made those claims somewhere, then please someone jump in and correct me :-). Guacamole is designed to perform reasonably well over connections that have elevated latency and lower bandwidth, as it can adapt to those conditions, usually better than the native protocols. It's also designed to give the user a single clientless interface using only a web browser, with no additional software, and is able to make those connections available via HTTP/HTTPS/WSS, which are pretty standard ports and protocols to have open across network boundaries. And, while, most of the time, performance should be comparable to - and may be faster than - other SSH clients, there are definitely some situations you're going to hit where the nature of the connection and what you're trying to do is better-suited for a native client. If your client computer is relatively "close" to the SSH server (in the single-digit ms range), and you're doing some very display-intensive things (cat /dev/urandom, or tailing a very verbose log file, etc.), I would fully expect that the platform-native SSH client is going to render the output of the SSH connection much more efficiently than the Guacamole combination where the SSH protocol has to be turned into Guacamole (series of images going one-way and keystrokes and mouse movements going the other way) and then rendered by a web browser. Now, the difference you're seeing is quite a bit - 4s -> 1m37s is something like a 2400% increase. That said, I'm not sure there's all that much that can be done - use "less" instead of cat, so that you're not attempting to stream the entire contents of the file all at once? Aside from the "cat /var/log/huge.log" situations, are there other areas where you're consistently seeing increased latency as compared to the native SSH client? -Nick >
