Collapsed forwarding question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Collapsed forwarding question

BARRY J BLUMENFELD
Hello,
     We are using squid-2.6STABLE13 on linux for our unusual application.  We have a situation where
a hundred clients might request a fairly large object from squid more-or-less simultaneously.  We are trying collapsed forwarding to reduce the load on the origin server.  The problem is that some of the clients timeout while waiting for a reply.  The question is how does squid schedule the response to multiple connections?  Does it send a little bit of the object to each connection in a round-robin?Does it wait until the entire object is received before beginning the reply to those that are sharing the connection?  If so, is there any chance that it could be changed to start sharing as soon as the header is received?  There are no timeouts with collapsed forwarding off.

Thanks very much.
Barry
Reply | Threaded
Open this post in threaded view
|

Re: Collapsed forwarding question

Henrik Nordström
tis 2007-05-15 klockan 19:55 -0400 skrev BARRY J BLUMENFELD:
> The question is how does squid schedule the response to multiple
> connections?

It waits for the HTTP headers. Then if the object could be cached it
sends it to all clients while beinge retreived from the origin.

If the object could not be cached the first client gets this response,
and the other clients gets forwarded as separate requests.

> There are no timeouts with collapsed forwarding off.

Could it be that the timeouts is related to range requests? Not entirely
sure what collapsed_forwarding will do on range requests..

Regards
Henrik

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Collapsed forwarding question

Henrik Nordström
ons 2007-05-16 klockan 21:12 -0400 skrev BARRY J BLUMENFELD:
> No, we are not using range requests.
> So the squid should forward what it has to each connection, one after the other, as data comes in from the origin server?

Yes.

But it might get a little upset on very large responses if the first
client stalls, not reading the response. Not entirely sure if that's
handled well.

Regards
Henrik

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Collapsed forwarding question

BARRY J BLUMENFELD
Hello,
   We have made some progress.  We actually have two squids in parallel with DNS load balancing.
We had been running them as each others parents so that we could try to reduce the load on the backend server.   If we stop cache_peering, then the timeouts go away.  The relevant lines
for server1 are
    cache_peer server2.domain    parent   3128  3130
    acl SERVER src server1.domain server2.domain
    cache_peer_access server2.domain allow !SERVER

We configure the two as parents rather than as siblings, because, for an expired file, squid won't
bother querying a sibling.  So, at this point, we have a choice between collapsed_forwarding or
the cache_peer relationship.  Is there some better configuration setup we can try?

Thanks very much.
Barry
----- Original Message -----
From: Henrik Nordstrom <[hidden email]>
Date: Thursday, May 17, 2007 5:09 pm
Subject: Re: [squid-users] Collapsed forwarding question
To: BARRY J BLUMENFELD <[hidden email]>
Cc: Squid Users <[hidden email]>


> ons 2007-05-16 klockan 21:12 -0400 skrev BARRY J BLUMENFELD:
>  > No, we are not using range requests.
>  > So the squid should forward what it has to each connection, one
> after the other, as data comes in from the origin server?
>  
>  Yes.
>  
>  But it might get a little upset on very large responses if the first
>  client stalls, not reading the response. Not entirely sure if that's
>  handled well.
>  
>  Regards
>  Henrik
Reply | Threaded
Open this post in threaded view
|

Re: Collapsed forwarding question

Henrik Nordström
tor 2007-05-17 klockan 19:33 -0400 skrev BARRY J BLUMENFELD:
> Hello,
>    We have made some progress.  We actually have two squids in parallel with DNS load balancing.
> We had been running them as each others parents so that we could try to reduce the load on the backend server.   If we stop cache_peering, then the timeouts go away.  The relevant lines
> for server1 are
>     cache_peer server2.domain    parent   3128  3130
>     acl SERVER src server1.domain server2.domain
>     cache_peer_access server2.domain allow !SERVER

That way might end up with request loops then depending on timing of the
requests to two servers, and due to collapsed_forwarding the loop isn't
noticed.

Explanation: Two different requests for the same URL hits both servers
at approximately the same time. They both forward to the other and
deadlock with the two waiting on each other and none talking to the
origin..

> We configure the two as parents rather than as siblings, because, for an expired file, squid won't
> bother querying a sibling.  So, at this point, we have a choice between collapsed_forwarding or
> the cache_peer relationship.  Is there some better configuration setup we can try?

You could look into removing the sibling restriction from cache
validations. But be warned that it's there to stop cache bouncing where
old content in some conditions ends up bouncing between the servers.

Deploying a second layer of proxies is one solution.

Implementing intra-array CARP routing another. Currently only
inter-array CARP routing exists in Squid.

The end goal of the above two solutions is to ensure that for each given
URL there is always one designated proxy which is responsible for
fetching this URL from the origin server, and that data then propagates
out to the other from there. This way request routing and freshness is
fully deterministic.

Regards
Henrik

signature.asc (316 bytes) Download Attachment