Existem muitos limites para a transferência de muitos arquivos pequenos. Alguns já foram mencionados: latência de rede, velocidade de gravação de disco, etc. No entanto, a maioria deles pode ser melhor otimizada usando o "rsync". Se os arquivos não existirem no destino e você tiver certeza de que o processo não será interrompido, o uso do tar canalizado para o tar será muito eficiente:
cd /SOURCE/DIR && tar cf - . | ssh DESTINATIONHOST "cd /DESTINATION/DIR && tar xpvf -"
Fundamentalmente você precisa agrupar todos os arquivos para que a sobrecarga de inicialização / desligamento do SCP ocorra apenas uma vez. Se você fizer esse startup / shutdown para cada arquivo, será muito ineficiente. O tubo "alcatrão" acima fará isso. De fato, 90% de todos os casos de uso serão bons o suficiente.
Esse "tar pipe" tem o benefício do processamento paralelo (lendo em um processo enquanto escreve em outro). No entanto, é limitado por algumas coisas:
- O TCP / IP nunca utilizará 100% do canal que possui.
- Cada processo é limitado por discos que podem fazer apenas uma gravação ou uma leitura por vez. Se você usa discos giratórios, tudo bem. Se você usar SSDs ou RAID (os tipos de RAID que permitem várias leituras paralelas), essa técnica terá um desempenho inferior.
Você pode trabalhar em torno de # 2 através de vários hacks, como a execução de dois ou mais processos, cada um em um subconjunto dos arquivos. No entanto, esses são imperfeitos e um pouco desleixados.
O TCP / IP é mais difícil de contornar e continuará sendo seu limite. De fato, se você ajustar o sistema para que tudo esteja otimizado, o TCP / IP não utilizará o tubo completo. Toda vez que o TCP / IP achar que encontrou a taxa de envio ideal, ele tentará enviar um pouco mais para testar se houver "mais espaço" disponível. Isso falhará e o TCP / IP voltará um pouco. Esse loop constante de aumento / falha / recuo significa que um fluxo TCP / IP alternará entre 100% de utilização e 50% de utilização ... o resultado é que, em média, o tubo será utilizado de 75 a 80%. (NOTA: Estas são estimativas ... faça algumas pesquisas no Google para encontrar os números exatos. O ponto é que será a média de 100% e algo que não é 100%, portanto nunca será 100%) .
Se você executar vários streams TCP / IP, todos eles estarão constantemente em loop através deste loop de aumento / falha / recuo. Se você tiver azar, todos colidirão ao mesmo tempo e todos recuarão muito, deixando o tubo subutilizado mais. Se você tiver sorte, eles colidirão menos e você obterá um gráfico que se parece com muitas bolas saltitonas ... ainda deixando o tubo subutilizado em conjunto.
Ah, e se você tiver uma única máquina cuja implementação TCP / IP não tenha as otimizações mais recentes, ou não esteja perfeitamente ajustada, ela pode mandar todo o sistema para fora.
Então, se o TCP / IP é tão terrível, por que continuamos a usá-lo? Não é tão ruim no caso típico de muitos tipos diferentes de tráfego compartilhando um pipe. O problema aqui é que você tem um aplicativo muito específico com um requisito muito específico. Portanto, você precisa de uma solução muito específica. Por sorte, muitas pessoas também estão em sua posição, então essas soluções estão se tornando mais fáceis de encontrar.
Sistemas como o link usam um protocolo personalizado sobre UDP / IP para que eles possam controlar o algoritmo back-off / rety. Eles usam correção de erro de encaminhamento (FEC) para que pequenos erros não exijam retransmissão (com TCP / IP um pequeno erro é um sinal para recuar), esquemas de compressão personalizados, cópia delta e seus próprios algoritmos de recuo e sistemas de limitação de taxa para obter a utilização total (ou próxima do total) do tubo. Todas são proprietárias, por isso não fica claro exatamente quais técnicas Aspera e seus concorrentes usam ou exatamente como funcionam.
Existem muitas empresas que inventaram tais sistemas e as fizeram parte de seus próprios produtos ou as venderam como um produto comercial.
Não sei de nenhuma implementação de código aberto no momento. (Eu gostaria de ser corrigido!)
Se este é um problema muito premente e vale a pena gastar dinheiro para consertar, experimente um dos produtos comerciais. Ou, se você não puder alterar seu software, precisará comprar um tubo maior. Felizmente, as interfaces de rede 10G e 40G estão caindo de preço.