ons 2003-02-12 klockan 20.07 skrev Duane Wessels:

> CARP
> 
>       squid-2.5 CARP configuration/implementation is different
>       than squid-2.x head.  For example, 2.5 uses 'carp-load-factor='
>       but 2.6 uses 'weight='

The CARP update is probably a bit too big for 2.5.. it is a major
rewrite of the CARP implementation to hopefully be somewhat closer to
the (expired) I-D and easier to use.

  http://devel.squid-cache.org/old_projects.html#carp

The patch should quite easily to 2.5 I think, but there probably have
been some bugfixes in the main tree after this got merged so some more
work is required.. probably better to copy the implementation from
Squid-3 if this is to be done.

Not sure if anyone is actually using the Squid "CARP".. and the name
"CARP" is somewhat of a misnomer as it is only using a small fraction of
the CARP specification in slight odd manners..

> annoying bug in Number of fields per header distribution
> 
>       Bug counts 0 fields per header when calling httpHeaderClean()
>       for new headers, before they are even used:
> 
>       id       #flds      count   %total
>        1           0   13363088    49.75
>        2           1      18216     0.07
>        3           2        979     0.00


A fix for this is welcome.


> ICP/HTCP treated differently.  In some places, ICP and HTCP are
> treated as equivalent.  For example, in "Peer Selection Algorithm"
> stats, "ICP" also counts HTCP.  But in other places, HTCP is not
> also counted.  For example:
> 
>       - "Number of ICP messages received"
>       - "Number of ICP messages sent"
>       - "Cache Client List" stats
>       - "List of Unknown sites sending ICP messages"
>       - ...cacheClientIcpRequests.A.B.C.D in SNMP

Note: HTCP is disabled by default in 2.5..


> syscalls.disk.unlinks confusion
> 
>       The counter is incremented for:
>       - unlinks performed by main squid process
>       - unlinks performed by DISKD processes
>       The counter is not incremented for:
>       - unlinks performed by AUFS threads
>       - unlinks performed by the unlinkd process

Fixing this could be acceptable for 2.5 I think.

> cachemgr "Cache Utilization" page
> 
>       this page gives too much detail to be useful to most
>       users, and the name sucks.  it should be removed.

You are welcome to do whatever you like with this page for Squid-3, but
I think it should stay in 2.5.

> in storeCheckCachable(), no.release_request always 0
> 
>       because storeReleaseRequest() clears ENTRY_CACHABLE, and
>       such objects get counted as no.not_entry_cachable instead

Not sure I understand this one without digging into the code.. is it
about some "cachemgr" statistics field?

> FETCHES under "Cache Client List"
> 
>       the FETCHES number counts requests forwarded for any reason
>       (ICP, HTCP, Cache Digests, default parent).
>       Following the FETCHES count is a percentage, based on the
>       number of ICP replies.  This percentage may be larger
>       than 100.  Just remove the percentage, or only count
>       fetches due to ICP?

Remove the percentage, or perhaps make it a percentage of all cache
misses.

> DISKD Q1, Q2 confusion
> 
>       documentation does not match the implementation.  Tried to
>       convince henrik of this before, but failed.

You can try again. I am not strict about this, and as I am not using
diskd I can only speak based on my experiences from aufs with similar
queue limit values..

> Redirectors recieve URIs with whitespace
> 
>       if "uri_whitespace allow" then redirectors may receive
>       URIs with whitespace and not properly parse them.

This should be fixed I think.

> IpcacheStats and FqdncacheStats
> 
>       I removed some members of IpcacheStats and FqdncacheStats
>       in squid-2 HEAD, but did not MFC to squid-2.5 (or squid-3)

Everything committed in Squid-2 HEAD still gets merged into Squid-3
after a while (as said in the notice about Squid-2.6 killed).

Is there actually any reason to make this change in 2.5? Considering
that 2.5 is a STABLE branch which should not be used for further
developments.. i.e. does it change anything except for internal code
cleanup?

-- 
Henrik Nordstrom <[EMAIL PROTECTED]>
MARA Systems AB, Sweden

Reply via email to