In <0012900002928762000002*@MHS>, on 03/19/98
   at 03:18 PM, Jerry Lawson <jlawson AT THEHARTFORD DOT COM> said:

>---------------------------- Forwarded with Changes
>---------------------------
>From: INTERNET.OWNERAD at SNADGATE
>Date: 3/19/98 3:47AM
>To: Jerry Lawson at ASUPO
>*To: *ADSM-L at SNADGATE
>Subject: Re: Compressalways option for V3 client
>-------------------------------------------------------------------------------
>> This is why COMPRESSALWAYS default is YES.  It will have NO effect unless
>> COMPRESSION is also ON.

>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

I intend to use compressalways=yes so I am satisfied with the default. It
fits with the total package of end to end performance improvements available
in version 3.  The major part of this is aggregates.  The bigger each
aggregate is the better, less server cpu cycles for commit processing and
faster migration and reclaims (when reclaim stops losing files that is).

So how do we make big aggregates?  By putting TXNGROUPMAX in the server to
256 and TXNBYTELIMIT to 25600 in the client.  These values say make an
aggregate of up to 256 files or 25.6 Mb whichever happens first. These
values introduce a problem though, namely the chance of hitting a
non-compressing file in the middle of a transaction goes up. Without CA=yes
all the work done on the transaction up to this point is thrown away, then
all the files in the transaction are sent again uncompressed and finally the
trouble making file is sent.  So to save sending 20% growth of a 100K zip
file, we resend on average 12.8 Mb.  It isn't worth it!

We up desktop systems, lots of little files so I expect to
see a big gain from aggregates.  Someone who is backing up large files will
see less of a performance gain as the number of files in an  aggregate goes
down.

I think IBM choose the default with this in mind.  And the default for disk
storagepool caching is NO.  Are they trying to tell us something?

I remember when version 3 was announced IBM saying that some
performance studies would be published.  Where are they?  They
would be real helpful on this issue I'm sure.
--
-----------------------------------------------------------
-----------------------------------------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma
bcolwell AT draper DOT com
-----------------------------------------------------------
=========================================================================