• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1238
  • Last Modified:

VPN slow to copy small files

We have a site to site VPN to a data center that has our web hosting.  Our side is a sonicwall NSA 2400 and their side is some sort of Cisco VPN concentrator (I've only got control of one side).  We need to transfer sites we develop across this VPN.

Large groups of small files are very slow across the VPN.  As an example, I have been using a directory with ~6500 files that is about 32MB.  If I copy it as is it takes something north of an hour.  If I ZIP it first it takes 2 minutes.  The compressed file is about 14MB.

Doing the same file transfers within either network is fast.

We have a 10MB EFM circuit here and I don't know exactly what is at the other side but when I test it we get ~50MB up and down.  Latency between locations across the VPN averages about 90ms.

On both sides of the file copy operation we have windows 2008 R2 x64 servers.  File transfers to and from the same servers within the LAN go normal speed.

The server on the remote side is a hyper-v guest.

What I have tried with little or no improvement:
Dialing back the encryption from AES-128 to 3Des to possibly reduce that overhead
Uninstalled all AV software on both sides.
Used both robocopy and richcopy with multithreading which helped some
disabled all the TCP offload settings on the test devices
Used FTP instead of windows file copy
disabled the site to site VPN, used the Cisco VPN client instead.
disabled all of the IPS/GAV/Spyware services on the sonicwall firewall

Any ideas here?  My developers are not thrilled by the prospect of having to deal with zipping their sites to upload them.
1 Solution
When you do the file transfers, are you using normal Windows SMB/CIFS transfer, such as using Windows Explorer? If so, SMB is notoriously bloated in header information for files, so you spend more time initiating a transfer for a file than actually sending the file itself if it's very small. When you ZIP it, you are creating a single file with one set of header info and then just a stream of binary data to transmit so it's much more efficient. I would try setting up an FTP server on the receiving end and try that as it's much more efficient at transferring files. See if that helps at all. In the end if that doesn't help as much as you'd like, you may be stuck with wrapping the files in some sort of container. It doesn't have to be compressed with ZIP necessarily, you could just do a TAR or something like that to put the files into a container.
Copying small files will always take more time than a single file. It is not a problem with VPN connection.
take a usb flash drive.
copy a bunch of small files (10000 or more to see visual difference) with total size around x MB.
try copying a single file of same size x MB to the flash drive.  calculate time for both operation
You can see lot of differences.

The same test can be tested within a single HDD as well. Reason is that, there are lot of overhead other then network like header info of each file etc. apart from that ..
if you see the number of packets will be different for each file you cant use the entire MTU of ethernet.

If you transfer 100 files of size 500 byte each, there will be 100 packets file data + 100 headers for file information + some overhead
If you transfer a single file with 50000 (500*100) bytes, the nmuber of packets will be 1 header with file information + 50 packets with file data (i have taken 1000 bytes as MTU) + some overhead
so it is the time difference between ~50 packets version ~200 packets

Hope this helps
John HurstBusiness Consultant (Owner)Commented:
As noted above, Windows browsing is a slow way to do things across VPN.

So in addition, two things:
1. VPN uses the slow part of DSL (upload vs. download) and VPN speeds will always be slower.
2. Default MTU in your routers boxes is 1500 and that fragments VPN packets, slowing things down even further. Set the MTU in your router boxes to 1492 or a bit less and see if that helps.

... Thinkpads_User
firstcallAuthor Commented:
Not sure how this got in cygwin...  oops

FTP did not make any difference as far as I could tell.

It is just a straight windows file copy and I was afraid of that.
I would check the MTU settings at each side just to make sure, but honestly it does sound like standard SMB inefficiency to me.

Featured Post

A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now