[squid-users] Debugging slow access

Steve Hill steve at opendium.com
Tue Jan 6 12:15:48 UTC 2015


On 05.01.15 18:15, Amos Jeffries wrote:

> Can you try making the constructor at the top of src/HelperReply.cc
> look like this and see if it resolves the problem?
>
> HelperReply::HelperReply(char *buf, size_t len) :
>          result(HelperReply::Unknown),
>          notes(),
>          whichServer(NULL)
> {
>      assert(notes.empty());
>      parse(buf,len);
> }

This didn't help I'm afraid.

Some further debugging so far today:
The notes in HelperReply are indeed empty when the token is added.

However, Auth::Negotiate::UserRequest::HandleReply() appends the reply 
notes to auth_user_request.  It fetches a cached user record from 
proxy_auth_username_cache and then calls absorb() to merge 
auth_user_request with the cached user record.  This ends up adding the 
new Negotiate token into the cached record.  This keeps happening for 
each new request and the cached user record gradually accumulates tokens.

As far as I can see, tokens are only ever read from the helper's reply 
notes, not the user's notes, so maybe the tokens never need to be 
appended to auth_user_request in the first place?

Alternatively, A->absorb(B) could be altered to remove any notes from A 
that have the same keys as B's notes, before using appendNewOnly() to 
merge them?

-- 
  - Steve Hill
    Technical Director
    Opendium Limited     http://www.opendium.com

Direct contacts:
    Instant messager: xmpp:steve at opendium.com
    Email:            steve at opendium.com
    Phone:            sip:steve at opendium.com

Sales / enquiries contacts:
    Email:            sales at opendium.com
    Phone:            +44-1792-824568 / sip:sales at opendium.com

Support contacts:
    Email:            support at opendium.com
    Phone:            +44-1792-825748 / sip:support at opendium.com


More information about the squid-users mailing list