Bhavesh, could you please quote properly.

>> "httpClientNoticeRequest.  Note however that what makes this tricky is
>> that on a miss we will go through this function twice -- the first
>> time we'll get a miss or a revalidation, the second time a hit.

>> Note also that a hit does not mean that we will get all of the data."

> Could you please elaborate  on the above on how I can go about getting
> realistic stats for the cache?

The main caching logic is in the function httpClientNoticeRequest.
This function does the following:

  (1) Check whether the request has already been marked as being in
      error (see httpClientNoticeError).  If so, we send an error
      reply to the client and we're done.

  (2) Check whether it's a side-effecting (POST or PUT) request; if
      so, we call object->request straight away to schedule sending
      the request.

  (3) Check whether we can serve the request from cache (haveData = 1).

  (4) Determine whether we need to revalidate (validate = 1).

  (5) Serve the data from the cache if possible.

  (6) Otherwise, schedule a server-side fetch and go to sleep on
      a condition variable.

Now consider what happens on a cache miss.  Client says ``GET foo'',
we go through case (6) above, and fall asleep.  Then, later, when the
server has started replying, we go through httpClientGetHandler.

However, httpClientGetHandler may, under some conditions, call
httpClientNoticeRequest.  This will notably happen if the in-cache
data is expires, and when the client is pipelining.

So you cannot just count the number of times we go through
httpClientNoticeRequest, you must also check whether this is the first
or second time through it.  The flag novalidate should help here.

What's more, Polipo caches partial data; hence, it is possible for
a single client request to be satisfied partially from the cache and
partially from the server.  I would recommend treating such partial
hits as misses, as this will give statistics similar to the ones that
Squid gives.

Stefan Monnier:

> Maybe a stat that would make sense is comparing byte-count (and
> packet-count?) on each sides.

Yep, that's a good idea (byte count, that is -- you won't get packet
count unless you hook into the transport layer).  However, if
I understand Bhavesh right, he wants to have statistics that resemble
those of Squid.

                                        Juliusz

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Polipo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/polipo-users

Reply via email to