Re: [squid-users] opening of flood gates

On Fri, 2002-11-22 at 06:29, Jens Vagelpohl wrote:
> i looked a little at the mailing list archives but could not really
> find anything about the behavior we are seeing.
>
> we use squid as a reverse proxy in front of some web servers to cache
> results and reduce the load on the origin servers. some of the requests
> to the origin servers take a long time, and it seems that when squid is
> waiting to receive an answer for a particular page from the origin
> server all additional requests squid receives for that same page are
> directly sent to the origin server as well, which tends to bog down the
> origin server completely in our case...
>
> is there a way to make squid not directly forward these new requests to
> the origin server while it is already waiting for that same page?

Ermm, there is a lot of logic in squid to handle such a style of thing.
There used to be (and probably still is) a single if test which if you
reverse or comment part of it out, will cause those requests to be
joined. ( I don't recall where offhand, sorry). I'm also not sure from
memory whether it needs the http headers to be recieved for it to join,
but IIRC it *does* need the headers recieved. This is because until we
see the headers we can't tell if the response is flagged as sharable or
not.

Note that joining is not always safe from a HTTP point of view, which is
why we don't, until we *know* the request is safe to join to. In the
reverse proxy scenario, you have more control over the server behaviour,
and thus can enable that. As I said though, I suspect that it still
won't do quite what you are looking for. Its definately something that
some hacking could allow, but you would want to be very precise about
where it was allowed to happen, otherwise nasty http races will occur..

Rob