Re: [squid-users] performance drop moving from 3.0 to 3.1?

On 18/03/11 10:05, david_at_lang.hm wrote:
> ping, any comments on this?
>
> excluding acl's, cache_peer* and *direct config entries (~500 lines
> worth, all IP, servername, port# or url_regex based)

Tested with or without all those ACLs? They do make a difference to
speed, even the fast ACL tests.

>
> the remaining config file is
>
> http_port 8000
> icp_port 0
> visible_hostname gromit1
> cache_effective_user proxy
> cache_effective_group proxy
> appaend_domain .invalid.server.name

NP: "append_domain" ?

> pid_filename /var/run/squid.pid
> cache_dir null /tmp
> client_db off
> cache_access_log syslog squid

NP: Squid needs a syslog format spec. Same as you would use in the
syslog config. "syslog:daemon.1" or some such. And the directive name
is now just "access_log"

> cache_log /var/log/squid/cache.log
> cache_store_log none
> coredump_dir none
> no_cache deny all

NP: directive name is just "cache".

>
> what would I need to do to track down the cause of this performance drop?

That same question is the topic of some discussion(s) in squid-dev.
http://www.squid-cache.org/mail-archive/squid-dev/201101/0106.html

There is about 30% CPU load increase as well as the raw speed drop. That
30% is IMO what you are measuring. When topping out the CPU it obviously
can't handle many more RPS.

  * adding IPv6 support
   - copying, checking version and text'ifying larger IPs a lot is SLOW.
   - looking up DNS twice (AAAA and A) is relatively slower.
   - failover when connecting via a network with broken IPv6
connectivity results slower server connect times. any transit network
blocking ICMPv6 breaks *your* IP failover.

  * adding async support
   - more overheads on every single async step / call.
   - some events being queued for immediate execution holding up others.
   - lots of legacy code calling handlers needlessly on errors. Under
async this is a full event scheduling cycle/delay on each such call.

  * HTTP/1.1 (is not explicitly mentioned by Alex, but...)
   - lot more logics checking whether HTTP/1.1 features are to be used.
   - chunking feature is a slow encoding, performed on all
unknown-length requests to servers. Which form a large % of POST. Gets a
bit worse in 3.HEAD where its also performed on many GET replies.

Some are offset by optimizations and fixes later, so its not cut-n-dry.
Work is underway by Alex and Co. to identify the problems. We all work
on ways to grab performance back when found. Most of these optimizations
won't make it into 3.1, but 3.2 hopes to be better.

That thread is a bit outdated now. Contact Alex for some commit points
that still need to be performance tested, and how to do that testing.

Amos

>
> David Lang
>
>
> On Sun, 13 Mar 2011, david_at_lang.hm wrote:
>
>> I'm using squid in a pure access control mode (all caching disabled)
>> and am looking to move from 3.0 to 3.1, but when I'm doing lab tests
>> with it I am seeing a significant performance drop.
>>
>> when doing a simple small request test (using ab to hammer the proxy
>> retrieving 40 byte pages) 3.0 is reaching 4200 request/sec while under
>> the exact same conditions 3.1.11 is barely topping 1400 requests/sec.
>>
>> if I request larger pages (100K), 3.0 does ~650 requests/sec while 3.1
>> only manages ~480 requests/sec. going up to 1M pagess, 3.0 does 90
>> requests/sec while 3.1 does 60
>>
>> this is with identical configuration except that 3.0 has the null disk
>> cache driver configured while 3.1 has that line commented out.
>>
>> In all of these cases, squid is maxing out at 100% of the single core
>> it has available to it.
>>
>> David Lang
>>
Received on Fri Mar 18 2011 - 02:34:49 MDT