bash script speed over ssh in background or foreground

Question

I have a curiosity:

I run a bash script over SSH connection that has a lot of output to stdout. does it make any performance difference if I run the process in background or foreground?

I have the feeling that running in background, even if I see the output to stdout anyway, might be faster because bash itself does not depend on SSH latency. Does this make sense?

Answer 1

As pointed out by sarnold, running the process in background won't make noticeable difference. I think redirecting output to a file will remove the possible bottleneck of the local terminal and thus be faster.

Anyway, if you still need to see the output, try adding these options for ssh:

ssh -c blowfish -C remotehost foo

Where -C will enable compression and -c blowfish will select a cypher algorithm that has a lower cpu impact

Answer 2

You've asked about two cases, but I think you need a third:

1. without background:

   ssh remotehost
   foo
   

2. with background:

   ssh remotehost
   foo &
   

3. output redirected:

   ssh remotehost
   foo > bar
   

Without the background and with the background won't much matter -- bash(1) doesn't actually have to do anything with the standard input, standard output or standard error when you're executing another program. bash(1) never even sees it. It is just waiting for the process to die, so it can give you another shell prompt.

When you run the script in the background, you'll be able to interact with your bash(1) again very quickly, but any output will still go over your ssh(1) channel, potentially very slowly, and potentially the write(2) syscalls in your ssh(1) client might block, causing the pseudo-terminal it creates to block, causing your script to block when it calls write(2). This is all identical to the first case -- the only difference is you can type commands to your bash(1) while the script is sending you output, and maybe kill %1 to kill it, or start other services, or whatever. The script will run at the same speed either way.

In the third case, when you redirect output to a file, the ssh(1) session is no longer a potential bottleneck, and thus not a potential bottleneck for the execution of your script. It can run quite quickly, perhaps much faster than even running it locally without output redirection. (Have you ever seen top(1) output for your terminals when you've run a command that generates a lot of terminal output?)

Of course, a tool like screen(1) (or dtach(1)?) can also let you run a script without sending its output over the terminal session, so maybe a fourth option is required. But there's probably more ways to run a script without forcing its output to be sent over the network...