On Sun, Sep 10, 2000 at 11:36:17AM +0530, Raja Prasad Rao wrote:
> I'ld like to know how exactly does this Global option "-z" work? I only know
> that it has got to do with compression and we have to chose a level between
> 1 to 9 along with -z.
If you use use -z it does choose a default. Level 3 I think, but perhaps
6.
I did a significant amount of testing using cvs over ssh and trying all
combinations of compression via ssh and cvs. They both use the gzip
compression method (both using zlib?). Yeah, I didn't expect compressed
cvs over compressed ssh to be effective, but it was easy enough to set up
the experiment so I did it. :-> The experiments were being done of a 33.6
modem. I no longer have the hard number though.
I noticed that once I started actually using compression, I quickly hit the
diminishing return of value for cost.
The biggest savings was using compression at all. That was, I *think*
about an order of magnitude savings. Using the highest compression didn't
gain much more (though the server I was testing against was a 486 using IDE
drives too, so the CPU was also busy doing those things).
If you plan on having a lot of people hitting the server at once, I'd
recommend a lower compression level. It will give you substantial savings
in the amount of network traffic, without stressing the server too much.
Many Internet based anonymous sites recommend -z3.
> The problem is we are having our repository in NewYork while quite a bit of
> development work is carried out in Hyderabad. So we checkout/update quite a
> bit from this remote location, which is normally quite time consuming? Can I
> actually expect to save significantly by going for this -z option?? While I
> experiment upon time saving by comparing the time with and without -z
> option. But the timings seem to depend a lot more on the actual network
> traffic at that point in time.
You really shouldn't need to do that many checkouts. You could take a lead
from Mozilla, and do a checkout off the mainbranch once, tar it up and put
it away. Then, when someone wants to get a new repository, they start off
with untarring that, then do a cvs update. Since update -r will move you
back and forth between branches, it will work for any branch you need.
This will allow CVS to send the minimal amount of into it needs too (files
that haven't changed aren't fetched, CVS will determine whether it's
cheaper to send a new file or a patch).
You could even automate updating this tar file once a month or so, so it
doesn't get too out of date.
You should be able to expect a savings in the amount of data sent across
the wire using -z. I can't remember off the top of my head if CVS has an
option for counting bytes sent across, but, if you can set up CVS to run
over ssh, do the following:
Create a shell script called ssh-v with the contents:
#!/bin/sh
ssh -v $*
Then, set CVS_RSH to use ssh-v instead of ssh. When you run CVS over
ssh-v, it will spit the number of bytes sent across the wire. You can then
change .ssh/config to use various levels of compression, and see how that
affects the number of bytes sent. Of course the numbers won't match
exactly what CVS would do (after all, running over ssh will compress the
CVS protocol as well, which I'm not sure if CVS does or not, or just the
data). But it will give you reasonable estimates. If you end up paying
per byte sent, this can be a benefit.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
