[PLUG] Rsyncd And Performance

[Eric Wilhelm]

# from Russell Senior
# on Wednesday 14 February 2007 02:44 pm:

>>>>>> "Jason" == Jason Van Cleve <jvancleve at chrome.com> writes:
>Jason> Thanks, Wil.  What seems implicit in these documents (and what
>Jason> I'm now trying to determine) is that that algorithm only
>Jason> applies when connecting to an rsync daemon on the remote side.

>Huh?  Each side computes its own checksum.  Then the checksums are
> compared.

When connecting via rsh or ssh, the remote shell basically starts rsync 
on the other end (think of it as your own private daemon.)  It's my 
understanding that once you get that far, algorithmically the operation 
is identical. The difference is simply that the communication is 
running (on pipes?) through rsh/ssh vs direct TCP.

If you want to learn more about the innards, lookup how to use your 
authorized_keys files and the SSH_ORIGINAL_COMMAND variable to 
intercept the remote shell command, then figure out how to strace rsync 
on the remote end for extra propeller beanie points.

I imagine there is some overhead to the tunnel, but since the data being 
communicated is "these changed, these did not" sort of stuff, I would 
guess you would only see a noticeable difference when you *benchmark* a 
sync that is pushing a lot of changed data (e.g. full tree to an empty 
one or other significant changeset.)  That really depends on the rsync 
TCP protocol vs ssh, but I believe you're paying for encryption over 
ssh and that may be worth the price.

--Eric
-- 
Atavism  n:  The recurrence of any peculiarity or disease of an ancestor
in a subsequent generation, usually due to genetic recombination.
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------