This is where I have a problem with the Compressalways default being YES instead
of NO.
My logic is as follows:
If compression is turned off, then the compressalways parm is ignored. What
difference does the default make in this situation?
If compression is turned on, setting the default to compressalways YES changes
the way the client works. (It no longer stops when growth is detected - it just
keeps on trucking.) The net result would be an increased use of storage pool
resources; in some case a rather significant amount (as much as 50% was quoted
to me by IBM). Additionally, if caching is turned on, failures can occur
(ANR0534 messages resulting in files not being backed up.) in one case, for us,
it was over 150 files.
I am of the opinion that the default for compressalways would be less obtrusive
if it were NO. This would induce less change to existing clients, and then
those that have a real issue with the overhead of the retires could change to
YES as needed. As it is, the impact to my customers when they roll out V3
clients is very pervasive.
Any comments?
Jerry Lawson
jlawson AT thehartford DOT com
______________________________ Forward Header __________________________________
Subject: Re: Compressalways option for V3 client
Author: INTERNET.OWNERAD at SNADGATE
Date: 3/19/98 3:47 AM
Maybe there is a slight confusion as to what COMPRESSALWAYS does.
Basically, if compressing an object causes it to grow (if already compressed,
for instance),
ADSM would retry, turning off compression for that object. If this happens a
lot, this is clearly
a performance overhead.
COMPRESSALWAYS YES says that even if the object grows, go ahead and send this
compressed
(larger) object anyway. This removes the performance overhead, but again if
you have too many, you
are sending more than you need to, so turning COMPESSION off is the answer.
This is why COMPRESSALWAYS default is YES. It will have NO effect unless
COMPRESSION is
also ON.
Hopefully, this will remove some of the confusion.....
>I noticed the default in the V3 client has changed from compressalways NO
>to compressalways YES.
>We don't use compression in any of our large local clients because it's
>always been faster to not compress.
>Have any of you switched from no compression to compression with your v3
>rollouts? Is compression now significantly faster to justify this change
>of default?
>Should I use the new capability with V3 on the host to change all the
>clients back to compressalways NO?
>Thanks,
>Julie
|
