Yes, we are trying to convince our customer to go on last stable
version released for the 4 upstream Squid, and schedule 2.6 migration
for 1500 others but we need a good reason (or proof) and it's seems
that 3.1 doesn't change anything in our case (I mean, visible
change)... or maybe, I didn't see it.
Maybe should I try 2.7 instead of 3.1 ? it seems 'act-as-origin'
option you told me is not available and could improve the bandwith
management.
In any cas, thank you very much for your assistance!
Best regards,
Romain
2011/7/4 Amos Jeffries <squid3_at_treenet.co.nz>:
> On 04/07/11 20:40, Romain wrote:
>>
>> Ok, so even if I have about 150 000 clients making arround 20 "4xx"
>> requests / day on 1500 Squid servers which relay its on 4 Squid
>> servers and then on 1 Apache, is it not a big deal for the last one?
>> (it's almost equal to 34 requests / sec)
>
> 34 req/sec? no that is not a big deal. Apache at the bottom of the hierarchy
> is the slowest link, with modern hardware it has several hundred req/sec
> capacity on just about any load.
>
> Still I can see that its annoying.
>
> NP: So far as I can tell from here you have taken the Squid-2.6 config as
> far as it can go. The requirement of not having different versions of Squid
> active at once is creating the main blocker problem. A migration starting
> with even just those bottom 4 Squid would enable some of the needed
> configurations to take place.
> IMHO 2.7 should be the next direction taken. It is a drop-in replacement
> for 2.6 (minimal adjustments to the existing setup) and provides the
> "act-as-origin" on http_port lines and many of the caching improvements.
>
> Cheers, and good luck.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE9 or 3.1.14
> Beta testers wanted for 3.2.0.9
>
Received on Mon Jul 04 2011 - 10:15:52 MDT
This archive was generated by hypermail 2.2.0 : Mon Jul 04 2011 - 12:00:02 MDT