Question

I’m working on a PHP application behind a Varnish Cache. The sys admins would like to keep the first_byte_timeout value relatively low. However in one particular corner of the application I need a long running PHP process (a big data file gets uploaded and it takes a minute or two process it all).

The problem is that the first_byte_timeout gets hit well before the process is finished. Naturally the process still finishes but Varnish returns a 503 because no data has been sent. To the user it looks like something has gone wrong, and if there’s any feed back about things actually going wrong the user will never see it.

What should I do?

Worse case senario is I do a big refactor so the process can run in a separate processes behind the scenes but that’s going to be a lot of work.

Is it possible to send some dummy data via PHP so Varnish keeps the connection open?

There’s a complication to this solution though, at the end of long running process PHP does a redirect (to another page where it gives feed back to the user on how things went). With all the things I’ve tried, that redirect will fail if php has already sent the HTTP headers, so what ever dummy data I send might have to be dummy headers? Or something that won’t make PHP think the headers have already been sent.

Is there some way to setup a special exceptions to Varnish, so just on this one screen it will wait longer then the global first_byte_timeout?

(I’m new to Varnish so if there’s some critical piece of information I’ve leaving out, please let me know. Thanks.)

Answer 1

Take a quick-fix and save yourself engineering time: modify the first_byte_timeout setting for this request only in Varnish. E.g.:

sub vcl_miss {
  if ( req.url ~ "your/special/url" ) {
    set bereq.first_byte_timeout = 5m;
  }
}