Re: [squid-users] cache hardware specification

Steve Snyder wrote:

> On Saturday 19 January 2002 12:59 pm, Robin Stevens wrote:
>
>>On Wed, Jan 16, 2002 at 09:17:11AM +0100, Chemolli Francesco (USI)
>>
> wrote:
>
>>>My box (single P2/450) with 6 9GB 7.2Krpm U2SCSI drives does 30
>>>Gb/day, with the CPU constantly over 85% during peak hours.
>>>
>>>If this is the kind of load you're having, get an AthlonXP with 2-3
>>>gigs of RAM, and lots of 10krpm spindles. I figure that with such a
>>>configuration you could double my traffic, maybe triple it.
>>>
>>Double certainly, tripling probably depends on traffic patterns. On
>>our systems (PIII-1000, 1.5GB RAM, 7x18GB 10krpm U160 drives), I've
>>pushed 10 million requests and 60GB per day through them at peak
>>request rates of around 220/sec, though this was close to the limit. I
>>suspect we might do a little better if most requests were not sent to a
>>parent cache, and that our newer systems with faster CPU, 15krpm disk
>>and more RAM could do a little better. I believe around 300
>>requests/sec is about the fastest any single instance of a stable squid
>>release has been pushed.
>>
>
> I notice that you (and the original poster) make no mention of network
> interfaces. Are you using gigabit Ethernet or will a 100Mbps interface
> do the job with this much traffic?

Hehehe... That's funny! ;-)

Squid cannot push past 100Mbps from a single machine under any
circumstances that I know of. You don't need Gigabit...if you need that
much throughput to support the traffic you need to support, then you'll
need multiple boxes and a load balancing method.

 
> Also, how many SCSI controllers are you using for these 7 10kpm drives?
> Assuming a STR of 52MB/sec (which is about what a Atlas 10K III gets on
> the outer cylinders), it would only take 3 drives to saturate a UW160
> interface. Even a UW320 controller would be inadequate to support the 7
> drives you've mentioned.

A single controller will work fine. Squid also doesn't really require
high throughput from the controller either--it requires low latency,
which is where multiple fast disks come in. However, just for your
reference, I've found that the law of diminishing returns begins to
become overwhelming with about 3-4 10k disks. So going to 5 disks gains
almost nothing, and going to 6 gains even less. This applies to async
i/o...DiskD behaves somewhat differently as it isn't as CPU bound as
async i/o (but is slower even with more disks).

Saturating the controller will /never/ be a problem--Squid is only going
to be pulling a few MB/sec from all disks combined. (Disks do not
handle lots of little tiny reads and writes very well.)

-- 
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support