On Sun, 7 Mar 2004, James MacLean wrote:
> 6MBytes. 620+ sites. Thousands of client computers :).
Approx how many of those client computers are actively surfing at a given
point in time?
I think you should split this load on multiple Squids. You already
indicated you have a SMP machine, in such case running more than one Squid
on the same server is possible.
> Certainly this goes up, and it is mostly on 1 CPU as I understand would be
> expected. Load gets over 2, but was staying under 3.
One Squid process can use only 1 CPU.
System "load" is pretty much worthless as load indication on a server.
> > * Number of active filedescriptors
>
> That climbs fast but does peek.
Where is the peak and normal values for your setup?
> The pipe is full regardless of having Squid up, but without squid the
> client response time is much more favorable. Maybe 10,000 requests spread
> over many clients works better over the pipe than all those requests from
> only Squid?
Depends a little on the QoS queue type. Some advanced QoS settings may
give a penalty if there is a single IP using a lot. Most don't.
> Ah. Ok, so with us we are using SCSI raided. And with that it sounds like
> one diskd line should satisfy?
You would get better disk performance if your split the raid in separate
drives.
But if you run without caching enabled the cache_dir is not used so in the
no cache configuration it does not matter what you have as cache_dir..
> It appears that requests not being serviced fast enough by the uplink is
> aiding in this congestion. I wonder if running multiple Squids on the one
> PC would be more effective than one with so many open FDs. I'm guessing
> that what might be sped up in FDs would get lost using independant
> caches?
If you see that your Squid hovers above 2000-3000 active filedescriptors
then splitting the load on multiple Squids will defenitely help, or wait
for the epoll support in squid-3 to stabilise which should allow Squid to
scale quite independent of the number of active filedescriptors.
Regards
Henrik
Received on Sun Mar 07 2004 - 10:23:40 MST
This archive was generated by hypermail pre-2.1.9 : Thu Apr 01 2004 - 12:00:01 MST