On Fri, 18 Mar 2011, Amos Jeffries wrote:
On 18/03/11 10:05, david@xxxxxxx 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.
I would expect them to, but my issue isn't with the overall speed, but
rather with the relative speed of the two versions when running the same
ruleset. It appears that 3.1 is significantly slower under these
conditions than 3.0.
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" ?
typo on my end, due to oddities in how I access my personal mail from work
I can't do a cut-n-paste so I retyped this.
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".
thanks, I'll correct it
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
thanks, I'll go through this tomorrow.
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.
3.1 was compiled without IPv6 support (I'll report all the config options
in the morning)
* 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.
possible
* 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.
since I was blasting with ab, i believe that it was doing HTTP/1.0 about
as simple as you can get.
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.
any feel for how 3.2 is doing (how close is it to no longer being 'release
candidate', which for some strange reason scares management types ;-)
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.
will do.
David Lang
Amos
David Lang
On Sun, 13 Mar 2011, david@xxxxxxx 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
