NGINX : Keep alive requests to static content ok - Keep alive requests to php-fpm requests hang until keepalive_timeout is reached

FYI, the initial question I have posted is here, no need to read it as I was way off initially:

https://serverfault.com/questions/427296/nginx-php-fpm-strange-issue-when-trying-to-display-images-via-php-gd-readf

I was able to track it down to keep alives.

Please bare in mind, when i speak of keep alives in this question, I mean USER <-> NGINX keep alives. NOT NGINX <-> BACKEND (php-fpm in this case).

Scenario three is the problem scenario, I have just included one and two to be clear that I have done all the required testing.

So, here is exactly what happens:

Scenario one [ keep alive enabled ]:

A) Request to static content [ non fastcgi based requerst, simple file system access ] is made

B) Keep alives are on

C) Content is sent no problem, 100% of the time

Scenario two [ keep alive disabled ]:

A) Request to dynamic php-fpm based content

B) Keep alives are off

C) Content is sent no problem, 100% of the time

Scenario three [ keep alives enabled ]:

A) Request to dynamic php-fpm based content

B) Keep alives are on

C) Content is sent, but the browser will hang in "loading state" until keepalive_timeout is reached. This state looks different accross browsers. For example, chrome will display the content, but will "spin" at the top browser. After keepalive_timeout is reached, spining stops and the request shows up in red in the debugger even tho the content is actually displayed fine. In IE the page remains blank until keep alive timeout is reached, and then the content shows up. Looking at the IE developer tools one sees the content takes "keepalive_timeout" seconds in "blue", which in IE developer tools case is "receiving".

Stumped completly, tried reverting the conf to the most basic form and this still happens.

To summerize, there appears to be some sort of network related issue (tcp/ip stack?) when serving php-fpm based results WITH keep alives enabled.

Any ideas?

Solution 1:

There's likely one or two things at fault here.

https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_keep_conn

syntax:     fastcgi_keep_conn on | off;
default:    

fastcgi_keep_conn off;

context:    http, server, location

By default, a FastCGI server will close a connection right after sending the response. When set to the value on, nginx will instruct a FastCGI server to keep connections open. This in particular is necessary for keepalive connections to FastCGI servers to function.

or

https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

upstream default {
  server 10.0.0.1:80;
  keepalive 1024 single;
}

Enables keep-alive connections for the upstream.

Num specifies the max number of connections to keep open before, if the max is reached it will close the least recently used connections.

Single treats everything as a single host. With this flag connections to different backends are treated as equal.

Both are valid for Nginx 1.1.4 or newer