2

We have the following arrangement: Dev Site <--vpn--> Prod Site. The Prod Site firewall, running pfSense 2, accepts VPN TCP/UDP traffic on SMB ports 135-139 and 445. Our developers can connect to administrative shares \\Computer\C$ without incident, and actually uploading individual files to the share is fairly breezy at around 200-300 kilobytes per second. However, when attempting to perform a deletion of a folder with many subfolders/files, or uploading many individual files, or modifying many individual files, the explorer grinds to a halt, usually working around 2-4 FILES per second (even if they are <1kb). This works out to be very painful when running sync jobs, etc. This lack of speed has been confirmed for Windows XP, 2k3 Server, and Windows 7 clients. The server in question is running Win2k3.

Some questions:

  1. Is there something I can do with the firewall to improve performance? How could I tell if it were a firewall issue?
  2. Is there something I can do with the server to improve performance?
  3. Is there anything else I can do to improve Windows file sharing performance?
4
  • 3
    Accessing Windows file shares over a VPN has never been good in my experience, and is never likely to be good. There's too much protocol overhead related to SMB.
    – joeqwerty
    May 11, 2012 at 16:14
  • 2
    Yup. I'd look at something like psexec and allow the users to initiate deletions of large numbers of files/folders "locally" through the remote shell; that'll minimize the round trip/enumeration overhead. That or RDP, if they're not handy with the command line.
    – gravyface
    May 11, 2012 at 16:26
  • @joeqwerty, gravyface thank you... I'll look into an alternative approach. May 11, 2012 at 17:31
  • Glad to help...
    – joeqwerty
    May 11, 2012 at 17:38

3 Answers 3

1

You should certainly check your office ISP's bandwidth to make sure it isn't oversubscribed, and you can use ping to test latency between the remote developers and your server. My guess is that neither will be the case, as you've discovered that SMB performance over a VPN generally stinks.

Your solution is to find another way for these remote users to manipulate files. You could try FTP, but that introduces another protocol, and FTP by itself is not particularly secure (better over the VPN). But your best bet is to give the users remote desktop to the server and have them do the deletions there. For mass uploads, they could upload a ZIP file and uncompress it on the server via remote desktop.

The question of sync jobs is challenging, because you most likely do have to look at each file. If the sync job can run over other protocols (psexec, FTP, SFTP, SCP, etc) that would likely be speedier.

5

Welcome to the wonderful world of SMB over any connection with higher than LAN latency. Everything you describe is perfectly normal for such scenarios, once you're over 20 ms things get significantly slower, in excess of 50 ms and it's painfully so. The protocol is very poorly designed for connections with higher than LAN latencies. Especially when working with shares with lots of files and/or directories.

SMBv2 has fixed that to some degree. If you have strictly Server 2008 with Vista or newer clients, it won't be as bad.

See "Performance issues" here for more in depth info: http://en.wikipedia.org/wiki/Server_Message_Block

0

There may also be an issue with packets being fragmented - in which case you can try to adjust the MTU between links (though this may not be possible with the connection under the VPN). For example, on my desktop - I can't send a ping larger than 1472 without it needing to be split into multiple packets (Win7 -> Win2008R2):

ping -f -l 1472 10.1.10.3

The -f argument is the don't fragment flag, and the -l is the size. I would suggest starting at 1500 and working your way down.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .