ADSM-L

Re: Encryption and Compression

2004-08-11 11:18:27
Subject: Re: Encryption and Compression
From: Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 11 Aug 2004 11:17:24 -0400
> My questions:
> 1) Why does the client 'with encryption' have objects compressed by 0%,
> when 'without encryption' is 36%. Does encryption nullify compression?

It isn't supposed to. I once attended an IBM presentation on then new TSM
features. The speaker claimed that compression was done before encryption
if the configuration files called for both compression and encryption.
I ran tests similar to the ones you describe. I don't remember seeing
compression change when encryption was enabled.

> 2) 'with encryption' data transfer time is 945 secs (10+ mins). Yet the
> elapsed time is only 6mins?

TSM 5.1 clients suffer from a large family of bugs resulting in incorrect
summary statistics. I don't remember offhand which of these bugs are still
around at the 5.1.5 service level.

> When i run this as a production backup, i will have maybe 30-40gb to backup
> and i was trying to estimate how much time this would take. I read on
> Richards' notes that encryption will seriosly slow down the time taken to
> backup. The test backup was only 528mb, yet the encryption backup was
> faster.

The tests I mentioned above included several backups with encryption and
several without. The scatter among the elapsed time values for each group
was larger than the difference between the means of the two groups. In
other words, the performance penalty for encryption was so small that it
was lost in the noise introduced by contention with other processes and
other network traffic. This was true even though our tests were run on
one of the oldest and slowest systems we owned (an HP K210, to be exact).

There are also some subtle ways to introduce bias into this kind of test.
For example, some disk subsystems have caches measured in gigabytes. If
a file that fits in cache is read twice, the second read is likely to
be much faster than the first one.

<Prev in Thread] Current Thread [Next in Thread>