Re: [squid-users] squid 3.2.0.5 smp scaling issues

sorry for the delay. I got a chance to do some more testing (slightly
different environment on the apache server, so these numbers are a
little lower for the same versions than the last ones I posted)

results when requesting short html page

squid 3.0.STABLE12 4000 requests/sec
squid 3.1.11 1500 requests/sec
squid 3.1.12 1530 requests/sec
squid 3.2.0.5 1 worker 1300 requests/sec
squid 3.2.0.5 2 workers 2050 requests/sec
squid 3.2.0.5 3 workers 2700 requests/sec
squid 3.2.0.5 4 workers 2950 requests/sec
squid 3.2.0.5 5 workers 2900 requests/sec
squid 3.2.0.5 6 workers 2530 requests/sec
squid 3.2.0.6 1 worker 1400 requests/sec
squid 3.2.0.6 2 workers 2050 requests/sec
squid 3.2.0.6 3 workers 2730 requests/sec
squid 3.2.0.6 4 workers 2950 requests/sec
squid 3.2.0.6 5 workers 2830 requests/sec
squid 3.2.0.6 6 workers 2530 requests/sec
squid 3.2.0.6 7 workers 2160 requests/sec instead of all processes being at 100% several were at 99%
squid 3.2.0.6 8 workers 1950 requests/sec instead of all processes being at 100% some were as low as 92%

so the new versions are really about the same

moving to large requests cut these numbers by about 1/3, but the squid
processes were not maxing out the CPU

one issue I saw, I had to reduce the number of concurrent connections or I
would have requests time out (3.2 vs earlier versions), on 3.2 I had to
have -c on ab at ~100-150 where I could go significantly higher on 3.1 and
3.0

David Lang

On Mon, 4 Apr 2011, david_at_lang.hm wrote:

> On Mon, 4 Apr 2011, Amos Jeffries wrote:
>
>> On 03/04/11 12:52, david_at_lang.hm wrote:
>>> still no response from anyone.
>>>
>>> Is there any interest in investigating this issue? or should I just
>>> write off squid for future use due to it's performance degrading?
>>
>> It is a very ambiguous issue..
>> * We have your report with some nice rate benchmarks indicating regression
>> * We have two others saying me-too with less details
>> * We have an independent report indicating that 3.1 is faster than 2.7.
>> With benchmarks to prove it.
>> * We have several independent reports indicating that 3.2 is faster than
>> 3.1. One like yours with benchmark proof.
>> * We have someone responding to your report saying the CPU type affects
>> things in a large way (likely due to SMP using CPU-level features)
>> * We have our own internal testing which shows also a mix of results with
>> the variance being dependent on which component of Squid is tested.
>>
>> Your test in particular is testing both the large object pass-thru (proxy
>> only) capacity and the parser CPU ceiling.
>>
>> Could you try your test on 3.2.0.6 and 3.1.12 please? They both now have a
>> server-facing buffer change which should directly affect your test results
>> in a good way.
>
> thanks for the response, part of my frustration was just not hearing anything
> back.
>
> I'll do the tests on the new version shortly (hopefully on monday)
>
> if there are other tests that people would like me to perform on the hardware
> I have available, please let me know.
>
> right now I am just testing proxy/ACL with no caching, but I am testing four
> traffic types
>
> 1. small static files
> 2. large static files
> 3. small dynamic files (returning the exact same data as 1, but only after a
> fixed delay)
> 4. large dynamic files.
>
> while I see a dramatic difference in the performance on the different tests,
> so far the ratios between the different versions have been consistant across
> all four scenerios.
>
> David Lang
>
Received on Fri Apr 08 2011 - 02:32:25 MDT