varnish-misc Digest, Vol 97, Issue 16

[Geoffrey Simmons]

> On Apr 17, 2014, at 11:51 PM, L Cruzero <lcruzero at gmail.com> wrote:
> 
> Geoff, Et al, thanks for your replies, i should have mentioned, that the 503's are not unique to POST requests, they are also happening more frequent within 
> (very rarely == on 0.0038% of requests), on a GETs.

But in your example with the GET, the FetchError is connection reset reading the backend response:

>   174 FetchError   c http first read error: -1 104 (Connection reset by peer)


That's pretty straightforward -- your backend broke off the connection before Varnish could read the response. Nothing wrong with the client connection that time.

But your previous "FetchError: backend write error", which in my experience has almost always really been an error on the client connection, is always about request bodies, and hence always about POST requests.

Understanding your "503's" will mean that you'll have to look at the details of the FetchError in each individual case, they're all different.

> i've been thinking of testing within my config something along this FOUND vcl code snipped as a possible solution. 
> sub vcl_fetch {
>            if (obj.status == 500 || obj.status == 503 || obj.status ==
>         504) {
>                    restart;
>             }
Well, that's retrying on those error codes, which is more of a workaround than a solution.

Retries are not a bad idea (why not just obj.status >= 500 ?), but they don't solve whatever it is that's causing the problem, they just give you another chance when there is a problem. And if the trouble keeps happening, then you'll hit the restart maximum and end up with 503 anyway.


HTH,
Geoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20140418/c7933266/attachment.html>