How to improve SSH/SCP performance

[jgriegershs]

Problem

Users of k2s system [ssh|scp] commands as well as maintainers of K2s repeatedly reported very poor performance of those commands.

One issue with too many PowerShell modules being loaded is already fixed with #639.

Another way to improve performance is to directly call the underlying executables in Go, i.e. ssh.exe and scp.exe instead of calling PowerShell scripts first.

Example

In case of opening an interactive SSH session, the invocation stack currently spans five layers (!):
k2s Go exe --> sshm shortcut --> PowerShell wrapper script --> PowerShell script --> ssh.exe

Solution Proposal

Call underlying ssh.exe and scp.exe directly in Go. This would also remove the need to create a costly PowerShell session (which takes at least two seconds on a potent dev machine).

PowerShell scripts like sshm.ps1 are merely a wrapper around ssh.exe. Also, system status check in PowerShell scripts can be replaced with a stricter timeout when connection via SSH, e.g. of two seconds. That way it would not matter if the K2s system is down in general, when the target machine is still reachable via SSH.

[Najzer0]

I wanted to test the toolchain once for ssh using "dotting" and not load-module... I believe inlining the powershell stuff would be faster than the load-module aproach... but I like this idea even more. From our side we discussed using ssh directly and not via the k2s wrapper due to the performance limitation. As of now we chain quite alot configuration ssh commands into one cmd just to bypass this ssh-session delay

[jgriegershs]

Funny enough our code base back in the old days was full of . and & statements to include the PowerShell stuff needed and eventually we decided to utilize the modules mechanism. At that time we did not experience performance penalties, but now taking the amount of PowerShell code into account, we have to be careful what we import.

[Najzer0]

as mentioned, that was only a wild "workaround" I imagined. We needed a function that resolves k2s.exe in our "consuming product" and there I noticed the performance impact of import vs dotting quite fast. It does make sense in most cases to use modules (eg exports visible to you afterwards). I like your idea to directly talk to the corresp. binaries from k2s.exe.

Great find that we could use plink.exe instead of the ssh.exe dependency (#789 ), I think k2s deploys plink itself and could utilize those then... I am just worried about plink mentioning "if you want a ssh terminal, plink is not for you" in their repo :-) (as after automation, "sshm" is the most used command for me)

[jgriegershs]

If it turns out that plink.exe is for some reason not suitable for interactive sessions, we can still use an existing ssh.exe. The aforementioned problems occurred in automation scenarios where plink.exe could be a reasonable alternative.
Anyways, thank you for sharing your experience with K2s 😄 .

[krotz-dieter]

For best performance I like the idea to make the ssh/scp connections directly in go, maybe even through a library.

[jgriegershs]

Please see my comment #789 (comment) regarding an interactive session.

Please see my comment #789 (comment) regarding SCP.