Re: [squid-users] Squid Hardware requirements.

On Sat, Jun 15, 2013 at 2:21 AM, Marcus Kool
<marcus.kool_at_urlfilterdb.com> wrote:
>>> The 14 MB per GB is documented in the Squid wiki and based on the
>>> observation that the avergae object size is 13 KB.
>>> If you only have 20-30% of the formula you may have a larger average
>>> object size or only use 20-30% of the confgured disk cache.
>>
>> Yes, it may be documented. You forgot the IF's and MAY's. IF's and
>> MAY's are very important. IF it applies to you, or it MAY apply to
>> you, Try not to quote things without qualifications or understanding.
>
> No. The FAQ is pretty clear about how many bytes are required per cached
> object.
> No IF's or MAY's.

No problems with that - bytes required per cached object.

Which is different from "14 MB per GB" based on the *assumption* of
13KB average object size. It will only apply IF the average size is
13KB.

> Eh? the "problem" of a web proxy is to serve HTTP/S requests as fast
> as possible. As memory is the fastest medium for caching objects,
> it is valid to go for a lot of memory.

Only if the objects you want can be found in cache. It doesn't follow
that when you have more memory, it automatically means it contains the
objects you want. It is true that a larger cache will increase the
chances of finding a required object, but it's not a linear
relationship -- it's a relationship that will taper off after some
point.

> A simple "Buy what will provide benefits in relation
> to cost" does not answer the question nor offers any help.

That was in response to "So get the best that your budget can buy."
There's no point in simply just spending to the max without qualifying
what benefits it will bring in the first place. As I mentioned, the
benefits of more memory (and disk cache) is simply not linear. After
some point, simply adding more memory/disk will provide nothing in
return. If you have a diverse range of users where they are less
likely to require the same objects, you will reach that
nothing-in-return point even sooner.
Received on Sat Jun 15 2013 - 05:01:47 MDT