Re: compressed cache store

True, if you have the spare CPU time to compress the data.

Also, with object grouping alone one can acheive a fairly large
"compression" factor (20-30% not unrealistic) compared to store each
file in it's own block, even if such techniques isn't really
compression, only by eleminating the dead space. (the data stays
literally identical, only difference is in the amount of wasted space
around your data).

Regarding seek times. Sure This can also be done. I estimate seek times
in Squid can be reduced about 100 times on writes and 20 times for reads
from the current design. But this is not actually related much to
compression, more about planning your I/O correctly.

Regards
Henrik

Roger Venning wrote:
>
> Hi guys,
>
> I saw a talk by a Hugh Williams (http://goanna.cs.rmit.edu.au/~hugh/)
> recently. During which he mentioned the result of one aspect of work on
> building fast web search engines - essentially compressed disk storage
> of objects that are later retrieved for summarisation. He claimed that
> the benefits of compression were that you could rip data off disk faster
> and (more dubiously) reduce seek time.
>
> Does anyone on the list have any feelings (or knowledge of prior work)
> about this idea? I'm thinking of trying my hand at implementing
> something, as the idea intrigues me. Obviously there might be issues in
> the restrictions on the way that objects are retrieved from disk and
> returned to clients.
>
> Roger.
Received on Mon Oct 29 2001 - 08:22:22 MST