Re: [rdiff-backup-users] rdiff-backup/rsync +ssh performance comparison

[Vadim Kouzmine]

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 <address@hidden>