Re: [squid-users] external_acl children...

From: Henrik Nordstrom <henrik_at_henriknordstrom.net>
Date: Thu, 21 Aug 2008 00:37:45 +0200

On ons, 2008-08-20 at 09:49 -0700, John Doe wrote:

> Ok, thx.
> I first thought squid had buffers (waiting queues) for helpers because of the "up to 1 pending requests queued" and "queue overload" messages.
> What do they mean?

It has buffers. The buffer is as large as there is children. So if you
have 1 children then 2 requests may be processed (one currently
processed, one queued)

Generally one should use the concurrency=<some high number>
children=<some small number> when making your own helper. You only need
a lot of children if your helper may block for extended periods of time
for example performing DNS lookups..

> Also, what are the "negative lookups" of negative_ttl of external_acl_type?
> First I thought they were the ERR results, but apparently not.

It is.

> I tried some "stress" tests (ab -n 10000 -c 20 http://path/to/image.gif) and get aroung 770req/s.
> It seems low for a Xeon 3.40 Ghz with 3GB of RAM (cache_mem 2GB) and 200GB cache_dir on a RAID1 (with the system)... no?

Very low indeed.

> I tried to comment as much params as I could in the conf (removed siblings, store logs, etc) but it does not change anything...
> What's a normal number of reqs/s for such config?

A simple TCP_MEM_HIT test on Pentium 3 some years ago was several
thousand requests/s. Proxied requests is significantly less.

> Also, while the url_rewrite logs lines would appear 10000 times, I only get like 14 external_acl logs...
> First 2 lines, then like 1 every seconds
> When I do x wgets, I get x external_acl logs.
> I have ttl=0, so it should not be a cache issue.

Not sure ttl=0 really is "no cache". It may well be cached for 0 seconds
truncated downwards (integer math using whole seconds).. The point of
the external acl interface is to get cacheability and request merging.
If you don't want these then use the url rewriter interface.

Regards
Henrik

Received on Wed Aug 20 2008 - 22:37:52 MDT

This archive was generated by hypermail 2.2.0 : Thu Aug 21 2008 - 12:00:03 MDT