Re: Features

> There is a major problem here though when you are running a large cache and
> have run into the maximum your hardware allows, which I would definately
> believe is out there when you are referring to the Intel Architecture
> (mainly ram).

NOVM? :)

> As for CPU hit, the only way I can see of truely avoiding this, is allowing
> some use of a plug in compression card. The problems here of course are
> that the few that are available most likely have very little support,
> and/or example code, and would have to vary for platform to platform, if
> some platforms have them at all!

In regards to CPU problems -> a p166mmx on a lightly loaded cache
(3000 requests/hour max), 25gb cache_swap, running NOVM eats only 1% CPU
.. considering that a PPro200 or something along those lines can be bought
for peanuts(1) and the average pro board will take 1Gb of RAM anyway... I
don't see a problem with RAM or CPU..

Have a flag in the cache_host directive for "compression support" on a
particular host and everything is happy... perhaps more options for
sending "compression_detect" requests etc for clients could be added
too... (hey, the next version of navigator could even be squid-compression
enabled too! *grin* => considering that most people use Squid as their
proxy, this isn't as insane as it sounds... :)

1. compared to bandwidth pricing..

>
> However it gets developed, use some easy "replacable" way to implement the
> compression/decompression. Some type of negotiation header (at the start of
> a persistent connection) wouldn't go amiss either...
>
> -=[ Stuart Young (Aka Cefiar) ]=--------------------------------------
> | http://amarok.glasswings.com.au/ | [email protected] |
> ----------------------------------------------------------------------
> | Jake and Elwood - The Blues Brothers! |
> | "You traded it?! You traded the Blues Mobile for this?" |
> | "No. For a microphone." "A microphone? OK I can see that." |
>
Received on Mon Nov 24 1997 - 02:53:07 MST