Re: [squid-users] Squid Hardware requirements.

With YMMV in mind, I get different mileage:

On Fri, Jun 14, 2013 at 7:41 PM, Marcus Kool
<marcus.kool_at_urlfilterdb.com> wrote:
> and if your network pipe has sufficient capacity, also fetching
> an object again from the internet is can be faster than fetching from disk.

Your network may be fast, but it doesn't imply a fast path between you
and the origin server. In other words, it depends on other factors
than just your own network pipe.

> - more expensive (disks + battery-backed I/O controller)

Expensive disks/battery-backed are over-kill. More/adequate spindles
should do the job just as well. Why do you need a battery-backed
controller? Squid is not a transaction-based system - if you lose the
cache, tough, do "squid -z" and start again.

> - Squid uses more memory to index the disk cache (14 MB memory per GB disk
> cache)

My memory allocation is only about 20-30% of that (formula), and
paging/swapping metrics doesn't indicate there is a problem. General
formulas may not always apply.

> unless a redundant hot-swap RAID array is used, less downtime.

Older versions has a problem if a cache_dir fails, I think. Has this
changed with later versions, or in the pipeline to change, anyone?

> One can also redistribute budget:
> - use the budget of the disk system to max out memory.

The benefits of memory will plateau pretty quickly. Unless one
regularly has a whole bunch of users wanting to access the same pages
within a relatively short time, the benefit from more memory has its
limits. Max-out could easily become wastage.

> - put as much memory as possible.

Disagree - see above. It depends.

> - carefully size the disk cache; not too large since Squid keeps the index

Agree. If your hit-ratios don't increase, there's not much point in
having larger cache_dir's. But I wouldn't go as far as "carefully".
You just need enough or more, just not too much more.

> - if using a disk cache, use fast disks and a very good caching I/O
> controller to get maximum disk performance

Up to a point only, as mentioned above. Local disk I/O may be fast,
but it doesn't mean your internet access will be as well. Which means
you end up spending money on hardware that does not deliver actual
results.

As Amos said, get the fastest per-core GHz you can find, number of
cores not important. And have enough disk spindles.
Received on Fri Jun 14 2013 - 13:53:33 MDT