Understanding NGINX's fastcgi_read_timeout

Viewed 2761

I'm "fine-tuning" a PHP web application served via NGINX with php-fpm as FastCGI sever.

From the documentation:

fastcgi_read_timeout

Defines a timeout for reading a response from the FastCGI server.

so far so good. But then...

The timeout is set only between two successive read operations, not for the transmission of the whole response.

The PHP script start sending data (nginx reads) then pauses (computing time) then send more data (nginx reads). If the pause lasts longer than the specified time the connection is dropped.

Is it the correct interpretation or am I missing something?

What does exaclty means "between two read operations" ?

Isn't the "whole response" duration that matters? And what parameter sets a limit for that?

1 Answers

The PHP script start sending data (nginx reads) then pauses (computing time) then send more data (nginx reads). If the pause lasts longer than the specified time the connection is dropped.

I think it's a correct interpretation.
And it's easy to test: write a simple php-script with some sleeps between echos and flushes. (Can't do it myself at the moment).

Isn't the "whole response" duration that matters?

To me personally, the fastcgi_read_timeout approach is more appealing:

  • If you server is under a high load with fixed timeout it will definitely fail from time to time. Users will be irritated, they'll refresh... send another request... And you server chokes even more, never fulfilling any of user's requests.
  • But if, no matter the load, you server shows it is still alive and trying hard to fulfill client's requests then it's up to them to decide to wait or to abort. Much better!

And what parameter sets a limit for that?

max_execution_time in php.ini or

fastcgi_param PHP_VALUE "max_execution_time=1000";

in your NGINX config

Related