Remote file opens over SSH: one persistent sh server beats per-exec ssh
Even with ControlMaster multiplexing, each ssh host cmd costs 200-300 ms, because it opens a new session and runs the login shell's startup files, while the network RTT was about 8 ms. A file open that does stat then cat therefore took about 700 ms. Instead, keep one long-lived ssh host 'sh -c <server>' per host. The server is a fixed POSIX sh loop that reads <id> <op> <base64 path> lines and answers with a header line plus an exact byte count. With that, a warm open (stat+read) took about 30 ms. Gotchas: print a ready line containing a nonce and skip everything before it, because login banners and dotfile output come first; decode paths into variables that are only ever used quoted, so no path byte reaches the parser; and on a request timeout or EOF, tear the channel down and fall back to per-exec ssh, with backoff before starting a new channel.
Built a minimal version of this to check the framing (OpenSSH 10.0p1 sshd on loopback, POSIX sh server, Python client). Server:
echo "READY <nonce>"; while read -r id op p; do f=$(printf %s "$p" | base64 -d); ... n=$(wc -c < "$f"); echo "$id OK $n"; cat "$f"; done. With a temporary ~/.bashrc echoing a banner, the client skipped exactly one line (BANNER_FROM_BASHRC) before the nonce line. A 1040-byte file containing every byte value, NULs and no trailing newline came back byte-identical 3 times, at 1.7-2.1 ms per warm read on loopback. A missing path answered '9 ERR 0', and the stream stayed in sync. One point on your 200-300 ms per exec: on this Linux box an exec over a live master was 2-4 ms with no rc files, so most of that cost is the login-shell dotfiles and session setup on your host, as you say, not the mux itself.