I am new with this backup tool and I am very impressed of course.
But I have very serious perf issues over vpn which I cannot get rid of.
I have a folder with about 70 000 files
I want to make a copy of created/modified files, based on archive bit.
let us do a test for explaining my issue.
I set a profile with mode update and "copy only files with archives attributes" flag
no rules for deleting destination files
no rules for copy missing files or folder
no creation of empy folders on destination
for testing, i deleted all archives attributes on source folder, and set an empty folder on destination. This empy folder should remain empty of course, as no archives attributes set.
1) first run
destination = local folder
duration less than 1 minutes - everything OK
1) second run
same profile but destination = network share folder over vpn
duration 7 hours !!!
I can see a small network dialog for each of 70 000 sources files, despite the copy only files with archives attributes, which is the cause of abnormal duration
7 hours for an empty destination folder which should remain empty !!!
the time is consumed with a small network dialog for each of the 70 000 files, for unknown reason as I asked to run only files with archive bit set on
What is wrong?
How the hell can I do something as simple as : just update 2 modified files over vpn within 2 minutes ?
I cannot believe that such a professional tool could be used efficiently only on a Lan !
Please help
Regards
Jim
Very slow update over vpn
-
- Site Admin
- Posts: 4050
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Very slow update over vpn
Can you show me a screenshot of this network dialog that popup for every single file?the time is consumed with a small network dialog for each of the 70 000 files
Hi. Sorry there is no pop up window. What I mean is that I can see on network tcp statistics a small network flow which is related to this low process:
for each source file, even with archive bit sef off, a tcp flow is initiated. For 70 000 files and for specific ping delay over vpn (100ms), we obtain 7 hours of running process for nothing
for information, I cut the profile in 2 chained profiles doing:
1) increment copy to temp local folder
2) moving files from temp local folder to remote folder via vpn
These 2 chained profiles, doing the same, are running in 3 minutes instead of 7 hours.
Regards
Jim
for each source file, even with archive bit sef off, a tcp flow is initiated. For 70 000 files and for specific ping delay over vpn (100ms), we obtain 7 hours of running process for nothing
for information, I cut the profile in 2 chained profiles doing:
1) increment copy to temp local folder
2) moving files from temp local folder to remote folder via vpn
These 2 chained profiles, doing the same, are running in 3 minutes instead of 7 hours.
Regards
Jim
-
- Site Admin
- Posts: 4050
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
the copy process is running in real time and allsync check if every source file is available at the destination. if you start a copy preview and process this copy preview the network overhead will be eliminated because allsync uses the static preview list.
nice solution!for information, I cut the profile in 2 chained profiles doing