backend web node keep-alive option

info+varnish at info+varnish at
Thu Nov 16 11:57:13 UTC 2017

Am 12.11.2017 um 15:42 schrieb Guillaume Quintard <guillaume at>:
> On Sat, Nov 11, 2017 at 9:48 PM, <info+varnish at> wrote:
>> I was observing a behavior of a PHP script on one backend server that got executed/requested
>> twice (but not by the client/browser).
>> The plain script just processes data and only outputs a response until its done. The observed
>> behavior is; when first_byte_timeout passes but the script is still processing data, the varnish
>> node answers with an 503 and the script gets listed twice in the webserver process list. So, either
>> it gets requested on this event again or the TCP connection close triggers an new execution. In any
>> case its a bug and because of missing resources to dive into a more deeper analyses, I just disabled
>> the enabled keep-alive option of the backend webserver (apache/httpd). The results: it helped to avoid
>> a further execution of the script.
>> The question is: What is the best practice to configure the backend webservers? Do you keep the
>> keep-alive option enabled or not?

Hi Guillaume,

> Why not just up the timeout value?

Sure, the mentioned script(task) is for my taste conceptually bad designed and I could 
convinced the developer to run some kind of a task queue. 

The primary focus of my question targeted the keep-alive part but while here: does it 
have negative implications having e.g. a 2h first_byte_timeout configuration? Is this

> Usually, you want to keep the keep-alive as it's much more efficient.

Also sure, but my big picture while asking was - heavy traffic. While the costs of the TCP handshake 
persists, the scenario is at the backend of the architecture where high bandwidth links exits. 
So, i can imagine that in heavy traffic scenarios, the keep-alive feature would lead to more 
memory consumption, more file descriptors and be more prone to denial of service attacks. 

Any experiences out there?     

More information about the varnish-misc mailing list