Desempenho lento do msysGit na unidade de rede mapeada

Question

Eu tenho um servidor web de desenvolvimento com um diretório de aplicativo mapeado para minha máquina local como a unidade Z: (por exemplo, \\ web_server \ wwwroot). A pasta compartilhada requer credenciais de domínio para acesso (minha conta de domínio é uma coproprietária na pasta).

Eu consigo ler e gravar arquivos, mas o desempenho do msysGit é lento.

servidor da Web:

patrick@web_server /c/inetpub/wwwroot (master) $ time git status > /dev/null
real    0m1.887s
user    0m0.015s
sys     0m0.015s

Máquina local (acessando a unidade de rede mapeada Z)

patrick@local_machine /z (master) $ time git status > /dev/null
real    0m25.500s
user    0m0.000s
sys     0m0.015s

Como posso resolver o que está causando o atraso de 25 segundos?

    

Answer 1

git status é um comando que lê e grava muitos arquivos. O armazenamento em rede, mesmo em algumas conexões de rede local, pode ser inaceitavelmente lento ao lidar com muitos arquivos ou muitos dados, ou ambos.

O problema é que o SMB (Server Message Block, também conhecido como Samba, também conhecido como Windows File Sharing) é um protocolo muito "tagarela", enviando lotes de pequenos pacotes para frente e para trás, e requer um < strong> boatload de "app turns", que aumenta o volume de dados que você precisa. Um "turno" é uma viagem de ida e volta entre o cliente e o servidor.

Algumas coisas:

• Experimente ping ing seu host remoto de sua máquina local. Se for mais de 5 milissegundos, o armazenamento em rede provavelmente não é adequado para muito mais do que carregar alguns kilobytes em um punhado de arquivos. Verifique também se há jitter e perda de pacotes. O jitter é quando o ping é altamente variável entre valores diferentes, e a perda de pacotes é quando um ping é completamente descartado (ele não é respondido). Ambos são deficiências muito ruins, quase tão ruins quanto a latência.

• Tente usar o WireShark para observar o tráfego entre seu host e seu roteador ao fazer git status . Você provavelmente verá muito solicitações TCP que são mais ou menos assim:

• O pacote sai da sua máquina

• Sua máquina aguarda (não faz nada)
• O servidor envia resposta

Para cada pacote originado de seu computador e destinado à caixa remota, rotule esse pacote "O" para "saída". Para cada pacote originado da caixa remota e destinado ao seu computador, rotule esse pacote "I" para "entrada".

• Conte o número de pacotes "I" seguidos sem nenhum pacote "O" entre eles.
• Conte o número de pacotes "O" seguidos sem nenhum pacote "I" entre eles.
• Crie uma relação aproximada do número de pacotes "I" com o número de pacotes "O".
• Se você estiver lendo arquivos (download), e a proporção não for altamente em favor de "I" pacotes (pacotes entrando em seu computador), então o protocolo é chatty .
• Se você estiver escrevendo (carregando ou modificando) arquivos, e a proporção não for altamente em favor de pacotes "O" (pacotes originados de seu computador), então o protocolo é chatty .
• Verifique o tamanho de cada pacote em relação à taxa de transferência de sua conexão esperada em um download HTTP bruto de um arquivo grande.
• Multiplique a latência do número de viagens de ida e volta e adicione o tempo de transferência dos arquivos para obter um número que deve ser em torno de 25 segundos.

Solução: reduza a latência ou use uma versão mais recente do protocolo SMB como suportado pelas versões mais recentes do Windows Server (que têm menos voltas de aplicativos e, portanto, maior desempenho em uma WAN) ou use algo como FTP com baixíssima (mas ainda alta sobrecarga ao acessar muitos arquivos), ou apenas operar diretamente no servidor e apenas transferir dados conforme necessário em massa (por exemplo, arquivos zip) para o servidor remoto.

    

Answer 2

Veja esta questão para coisas que você pode fazer para acelerar a unidade de rede, como colocá-la no modo "link lento" para que os arquivos sejam eventualmente sincronizados. Isso ajuda muito porque você está lendo e gravando no disco local em vez da rede.