Re: Client Compression question

> One thing though, is that you shouldn't use
> Compress Always. This can really slow things
> down.

I'm curious why you say this. COMPRESSALWAYS YES was added a while back as 
a performance enhancement. If you set COMPRESSALWAYS NO, if a compressed 
file grows, then the entire transaction needs to be retried, which impacts 
performance.

I suppose if the file were to grow substantially, then the time it takes 
to "compress" the growing file could exceed the time it would take to 
retry the transaction. But I would think that would be a very rare 
circumstance indeed.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Daniel Sparrman <daniel.sparrman AT EXIST DOT SE>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/10/2002 02:06
Please respond to "ADSM: Dist Stor Manager"

 
        To:     ADSM-L AT VM.MARIST DOT EDU
        cc: 
        Subject:        Re: Client Compression question

 

Hi

Normally, with powerful servers, the impact of compression wouldn't be 
that
much.

Client compression means you put a lot of load on the client, because it
has to do the compression.

With a P3 1Ghz machine, this impact shouldn't be noticable. We're running
50 servers with client compression, and we're having about 6-7 MB/s on a
100MB/s ethernet. Thats the Network Throughput.

What you should look for is also the Aggregate Data Rate. Normally, the
Network Throughput is just how fast your LAN is. But with compression
enabled, the data throughput should be greater than the Network 
Throughput.

One thing though, is that you shouldn't use Compress Always. This can
really slow things down.

Another thing to look at his to see if your clients are optimized.
Normally, the later TSM clients have good performance, thought client
before 4.2.1.15 has had bad perfomance.

Therefore, take a look at your options file, and upgrade the clients to
4.2.1.15 or 4.2.1.18. This should increase your performance.

Best Regards

Daniel Sparrman
-----------------------------------
Daniel Sparrman
Daniel Sparrman
Exist i Stockholm AB
Bergkällavägen 31D
192 79 SOLLENTUNA
Växel: 08 - 754 98 00
Mobil: 070 - 399 27 51


  
                    Kevin  
                    <kevin@STORAG        To:     ADSM-L AT VM.MARIST DOT EDU    
                    EPIPE.COM>           cc:  
                    Sent by:             Subject:     Re: Client 
Compression question 
                    "ADSM: Dist  
                    Stor Manager"  
                    <ADSM-L AT VM DOT MA  
                    RIST.EDU>  
  
  
                    2002-01-09  
                    21:11  
                    Please  
                    respond to  
                    "ADSM: Dist  
                    Stor Manager"  
  
  




Hi Stefan,

Using compression will really slow down the backup - mostly in backup
mode, but in restore as well. If you set the format parameter in the
device class to drive (instead of a fixed number) you will get both the
benefit of a dynamic device class with regard to number of drives (for
additional drive installations and drive failure(s)) and you will enable
automatic hardware compression. This compression is better than the
software based compression, however when the system is queried, the
number returned will reflect raw data sizes, not compressed data sizes.
Client side (software based) compression or server side (software based
compression) will work in conjunction with library based hardware
compression however you will not receive any compression benefit by
running both and the numbers returned upon query will not reflect the
actual size of data on the tape. In some cases an already compressed
file has taken 15 minutes while software based compression tried to
re-compress it. The impact is not small.

Remember, this is based on the device class specification of
format=drive, and may not be applicable to all drives, but only those
with compression capabilities. We currently use LTO based native fiber
drives.

Choosing one method of compression over the other will improve
performance and specifying hardware compression while forcing off
software compression should really improve performance.

Another neat performance tuning trick (as I'm sure you already know) is
to backup to a hard drive initially, and then force migration (set the
pool to migrate hi=0 lo=0 in a script, and then set it back to normal
again after an hour or so) to de-stage the data off the hard disk and
onto tape. This allows multiple sessions (sessions are not limited to
number of available tape drives) and hard disk is generally faster as a
storage pool.

Let me know if this helps,

Kevin.