Nginx – atomic deployments with Nginx and PHP FPM

deploymentnginxphp-fpmphp5

I'm trying to get atomic deployments, I don't want to lose/drop any requests.

I deploy the code using Capistrano, classic situation were you have a 'current' dir that is a symlink to
the latest release in the 'release' folder.
I'm using Nginx, PHP 5.5 FPM with Opcache.
Following the idea of just using $realpath_root in Nginx I'm expecting that a simple nginx reload would suffice, but it's not.
With nginx reload it seems that I'm not losing any requests but php-fpm is still executing the code from the previous old dir.
If I do a 'php-fpm reload' then php fpm is reading from the new dir but I can still see that I'm losing some requests:

'recv() failed (104: Connection reset by peer) while reading response header from upstream'

The question is: should I reload PHP FPM or not?

From what I understand nginx is passing the path to php-fpm and from the nginx debug log I can see that the path passed is the right one but php-fpm still executes the old one.

2014/09/23 17:13:22 [debug] 26234#0: *1742 http script var: "/shop/www/htdocs/current/web"
2014/09/23 17:13:22 [debug] 26234#0: *1742 posix_memalign: 00000000010517A0:4096 @16
2014/09/23 17:13:22 [debug] 26234#0: *1742 http script copy: "SCRIPT_FILENAME"
2014/09/23 17:13:22 [debug] 26234#0: *1742 http script var: "/shop/www/htdocs/ive/releases/20140923124417/web"
2014/09/23 17:13:22 [debug] 26234#0: *1742 http script var: "/app.php"
2014/09/23 17:13:22 [debug] 26234#0: *1742 fastcgi param: "SCRIPT_FILENAME: /shop/www/htdocs/live/releases/20140923124417/web/app.php"
2014/09/23 17:13:22 [debug] 26234#0: *1742 http script copy: "DOCUMENT_ROOT"
2014/09/23 17:13:22 [debug] 26234#0: *1742 http script var: "/shop/www/htdocs/live/releases/20140923124417/web"
2014/09/23 17:13:22 [debug] 26234#0: *1742 fastcgi param: "DOCUMENT_ROOT: /shop/www/htdocs/live/releases/20140923124417/web"
2014/09/23 17:13:22 [debug] 26234#0: *1742 http script copy: "APPLICATION_ENV"

What am I missing? thanks

Best Answer

It sounds like you have made changes to the default OPcache configuration.

The defaults are:

opcache.validate_timestamps = 1
opcache.revalidate_freq = 2

This specifies whether and for how long OPcache should wait before checking to see if a file on disk has changed. In this case, yes, and after two seconds.

First, try re-enabling this option, as it sounds like you have turned it off.

Related Topic