More info here;
I'm looking at a dump from the wire, and it doesn't make any sense;
e.g,. something logged as taking 79ms takes less than .5ms from GET to
last ack.
The interesting thing is that this seems related to client persistent
connections; if I turn client pconns off, it goes back to 0 or nearby.
I'm also using http11; I tried turning that off, but my clients aren't
sending Connection: keep-alive, so there aren't any pconns in use in
this case.
On 23/10/2008, at 5:49 AM, Henrik Nordstrom wrote:
(15.49.47) mnot: the other issue I see is TCP_MEM_HITs taking a few
hundred milliseconds, even on a lightly loaded box, with responses
smaller than the write buffer. (and no, hno, they're not collpased ;)
If there is Vary+ETag involved then those MAY be partial cache misses.
There is a slight grey zone there an If-None-Match query for finding
which object to respond with results in TCP_(MEM_)HIT if the 304
indicated object is a hit.
Could also be delays due to acl lookups or url rewriters.
--
Mark Nottingham [EMAIL PROTECTED]
