Search squid archive

Re: Architecture for scaling delivery of large static files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 16 Jul 2009 09:22:25 +1000, Jamie Tufnell <diesql@xxxxxxxxxxxxxx>
wrote:
> Thank you both for your responses, good to hear I might be on the right
> track!
> 
> Amos wrote:
>> Just note that for MB or so scale files in memory Squid-2 is a snail,
and
>> Squid-3 does not yet provide collapsed forwarding.
> 
> We are talking files up-to-1GB in size here.  Taking that into
> consideration, would you still recommend this architecture?

Yes, the architecture itself is sound.

This just alters the tuning recommendations. Normally we say faster squid
are due to more memory and RAM-caching stuff.

For you with MB->GB files in Squid-2 that changes to faster Squid due to
limiting RAM-cache to small files, with lots of large fast disks. Squid is
limited to a few million (2^24) cache _objects_ so up the that amount of GB
files can be cached on disk for one Squid. The more disks you can be
reading from in parallel the better, 3 disks is apparently optimal for
general use, but you can test that and see what suits with your objects and
load.

Amos


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux