Re: duplicate StoreEntries?

On Thursday 17 April 2003 18.30, Chengdu Huang wrote:

> When Squid sees a client request asking for a URL, if there's no
> existing StoreEntry available for this URL, it creates a new
> StoreEntry which starts with a private key and nobody else can see
> this StoreEntry. After the reply comes back from the origin server,
> the StoreEntry might be set to public key depends on whether the
> reply is cachable. But again, before that, no other request can see
> this StoreEntry.

Correct.

> Those are my understandings of the code and here comes the
> question: what if before the key is set to public Squid gets a lot
> of other client requests all of which ask for the same URL?

Any reqests received from the point where the StoreEntry have been
assigned a public key will find this StoreEntry and use the data
stored within it.

If there is multiple requests received before there is a public
StoreEntry for the URL then multiple StoreEntry objects is created.
The last one which gets assigned a public key stays in the cache.

The reason to why Squid behaves like this is request latency. Before
the reply headers have been received Squid does not know if the reply
may be cached or not, and it is not very often Squid received
parallell requests for the same URL in real life. In most cases where
this happens in real life there is a server/networking problem
delaying upstream processing of the first request or the reply is
dynamically generated and not cacheable, meaning that if Squid would
wait for the reply then in the majority of cases the only effect
would be that processing of the second/third requests for the URL is
significantly delayed.

In accelerator setups the situation may be very different, but so far
nobody have been motivated enough to introduce a tuning know to allow
accelerator setups to tune this behaviour of Squid.

Regards
Henrik
Received on Fri Apr 18 2003 - 01:52:01 MDT