SSH is slow, but in my experience the primary cause of slowdown is session setup.
Be it PAM, or whatever OpenBSD is doing, the session setup kills performance, whether you're re-using the SSH connection or not, every time you start something within that connection.
Now obviously for long running stuff, that doesn't matter as much as the total overhead. But if you're doing long running ssh you're probably using SSH for its remote terminal purposes and you don't care if it takes 0.5 seconds or 1 second before you can do anything. And if you want file transfer, we already had a HTTP/3 version of that - it's called HTTP/3.
Ansible, for example, performs really poorly in my experience precisely because of this overhead.
Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost.
> Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost.
HMU on my email. I've been working on/with this since 2016, and I'd love to discuss: <https://github.com/rollcat/judo>
To speed up Ansible it's sufficient to enable ControlMaster with a short timeout tbh
I don't believe control master solves the problem, as long as Ansible is configured to create a new session within the long-running SSH connection then it will still have the session setup overhead. I tested this myself when prototyping the replacement.
However, it looks like pipelining (and obviously forking) could do a lot to help.
That being said, there were _many_ reasons for me to drop Ansible. Including poor non-linux host support, Yaml, the weird hoops you have to jump through to make a module, and difficulty achieving certain results given the abstraction choices.
I think Ansible is great, it solves a problem, but my problem was very specific, Ansible was a poor fit for it, and performance was just one of many nails in the coffin for me.