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:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 12:19 PM To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
