Re: [squid-users] is this possible?

Thanks for the hint.

I'm using the collapsed_forwarding and quick_abort_* options and seem to
be having some luck. There are, however, oddities. It seems that
sometimes additional requests are still being forwarded to the
underlying web server. Other than "squidclient mgr:active_requests" are
there any other ways of monitoring the status of subsequent requests
which should be deferred to wait for the original?

thanks

JR

Amos Jeffries wrote:
> botemout_at_gmail.com wrote:
>> Greetings
>>
>> We have an unusual problem.
>>
>> One of our clients uses a program to request map data from one of our
>> servers. We have a reverse proxy squid cache in front of it. Client
>> hits squid, which gets data from web server and serves it back to client.
>>
>> Here's the problem. Client uses broken code that times out before the
>> map data is finished processing. It then resubmits the request.
>> It'll do this about 10 times before finally dying. Each new request,
>> however, also times out so nothing is done and lots of time is wasted
>> (as single one of these requests might take 5 minutes to return).
>>
>> So, I've proposed that we use url_rewrite_program to pass the request
>> to a program which makes the request to the webserver (and DOESN'T
>> timeout!), it then returns the same URL but by this time the object is
>> in the cache and the original squid process returns the data from the
>> cache.
>>
>> Is this craziness? Anyone do anything like this before? Or is there
>> some better, easier way to handle this?
>
> There are a couple of things worth trying:
>
> * quick_abort_min/quick_abort_max. Make sure they are set to allow
> squid to finish the first request even after client is gone. This will
> at least let the retries have shorted generation times.
>
> * If you are using Squid-2 collapsed_forwarding is your very best
> friend. Cupled wit the above it will ensure only the first request gets
> to the backend and later ones get served whatever data it came up with.
>
>
> * Personally I'd also stick a 5-10 minute minimum cache time on all
> results if the backend takes 5 minutes to generate.
>
> Short caching times still lets you update relatively quickly, but you
> want to have them stick around just long enough to catch followups and
> if all clients suddenly got this terrible software they won't kill your
> service with retries.
>
> Amos
Received on Tue Jun 02 2009 - 18:56:10 MDT