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@xxxxxxxxxxxxx>: > 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 >
