Re: 2.5.STABLE2 around the corner

From: Henrik Nordstrom <hno@dont-contact.us>
Date: 12 Feb 2003 20:41:26 +0100

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 <hno@squid-cache.org>
MARA Systems AB, Sweden
Received on Wed Feb 12 2003 - 12:41:34 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:14 MST