[
Lists Home |
Date Index |
Thread Index
]
On Wed, 9 Feb 2005 14:00:38 -0800, Wolfgang Hoschek <whoschek@lbl.gov> wrote:
>
> Better compression does not necessarily equal better performance. GZIP
> is very compute-intensive, it actually degrades performance (while it
> does offer more compression). You can verify this yourself via the
> compressionLevel flag. There's an explicit tradeoff here to be made.
FWIW:
I happen to sit across the hall from the person who provisions
hardware for much of the group. When an interesting new box comes in,
and I have the time I'll put it though it's paces. At the moment I
happen to be using a high end workstation with dual 2.8 Ghz Xeon's.
Problem is, it was provisioned with 7200 RPM drives configured RAID 1,
it spends most of it's time in IO wait.
As an experiment I tried turning on Windows disk compression, the
rational being smaller amounts of data back and forth from disk would
result in relatively faster IO at the expense of CPU which I appeared
ot have excessive amounts of. No such luck; my benchmark scratch
compile (about 880 Java classes) went from 22 seconds to about 34
seconds. By comparison, a single 2.8 Ghz CPU system with 10K RPM
disks configured RAID 0 can do the compile in around 10 seconds.
Now if I had the ability to fine tune the Windows disk compression
settings the results might have been different.
--
Peter Hunsberger
|
