Re: Multiple request blocking

On 6 Jul 2001, at 4:12, Henrik Nordstrom <hno@hem.passagen.se> wrote:
>
> It is about the ability for new clients to join a already running server
> request for the same object.
>
> Three options exists
>
> a) From start (wanted by Eric, as it takes time before the reply headers
> are received as required by 'b')
> b) Allowed once it is known that the object should be cachable (current
> model)
> c) Never

 I think its wrong to introduce as general solution that squid joins
 requests before headers are got. In most cases CGI is private thing,
 static content takes very little time and resources to service, so
 requesting multiple copies from source is the safe and right thing.
 In general, we can't know if CGI is private until we see the headers,
 so for general case we should remain as current, imo.

 Yet there are cases when such optimistic joining can help abit, for
 eg. clients who start ftp:// fetch of a large file after some announce
 can happen to start fetches within 30sec window. (this does happen, btw,
 and suprisingly often) Clients end up fetching same file multiple times,
 wasting both bandwidth and adding time.

 Ideally, we could join requests based on URL first, then when headers
 are received, if cachable, continue joined, if uncachable specified,
 unjoin requests and start individual sessions. But that may be not
 worth added complexity.

On 30 Jun 2001, at 1:05, Henrik Nordstrom <hno@hem.passagen.se> wrote:

> Seems to be a problem with refreshes when the object is already cached
> but expired.
>
> Not sure what to do about it. Not sure what to do about it, or if it is
> of general interest to Squid in normal use outside this specific
> benchmark.

 I think handling this would be interesting for many sites, perhaps
 especially in accelerator modes. This can protect backend servers from
 being overloaded by some popular object that is cachable enough time but
 takes alot of time/cpu to generate/refresh. After expiring, spike of
 load is pushed onto backend servers and clients see high latency.

 What I'd propose is to service stale object to clients if it is not too
 stale, and at the same time initiate refresh.

 Define that it is a cache_hit if object is expired+refreshing and it
 expired not too long ago. So clients would receive cached object if
 it is cachable even if it is stale. Probably stale_hit time should be
 dynamic, either based on time it took to fetch object initially, or
 something similar to lm_factor (it doesn't very much make sense to rush
 with refreshing if object has been fresh for weeks).
 I guess there should also be some minimum stale_hit time: 1 sec or few.
 This way objects that are requested more than once/sec can be serviced
 as fresh for the duration of refresh. I think this reaches Eric's goal
 and is more generally useful.

> Fellow Squid developers: What is your opinion on how/if/when we should
> chain concurrent requests for the same object before even the status is
> known?

 b) or even c) if that has other bonuses. Or join on URL and unjoin later
 if required, but only if that is worth added complexity.

> Eric Barsness wrote:
> >
> > Thanks for the reply. I should have been more clear in my description. We
> > are trying to do option A, as you describe below.
> >
> > What the TPC-W benchmark specifies is that certain dynamic web pages can be
> > cached for up to 30 seconds each. There are approximately 48 of these
> > pages and they each get requested around 12 times a second in Unisys'
> > current TPC-W results (and that rate will probably increase greatly in the
> > near future). These dynamic pages may take up to a second or so to be
> > generated, so we could see many requests for the same page in the very
> > short period of time it takes to refresh the page in the cache. In the
> > case of the benchmark, we know that the page will always cacheable, and
> > therefore only a single request would be enough.
> >
> > After setting neighbors_do_private_keys to 0 and recompiling, we still see
> > multiple requests getting through on a cache miss. It also seems strange
> > to me that we see a SWAPOUT before we see a RELEASE in the store log in
> > some cases. Here is an example:
> >
> > Store Log
> >
> > 993063160.404 RELEASE 00000503 200 993063129 993063129 993063159 text/html
> > 7838/7838 GET http://127.0.0.1:7784/w.pgm?3&SUBJECT_STRING=REFERENCE&IFRAME
> > =
> > 993063160.404 SWAPOUT 00000526 200 993063159 993063160 993063189 text/html
> > 7819/7819 GET http://127.0.0.1:7784/w.pgm?3&SUBJECT_STRING=REFERENCE&IFRAME
> > =

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Fri Jul 06 2001 - 02:49:17 MDT