[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    Cache-Control question
From:       Adrian Chadd <adrian () creative ! net ! au>
Date:       2006-09-29 16:17:49
Message-ID: 20060929161749.GP3671 () skywalker ! creative ! net ! au
[Download RAW message or body]

Hi,

I've been profiling the HTTP code in squid-3 and I've found that ~1.5% of
CPU time is spent in HttpHeader::getCc(). Now, this does something rather
evil:

* HttpHeader::parse() doesn't pay any special attention to Cache-Control
  headers; it just happily treats them like any other header.
* walks the entire header array looking for Cache-Control headers;
* creates a string (blank)
* parses them right there and then;
* parser function returns the temporary string, which is copied-on-return.
* populates a HttpHdrCc class 
* deletes the temporary string!
* returns the HttpHdrCc class.

Now, if they change, putCc() will find the Cache-Control header(s), delete
them and replace with a freshly packed string representation!

What I'd like to do as an experiment is this:

* Parse the Cache-Control header(s) during HttpHeader::parse(), so
  this won't cost us any more than checking them once (and saves us
  if somehow the same request has Cache-Control stuff checked >once..)
* If someone calls getCc() then the pre-parsed data is given;
* If someone calls putCc() then it over-rides the parsed CC info
  (ie, some flags and some integer values);
* during HttpHeader::packInto() (ie, when the request is being written
  to disk or being written to a client, -then- generate the string
  representation.

Also, a lot of time is spent in HttpMsg::httpMsgParseStep() (13%),
HttpHeaderParse() (10% of total runtime, overlapping with ParseStep),
parseHttpRequest() is 6.5%, HttpHeaderClean() (3.8%). Argh.



Adrian

[prev in list] [next in list] [prev in thread] [next in thread]