I have a PHP script that does some data processing. The time that it takes to the script to finish all the job is based on the user input. It's not unusual that it takes 5-15 minutes of processing.

On apache everything works fine, however on Nginx the connection just got closed. When the processing time is low, everything is fine. The problem comes on the long requests...

There is no error in none of the logs. I suspect that the browser closes the connection.

I sniffed the headers, and it appears that Nginx doesn't send any response, until the processing is done. Not a single header.

I tried sending headers from the script, but it seems that nginx caches them all.

Afterwards, I disabled PHP output buffering and enabled implicit flush. I disabled gzip compression and zlib. I minimize FAST_CGI_BUFFERS to the minimum allowed, which is: fastcgi_buffers 2 1k; fastcgi_buffer_size 1k; fastcgi_busy_buffers_size 1k; fastcgi_max_temp_file_size 0;

Still, it refuse to send headers...

So just to prove my case, in one of the loops inside the code, I did a var_export to one of the objects...

BOOM!!! - it works...

Can anyone think of a more elegant solution?


Update August 19th

Something crazy is going on. After I tried debugging it for 2 full days without any luck, I tried something I should've done before.

I tried this config on Linode, and it works!!!

So probably the problem is somewhere in Ubuntu config... Have no idea where to look.


You have to play around with the timeouts of the server. Nginx is closing the connection because it believes that it's finished and silently closes the connection. There are four directives that come to my mind which could do the trick for you.

client_body_timeout (default is 65)
client_header_timeout (default is 65)
keepalive_timeout (default is 65)
send_timeout (default is 65)

All values are in seconds. Please report back if any of these did the trick (personally I believe it should be keep alive, but please test).

  • Thanks. But I have all this timeouts set... I think that Nginx is not the one that closes the connection. I think it's the web browser... Because Nginx's error logs are clean... – tounano Aug 18 '12 at 0:53
  • Have you tried increasing them? Yes, the browser closes after 65 seconds (this is true for IE and FF, others might close earlier or later) and that's exactly the keepalive_timeout which is set by default in nginx. The best solution for you would be to use AJAX for this and display a progress to the user. – Fleshgrinder Aug 18 '12 at 0:57
  • Thanks. I found a combination that work, but really bad. So it's sort of progress :) When I set both keepalive_timeout and send_timeout on 1200s, it shows me the result after 11 minutes. The php itself runs for 180-200 seconds. I guess that the rest is being ran on Idle... Any ideas why? Thanks – tounano Aug 18 '12 at 11:59
  • That's really weird. May I also suggest like @Stef Pause that you post your configs in your question. Otherwise it's really, really hard to help here. – Fleshgrinder Aug 20 '12 at 22:44

@Fleshgrinder's on the right track, I think, but there are specific fastcgi timeout parameters that you should check, as listed in nginx's fastcgi_module documentation. In particular, I'd look at increasing fastcgi_read_timeout from its default of 60s to 1000 and see if that sorts it.

  • Thank, however I'kk say to I said to @flashgeinder My timeouts are good. If it was a fastcgi_read_timeout, we'd see it in the log and we'd get Response Headers from nginx. In my case, there is no error. It's just the response headers are being buffered.... and then the BROWSER closes the connection. – tounano Aug 18 '12 at 6:37
  • Can you add your nginx (plus any includes) and PHP configs to your question, please? It's hard to see the full picture otherwise. Have you tried adding headers to the particular nginx location that pass to PHP_FPM, such as add_header X-Accel-Buffering no? What's fastcgi_ignore_client_abort set to? – Stef Pause Aug 18 '12 at 13:24
  • Hey, Thanks. It appears that the problem is on the Linux side... – tounano Aug 19 '12 at 10:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.