Subject | Re: Blob Compress -- Some Numbers |
---|---|
Author | Aleksey Karyakin |
Post date | 2005-05-19T20:54:15Z |
--- In Firebird-Architect@yahoogroups.com, "Miroslav Penchev"
<miroslavp@m...> wrote:
I/O, you should consider latency and throughput separately.
Compression can improve throughput at cost of more CPU cycles and can
do nothing against latency of random page reads. Before answering "I
don't care about cheap CPU cycles", consider that there is another,
trivial and almost linear way of disk throughput scaling - using
RAID. Top TPC-C tests employ some hundreds SCSI disks in parallel.
Targeting the same degree of CPU scaling is much more difficult,
isn't it?
Regards,
Aleksey Karyakin
<miroslavp@m...> wrote:
>space on
> The main idea of compressed blob was not to gain little more free
> HDD. The main idea is to decrease the amount of reading datefrom "slow"
> HDD by compressed data and by this way to gain in performance ofserver
> and client (also reducing data transferred on the wire).It may not be so easy. To estimate the performance effect of disk
I/O, you should consider latency and throughput separately.
Compression can improve throughput at cost of more CPU cycles and can
do nothing against latency of random page reads. Before answering "I
don't care about cheap CPU cycles", consider that there is another,
trivial and almost linear way of disk throughput scaling - using
RAID. Top TPC-C tests employ some hundreds SCSI disks in parallel.
Targeting the same degree of CPU scaling is much more difficult,
isn't it?
Regards,
Aleksey Karyakin