<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-06-22 13:33 GMT+02:00 Geoff Simmons <span dir="ltr"><<a href="mailto:geoff@uplex.de" target="_blank">geoff@uplex.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On 06/22/2016 01:04 PM, Luca Toscano wrote:<br>
><br>
> Nice test that I found in the Varnish codebase (meant to trigger a<br>
> VSL timeout):<br>
><br>
> <a href="https://github.com/varnishcache/varnish-cache/blob/4.1/bin/varnishtest/tests/r01762.vtc#L29" rel="noreferrer" target="_blank">https://github.com/varnishcache/varnish-cache/blob/4.1/bin/varnishtest/tests/r01762.vtc#L29</a><br>
<br>
</span>That's<br>
><br>
probably your best bet. Otherwise, triggering VSL timeouts can<br>
be tricky, because there are a lot of things going on that are hard to<br>
control.<br>
<br>
You said that your PHP script sleeps before emitting "HTML" -- if<br>
that's what you really meant, then your response probably sent<br>
headers, and then went to sleep before sending the body. In that case,<br>
there won't be a first_byte_timeout -- the timeout is until any part<br>
of the response arrives, including headers.<br></blockquote><div><br></div><div>Sorry, what I meant to say was the whole request (headers included).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
You could try the same trick but with a large between_bytes_timeout.<br>
Or find a way to send nothing at all, not even headers, until the<br>
first_byte_timeout elapses.<br>
<br>
I have in fact seen VSL timeouts in production as a result of<br>
long-running responses, but if you want to reliably reproduce it that<br>
way, try making the time differences very large -- say timeouts=150s,<br>
and have your backend delay the response for five minutes.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>Thanks to the Varnish devs on IRC I found a way to repro and also an explanation. Varnish workers write log tags to a buffer, that gets flushed to shmlog when it is full. A busy server might flush the buffer often, and it can happen that a Begin tag gets flushed to shmlog without the rest (including the End tag, for example, due to long backend processing). The VSL API will check in the Dispatch function that a Begin tag is not delayed more than what specified by the -T parameter (or by the default 120 seconds). This behavior is of course a bit difficult to reproduce, but the -p debug=+syncvsl helps forcing Varnish to make VSL synchronous.</div><div><br></div><div>Thanks a lot for all the help!</div><div><br></div><div>Luca</div></div><br></div></div>