I've done some tests in the past (but I have to search for my results ...).
Note that these are with 100 Mbs Ethernet.
Recent ones:
Exchange TDP
Exchange DB compressed 50.3 GB - 1:19:30 elapsed time, 10.81 MB/sec (Backup)
Exchange DB uncompressed 63.1 GB - 1:36:30 elapsed time, 11.15 MB/sec
(Backup)
We backup Oracle directly with the b/a client, (No TDP) and always get huge
compressions rates (88% compression).
This was a multi-session backup test a while ago:
(Again on 100 Mbs Ethernet), 9.9GB of source data (compressed to 1.19GB)
elapsed time of 152 seconds - this translates to 65 MB/sec which we could
not achieve with 100 Mbs Ethernet without the compression. (We tend to max
out on CPU on these types of backups).
With client compression on backups you have to make sure no files are
growing during compression and being resent - this will add time to your
backups. We exclude files like .zip etc from compression and also scan the
client logs for any files that grow during compression (you can also use
compressalways to avoid the resends).
I'm going to search for other tests I've done (or do some again) and I'll
post those results.
Tim Rushforth
City of Winnipeg
-----Original Message-----
From: TSM_User [mailto:tsm_user AT YAHOO DOT COM]
Sent: Wednesday, September 22, 2004 12:19 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: D2D on AIX
This is true, I was just wondering if others were seeing the same thing. We
expected it to take longer but not two to three times as long. In the end
after compression there would be less data to transfer so we thought there
would be some gain there.
Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM> wrote:
>Tim, we recently ran a bunch of tests on client side compression.
>In every test the backup ran for 2 to 3 times longer. In some cases
>this wouldn't be a big deal when you look at the backup alone being
>incremental and all. However, we also believed that it would also
>cause the restore to run 2 to 3 times as long to uncompress the data.
>As a result of these tests and thoughts we decided not to
>implement client side compression.
Uncompress should be much faster and less cpu intensive than compression.
In compression you are searching for redundant tokens. In uncompression
you are basically performing token substitution.
Rick
-----------------------------------------
The information contained in this message is intended only for the personal
and confidential use of the recipient(s) named above. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that you
have received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited. If you
have received this communication in error, please notify us immediately,
and delete the original message.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
