benchmarking rsync's -z compression utility

[jw schultz]

On Sat, May 10, 2003 at 05:58:57PM +0800, Leaw, Chern Jian wrote:
> Hi,
> Is there a way in which rsync's -z compression (zlib) utility can be
> benchmarked? 

In a way.  It depends on what you are benchmarking.  There
are many things you can measure,  There is disk load, CPU
load, memory usage and network load.  Obviously compression
will cost you CPU but how much and for what gains.  The most
important measure would be the network load.  A packet
sniffer or similar tool would be the best method.  Second
most important would be to measure wall-clock time.

> I'm trying to compare the compression ratio between rsync and external
> compression tools like gzip and bzip2. 

Perhaps when you are done you might compare apples to
baboons.

If you want to compare the effectiveness of rsync's
internal compression with an extern compression you would
compare against the compression in ssh or of a vpn tunnel.

> Are there any advantages to using rsync's internal compression mechanism
> specified with the -z option compared to solely applying external
> compression i.e. bzip2 to the files and invoking rsync to transfer these
> files without the -z option?

The point or rsync is to synchronise.  It can synchronise
compressed files but the compression tends to defeat the
efficiency of rsync and depending on the actual compression
method and file content may result in increased network
load.  There is an rsyncable patch available for gzip that
reduces the adverse affect compression has on rsync.

If your question is whether it is faster or less network
load use rsync -z or another method to copy to an empty
destination scp -C or a tar/cpio pipeline with compression
will almost certainly preform better.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt