The additional testing is nice to see, but you're not thinking the
issues through far enough when it comes to scaling up a service like
this. It's good to benchmark something which hasn't been tested in
some time, but you have to do pretty extensive benchmarks if you're
going to come to any sweeping conclusions for *all* uses of a program.
Let's say rsync takes 10% of the cpu on the client, and 10% of the
cpu on a server. Let's say cvsup for the same update takes 15% CPU
on the client, and 7% on the server. If your benchmarks ignore the
load on the server, then they can not possibly see problems which
could occur when scaling up to more clients.
With a single client connecting to the server, *neither* side is the
bottleneck. It might be the disk-speed is the main bottleneck at that
point. The update might take longer with cvsup due to the 15% CPU on
the client, but the CPU isn't much of a *bottleneck* at that point.
But with 10 connections in my fake scenario, rsync could be using 100%
of the CPU on the server. It's at this point that rsync will see some
bottleneck, while cvsup would only be using 70% of a CPU. Yes, cvsup
will be using much more on each client, but then each client shows up
with it's own CPU(s) to take up whatever load is thrown at that client.
The server does not receive additional CPU's or network-cards for
each connection that it accepts.
Again, my feeling is that rsync is almost certainly fine for using
with dragonfly's repository, given how much faster machines and
networks have gotten, and how many simultaneous connections are seen
for dragonfly repo-servers.
It makes plenty of sense to stick with rsync if your servers are not
overloaded. But if you want to prove rsync is better than cvsup for
what the loads that cvsup was *MEANT* to solve, then your tests are
not extensive enough. Benchmarking a client/server setup like cvsup
is a lot of work to get a complete picture.
Also note that you don't need to "prove" that rsync is "better". If ...
