Eric,
I agree that your speed test in item #2 would be valid if the clients
were backed up one at a time. That is, the time lost to cpu compression
would be wasted. However, if several clients are backed up
simultaneously, that time is not wasted, it is used by other clients
sending their data up the line. This results in the benefits of
compression at no cost.
As far as restores go, decompression of files is usually an order of
magnitude faster than compression, so the CPU use is low. Furthermore,
CPU time is far overshadowed by other limiting factors such as line
speed, tape speed, and ADSM server overhead.
As a rule of thumb, we compress data unless we know it to be already
compressed on the client. Such a case would be an NT folder that is
always compressed, a full backup of a Netware server, or a file type
that is compressed in its native state, such as a disk full of nothing
but JPEG's.
As a final comment (for Netware users), some people never compress
Netware data because they know Netware automatically compresses files
after a 'non-usage' delay (and decompresses upon use). However, this
delay is usually on the order of one or two days. So the compressed
data is the data that has NOT changed and will not be backed up. On the
other hand, the data that HAS changed is uncompressed and would benefit
from ADSM client compression. So, depending upon your compression
delay, Netware may well benefit from compression.
My 2k,
Ron Clendenny
Callaway Nuclear Plant
Fulton, Missouri
<rdclendenny AT cal.ameren DOT com>
> -----Original Message-----
> From: Eric van Loon [SMTP:evanloon AT KLM DOT NL]
> Sent: Wednesday, April 08, 1998 8:30 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Compression
>
> Hi Rob,
> I haven't encountered problems related to compression yet.
> My view is that there are three considerations before using
> compression on the client:
> 1) If the client has enough processing power you can use compression.
> I wouldn't recommend it for 286, 386 or 486 clients if it's not
> absolutely necessary.
> 2) If your network speed is high enough I shouldn't use compression.
> It can slow down your backups. You should test this in your
> environment. Just take a large file and backup it twice, once with
> compression=yes and once with compression=no and measure the elapse
> time. My experience is that one should use compression over a 4 Mb.
> Token-Ring network an one should turn of compression when using 16 Mb.
> Token-Ring, 100 Mb. Fast Ethernet or equivalent networks.
> Because decompressing files is less CPU consuming restoring compressed
> files over a slow network will probably be faster than restoring
> uncompressed files over a faster network. Again, you should test this.
> 3) If your do not compress files you server's primary storage pool
> will much faster be filled. You will also probably use more tapes,
> unless you have a tape unit which uses hardware compression (like
> 3490, 3495, Magstar or Magstar MP units).
> Kindest regards,
> Eric van Loon
>
> ----------
> From: Rob Middleton
> Sent: dinsdag 7 april 1998 23:39
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Compression
>
> Hello Folks
>
> I would like to know peoples experiences with compression (ON or OFF).
> We
> are NT 4.0 Client 2.1.0.6. backing up to AIX server. We have some
> clients
> using compression and some not. From your experiences, are there any
> problems with restoring, etc. to look out for? Is it recommended or
> not??
> Should I or shouldn't I? Any guidance or suggestions would be much
> appreciated....
>
> Regards.....Rob
|
