On Mon, 2006-02-20 at 21:11 -0800, dean gaudet wrote: > actually we can get rid of ssh entirely as well and just use pipes > between the rdiff-backup and "rdiff-backup --server"... to reduce the > variables even further. > > when i compare: > > rdiff-backup src dst1 > > with: > > rdiff-backup --remote-schema '%s' src 'rdiff-backup --server'::dst2 > > i'm seeing an avg of 0.9s real-time for the first and 1.4s real-time > for the second using an extracted copy of rdiff-backup-1.0.4.tar.gz as > the src. (the results are quite repeatable so i didn't bother with a > larger src.) > > my suspicion would be something serializing in the protocol... > > -dean
Some test results below. Backup src is single 512MB file with urandom stuff. Servers are 3GHz P4 Xeon, gigabit lan. rdiff-backup 1.1.5 / python 2.4.2. Time in SECONDS. 1) rdiff-backup src dst 16.9s 2) rdiff-backup --remote-schema '%s' src 'rdiff-backup --server'::dst 21.3s 3) rdiff-backup -remote-schema 'ssh %s rdiff-backup' server2::src dst 80.0s (76.7s with blowfish and 75.9s with arcfour) 4) rdiff-backup through netcat (no ssh/no encryption) 76.4s (just like with ssh?!) 5) rdiff-backup -remote-schema 'ssh -C %s rdiff-backup' server2::src dst 129.1s (compression makes it so much slower!) 6) scp server2:src/bigfile dst/ 13.6s 7) rsync server2:src/ dst/ 14.1s So, yes, something is wrong with serializing. And looks like it's seriously affected by latency, compare 2) with 3),4). ------ Just in case this is how I run it with netcat. Sure must be an easier way :) On src (remote server2): nc -l -p 5555 <afifo | rdiff-backup --server >afifo On dst (local receiver): rdiff-backup --remote-schema 'nc %s 5555' server2:src dst -- Vadim <[EMAIL PROTECTED]> _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
