Eu tenho uma curiosidade:
Eu executo um script bash sobre conexão SSH que tem muitos resultados para stdout. isso faz alguma diferença de desempenho se eu executar o processo em segundo plano ou em primeiro plano?
Tenho a sensação de que a execução em segundo plano, mesmo que eu veja a saída para stdout de qualquer maneira, pode ser mais rápido porque o próprio bash não depende da latência do SSH. Isso faz sentido?
Como apontado por sarnold, executar o processo em segundo plano não fará diferença notável. Acho que redirecionar a saída para um arquivo removerá o possível gargalo do terminal local e, portanto, será mais rápido.
De qualquer forma, se você ainda precisar ver a saída, tente adicionar essas opções para ssh:
ssh -c blowfish -C remotehost foo
Onde -C ativará a compactação e -c blowfish selecionará um algoritmo de cifra que tenha um menor impacto de cpu
Você perguntou sobre dois casos, mas acho que precisa de um terceiro:
sem fundo:
ssh remotehost
foo
com fundo:
ssh remotehost
foo &
saída redirecionada:
ssh remotehost
foo > bar
Sem o plano de fundo e com o plano de fundo não importa muito - bash(1) na verdade não precisa fazer nada com a entrada padrão, saída padrão ou erro padrão quando você está executando outro programa. bash(1) nunca vê isso. Ele está apenas esperando o processo morrer, então ele pode lhe dar outro prompt de shell.
Quando você executar o script em segundo plano, poderá interagir com o bash(1) novamente muito rapidamente, mas qualquer saída ainda ultrapassará o canal ssh(1) , possivelmente muito lentamente e, potencialmente, o write(2) syscalls no seu cliente ssh(1) pode bloquear, fazendo com que o pseudo-terminal que ele cria bloqueie, fazendo com que seu script seja bloqueado quando ele chama write(2) . Isso é tudo idêntico ao primeiro caso - a única diferença é que você pode digitar comandos para o seu bash(1) enquanto o script está enviando a saída, e talvez kill %1 para eliminá-lo ou iniciar outros serviços, ou o que for. O script será executado na mesma velocidade de qualquer maneira.
No terceiro caso, quando você redireciona a saída para um arquivo, a sessão ssh(1) não é mais um gargalo potencial e, portanto, não é um gargalo potencial para a execução do seu script. Ele pode ser executado rapidamente, talvez muito mais rápido do que até executá-lo localmente sem redirecionamento de saída. (Você já viu top(1) de saída para seus terminais quando você executou um comando que gera muita saída de terminal?)
É claro que uma ferramenta como screen(1) (ou dtach(1) ?) também pode permitir que você execute um script sem enviar sua saída pela sessão do terminal, então talvez uma quarta opção seja necessária. Mas provavelmente há mais maneiras de executar um script sem forçar sua saída a ser enviada pela rede ...
Tags performance ssh bash