On 18/03/11 10:05, da...@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, da...@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
