Desenvolvedores estão tendo um desempenho muito ruim com o Windows Explorer, particularmente adicionando / excluindo arquivos, através de VPN para compartilhamento Win2k3

Question

Temos a seguinte disposição: Dev Site < - vpn - > Site de Prod. O firewall do site Prod, executando o pfSense 2, aceita tráfego VPN TCP / UDP nas portas SMB 135-139 e 445. Nossos desenvolvedores podem se conectar a compartilhamentos administrativos \Computer\C$ sem incidentes e, na verdade, fazer o upload de arquivos individuais para o compartilhamento é bastante rápido 200 a 300 kilobytes por segundo. No entanto, ao tentar executar uma exclusão de uma pasta com muitas subpastas / arquivos, ou carregar muitos arquivos individuais, ou modificar muitos arquivos individuais, o explorador fica paralisado, geralmente trabalhando em torno de 2 a 4 arquivos por segundo (mesmo que estejam < 1kb). Isso é muito doloroso ao executar trabalhos de sincronização, etc. Essa falta de velocidade foi confirmada para clientes Windows XP, 2k3 Server e Windows 7. O servidor em questão está executando o Win2k3.

Algumas perguntas:

1. Existe algo que eu possa fazer com o firewall para melhorar o desempenho? Como eu poderia dizer se era um problema de firewall?
2. Existe algo que eu possa fazer com o servidor para melhorar o desempenho?
3. Há mais alguma coisa que eu possa fazer para melhorar o desempenho do compartilhamento de arquivos do Windows?

Answer 1

Você deve verificar a largura de banda do ISP do seu escritório para certificar-se de que não está com excesso de assinaturas e pode usar o ping para testar a latência entre os desenvolvedores remotos e o servidor. Meu palpite é que nenhum dos dois será o caso, já que você descobriu que o desempenho do SMB em uma VPN geralmente é ruim.

Sua solução é encontrar outra maneira para esses usuários remotos manipularem arquivos. Você poderia tentar FTP, mas isso introduz outro protocolo, e FTP por si só não é particularmente seguro (melhor através da VPN). Mas a sua melhor aposta é dar aos usuários a área de trabalho remota para o servidor e fazê-los fazer as exclusões lá. Para uploads em massa, eles podem fazer upload de um arquivo ZIP e descompactá-lo no servidor por meio de uma área de trabalho remota.

A questão dos trabalhos de sincronização é desafiadora, porque você provavelmente faz precisa examinar cada arquivo. Se o trabalho de sincronização puder ser executado sobre outros protocolos (psexec, FTP, SFTP, SCP, etc.) que provavelmente seriam mais rápidos.

    

Answer 2

Bem-vindo ao maravilhoso mundo do SMB em relação a qualquer conexão com latência maior que a LAN. Tudo o que você descreve é perfeitamente normal para tais cenários, uma vez que você tem mais de 20 ms, as coisas ficam significativamente mais lentas, acima de 50 ms, e é doloroso. O protocolo é muito mal projetado para conexões com latências mais altas do que a LAN. Especialmente ao trabalhar com compartilhamentos com muitos arquivos e / ou diretórios.

O SMBv2 corrigiu isso em algum grau. Se você tem estritamente o Server 2008 com o Vista ou com clientes mais novos, não será tão ruim.

Consulte "Problemas de desempenho" aqui para mais informações detalhadas: link

    

Answer 3

Também pode haver um problema com os pacotes sendo fragmentados - nesse caso, você pode tentar ajustar o MTU entre os links (embora isso possa não ser possível com a conexão na VPN). Por exemplo, na minha área de trabalho - não consigo enviar um ping maior que 1472 sem precisar ser dividido em vários pacotes (Win7 - > Win2008R2):

ping -f -l 1472 10.1.10.3

O argumento -f é o sinalizador não fragmentado e o -l é o tamanho. Gostaria de sugerir a partir de 1500 e trabalhar o seu caminho.