With YMMV in mind, I get different mileage: On Fri, Jun 14, 2013 at 7:41 PM, Marcus Kool <marcus.kool@xxxxxxxxxxxxxxx> 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.