Deployment 原子部署:在Nginx重新加载之后,PHP-FPM仍然指向旧的webroot

Deployment 原子部署:在Nginx重新加载之后,PHP-FPM仍然指向旧的webroot,deployment,nginx,php,Deployment,Nginx,Php,我正在尝试使用Nginx和带有Opcache的PHP5.5-FPM进行原子部署 这个想法就是在nginx.conf中更改webroot,然后运行 nginx重新加载 我所期望的是,Nginx将等待当前请求结束,然后重新加载自己,将新的webroot路径传递给PHP-FPM,但它不起作用:PHP-FPM仍在从旧目录加载PHP文件。 为了不获取符号链接(/prod/current),而是获取真实路径,我在Ngnix中使用了(未记录的)$realpath\u root。 此处记录了该技术: 调试Ngi

我正在尝试使用Nginx和带有Opcache的PHP5.5-FPM进行原子部署

这个想法就是在nginx.conf中更改webroot,然后运行

nginx重新加载

我所期望的是,Nginx将等待当前请求结束,然后重新加载自己,将新的webroot路径传递给PHP-FPM,但它不起作用:PHP-FPM仍在从旧目录加载PHP文件。 为了不获取符号链接(/prod/current),而是获取真实路径,我在Ngnix中使用了(未记录的)$realpath\u root。 此处记录了该技术: 调试Nginx我可以清楚地看到它正在通过新的(真实的)路径

为了让它工作,我必须运行一个

php fpm重新加载

但我失去了一些请求

'从上游读取响应头时recv()失败(104:对等方重置连接)'

这是我正在使用的nginx文件:

server {
  listen              26023;

  server_name         prod.example.com;

  client_max_body_size  20m;
  client_header_timeout 1200;
  client_body_timeout   1200;
  send_timeout          1200;
  keepalive_timeout     1200;


  access_log  /var/logs/prod/nginx/prod.access.log main;
  error_log   /var/logs/prod/nginx/prod.error.log;

  set $root_location /var/www/htdocs/prod/current/web;
  root $root_location;

  try_files   $uri $uri/ /index.php?$args;
  index       index.php;


  location ~ \.php$ {
    fastcgi_pass    unix:/var/run/php5-fpm/prod.sock;
    fastcgi_index   index.php;

    include         fastcgi_params;

    fastcgi_connect_timeout 1200;
    fastcgi_send_timeout    1200;
    fastcgi_read_timeout    1200;
    fastcgi_ignore_client_abort on;

    fastcgi_param   SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
    fastcgi_param   DOCUMENT_ROOT   $realpath_root;

    fastcgi_param   APPLICATION_ENV live;
    fastcgi_param   HTTPS           $thttps;
  }

}
这是池配置:

:~$ curl http://127.0.0.1/fpm_status_prod
pool:                 prod
process manager:      dynamic
start time:           23/Sep/2014:22:42:34 +0400
start since:          1672
accepted conn:        446
listen queue:         0
max listen queue:     0
listen queue len:     0
idle processes:       49
active processes:     1
total processes:      50
max active processes: 2
max children reached: 0
slow requests:        0

有什么建议吗?

我解决了这个问题,我也在为类加载器使用APC,但它没有被清除。

为什么要使用APC和OpCache?它增加了什么功能,缩短了可测量的时间?我很感兴趣,因为缓存中存在过时的东西一直是我的主要问题,但收获甚微。composer建议将APCu与OpCache结合使用:
:~$ curl http://127.0.0.1/fpm_status_prod
pool:                 prod
process manager:      dynamic
start time:           23/Sep/2014:22:42:34 +0400
start since:          1672
accepted conn:        446
listen queue:         0
max listen queue:     0
listen queue len:     0
idle processes:       49
active processes:     1
total processes:      50
max active processes: 2
max children reached: 0
slow requests:        0